pooled-connection-factory credentials fail to persist between server restarts

[tc7]

While trying to test a fix for a remote ejb issue I have found a problem with pooled-connection-factory credentials.

It appears JBoss 7.1.2 nightly snapshot (16th April 2012) has tightened up security somewhat such that credentials are now required for internal pooled connection factory.

I have found that user credentials specified for the hornetq configuration are not persisted between server restarts.

For example. In the following configuration my server starts correctly the first time.

However the <user> and <password> elements are mysteriously deleted by the app server.

                  <jms-connection-factories>

                    <pooled-connection-factory name="hornetq-ra">

                        <transaction mode="xa"/>

                        <connectors>

                            <connector-ref connector-name="remote-jms"/>

                        </connectors>

                        <entries>

                            <entry name="java:/remote-JmsXA"/>

                        </entries>

                        <user>jmsUser</user>

                        <password>mypass</password>

                    </pooled-connection-factory>

                </jms-connection-factories>

I get one successful startup.

Next server restart I get:

20120416 19:59:04,899 ERROR [org.hornetq.core.protocol.core.impl.HornetQPacketHandler] (Old I/O server worker (parentId: 931623960, [id: 0x37877418, /160.222.152.133:5445])) Failed to create session : HornetQException[errorCode=105 message=Unable to validate user: null]

  at org.hornetq.core.security.impl.SecurityStoreImpl.authenticate(SecurityStoreImpl.java:147) [hornetq-core-2.2.13.Final.jar:]

  at org.hornetq.core.server.impl.HornetQServerImpl.createSession(HornetQServerImpl.java:807) [hornetq-core-2.2.13.Final.jar:]

  at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handleCreateSession(HornetQPacketHandler.java:187) [hornetq-core-2.2.13.Final.jar:]

  at org.hornetq.core.protocol.core.impl.HornetQPacketHandler.handlePacket(HornetQPacketHandler.java:85) [hornetq-core-2.2.13.Final.jar:]

  at org.hornetq.core.protocol.core.impl.ChannelImpl.handlePacket(ChannelImpl.java:508) [hornetq-core-2.2.13.Final.jar:]

  at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.doBufferReceived(RemotingConnectionImpl.java:556) [hornetq-core-2.2.13.Final.jar:]

  at org.hornetq.core.protocol.core.impl.RemotingConnectionImpl.bufferReceived(RemotingConnectionImpl.java:517) [hornetq-core-2.2.13.Final.jar:]

  at org.hornetq.core.remoting.server.impl.RemotingServiceImpl$DelegatingBufferHandler.bufferReceived(RemotingServiceImpl.java:533) [hornetq-core-2.2.13.Final.jar:]

  at org.hornetq.core.remoting.impl.netty.HornetQChannelHandler.messageReceived(HornetQChannelHandler.java:73) [hornetq-core-2.2.13.Final.jar:]

  at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:100) [netty-3.2.6.Final.jar:]

  at org.jboss.netty.channel.StaticChannelPipeline.sendUpstream(StaticChannelPipeline.java:372) [netty-3.2.6.Final.jar:]

  at org.jboss.netty.channel.StaticChannelPipeline$StaticChannelHandlerContext.sendUpstream(StaticChannelPipeline.java:534) [netty-3.2.6.Final.jar:]

  at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:287) [netty-3.2.6.Final.jar:]

  at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.decode(HornetQFrameDecoder2.java:169) [hornetq-core-2.2.13.Final.jar:]

  at org.hornetq.core.remoting.impl.netty.HornetQFrameDecoder2.messageReceived(HornetQFrameDecoder2.java:134) [hornetq-core-2.2.13.Final.jar:]

  at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:80) [netty-3.2.6.Final.jar:]

  at org.jboss.netty.channel.StaticChannelPipeline.sendUpstream(StaticChannelPipeline.java:372) [netty-3.2.6.Final.jar:]

  at org.jboss.netty.channel.StaticChannelPipeline.sendUpstream(StaticChannelPipeline.java:367) [netty-3.2.6.Final.jar:]

  at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:274) [netty-3.2.6.Final.jar:]

  at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:261) [netty-3.2.6.Final.jar:]

  at org.jboss.netty.channel.socket.oio.OioWorker.run(OioWorker.java:100) [netty-3.2.6.Final.jar:]

  at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.2.6.Final.jar:]

  at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:44) [netty-3.2.6.Final.jar:]

  at org.jboss.netty.util.VirtualExecutorService$ChildExecutorRunnable.run(VirtualExecutorService.java:181) [netty-3.2.6.Final.jar:]

  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.7.0_03]

[jaikiran]

FWIW, this looks the same as https://community.jboss.org/thread/198402?tstart=0 (which was opened by another user a few minutes back). It does appear to be a bug. Could you please file a JIRA if it hasn't yet been done?

[tc7]

Ok, I've raised a JIRA (I think!):

https://issues.jboss.org/browse/AS7-4521

[jbertram]

It appears JBoss 7.1.2 nightly snapshot (16th April 2012) has tightened up security somewhat such that credentials are now required for internal pooled connection factory.

It looks to me like your connection factory is actually going to a remote server (rather than being "internal") in which case you will definitely need to configure security credentials since remote connectivity is secured by default.  To be clear, a <pooled-connection-factory> using an in-vm connection factory would not need security credentials since it would be local rather than remote.

Regarding AS7-4521, it has been assigned to the appropriate person and he's acknowledged that it is a bug and is working on a fix.

[tc7]

Justin, yes that is correct. We're attempting to use a single (remote) JMS endpoint for distributed server notifications (a number of standalone JBoss instances). Notifications are received via message driven beans, so that is why the hornetq-ra pooled connection factory is being used (and has been altered to point to the common JMS endpoint within a remote JBoss instance).

I have also noticed that when using the netty connection factory credentials are also required. Only when using a connection factory with an "in-vm" connection can credentials be omitted. I suppose this is reasonable given netty connections (may) be available to other JMS clients.