几个比较意思的情况记录一下:
1. 应该lookup那个ClusteredConnectionFactory. 单个server失败后消息的收发不会丢。
2. MDB会自动处理Failover
3. 从HA-JNDI(1100端口)lookup到的topic/ConnectionFactory可以缓存。
4. 根据缺省负载均衡策略,每次CF创建的Connection会指向不同server
5. 从Connection到session不要缓存,原来指向的server失败后,session会报错, Conection偶尔报错。
6. 最神奇的MessageConsumer.receive()方法在一个server失效后跟着傻掉(很弱智)
7. MessageConsumer.receive(timeout)会在下次进入时,从活着的server拿到消息
8. 正常的queue会被server端的MDB轮流接受.
9. Consumer的Listner没有测试
10. stateless session bean 加上@Cluster后,也会轮流被派发到不同server
11. slsb会自动处理server失败
12. Ctrl+Z会让JBoss 5.1错乱mdb收不到消息。。。残念
基本上正常
1. 应该lookup那个ClusteredConnectionFactory. 单个server失败后消息的收发不会丢。
2. MDB会自动处理Failover
3. 从HA-JNDI(1100端口)lookup到的topic/ConnectionFactory可以缓存。
4. 根据缺省负载均衡策略,每次CF创建的Connection会指向不同server
5. 从Connection到session不要缓存,原来指向的server失败后,session会报错, Conection偶尔报错。
6. 最神奇的MessageConsumer.receive()方法在一个server失效后跟着傻掉(很弱智)
7. MessageConsumer.receive(timeout)会在下次进入时,从活着的server拿到消息
8. 正常的queue会被server端的MDB轮流接受.
9. Consumer的Listner没有测试
10. stateless session bean 加上@Cluster后,也会轮流被派发到不同server
11. slsb会自动处理server失败
12. Ctrl+Z会让JBoss 5.1错乱mdb收不到消息。。。残念
基本上正常