1,到达memoryLimit之后, produce会很慢,默认的memoryLimit和flowControl关掉。否则一旦超标很坑爹
2,jaas的认证方式在大量并发连接下会出错。 并且会很慢,还会阻塞connection,即使发送是async模式的也会阻塞,并且因此拖垮掉producer,改成simple 认证凑合用
3,那些默认的什么demo啊, camel里那个示例的router啊都停掉删掉。
4,客户端采用连接池, conn和session都应该被cache, 这俩无论那个创建成本都不低。
5,bin/activemq里配置jvm参数。 默认的配置简直就是在坑爹。 只能vi 找到然后自己替换吧。
总而言之, activemq的文档扯淡, 是个坑爹的玩意,但是配好了还勉强够用。
做了共享DB的主从机, 在自己的机器上起了1000个并发连接 + 1000个线程同时发送100万个持久化消息,采用session transcated模式 一次一commit, ActivemqConnectionPool的连接池, 每条1k数据, 大概每秒写入7000条左右的数据, 服务器上的话应该更快些吧。
2,jaas的认证方式在大量并发连接下会出错。 并且会很慢,还会阻塞connection,即使发送是async模式的也会阻塞,并且因此拖垮掉producer,改成simple 认证凑合用
3,那些默认的什么demo啊, camel里那个示例的router啊都停掉删掉。
4,客户端采用连接池, conn和session都应该被cache, 这俩无论那个创建成本都不低。
5,bin/activemq里配置jvm参数。 默认的配置简直就是在坑爹。 只能vi 找到然后自己替换吧。
总而言之, activemq的文档扯淡, 是个坑爹的玩意,但是配好了还勉强够用。
做了共享DB的主从机, 在自己的机器上起了1000个并发连接 + 1000个线程同时发送100万个持久化消息,采用session transcated模式 一次一commit, ActivemqConnectionPool的连接池, 每条1k数据, 大概每秒写入7000条左右的数据, 服务器上的话应该更快些吧。