6 Replies Latest reply on Sep 14, 2009 10:50 PM by Ron Sigal

    port problem on windows embedded pos

    Razvan A. Newbie

      I am currently working on a java ee project and we use Jboss as the application server.
      The server should run on windows xp, linux and also on windows embedded for point of sale (i know it is a funny choice).
      Jboss version: 5.1 GA
      On my windows XP it works fine.
      On we pos (same config) I have a problem with clients for jbm and datasource. I think it is a port problem. I deactivated the firewall, i also checked in windows registry for blocked ports, no problem there.
      I gives me:

      ERROR [JBossConnectionFactory] Failed to download and/or install client side AOP stack
       at org.jboss.jms.client.delegate.DelegateSupport.handleThrowable(DelegateSupport.java:240)
       at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:205)
       at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:160)
       at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.org$jboss$jms$client$delegate$ClientConnectionFactoryDelegate$getClientAOPStack$aop(ClientConnectionFactoryDelegate.java:237)
       at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.getClientAOPStack(ClientConnectionFactoryDelegate.java)
       at org.jboss.jms.client.ClientAOPStackLoader.load(ClientAOPStackLoader.java:75)
       at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFactory.java:192)
       at org.jboss.jms.client.JBossConnectionFactory.createQueueConnection(JBossConnectionFactory.java:101)
       at org.jboss.jms.client.JBossConnectionFactory.createQueueConnection(JBossConnectionFactory.java:95)
       at org.jboss.resource.adapter.jms.inflow.dlq.AbstractDLQHandler.setupDLQConnection(AbstractDLQHandler.java:137)
       at org.jboss.resource.adapter.jms.inflow.dlq.AbstractDLQHandler.setup(AbstractDLQHandler.java:83)
       at org.jboss.resource.adapter.jms.inflow.dlq.JBossMQDLQHandler.setup(JBossMQDLQHandler.java:48)
       at org.jboss.resource.adapter.jms.inflow.JmsActivation.setupDLQ(JmsActivation.java:413)
       at org.jboss.resource.adapter.jms.inflow.JmsActivation.setup(JmsActivation.java:351)
       at org.jboss.resource.adapter.jms.inflow.JmsActivation$SetupActivation.run(JmsActivation.java:729)
       at org.jboss.resource.work.WorkWrapper.execute(WorkWrapper.java:205)
       at org.jboss.util.threadpool.BasicTaskWrapper.run(BasicTaskWrapper.java:260)
       at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
       at java.lang.Thread.run(Thread.java:619)
      Caused by: org.jboss.remoting.CannotConnectException: Can not get connection to server. Problem establishing socket connection for InvokerLocator [bisocket://uc_0183_0181/?JBM_clientMaxPoolSize=200&clientLeasePeriod=10000&clientSocketClass=org.jboss.jms.client.remoting.ClientSocketWrapper&connectionWait=10&dataType=jms&marshaller=org.jboss.jms.wireformat.JMSWireFormat&numberOfCallRetries=1&pingFrequency=214748364&pingWindowFactor=10&socket.check_connection=false&stopLeaseOnFailure=true&timeout=0&unmarshaller=org.jboss.jms.wireformat.JMSWireFormat&validatorPingPeriod=10000&validatorPingTimeout=5000]
       at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:776)
       at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.transport(BisocketClientInvoker.java:426)
       at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
       at org.jboss.remoting.Client.invoke(Client.java:1724)
       at org.jboss.remoting.Client.invoke(Client.java:629)
       at org.jboss.remoting.Client.invoke(Client.java:617)
       at org.jboss.jms.client.delegate.DelegateSupport.doInvoke(DelegateSupport.java:189)
       ... 18 more
      Caused by: java.lang.IllegalArgumentException: port out of range:-1
       at java.net.InetSocketAddress.<init>(InetSocketAddress.java:118)
       at org.jboss.remoting.transport.socket.SocketClientInvoker.createSocket(SocketClientInvoker.java:197)
       at org.jboss.remoting.transport.bisocket.BisocketClientInvoker.createSocket(BisocketClientInvoker.java:433)
       at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.getConnection(MicroSocketClientInvoker.java:1089)
       at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:762)
       ... 24 more

      I don't know if my problem is a remoting or a jbm problem (or maybe a java on we pos problem)!, so i am sorry if i placed wrong my message.

        • 1. Re: port problem on windows embedded pos
          Ron Sigal Master

          Interesting problem. That InvokerLocator, "bisocket://uc_0183_0181/?JBM_clientMaxPoolSize ...", should have a port following the host. The way JBossMessaging works is, you download a connection factory, and the connection factory carries with it the InvokerLocator, which suggests that something is going wrong when JBossMessaging starts up on the server. Look for suspicious complaints in the server.log.

          • 2. Re: port problem on windows embedded pos
            Razvan A. Newbie

            Thank you for your prompt reply Ron!

            This is the log part where the JBM server starts up:

            2008-03-10 08:02:20,291 INFO [org.jboss.jms.server.ServerPeer] (main) JBoss Messaging 1.4.3.GA server [0] started
            2008-03-10 08:02:22,194 INFO [org.jboss.jms.server.connectionfactory.ConnectionFactory] (main) Connector bisocket://uc_0183_0181:-1 has leasing enabled, lease period 10000 milliseconds
            2008-03-10 08:02:22,194 INFO [org.jboss.jms.server.connectionfactory.ConnectionFactory] (main) org.jboss.jms.server.connectionfactory.ConnectionFactory@390a74 started
            2008-03-10 08:02:22,214 INFO [org.jboss.jms.server.connectionfactory.ConnectionFactoryJNDIMapper] (main) supportsFailover attribute is true on connection factory: jboss.messaging.connectionfactory:service=ClusteredConnectionFactory but post office is non clustered. So connection factory will *not* support failover
            2008-03-10 08:02:22,214 INFO [org.jboss.jms.server.connectionfactory.ConnectionFactoryJNDIMapper] (main) supportsLoadBalancing attribute is true on connection factory: jboss.messaging.connectionfactory:service=ClusteredConnectionFactory but post office is non clustered. So connection factory will *not* support load balancing
            2008-03-10 08:02:22,264 INFO [org.jboss.jms.server.connectionfactory.ConnectionFactory] (main) Connector bisocket://uc_0183_0181:-1 has leasing enabled, lease period 10000 milliseconds
            2008-03-10 08:02:22,264 INFO [org.jboss.jms.server.connectionfactory.ConnectionFactory] (main) org.jboss.jms.server.connectionfactory.ConnectionFactory@d9e447 started
            2008-03-10 08:02:22,574 INFO [org.jboss.jms.server.destination.QueueService] (main) Queue[/queue/DLQ] started, fullSize=200000, pageSize=2000, downCacheSize=2000
            2008-03-10 08:02:22,594 INFO [org.jboss.jms.server.destination.QueueService] (main) Queue[/queue/ExpiryQueue] started, fullSize=200000, pageSize=2000, downCacheSize=2000
            2008-03-10 08:02:22,604 INFO [org.jboss.jms.server.connectionfactory.ConnectionFactory] (main) Connector bisocket://uc_0183_0181:-1 has leasing enabled, lease period 10000 milliseconds
            2008-03-10 08:02:22,604 INFO [org.jboss.jms.server.connectionfactory.ConnectionFactory] (main) org.jboss.jms.server.connectionfactory.ConnectionFactory@da253 started
            2008-03-10 08:02:22,634 INFO [org.jboss.resource.connectionmanager.ConnectionFactoryBindingService] (main) Bound ConnectionManager 'jboss.jca:service=ConnectionFactoryBinding,name=JmsXA' to JNDI name 'java:JmsXA'

            I took some tests on linux (same device with linux suse on it), the problem is the same.

            If i try with a jms client from another computer to connect to the server it doesn't print anything in the server.log!

            The JBM doesn't complain of anything, it just sets the port -1.
            Now my desire is to see why. I think the only way to see the root problem is to do a remote debug on the device to see why the port is not set.

            If you have some advices, please share!

            Thank you,
            Razvan A.

            • 3. Re: port problem on windows embedded pos
              Ron Sigal Master

              Hi Razvan,

              I don't have a lot to add. You could also try increasing the log level, particularly of JBossMessaging, to TRACE. Look for jboss-log4j.xm in $JBOSS_HOME/server/$CONFIG/conf. In fact, I think this issue has more to do with JBossMessaging than JBossRemoting. You might try posing the question on the JBossMessaging users forum: http://www.jboss.org/index.html?module=bb&op=viewforum&f=238 .

              Good luck.


              • 4. Re: port problem on windows embedded pos
                Peter Gymoese Newbie

                I'm seeing something similar. We have a JBoss AS (4.3.2) running the server part of our application and several remote clients communicating with the server via. JMS (JBoss messaging 1.4.4 GA) + several stateless session beans.

                If I configure the jboss remoting service to use SSL then I get the same problem as posted above, but ONLY if I configure my JBoss AS with a hostname and not an IP addr. during startup with the -b option.

                The server and the client are running on the same machine and everything works nicely if I configure my server with -b <IP-Addr> but not with -b - and yes I'm 100% sure it resolves correctly (o;

                What I have noticed is that the serverBindPort of the SslBiSocket configuration seems to be ignored once the serverBindAddress part is a hostname that needs to be resolved.

                I have the port configured to default which is 5457 and that is also the port which is used when I used an IP address in my binding, however if I specify the hostname for my machine then the port is just randomly picked and this seems to be causing the problem.

                BTW. it seems a bit strange that when I run my hostname set using the -b then it is printed as resolved in the logs.

                Starting JBoss with -b "EXI_PEG-W01.headquarters.excitor.dk" will provide the following log line:

                Connector sslbisocket:// has leasing enabled....

                First of all you can see that the port is not 5457 as configured and secondly the bindadr. has already been resolved and the resolved adr. is what is sent to the client which is not at all smart - at least that is how it seems to work (o;

                If you look at i.e. the WebService service it prints:

                ... codebase: http://EXI_PEG-W01.headquarters.excitor.dk:8083/

                Where the hostname maintains unresolved, might just be a log detail?

                Anyway, if I start my JBoss server with -b then, as stated above, everything works fine and I get the following in the log:

                Connector sslbisocket:// has leasing enabled...

                Now the correct 5457 port is used!

                Actually I can make it run with the hostname set if I just hardcode the in the remoting-sslbisocket-service.xml - not really an option though (o;

                Hopefully this can be somewhat usefull when someone goes bughunting (o:

                • 5. Re: port problem on windows embedded pos
                  Ron Sigal Master

                  Hi Peter,

                  Strange. I haven't been able to duplicate your experience. Are you using the standard remoting-sslbisocket-service.xml file, or have you modified it?


                  • 6. Re: port problem on windows embedded pos
                    Ron Sigal Master

                    I don't know if this is relevant, but I just noticed I had a unit test that was creating an InvokerLocator with port == -1. It turns out that I was creating


                    instead of


                    Later on, the parsing code in the InvokerLocator class turned the port into -1.

                    Moral: check InvokerLocator.