dispatcher

最近2年一直能看到 Net Core的介绍，看到支持WPF和Winform引起了兴趣，写简单Demo运行看效果和了解部署。 现在准备把项目正式迁移到.Net Core, 就先用了一个比较单一的项目试试，编译很大部分很顺利通过，没有什么需要注意， 也就没有什么印象，一运行不得了各种报错。 也没有去看具体原因，先直接解决让程序运行正常。 一、BeginInvoke public static void DoWork(Action action, int millisecond = 500) { new Action(() => { System.Threading.Thread.Sleep(millisecond); Dispatcher.CurrentDispatcher.BeginInvoke(action); }).BeginInvoke(null, null); } 以前的写法运行就报错，System.PlatformNotSupportedException:“Operation is not supported on this platform.” 改后代码: public static void DoWork(Action action, int millisecond = 500) { Task.Run(() => { Task.Delay(millisecond);

最近2年一直能看到 Net Core的介绍，看到支持WPF和Winform引起了兴趣，写简单Demo运行看效果和了解部署。 现在准备把项目正式迁移到.Net Core, 就先用了一个比较单一的项目试试，编译很大部分很顺利通过，没有什么需要注意， 也就没有什么印象，一运行不得了各种报错。 也没有去看具体原因，先直接解决让程序运行正常。 一、BeginInvoke public static void DoWork(Action action, int millisecond = 500) { new Action(() => { System.Threading.Thread.Sleep(millisecond); Dispatcher.CurrentDispatcher.BeginInvoke(action); }).BeginInvoke(null, null); } 以前的写法运行就报错，System.PlatformNotSupportedException:“Operation is not supported on this platform.” 改后代码: public static void DoWork(Action action, int millisecond = 500) { Task.Run(() => { Task.Delay(millisecond);

[TOC] Client提交任务 执行模式有：本地、远程Standalone等，下面只介绍yarn模式。 Yarn模式 ： Job模式是每个flink job 单独在yarn上声明一个flink集群 Session模式会在集群中维护flink master，即一个yarn application master，运行多个job。 Job模式（重点是加上-m yarn-cluster）：./flink run -m yarn-cluster -d -yst -yqu flinkqu -yst -yn 4 -ys 2 -c flinkdemoclass flinkdemo.jar args1 args2 ... Session模式： 先启动session：./bin/yarn-session.sh 后提交job：./bin/flink run ./path/to/job.jar detached模式：上面job模式的-d代表detached，这种情况下flink yarn client将会只提交任务到集群然后关闭自己。这样就不能从 env.execute() 中获得 accumulator results 或 exceptions。而在session模式下使用，则无法使用flink停止yarn session，需用yarn工具来停止 yarn application -kill

2003 年，老兵哥初到中兴开始研究生实习，Spring 就是那年诞生的，2004 年 3 月发布了 1.0 版本，到现在已经超过 15 年了。从单体式分层架构到云原生微服务架构，它稳坐在 JAVA 应用框架的头把交椅上从未被撼动，它给我们带来了巨大的价值，不仅可以降低开发难度，同时还可以提升开发效率。但时间这把杀猪刀不仅改变了老兵哥，也同样没放过 Spring，我们都变得越来越强大了。 在 Spring Boot / Spring Cloud 面世之前，它已经演进了 5 个大版本和无数小版本，功能和生态都变得越来越丰富。但对初涉 Spring 的小伙伴们来说，这就不太公平了，不像老兵哥可以伴着它慢慢成长，现在这套技术栈已经很庞大了，短时间内吃透这个巨无霸，有没有捷径可走呢？有，就像当年 DOS 操作系统一张软盘就装下了，总共才几 MB，现在动不动就几十上百 GB，但操作系统内核是很小的，其原理机制就是教科书上那些，一生二、二生三、三生万物，唯有掌握这些稳定不变的“一二三”，即核心原理机制（例如：IOC \ AOP \ ORM 等），那我们的学习就可以达到事半功倍了。 就像我们购买了毛坯房，入住前必须装修一番，其中水、电、气、网等管路的布线必须先行，不同管路有不同的走法，有的走地板，有的走墙面，等管路都铺设妥当了才能铺地砖、吊天花、刷墙贴纸等。作为业主，如果你不知道这些管路的走线

2003 年，老兵哥初到中兴开始研究生实习，Spring 就是那年诞生的，2004 年 3 月发布了 1.0 版本，到现在已经超过 15 年了。从单体式分层架构到云原生微服务架构，它稳坐在 JAVA 应用框架的头把交椅上从未被撼动，它给我们带来了巨大的价值，不仅可以降低开发难度，同时还可以提升开发效率。但时间这把杀猪刀不仅改变了老兵哥，也同样没放过 Spring，我们都变得越来越强大了。 在 Spring Boot / Spring Cloud 面世之前，它已经演进了 5 个大版本和无数小版本，功能和生态都变得越来越丰富。但对初涉 Spring 的小伙伴们来说，这就不太公平了，不像老兵哥可以伴着它慢慢成长，现在这套技术栈已经很庞大了，短时间内吃透这个巨无霸，有没有捷径可走呢？有，就像当年 DOS 操作系统一张软盘就装下了，总共才几 MB，现在动不动就几十上百 GB，但操作系统内核是很小的，其原理机制就是教科书上那些，一生二、二生三、三生万物，唯有掌握这些稳定不变的“一二三”，即核心原理机制（例如：IOC \ AOP \ ORM 等），那我们的学习就可以达到事半功倍了。 就像我们购买了毛坯房，入住前必须装修一番，其中水、电、气、网等管路的布线必须先行，不同管路有不同的走法，有的走地板，有的走墙面，等管路都铺设妥当了才能铺地砖、吊天花、刷墙贴纸等。作为业主，如果你不知道这些管路的走线

前情提要： Spark RPC框架源码分析（一）简述 一. Spark RPC概述 上一篇我们已经说明了Spark RPC框架的一个简单例子，Spark RPC相关的两个编程模型，Actor模型和Reactor模型以及一些常用的类。这一篇我们还是用上一篇的例子，从代码的角度讲述Spark RPC的运行时序，从而揭露Spark RPC框架的运行原理。我们主要将分成两部分来讲，分别从服务端的角度和客户端的角度深度解析。 不过源码解析部分都是比较枯燥的，Spark RPC这里也是一样，其中很多东西都是绕来绕去，墙裂建议使用上一篇中介绍到的那个Spark RPC项目，下载下来并运行，通过断点的方式来一步一步看，结合本篇文章，你应该会有更大的收获。 PS：所用spark版本：spark2.1.0 二. Spark RPC服务端 我们将以上一篇HelloworldServer为线索，深入到Spark RPC框架内部的源码中，来看看启动一个服务时都做了些什么。 因为代码部分都是比较绕的，每个类也经常会搞不清楚，我在介绍一个方法的源码时，通常都会将类名也一并写出来，这样应该会更加清晰一些。 HelloworldServer{ ...... def main(args: Array[String]): Unit = { //val host = args(0) val host =

在 spark 源码分析之五 -- Spark内置RPC机制剖析之一创建NettyRpcEnv 中，剖析了NettyRpcEnv的创建过程。 Dispatcher、NettyStreamManager、TransportContext、TransportClientFactory、TransportServer、Outbox、Inbox等等基础的知识都已经在前面剖析过了。 可以参照如下文章做进一步了解。 spark 源码分析之五 -- Spark内置RPC机制剖析之一创建NettyRpcEnv spark 源码分析之六 -- Spark内置RPC机制剖析之二Dispatcher和Inbox、Outbox剖析 spark 源码分析之七 -- Spark内置RPC机制剖析之三RpcEndPoint和RpcEndPointRef剖析 spark 源码分析之八 -- Spark内置RPC机制剖析之四TransportContext和TransportClientFactory剖析 spark 源码分析之九 -- Spark内置RPC机制剖析之五StreamManager和RpcHandler spark 源码分析之十 -- Spark内置RPC机制剖析之六TransportResponseHandler

问题背景 NIO是面向缓冲区进行通信的，不是面向流的。我们都知道，既然是缓冲区，那它一定存在一个固定大小。这样一来通常会遇到两个问题： 消息粘包 ：当缓冲区足够大，由于网络不稳定种种原因，可能会有多条消息从通道读入缓冲区，此时如果无法分清数据包之间的界限，就会导致粘包问题； 消息不完整 ：若消息没有接收完，缓冲区就被填满了，会导致从缓冲区取出的消息不完整，即半包的现象。 介绍这个问题之前，务必要提一下我代码整体架构。 代码参见GitHub仓库 https://github.com/CuriousLei/smyl-im 在这个项目中，我的NIO核心库设计思路流程图如下所示 介绍： 服务端为每一个连接上的客户端建立一个Connector对象，为其提供IO服务； ioArgs对象内部实例域引用了缓冲区buffer，作为直接与channel进行数据交互的缓冲区； 两个线程池，分别操控ioArgs进行读和写操作； connector与ioArgs关系：（1）输入，线程池处理读事件，数据写入ioArgs，并回调给connector；（2）输出，connector将数据写入ioArgs，将ioArgs传入Runnable对象，供线程池处理； 两个selector线程，分别监听channel的读和写事件。事件就绪，则触发线程池工作。 思路 光这样实现，必然会有粘包、半包问题

java nio消息半包、粘包解决方案 问题背景 NIO是面向缓冲区进行通信的，不是面向流的。我们都知道，既然是缓冲区，那它一定存在一个固定大小。这样一来通常会遇到两个问题： 消息粘包：当缓冲区足够大，由于网络不稳定种种原因，可能会有多条消息从通道读入缓冲区，此时如果无法分清数据包之间的界限，就会导致粘包问题； 消息不完整：若消息没有接收完，缓冲区就被填满了，会导致从缓冲区取出的消息不完整，即半包的现象。 介绍这个问题之前，务必要提一下我代码整体架构。 代码参见GitHub仓库 https://github.com/CuriousLei/smyl-im 在这个项目中，我的NIO核心库设计思路流程图如下所示 介绍： 服务端为每一个连接上的客户端建立一个Connector对象，为其提供IO服务； ioArgs对象内部实例域引用了缓冲区buffer，作为直接与channel进行数据交互的缓冲区； 两个线程池，分别操控ioArgs进行读和写操作； connector与ioArgs关系：（1）输入，线程池处理读事件，数据写入ioArgs，并回调给connector；（2）输出，connector将数据写入ioArgs，将ioArgs传入Runnable对象，供线程池处理； 两个selector线程，分别监听channel的读和写事件。事件就绪，则触发线程池工作。 思路 光这样实现

1. Struts2的结果视图 Struts2的每一个atcion都可以有不同的结果返回方式，在result中返回结果类型type属性有11种返回结果类型的方式。最主要最常用的有redirect、redirectAction、dispather三种跳转方式。 具体跳转方式的type类型可以在struts-default.xml中查找到，具体如下： < package name ="struts-default" abstract ="true" > < result-types > < result-type name ="chain" class ="com.opensymphony.xwork2.ActionChainResult" /> < result-type name ="dispatcher" class ="org.apache.struts2.dispatcher.ServletDispatcherResult" default ="true" /> < result-type name ="freemarker" class ="org.apache.struts2.views.freemarker.FreemarkerResult" /> < result-type name ="httpheader" class ="org.apache.struts2