PortUtil - Hits Max Will Always Hand Out 65535

[jcreynol]

I think I've done all the requisite searching to see if this has been discussed elsewhere and I'm slightly convinced it may be a bug that hasn't been uncovered in that I'm not certain it has been hit as hard in testing, as it is in our production environment of 6000+ Swing Clients invoking various EJBs for 10 hours straight at sub-second intervals. Some of the behaviors we have seen -- server crashes without log details or errors and hung clients that never receive response nor exception -- may possibly be related to port issues.

private static synchronized int getNextPort()
 {
 if (portCounter < MAX_LEGAL_PORT)
 return portCounter++;

 portCounter = MIN_UNPRIVILEGED_PORT;
 return MAX_LEGAL_PORT;
 }

Since these methods are static and portCounter is static, overtime this socket connectors will grow to where all will try MAX_LEGAL_PORT to no avail, no?

As an example, here's the log entry 1.5 seconds before the server was auto-restarted by a cron job:

2008-03-07 12:28:14,689 INFO (WorkerThread#140[10.29.10.109:64619]) [xxx.dao.RDBContactEventLogDAO] Option size: 2
INFO (main) [com.arjuna.ats.jbossatx.jta.TransactionManagerService] JBossTS Transaction Service (JTA version) - JBoss Inc.

Shouldn't we drop back down to the MIN_UNPRIVILEGED_PORT if the MAX_LEGAL_PORT won't work? As it is, the portCounter is initialized to a random number so x number of ports between MIN_UNPRIVILIGED_PORT and RANDOM_PORT go unchecked...

Any thoughts on the topic are very much appreciated.

Thanks,
John

[ron_sigal]

After getNextPort() returns MAX_LEGAL_PORT, the next call to getNextPort() will return MIN_UNPRIVILEGED_PORT.

[jcreynol]

Got it. Need to step through that a little slower. Thanks for the reply. Before I post another thread, I see that the docs say Connector has a default "socketTimeout" of 60000, but the default jboss-service.xml -- at least the one that was packaged with the 4.2.0 and 4.2.2 that I have, has this set at 600000. Beginning to think that's my issue and going to try a 60000 setting to see if that cleans things up a bit and more quickly frees up the WorkerThreads for re-use.

http://labs.jboss.com/jbossremoting/docs/guide/ch05.html#d0e2491

493 <attribute name="Configuration">
494 <!-- Using the following <invoker> element instead of the InvokerLocator above because specific attributes needed. -->
495 <!-- If wanted to use any of the parameters below, can just add them as parameters to the url above if wanted use the InvokerLocator attribute. -->
496 <config>
497 <!-- Other than transport type and handler, none of these configurations are required (will just use defaults). -->
498 <invoker transport="socket">
499 <attribute name="dataType" isParam="true">invocation</attribute>
500 <attribute name="marshaller" isParam="true">org.jboss.invocation.unified.marshall.InvocationMarshaller</attribute>
501 <attribute name="unmarshaller" isParam="true">org.jboss.invocation.unified.marshall.InvocationUnMarshaller</attribute>
502 <!-- This will be port on which the marshall loader port runs on. -->
503 <!-- <attribute name="loaderport" isParam="true">4447</attribute> -->
504 <!-- The following are specific to socket invoker -->
505 <!-- <attribute name="numAcceptThreads">1</attribute>-->
506 <!-- <attribute name="maxPoolSize">303</attribute>-->
507 <!-- <attribute name="clientMaxPoolSize" isParam="true">304</attribute>-->
508 <attribute name="socketTimeout" isParam="true">600000</attribute>

Should a Jira issue be created to modify the socketTimeout in jboss-service.xml that ships in the default distribution? (or maybe the docs need to change?)

Thanks again for the speedy reply!

-John

[ron_sigal]

Hmmm. Actually, that's an oversight in jboss-service.xml, since "socketTimeout" hasn't been used for quite a while. The current parameter is "timeout", so setting "socketTimeout" wouldn't have any effect. The default values are 60000 on the server and 1800000 on the client.

[jcreynol]

Thanks once again. I do see that this shows as timeout in the jmx-console for the Connector. Looks like the .xml and the docs need to be updated.
http://labs.jboss.com/jbossremoting/docs/guide/ch05.html#d0e2491

Note that all the server side socket invoker configurations will be set to their default values in this case. Also, it is important to add CDATA to any locator uri that contains more than one parameter.

The other way to configure the Connector and its server invoker in greater detail is to provide an invoker sub-element within the config element of the Configuration attribute. The only attribute of invoker element is transport, which will specify which transport type to use (e.g.. socket, rmi, http, or multiplex). All the sub-elements of the invoker element will be attribute elements with a name attribute specifying the configuration property name and then the value. An isParam attribute can also be added to indicate that the attribute should be added to the locator uri, in the case the attribute needs to be used by the client. An example using this form of configuration is as follows:


 <mbean code="org.jboss.remoting.transport.Connector"
 name="jboss.remoting:service=Connector,transport=Socket"
 display-name="Socket transport Connector">

 <attribute name="Configuration">
 <config>

 <invoker transport="socket">
 <attribute name="numAcceptThreads">1</attribute>
 <attribute name="maxPoolSize">303</attribute>
 <attribute name="clientMaxPoolSize" isParam="true">304</attribute>
 <attribute name="socketTimeout">60000</attribute>
 <attribute name="serverBindAddress">192.168.0.82</attribute>
 <attribute name="serverBindPort">6666</attribute>
 <attribute name="clientConnectAddress">216.23.33.2</attribute>
 <attribute name="clientConnectPort">7777</attribute>
 <attribute name="enableTcpNoDelay" isParam="true">false</attribute>
 <attribute name="backlog">200</attribute>
 </invoker>

 <handlers>
 <handler subsystem="mock">
 org.jboss.remoting.transport.mock.MockServerInvocationHandler
 </handler>
 </handlers>
 </config>
 </attribute>

 </mbean>

[ron_sigal]

Good catch. Thanks!