JMS（Jboss Messaging）的一点使用心得（十三）拔网线后的重连----JMS Connection原理浅析及应用(zhuan)

在前面的文章里，我们介绍了可以自动重连的JmsMessageListenerContainer，自动重连的原理就是利用了JMS Connction的ExceptionListen机制。现在我们讨论一下Jms Connection的简单原理及应用。
    Jboss Messaging管理了两组Connection，Server端的和Client端的；其实他们都是一个东西，因为连接都是相互的嘛。
    Server端的Connection管理是利用 [org.jboss.jms.server.connectionfactory.ConnectionFactory]实现的，大家可以在[\ jboss-4.2.2.GA\server\messaging1.4SP3\deploy\jboss-messaging.sar\connection -factories-service.xml]里配置它，大家也可以通过源码来研究。不管是Serber端还是Client端都从这个Factory里面拿Jms Connection。
    另外，对Client的Jms Connction还有一个设置，就是[org.jboss.remoting.transport.Connector]的设置，它配置在[\ jboss-4.2.2.GA\server\messaging1.4SP3\deploy\jboss-messaging.sar\remoting -bisocket-service.xml]里。
    根据Jboss Messaging的默认配置，Server端Jms Connection的每隔30秒会去Check一下所有的JMS 连接，如果发现连接错误，则该连接就会被回收，以提供给其他的Client端使用。这样做是为了避免出现大量无用连接而耗费系统资源。而Client端的连接自动Check间隔为5分钟，就是说如果直到Client端和Server端的连接断掉5分钟后，才会触发Client端Jms Connection的onException。
    这样就会出现一种可能，假如Client端和Server端的网线中断时间在30秒~5分钟之间，Server端已经回收了该连接，而Client却认为这个连接仍然OK，那Client端就永远收不到Jms消息了...
     我们可以通过修改设置来解决这个问题。首先看看Server端，考虑到Server端的性能和稳定性，我们决定不做修改。只有改Client端了。如果我们让Client的连接Check时间小于或者等于30秒，比如说29秒，就可以解决这个问题。于是我们可以做以下修改：
1. connection-factories-service.xml

<? xml version="1.0" encoding="UTF-8" ?>

<!--

Messaging Connection Factories deployment descriptor.

$Id: connection-factories-service.xml 3201 2007-10-19 10:39:50Z timfox $

-->

< server >

<!-- The default connection factory does not support automatic failover or load balancing-

this is so we can maintain compatiblity with applications written for JBoss MQ which use this

connection factory.

-->

< mbean code ="org.jboss.jms.server.connectionfactory.ConnectionFactory"

name ="jboss.messaging.connectionfactory:service=ConnectionFactory"

xmbean-dd ="xmdesc/ConnectionFactory-xmbean.xml" >

< depends optional-attribute-name ="ServerPeer" > jboss.messaging:service=ServerPeer </ depends >

< depends optional-attribute-name ="Connector" > jboss.messaging:service=Connector,transport=bisocket </ depends >

< depends > jboss.messaging:service=PostOffice </ depends >

< attribute name ="SupportsFailover" > true </ attribute >

< attribute name ="DisableRemotingChecks"> true </ attribute >

< attribute name ="JNDIBindings" >

< bindings >

< binding > /ConnectionFactory </ binding >

< binding > /XAConnectionFactory </ binding >

< binding > java:/ConnectionFactory </ binding >

< binding > java:/XAConnectionFactory </ binding >

</ bindings >

</ attribute >

</ mbean >

<!-- A clustered connection factory that supports automatic failover and load balancing of created

connections.

This factory is not suitable to be used by MDBs.

-->

< mbean code ="org.jboss.jms.server.connectionfactory.ConnectionFactory"

name ="jboss.messaging.connectionfactory:service=ClusteredConnectionFactory"

xmbean-dd ="xmdesc/ConnectionFactory-xmbean.xml" >

< depends optional-attribute-name ="ServerPeer" > jboss.messaging:service=ServerPeer </ depends >

< depends optional-attribute-name ="Connector" > jboss.messaging:service=Connector,transport=bisocket </ depends >

< depends > jboss.messaging:service=PostOffice </ depends >

< attribute name ="DisableRemotingChecks"> true </ attribute >

< attribute name ="JNDIBindings" >

< bindings >

< binding > /ClusteredConnectionFactory </ binding >

< binding > /ClusteredXAConnectionFactory </ binding >

< binding > java:/ClusteredConnectionFactory </ binding >

< binding > java:/ClusteredXAConnectionFactory </ binding >

</ bindings >

</ attribute >

< attribute name ="SupportsFailover" > true </ attribute >

< attribute name ="SupportsLoadBalancing" > true </ attribute >

</ mbean >

<!-- A connection factory with no JNDI bindings that is used in clustering to create the connections that

pull messages from one node to another

-->

< mbean code ="org.jboss.jms.server.connectionfactory.ConnectionFactory"

name ="jboss.messaging.connectionfactory:service=ClusterPullConnectionFactory"

xmbean-dd ="xmdesc/ConnectionFactory-xmbean.xml" >

< depends optional-attribute-name ="ServerPeer" > jboss.messaging:service=ServerPeer </ depends >

< depends optional-attribute-name ="Connector" > jboss.messaging:service=Connector,transport=bisocket </ depends >

< depends > jboss.messaging:service=PostOffice </ depends >

< attribute name ="SupportsFailover" > false </ attribute >

< attribute name ="SupportsLoadBalancing" > false </ attribute >

< attribute name ="DisableRemotingChecks"> true </ attribute >

</ mbean >

<!-- An example connection factory with all attributes shown

<mbean code="org.jboss.jms.server.connectionfactory.ConnectionFactory"

name="jboss.messaging.connectionfactory:service=MyExampleConnectionFactory"

xmbean-dd="xmdesc/ConnectionFactory-xmbean.xml">

<!- - You can specify the default Client ID to use for connections created using this factory - ->

</constructor>

<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>

<!- - The transport to use - can be bisocket, sslbisocket or http - ->

<depends optional-attribute-name="Connector">jboss.messaging:service=Connector,transport=http</depends>

<depends>jboss.messaging:service=PostOffice</depends>

<!- - PrefetchSize determines the approximate maximum number of messages the client consumer will buffer locally - ->

<!- - Paging params to be used for temporary queues - ->

<!- - The batch size to use when using the DUPS_OK_ACKNOWLEDGE acknowledgement mode - ->

<!- - Does this connection factory support automatic failover? - ->

<attribute name="SupportsFailover">false</attribute>

<!- - Does this connection factory support automatic client side load balancing? - ->

<attribute name="SupportsLoadBalancing">false</attribute>

<!- - The class name of the factory used to create the load balancing policy to use on the client side - ->

<attribute name="LoadBalancingFactory">org.jboss.jms.client.plugin.RoundRobinLoadBalancingFactory</attribute>

<!- - Whether we should be strict TCK compliant, i.e. how we deal with foreign messages, defaults to false- ->

<!- - Disable JBoss Remoting Connector sanity checks - There is rarely a good reason to set this to true - ->

<attribute name="DisableRemotingChecks">false</attribute>

<!- - The connection factory will be bound in the following places in JNDI - ->

<binding>/acme/MyExampleConnectionFactory</binding>

<binding>/acme/MyExampleConnectionFactoryDupe</binding>

<binding>java:/connectionfactories/acme/connection_factory</binding>

</bindings>

</attribute>

</mbean>

-->

</ server >

2. remoting-bisocket-service.xml

<? xml version="1.0" encoding="UTF-8" ?>

<!--

Standard bisocket-based Remoting service deployment descriptor.

$Id: remoting-bisocket-service.xml 3409 2007-12-04 21:32:54Z timfox $

-->

< server >

<!-- Standard bisocket connector - the bisocket transport only opens connection from client->server

so can be used with firewalls where only outgoing connections are allowed.

For examples of HTTP and SSL transports see docs/examples -->

< mbean code ="org.jboss.remoting.transport.Connector"

name ="jboss.messaging:service=Connector,transport=bisocket"

display-name ="Bisocket Transport Connector" >

< attribute name ="Configuration" >

< config >

< invoker transport ="bisocket" >

<!-- There should be no reason to change these parameters - warning!

Changing them may stop JBoss Messaging working correctly -->

< attribute name ="marshaller" isParam ="true" > org.jboss.jms.wireformat.JMSWireFormat </ attribute >

< attribute name ="unmarshaller" isParam ="true" > org.jboss.jms.wireformat.JMSWireFormat </ attribute >

< attribute name ="dataType" isParam ="true" > jms </ attribute >

< attribute name ="socket.check_connection" isParam ="true" > false </ attribute >

< attribute name ="timeout" isParam ="true" > 29000 </ attribute >

< attribute name ="serverBindAddress" > ${jboss.bind.address} </ attribute >

< attribute name ="serverBindPort" > 4457 </ attribute >

< attribute name ="clientSocketClass" isParam ="true" > org.jboss.jms.client.remoting.ClientSocketWrapper </ attribute >

< attribute name ="serverSocketClass" > org.jboss.jms.server.remoting.ServerSocketWrapper </ attribute >

< attribute name ="numberOfCallRetries" isParam ="true" > 1 </ attribute >

< attribute name ="pingFrequency" isParam ="true" > 214748364 </ attribute >

< attribute name ="pingWindowFactor" isParam ="true" > 10 </ attribute >

< attribute name ="onewayThreadPool" > org.jboss.jms.server.remoting.DirectThreadPool </ attribute >

< attribute name ="clientLeasePeriod" isParam ="true" > 10000 </ attribute >

< attribute name ="numberOfRetries" isParam ="true" > 10 </ attribute >

<!-- Max Number of connections in client pool. This should be significantly higher than

the max number of sessions/consumers you expect -->

< attribute name ="JBM_clientMaxPoolSize" isParam ="true" > 200 </ attribute >

<!-- Use these parameters to specify values for binding and connecting control connections to

work with your firewall/NAT configuration

-->

</ invoker >

< handlers >

< handler subsystem ="JMS" > org.jboss.jms.server.remoting.JMSServerInvocationHandler </ handler >

</ handlers >

</ config >

</ attribute >

</ mbean >

</ server >

问题解决。OK！

JMS（Jboss Messaging）的一点使用心得（十三）拔网线后的重连----JMS Connection原理浅析及应用(zhuan)

JMS（Jboss Messaging）的一点使用心得（十三）拔网线后的重连----JMS Connection原理浅析及应用(zhuan)

你可能感兴趣的:(JMS（Jboss Messaging）的一点使用心得（十三）拔网线后的重连----JMS Connection原理浅析及应用(zhuan))