1 Reply Latest reply on Sep 14, 2007 3:55 AM by Ron Sigal

    client consumes too many socket connections

    Pavel Melech Newbie

      Hi,

      I updated my application to JBoss 4.2.0 and some clients (machine dependent) consume too many connections or more probably - do not release used socket connections.
      I configured the connection pool on the server to 300 and it didn't help (which made me suspect its about not releasing the connections and not about consuming too much), and the strange thing is that it doesn't happen on all machines (same OS, don't know what else should I check).

      the configuration I tried to change (according to documentation is:

      <mbean code="org.jboss.remoting.transport.Connector"
       name="jboss.remoting:service=Connector,transport=socket"
       display-name="Socket transport Connector">
      
       <!-- Can either just specify the InvokerLocator attribute and not the invoker element in the -->
       <!-- Configuration attribute, or do the full invoker configuration in the in invoker element -->
       <!-- of the Configuration attribute. -->
      
       <!-- Remember that if you do use more than one param on the uri, will have to include as a CDATA, -->
       <!-- otherwise, parser will complain. -->
       <!-- <attribute name="InvokerLocator"><![CDATA[socket://${jboss.bind.address}:4446/?datatype=invocation]]></attribute> -->
      
       <attribute name="Configuration">
       <!-- Using the following <invoker> element instead of the InvokerLocator above because specific attributes needed. -->
       <!-- 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. -->
       <config>
       <!-- Other than transport type and handler, none of these configurations are required (will just use defaults). -->
       <invoker transport="socket">
       <attribute name="dataType" isParam="true">invocation</attribute>
       <attribute name="marshaller" isParam="true">org.jboss.invocation.unified.marshall.InvocationMarshaller</attribute>
       <attribute name="unmarshaller" isParam="true">org.jboss.invocation.unified.marshall.InvocationUnMarshaller</attribute>
       <!-- This will be port on which the marshall loader port runs on. -->
       <!-- <attribute name="loaderport" isParam="true">4447</attribute> -->
       <!-- The following are specific to socket invoker -->
       <attribute name="numAcceptThreads">1</attribute>
       <attribute name="maxPoolSize">300</attribute>
       <attribute name="clientMaxPoolSize" isParam="true">300</attribute>
       <attribute name="timeout">5000</attribute>
       <attribute name="serverBindAddress">${jboss.bind.address}</attribute>
       <attribute name="serverBindPort">4446</attribute>
       <attribute name="enableTcpNoDelay" isParam="true">false</attribute>
       <attribute name="backlog">2</attribute>
       <!-- The following is for callback configuration and is independant of invoker type -->
       <!-- <attribute name="callbackMemCeiling">30</attribute>-->
       <!-- indicates callback store by fully qualified class name -->
       <!-- <attribute name="callbackStore">org.jboss.remoting.CallbackStore</attribute>-->
       <!-- indicates callback store by object name -->
       <!-- <attribute name="callbackStore">jboss.remoting:service=CallbackStore,type=Serializable</attribute> -->
       <!-- config params for callback store. if were declaring callback store via object name, -->
       <!-- could have specified these config params there. -->
       <!-- StoreFilePath indicates to which directory to write the callback objects. -->
       <!-- The default value is the property value of 'jboss.server.data.dir' and if this is not set, -->
       <!-- then will be 'data'. Will then append 'remoting' and the callback client's session id. -->
       <!-- An example would be 'data\remoting\5c4o05l-9jijyx-e5b6xyph-1-e5b6xyph-2'. -->
       <!-- <attribute name="StoreFilePath">callback</attribute>-->
       <!-- StoreFileSuffix indicates the file suffix to use for the callback objects written to disk. -->
       <!-- The default value for file suffix is 'ser'. -->
       <!-- <attribute name="StoreFileSuffix">cst</attribute>-->
       </invoker>
      
       <!-- At least one handler is required by the connector. If have more than one, must decalre -->
       <!-- different subsystem values. Otherwise, all invocations will be routed to the only one -->
       <!-- that is declared. -->
       <handlers>
       <!-- can also specify handler by fully qualified classname -->
       <handler subsystem="invoker">jboss:service=invoker,type=unified</handler>
       </handlers>
       </config>
       </attribute>
       <depends>jboss.remoting:service=NetworkRegistry</depends>
       </mbean>
      
      

      on every connection I see in the log:

      "DEBUG org.jboss.remoting.transport.socket.SocketClientInvoker - java.net.SocketException"

      and on failure I see:

      org.jboss.remoting.CannotConnectException: Can not get connection to server. Problem establishing socket connection for locator - InvokerLocator [socket://192.168.3.176:4446/?clientMaxPoolSize=300&dataType=invocation&enableTcpNoDelay=false&marshaller=org.jboss.invocation.unified.marshall.InvocationMarshaller&unmarshaller=org.jboss.invocation.unified.marshall.InvocationUnMarshaller]
      at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:319)
      at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:116)
      at org.jboss.remoting.Client.invoke(Client.java:612)
      at org.jboss.remoting.Client.invoke(Client.java:604)
      at org.jboss.invocation.unified.interfaces.UnifiedInvokerProxy.invoke(UnifiedInvokerProxy.java:175)
      at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)
      at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)
      at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61)
      at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
      at org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:184)
      at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
      at $Proxy4.create(Unknown Source)
      at com.proficiency.cg.agent.management.taskprocessing.TaskPostProcessorUtils.informServer(TaskPostProcessorUtils.java:537)
      at com.proficiency.cg.agent.management.taskprocessing.TaskPostProcessorUtils.persistentInformServer(TaskPostProcessorUtils.java:448)
      at com.proficiency.cg.agent.management.taskprocessing.TaskPostProcessorUtils.finishTask(TaskPostProcessorUtils.java:273)
      at com.proficiency.cg.agent.management.taskprocessing.TaskPostProcessorUtils.postProcessTask(TaskPostProcessorUtils.java:83)
      at com.proficiency.cg.agent.management.taskprocessing.TaskProcessorThread.postProcessTask(TaskProcessorThread.java:734)
      at com.proficiency.cg.agent.management.taskprocessing.TaskProcessorThread.processTask(TaskProcessorThread.java:626)
      at com.proficiency.cg.agent.management.taskprocessing.TaskProcessorThread.run(TaskProcessorThread.java:140)
      Caused by: java.net.SocketException: Can not obtain client socket connection from pool. Have waited 30 seconds for available connection (3 in use)
      at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.getConnection(MicroSocketClientInvoker.java:706)
      at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:315)
      ... 18 more


      help will be very appriciated!

      thanks,




        • 1. Re: client consumes too many socket connections
          Ron Sigal Master

          Sorry it's taken me so long to respond. Are you still experiencing this problem?

          I'm not sure what you mean when you say "some clients ... consume too many connections". Could you elaborate?

          I can't tell what's happening from the information you provided, but I have a couple of observations.

          1. I see that you reduced the timeout value to 5000. Are you sure that's not causing a problem?

          2. The line numbers in your stacktrace match Remoting 2.0.0 instead of Remoting 2.2.0, the latter being the version that ships with JBossAS 4.2.0. Maybe you should check out your classpath.