Skip to main content

[jms-spec users] Re: JMS20Demo app on diff configurations

  • From: Nigel Deakin <nigel.deakin@...>
  • To: Oleg Tsal-Tsalko <oleg.tsalko@...>
  • Cc: users@..., users@...
  • Subject: [jms-spec users] Re: JMS20Demo app on diff configurations
  • Date: Wed, 31 Oct 2012 11:47:05 +0000
  • Organization: Oracle Corporation

Oleg,

On 30/10/2012 21:40, Oleg Tsal-Tsalko wrote:
Hi Nigel
 
Exactly what did you change? Can you say more about what you were trying to do (and why)?
Were you using a GlassFish cluster? I would recommend not trying clustering until you are happy the non-clustered case works.
 
I've run Open MQ broker using imqbrokerd -port 7777.
I've changed <jms-connection-factory> addressList property to mq://localhost:7777 in web.xml file.
No, I'm not usign GlassFish cluster yet:) Trying to do simple thing - get Glassfish work with remote broker, because in real life we almost always using remote brokers and 3rd party providers.
OK, that sounds sensible.


Did you change the GlassFish "JMS broker type" to REMOTE? (Set in the GlassFish admin console). If not then you would have two brokers running, one started by you, and one started automatically by GlassFish, which might be causing confusion. Sounds like there might be confusion about which broker your application was connecting to.

No. I didn't know that I need to change "JMS broker type" to REMOTE. It seams I really have two brokers running... 
Will fix it. Thnx.

When you change the broker type to REMOTE, you should also configure the port on which the remote broker is running (7777) .
If you do this you don't have to configure addressList on the connection factory. The resource adapter will connect to the specified broker anyway.

In the GlassFish admin console, navigate to Configurations --> server-config --> Java Message Service
and set
JMS Service Type to REMOTE
(When I tried that I got a error in the admin console, but it worked anyway)

Then navigate to Configurations --> server-config --> Java Message Service --> JMS Hosts -> default_JMS_host
and set
Port: to 7777 (or whatever)

You can still override the addressList used by a specific connection factory, but since you're simply switching from an embedded broker to a single external broker you don't need to do this.


If not then you would have two brokers running, one started by you, and one started automatically by GlassFish, which might be causing confusion. Sounds like there might be confusion about which broker your application was connecting to.
 
But why it should cause confusion for GlassFish?

I didn't say it would cause confusion for GlassFish. I meant it might cause confusion for you, since if you leave the broker type as "EMBEDDED", and don't configure addressList in your connection factories, you will find you are connecting to the embedded broker rather than the broker you are expecting to connect to.


Build numbers are not always unique, so please give the exact build version, e.g. glassfish-4.0-b61-10_28_2012

I was using glassfish-4.0-b60-10_23_2012.

I just unzipped glassfish-4.0-b61-10_28_2012 and used "asadmin start-domain" to start it . I could point a web browser at localhost:8080 and got the default "your server is now running page". I then typed "asadmin ping-jms" to trigger the startup of the embedded MQ broker, and it started listening on port 7676.
If you create a cluster then different port numbers than these will be used (to avoid port clashes).

Ah. I've got different ports for GF and MQ broker because I've configured my new GF installation's domain using NetBeans. And it seams NetBeans changed ports for me to distingueshed between several GF instances.
Using asadmin tools and default domain I've got default ports!

Not sure about that. Let's try to understand the other issues first.

So what is the reason for that errors running diff receivers examples?

I don't know about the security error, if that's what you are asking about.

The first thing to investigate is to make sure you have only one broker running, and that your applications can connect to it.


If you're using the built-in MQ broker which is started automatically when you start GlassFish, then the message store is under the domain directory (e.g. glassfish-4.0-b61-10_28_2012\glassfish3\glassfish\domains\domain1\imq\instances\imqbroker) or, if you are using a cluster, under the instance directory of each GlassFish instance.
If you have downloaded Open Message Queue and started that broker, then the message store will be under the Open Message Queue installation (e.g. mq5.0-binary\mq\var\instances\imqbroker) 

Understood. So based on behaviour I've observed it seams messages were stored by embedded MQ broker.

When I have time I will try again using latest GF + REMOTE "JMS broker type" and let you know results...

Please configure the port as described above as well. Good luck...

Nigel


Thank you,
Oleg

2012/10/29 Nigel Deakin <nigel.deakin@...>
Oleg,


On 28/10/2012 12:27, Oleg Tsal-Tsalko wrote:
Hi Nigel,

Was running your JMS20Demo application as it is using GF embedded Open MQ broker and it was working perfectly.


Great!


Then I took latest available Open MQ 5.0 bundle, build it and run locally on custom port.
I've changed deployment descriptor for JMSConnectionFactory to point on this separately running Open MQ instance.

Exactly what did you change? Can you say more about what you were trying to do (and why)?

Were you using a GlassFish cluster? I would recommend not trying clustering until you are happy the non-clustered case works.

Did you change the GlassFish "JMS broker type" to REMOTE? (Set in the GlassFish admin console). If not then you would have two brokers running, one started by you, and one started automatically by GlassFish, which might be causing confusion.

However JMS20Demo app's behavior becomes strange:
Among all sender/receiver cases implemented there only _Using the JMS 2.0 simplified API and injection to send a message
(JavaEESenderNewCDI) _seams work. All other cases don't produce errors, but no messages really sent or received.

Sounds like there might be confusion about which broker your application was connecting to.



I thought that GF b56 build might not work with latest available Open MQ 5.0 distribution. I took latest available GF
b60 build to repeat experiment.

Build numbers are not always unique, so please give the exact build version, e.g. glassfish-4.0-b61-10_28_2012


But JMS20Demo app seams not working with GF b60 build at all. Using either embedded Open MQ broker or separate instance
built from latest available sources among all sender cases again works only _Using the JMS 2.0 simplified API and
injection to send a message (JavaEESenderNewCDI)_.

But first receive example _Using the JMS 1.1-style API to receive a message (JavaEESyncReceiverOld)_ crashes with error:

[#|2012-10-28T01:54:53.235+0300|SEVERE|44.0|beans.JavaEESenderOld|_ThreadID=85;_ThreadName=http-listener-1(1);_TimeMillis=1351378493235;_LevelValue=1000;|com.sun.messaging.jms.JMSException:
MQRA:CFA:allocation failure:createConnection:Error in allocating a connection. Cause: MQJMSRA_MC4001:
constructor:Aborting:JMSException on createConnection=[C4060]: Login failed:  user=guest, broker=localhost:7777(57373),
error code: C4060
at com.sun.messaging.jms.ra.ConnectionFactoryAdapter._allocateConnection(ConnectionFactoryAdapter.java:213)
at com.sun.messaging.jms.ra.ConnectionFactoryAdapter.createConnection(ConnectionFactoryAdapter.java:170)
at com.sun.messaging.jms.ra.ConnectionFactoryAdapter.createConnection(ConnectionFactoryAdapter.java:152)
at beans.JavaEESenderOld.sendMessageOld(JavaEESenderOld.java:63)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.glassfish.ejb.security.application.EJBSecurityManager.runMethod(EJBSecurityManager.java:1061)
at org.glassfish.ejb.security.application.EJBSecurityManager.invoke(EJBSecurityManager.java:1133)
at com.sun.ejb.containers.BaseContainer.invokeBeanMethod(BaseContainer.java:4696)
at com.sun.ejb.EjbInvocation.invokeBeanMethod(EjbInvocation.java:624)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:796)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:576)
at org.jboss.weld.ejb.SessionBeanInterceptor.aroundInvoke(SessionBeanInterceptor.java:42)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:857)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:796)
at com.sun.ejb.EjbInvocation.proceed(EjbInvocation.java:576)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.doAround(SystemInterceptorProxy.java:162)
at com.sun.ejb.containers.interceptors.SystemInterceptorProxy.aroundInvoke(SystemInterceptorProxy.java:144)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at com.sun.ejb.containers.interceptors.AroundInvokeInterceptor.intercept(InterceptorManager.java:857)
at com.sun.ejb.containers.interceptors.AroundInvokeChainImpl.invokeNext(InterceptorManager.java:796)
at com.sun.ejb.containers.interceptors.InterceptorManager.intercept(InterceptorManager.java:369)
at com.sun.ejb.containers.BaseContainer.__intercept(BaseContainer.java:4668)
at com.sun.ejb.containers.BaseContainer.intercept(BaseContainer.java:4656)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandler.invoke(EJBLocalObjectInvocationHandler.java:213)
at com.sun.ejb.containers.EJBLocalObjectInvocationHandlerDelegate.invoke(EJBLocalObjectInvocationHandlerDelegate.java:88)
at $Proxy167.sendMessageOld(Unknown Source)
at beans.__EJB31_Generated__JavaEESenderOld__Intf____Bean__.sendMessageOld(Unknown Source)
at servlets.Servlet1.handle(Servlet1.java:165)
at servlets.Servlet1.processRequest(Servlet1.java:113)
at servlets.Servlet1.doGet(Servlet1.java:134)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at org.apache.catalina.core.StandardWrapper.service(StandardWrapper.java:1593)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:285)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:665)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:604)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:162)
at org.apache.catalina.connector.CoyoteAdapter.doService(CoyoteAdapter.java:337)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:240)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:172)
at org.glassfish.grizzly.http.server.HttpHandler.doHandle(HttpHandler.java:164)
at org.glassfish.grizzly.http.server.HttpServerFilter.handleRead(HttpServerFilter.java:175)
at org.glassfish.grizzly.filterchain.ExecutorResolver$9.execute(ExecutorResolver.java:119)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:265)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:200)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:134)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:781)
at org.glassfish.grizzly.strategies.AbstractIOStrategy.fireIOEvent(AbstractIOStrategy.java:112)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.run0(WorkerThreadIOStrategy.java:115)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy.access$100(WorkerThreadIOStrategy.java:55)
at org.glassfish.grizzly.strategies.WorkerThreadIOStrategy$WorkerThreadRunnable.run(WorkerThreadIOStrategy.java:135)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:578)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:558)
at java.lang.Thread.run(Thread.java:722)
Caused by: javax.resource.spi.ResourceAllocationException: Error in allocating a connection. Cause: MQJMSRA_MC4001:
constructor:Aborting:JMSException on createConnection=[C4060]: Login failed:  user=guest, broker=localhost:7777(57373),
error code: C4060
at com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:312)
at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:195)
at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:170)
at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:165)
at com.sun.messaging.jms.ra.ConnectionFactoryAdapter._allocateConnection(ConnectionFactoryAdapter.java:211)
... 66 more
Caused by: com.sun.appserv.connectors.internal.api.PoolingException: MQJMSRA_MC4001: constructor:Aborting:JMSException
on createConnection=[C4060]: Login failed:  user=guest, broker=localhost:7777(57373), error code: C4060
at com.sun.enterprise.resource.pool.datastructure.RWLockDataStructure.addResource(RWLockDataStructure.java:103)
at com.sun.enterprise.resource.pool.ConnectionPool.addResource(ConnectionPool.java:282)
at com.sun.enterprise.resource.pool.ConnectionPool.createResourceAndAddToPool(ConnectionPool.java:1512)
at com.sun.enterprise.resource.pool.ConnectionPool.createResources(ConnectionPool.java:944)
at com.sun.enterprise.resource.pool.ConnectionPool.initPool(ConnectionPool.java:230)
at com.sun.enterprise.resource.pool.ConnectionPool.internalGetResource(ConnectionPool.java:511)
at com.sun.enterprise.resource.pool.ConnectionPool.getResource(ConnectionPool.java:381)
at com.sun.enterprise.resource.pool.PoolManagerImpl.getResourceFromPool(PoolManagerImpl.java:245)
at com.sun.enterprise.resource.pool.PoolManagerImpl.getResource(PoolManagerImpl.java:170)
at com.sun.enterprise.connectors.ConnectionManagerImpl.getResource(ConnectionManagerImpl.java:343)
at com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:306)
... 70 more
Caused by: com.sun.appserv.connectors.internal.api.PoolingException: MQJMSRA_MC4001: constructor:Aborting:JMSException
on createConnection=[C4060]: Login failed:  user=guest, broker=localhost:7777(57373), error code: C4060
at com.sun.enterprise.resource.pool.ConnectionPool.createSingleResource(ConnectionPool.java:924)
at com.sun.enterprise.resource.pool.ConnectionPool.createResource(ConnectionPool.java:1189)
at com.sun.enterprise.resource.pool.datastructure.RWLockDataStructure.addResource(RWLockDataStructure.java:98)
... 80 more
Caused by: com.sun.appserv.connectors.internal.api.PoolingException: MQJMSRA_MC4001: constructor:Aborting:JMSException
on createConnection=[C4060]: Login failed:  user=guest, broker=localhost:7777(57373), error code: C4060
at com.sun.enterprise.resource.allocator.NoTxConnectorAllocator.createResource(NoTxConnectorAllocator.java:148)
at com.sun.enterprise.resource.pool.ConnectionPool.createSingleResource(ConnectionPool.java:907)
... 82 more
Caused by: javax.resource.spi.ResourceAdapterInternalException: MQJMSRA_MC4001: constructor:Aborting:JMSException on
createConnection=[C4060]: Login failed:  user=guest, broker=localhost:7777(57373), error code: C4060
at com.sun.messaging.jms.ra.ManagedConnection.<init>(ManagedConnection.java:201)
at com.sun.messaging.jms.ra.ManagedConnectionFactory.createManagedConnection(ManagedConnectionFactory.java:226)
at com.sun.enterprise.resource.allocator.NoTxConnectorAllocator.createResource(NoTxConnectorAllocator.java:128)
... 83 more
Caused by: com.sun.messaging.jms.JMSSecurityException: [C4060]: Login failed:  user=guest, broker=localhost:7777(57373)
at com.sun.messaging.jmq.jmsclient.ProtocolHandler.authenticate(ProtocolHandler.java:1137)
at com.sun.messaging.jmq.jmsclient.ProtocolHandler.hello(ProtocolHandler.java:1044)
at com.sun.messaging.jmq.jmsclient.ProtocolHandler.hello(ProtocolHandler.java:935)
at com.sun.messaging.jmq.jmsclient.ConnectionImpl.hello(ConnectionImpl.java:588)
at com.sun.messaging.jmq.jmsclient.ConnectionImpl.openConnection(ConnectionImpl.java:2503)
at com.sun.messaging.jmq.jmsclient.ConnectionImpl.init(ConnectionImpl.java:1154)
at com.sun.messaging.jmq.jmsclient.ConnectionImpl.<init>(ConnectionImpl.java:466)
at com.sun.messaging.jmq.jmsclient.UnifiedConnectionImpl.<init>(UnifiedConnectionImpl.java:66)
at com.sun.messaging.jmq.jmsclient.XAConnectionImpl.<init>(XAConnectionImpl.java:64)
at com.sun.messaging.XAConnectionFactory.createXAConnection(XAConnectionFactory.java:97)
at com.sun.messaging.jms.ra.ManagedConnection.<init>(ManagedConnection.java:197)
... 85 more
|#]

It seams in latest GF it has been changed not only default GF HTTP listener port (from 8080 to 26682) and embedded Open
MQ default port (from 7676 to 26678)

I just unzipped glassfish-4.0-b61-10_28_2012 and used "asadmin start-domain" to start it . I could point a web browser at localhost:8080 and got the default "your server is now running page". I then typed "asadmin ping-jms" to trigger the startup of the embedded MQ broker, and it started listening on port 7676.

If you create a cluster then different port numbers than these will be used (to avoid port clashes).


but also some default auth policy for JMS clients...

Not sure about that. Let's try to understand the other issues first.



Another thing which is not really clear for me. When I'm using either embedded Open MQ broker or separate broker
instance with same GF server I can see old messages in queues. When I've moved to new GF instance I've got fresh new
clean queues. It seams that messages are stored not on broker side but on GF side.

If you're using the built-in MQ broker which is started automatically when you start GlassFish, then the message store is under the domain directory (e.g. glassfish-4.0-b61-10_28_2012\glassfish3\glassfish\domains\domain1\imq\instances\imqbroker) or, if you are using a cluster, under the instance directory of each GlassFish instance.

If you have downloaded Open Message Queue and started that broker, then the message store will be under the Open Message Queue installation (e.g. mq5.0-binary\mq\var\instances\imqbroker)


This is also strange for me.

I'm a bit confused by this strange behaviour. You might say all is ok, cause I just missed smth. Or probably there are
some bugs.
Please advice. I've put in CC GF mailing list as well. Probably it is more question to GF experts...

Thank you,
Oleg

You're welcome,

Nigel



[jms-spec users] JMS20Demo app on diff configurations

Oleg Tsal-Tsalko 10/28/2012

[jms-spec users] Re: JMS20Demo app on diff configurations

Nigel Deakin 10/29/2012

[jms-spec users] Re: JMS20Demo app on diff configurations

Oleg Tsal-Tsalko 10/30/2012

[jms-spec users] Re: JMS20Demo app on diff configurations

Nigel Deakin 10/31/2012
 
 
Close
loading
Please Confirm
Close