[jboss-user] [JBoss Messaging] - Re: close jms conection cause block

Ivan Nushev do-not-reply at jboss.com
Thu Jun 16 04:11:06 EDT 2011

Ivan Nushev [http://community.jboss.org/people/ivannushev] created the discussion

"Re: close jms conection cause block"

To view the discussion, visit: http://community.jboss.org/message/610497#610497

Hi all. I've fixed my blocking problem. I'm exposing below how I overcome it.
First of all, the blocking issue wasn't in JBoss Messaging itself, but in the way I used it. That's why I have to explain a bit more about my use case. Our business needs supposed to have multiple subscribers interesting in a set of business events. Events are fired when some business objects are modified. Then subscribers are notified about these changes and they take appropriate actions. These business needs were designed to be fulfilled as using a chain of JMS destinations. Business events are registered to the first JMS destination. Then a MDB consumes them and based on existing subscriptions decides whether to publish business messages to the second JMS destination (of type Topic because it has to notify multiple subscribers). That design was chosen in order to make processing of events to happen asynchronously from their generation and to eliminate delay when events are turned into business messages. Moreover publishing of business events and their consuming was put in distributed transaction management. 
So the first JMS misuse was that the business event destination (the first one of the chain) was of type Queue. As JMS documentation states in case of chaining all destinations have to be of same type. The second design misuse was that both destinations don't know about each other: as JBoss Messaging examples exposes, in case of chaining the second destination have to be set as JMSReplyTo property to each message (this is not a proper JMS requirement and I suppose it is needed in order JBM to make appropriate synchronization of JMS resources). I turn the JMS Queue into JMS Topic because the second destination is to be Topic for our business needs. As its messages are consumed by a MDB, then a durable subscription has to be done for it. 
There was a chance to have JMS resource leaking because I implemented JMS resource reusing inside SLSB-s responsible for JMS message publishing following the tutorial examples and that's why I remove that i.e. JMS resources are obtained and released for each call.
I have to mention our business needs requires to use HTTPS for transport protocol and that's why SSLServlet remoting transport was chosen for JMS. This circumstance added a lot complications to the service because that transport is unidirectional, initiated from clients to the server and not so reliable as the practice showed. I still haven't found reliable JMS configuration for SSLServlet transport which makes JMS MessageListener-s (subscribed to the second Topic in our case) to survive 'forever': I mean that somehow they stop receiving messages, their subscription is seen in jmx-console, but it is registered that some number of messages are not delivered (112 is the number of not delivered messages):
I attach the configuration file asking for hints what settings could be wrong. Thanks.

<mbean code="org.jboss.remoting.transport.Connector"
    display-name="JMS Public Servlet transport Connector">
    <attribute name="Configuration">
            <invoker transport="sslservlet">
                    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="serverBindAddress">${jboss.bind.address}</attribute>
                <attribute name="serverBindPort">443</attribute>
                <attribute name="clientConnectAddress">${public.firewall.address}</attribute>
                <attribute name="clientConnectPort">443</attribute>
                <attribute name="numberOfCallRetries" isParam="true">3</attribute>
                <attribute name="pingFrequency" isParam="true">1200000</attribute>
                <attribute name="pingWindowFactor" isParam="true">2</attribute>
                <attribute name="onewayThreadPool">org.jboss.jms.server.remoting.DirectThreadPool</attribute>
                <attribute name="callbackStore">org.jboss.remoting.callback.BlockingCallbackStore</attribute>
                <attribute name="unwrapSingletonArrays">true</attribute>
                <attribute name="path">unified-invoker/PublicJmsServerInvokerServlet</attribute>
                <attribute name="return-exception">true</attribute>
                <attribute name="createUniqueObjectName">true</attribute>
                <attribute name="useAllParams" isParam="true">true</attribute>
                <!-- End immutable parameters -->

                <attribute name="generalizeSocketException" isParam="true">true</attribute>
                <attribute name="callbackErrorsAllowed">1</attribute>
                <attribute name="stopLeaseOnFailure" isParam="true">true</attribute>
                <attribute name="socketTimeout" isParam="true">120000</attribute>
                <attribute name="writeTimeout" isParam="true">30000</attribute>

                <attribute name="callbackTimeout" isParam="true">10000</attribute>
                <attribute name="JBM_clientMaxPoolSize" isParam="true">200</attribute>
                <attribute name="maxPoolSize" isParam="true">300</attribute>

                    Periodicity of client pings. Server window by default is twice this
                <attribute name="clientLeasePeriod" isParam="true">50000</attribute>
                <attribute name="validatorPingPeriod" isParam="true">50000</attribute>
                <attribute name="validatorPingTimeout" isParam="true">25000</attribute>
                <attribute name="registerCallbackListener" isParam="true">true</attribute>

                <attribute name="timeout" isParam="true">3600000</attribute>
                <attribute name="continueAfterTimeout" isParam="true">false</attribute>
                    Set this to true if you want the servlet transport to block waiting
                    for server->client traffic. Or false if you want it to poll for new
                    traffic periodically. Recommended is blocking
                <attribute name="blockingMode" isParam="true">blocking</attribute>

                    Timeout for blocking. Only has relevance if blockingMode = blocking
                <attribute name="blockingTimeout" isParam="true">30000</attribute>

                    The periodicity of polling. Only has relevance if blockingMode =
                    attribute name="callbackPollPeriod" isParam="true">10000</attribute
                <handler subsystem="JMS">org.jboss.jms.server.remoting.JMSServerInvocationHandler</handler>

Reply to this message by going to Community

Start a new discussion in JBoss Messaging at Community

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jboss-user/attachments/20110616/f77f06d7/attachment-0001.html 

More information about the jboss-user mailing list