Mobility

问题描述主要还是通过一个例子加深一下对java多线程里wait,notify的理解，因此写了一个例子，三个线程分别输出A,B,C三个字母，控制这三个线程的执行顺序，从而实现ABCABCABC..这样的输出。 方案一：synchronized + wait/notify这个问题主要还是需要设计一下锁的策略，这里只是提供了一种方式： 每个线程占用两把锁，分别代表自己(self)和前一个线程（prev）, 三个线程的持有锁情况如下表所示： 线程号prev锁self锁 A c a B a b C b c A 首先启动，持有ac, 运行后先释放a, b可以执行。 线程run方法代码如下： <span class="hljs-keyword">public</span> <span class="hljs-keyword">void</span> <span class="hljs-title">run</span>(...

问题过程我司需要接收很多外部数据，数据源的形式很多，ibmmq, activemq, redis pubsub, 等等都有。为了将这些数据接到内部amq/kafka，之前运行了一大批进程，管理起来十分复杂，因此最近用apache-camel对这些进程作了整合。 上线几个小时之后，kafka磁盘空间开始报警。初步断定是这次上线导致的。 排查流程主要还是对kafka不熟悉，只是能用而已，因此排查过程走了不少弯路。 由于camel本身文档很不完善，一开始配置参数时也主要靠看源码+猜，所以首先怀疑配置的压缩参数compressionCodec=gzip是否无效。 因此进行了一次简单的测试（别问我为什么一开始不测）。建了一个单分区的测试topic, 然后分别使用gzip和none模式发送相同的数据，观察kafka的log file文件大小变化趋势。发现压缩确实是有效的。 因此又跟直接使用kafka api作了对比，发现差别非常大，即使是压缩之后，使用camel-kafka占用的空间也比使用api大数倍。然后去查了两边源码，发现最底层的代码是完全一致的，所以还是怀疑某些参...

Java 的 Integer 缓存机制是一个高频面试题，也是日常开发中容易踩坑的地方。理解它，首先从一个看起来违反直觉的实验开始。 诡异的 1281234567Integer a = 148;Integer b = 148;System.out.println(a == b); // false —— 符合预期，两个不同对象Integer c = 48;Integer d = 48;System.out.println(c == d); // true —— 等等，为什么？ 同一个 == 比较，148 返回 false，48 返回 true。原因就在于 Integer 缓存。 IntegerCache 源码分析当 Java 编译 Integer a = 48 时，实际上执行的是： 1Integer a = Integer.valueOf(48); 来看 Integer.valueOf() 的源码（JDK 8）： 12345public static Integer valueOf(int i) { if (i >= IntegerCache.lo...

storm的周边生态非常丰富，与kafka,activemq,hdfs,hbase等的交互都有现成的工具包可以使用。大部分工具，包括今天介绍的这几个，在jstorm中也可以完全正常的使用。 storm-jms实现了与activemq等jms实现的交互。 这里主要介绍JmsSpout。由于storm中发送队列数据与普通java程序没有任何区别，专门封装一个bolt显得有些多此一举。 https://github.com/ptgoetz/storm-jms 包中自带了使用spring方式加载队列配置。 使用示例1234567891011121314JmsProvider jmsQueueProvider = new SpringJmsProvider( "jms-activemq.xml", "jmsConnectionFactory", "TEST_QUEUE");JmsTupleProducer producer = new JsonTupleProducer();// JMS Queue S...

UI说明jstorm的UI相对于storm提供了更为丰富的监控项。UI本身是在tomcat中运行的一个war包，进行二次开发也相对容易。 cluster页Cluster Summary, Cluster Stats, Topology Summarycluster的整体信息, conf中是nimbus节点的配置。 Topology Summary当前运行的所有topology列表及概要信息，conf中对应的是topology单独配置的配置项。 Supervisor Summary所有supervisor列表, 可以查看supervisor的配置、日志等。 topology页Topology Summary主要关注Topology Graph 项，这是Component Metrics 页的概要信息，可以较直观的看出运行状况。 其中，节点大小和箭头粗细代表数据量，节点颜色用于区分spout和bolt。箭头颜色对应TupleLifeCycle属性，由绿到红越来越慢。箭头变红色时，可以适当增加下游节点的并行度。 Component Metrics包含每个spout, bolt的统计信息...

Storm（以及阿里巴巴开源的 JStorm）是一个分布式实时计算框架。它的编程模型跟传统 Java 程序有一些关键区别，如果不了解这些区别，很容易写出在本地跑得好好的、部署到集群就出各种诡异 bug 的代码。 本文不深入 Storm 内核原理，而是聚焦开发者最需要知道的几个关键区别，帮你快速上手并避开常见坑。 Storm 运行机制速览一个 Storm Topology 由若干 Spout（数据源）和 Bolt（处理逻辑）组成，它们分散运行在多个 Worker（进程）中。同一个 Worker 可能同时运行多个 Spout/Bolt 的多个线程。 关键要理解的是：你的代码会被序列化后分发到各个 Worker 上执行，而不是在提交 Topology 的那台机器上运行。 与传统 Java 程序的三大关键区别1. main 方法只跑在 Nimbus 上main 方法只在提交 Topology 时运行在 Nimbus（Storm 的 master 节点）上。它的作用仅限于构建 Topology 的结构并提交——实际的 Spout 和 Bolt 代码不在 main 方法所在进程...

Web Console 的安全风险activemq的web console是基于jetty实现，其权限管理也是基于jetty. 根据需求，可以给不同的用户赋予不同的权限。jetty的权限管理还算灵活，虽然配起来比较麻烦，可以分别设定某个角色（role）下的用户是否有对某个页面的访问权限。 JAAS 认证配置下面简要介绍一下配置方法，只需要修改/conf 下的 jetty.xml， jetty-realm.properties 1. jetty-realm.properties   这里面配置了所有用户的用户名，密码和所属角色，按照如下格式： username: password [,rolename ...]    ## 角色与权限定义 2\. jetty.xml 首先对每个角色配置一个Constraint 类，其中roles及对应 jetty-realm.properties中的rolename <bean id="securityConstraint" class="org.e...

Storm UI 概览Storm UI对于排查storm使用过程中遇到的问题会很有帮助，但是有些属性的含义不是很明确，虽然都是很简单的概念，如果不知道的话也会很难受。 先说一点，鼠标只到UI上的标题栏时，是可以看到这一属性的具体属性的，几篇google rank很高的文章，其实就是把这个信息整理了下来。 其实大部分属性都是很直白的，看到名字就知道是什么意思，我在这儿之把一些可能造成困扰的属性列一下，方便大家查问题。   关键指标详解emitted和transfered: emitted，就是发射出的数据条数，也就是调用OutputCollector的emit方法的次数。transferred则是实际tuple发送到下一个task的数目。乍一看是一样的对吗。其实一般情况下也确实是一样的。但是，比如，一个bolt 发射了数据，但是下游并没有其他bolt取这个数，这个bolt的transfer数就会是0\. 又比如，如果一个bolt A使用all group的方式(每一个bolt都要接收到)向bolt B发射tuple，那么transfered就会是emitted的数倍。 e...

问题现象最近在使用activemq 的连接池时，发现它存在很严重的内存泄露问题。 排查过程通过jmap监控，可以看到java.util.concurrent.locks.ReentrantLock, org.apache.activemq.pool.PooledConnection这两个类占用的空间非常大，而且增长速度也很快。 根因分析网上查了一下，正好找到activemq的bug 报告.:https://issues.apache.org/jira/browse/AMQ-3997 解决方案这个bug 在5.7中已经修复，可以通过升级版本解决。 同时，也有另一种解决方式，就是使用spring带的连接池替换activemq自带的连接池，配置如下： <bean id="jmsConnectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory"> <property name="brokerURL" value="v...

测试场景公司使用activemq和camel做消息的分发，之前数据量不是很大，所以一直没怎么考虑效率问题，对camel的工作原理研究也不深。单是最近随着业务量的增加，camel的效率逐渐成了瓶颈，所以根据日志大概了解了camel的工作原理。虽然camel是被嵌入到activemq中，但在工作过程中，camel和activemq其实还是相对独立的。我们在camel中会配置一个到activemq的连接. http://camel.apache.org/activemq.html 关于vm这种传输方式，参考http://activemq.apache.org/vm-transport-reference.html 瓶颈分析看了下日志，发现这种配置下camel会有一个很严重的问题: camel每次执行转发操作时，都会新建一个到activemq的连接，之后再将其关闭。这严重拖慢了转发效率，因为事实上每次转发都可以使用同一个连接。 优化建议因此查了一下camel文档，找到了 http://camel.apache.org/activemq.html 。 里边有关于线程池的配置： &n...