JBoss Messaging and Bisocket Transport

[ebenezersamuel]

Hi,

JBoss AS: 4.2.2.GA
JBM: 1.4.0.SP3
Remoting: 2.2.2.SP7-brew

We are planning to use Http Transport instead of Bisocket Transport in JBoss Messaging; this is because we have an external load balancer which would balance the load across all the messaging instances (We have 5 JBoss Server running in 5 Physical Machines and one JBoss instance in each Server and there are many senders that would be sending messages and the load balancer would spread the load across the queues in a round robin fashion). Now we are unable to use bisocket transport because it opens a second port 4457 and keeps it open and our load balncer is configured to use 1099 and because the second port is always open, the load balancer is unable to do its work. Basically, when the load balancer gets the very first message, it chooses a instance to which it sends the message and then when the second message comes, it HAS to choose the next instance, BUT, that doesnt happen since the bisocket transport has a second port that is always open, the load balancer chooses the first machine to send the other messages that comes.

Is there any way that we can stop the opening of the second port that is being opened by the Bisocket transport?

BTW, I have read that bisocket transport is useful in place where the server is behind a firewall and this server opens the call back port (the second port 4457, here) so that clients can use that. Our Server is not behind a firewall and so we do not want the call back port.

Thanks,
Ebe

[ron_sigal]

Hi Ebe,

The bisocket transport needs the second port to support clients behind firewalls, which, as you mention, is the reason the bisocket transport was developed. However, if you're not going to use the bisocket transport, you can just remove the bisocket configuration and it won't run at all.

I believe that the JBossMessaging directory structure might change from version to version, but you should look for a file in the JBM deployment that's called something like "remoting-service.xml" and look for the bisocket Connector MBean:

 <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">0</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>
 <!-- End immutable parameters -->

 <!-- Periodicity of client pings. Server window by default is twice this figure -->
 <attribute name="clientLeasePeriod" isParam="true">10000</attribute>

 <!-- Number of seconds to wait for a connection in the client pool to become free -->
 <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
 <attribute name="secondaryBindPort">xyz</attribute>
 <attribute name="secondaryConnectPort">abc</attribute>
 -->

 </invoker>
 <handlers>
 <handler subsystem="JMS">org.jboss.jms.server.remoting.JMSServerInvocationHandler</handler>
 </handlers>
 </config>
 </attribute>
 </mbean>

If you delete that and replace it with an HTTP connector, the secondary port will go away.

-Ron

[timfox]

Bear in mind, that you'll get much lower performance if you use the HTTP transport, and we don't recommend it if you want stability.

[rajan11]

What do you mean by "much lower performance"? Do you have any numbers? Why is http transport not stable?

[ataylor]

What do you mean by "much lower performance"?

This is inherent in the protocol, it will never perform as well as plain TCP. Also typically this means that clients are talking to servers over a slower network, i.e. the internet.