Andreas/Frank,
Ok...this might not be an RA issue. The stack trace now shows the root
NPE (not sure why it didn't before...). It is:
Caused by: java.lang.NullPointerException
at com.sun.enterprise.resource.PoolManagerImpl.getResourceFromPool(PoolManagerImpl.java:248)
at com.sun.enterprise.resource.PoolManagerImpl.getResource(PoolManagerImpl.java:176)
at com.sun.enterprise.connectors.ConnectionManagerImpl.internalGetConnection(ConnectionManagerImpl.java:337)
at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:189)
at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:165)
at com.sun.enterprise.connectors.ConnectionManagerImpl.allocateConnection(ConnectionManagerImpl.java:158)
at com.stc.jmsjca.core.JConnection.createSessionByApplication(JConnection.java:131)
... 36 more
and that code looks like:
public ResourceHandle getResourceFromPool(ResourceSpec spec, ResourceAllocator alloc, ClientSecurityInfo info, Transaction tran) throws PoolingException {
ResourcePool pool = getPool( spec.getConnectionPoolName() );
// pool.getResource() has been modified to:
// - be able to create new resource if needed
// - block the caller until a resource is acquired or
// the max-wait-time expires
return pool.getResource(spec, alloc, tran); <<<<<< line 248
}
so the call getPool returns null.
In terms of architecture and clustering, I'm wondering a few things. Here is our setup.
We run a DAS on machine0.
We then run cluster1 with instance1-1 and instance1-2 on machine1 and machine2 respectively.
We also run cluster2 with instance2-1 and instance2-2 on machine1 and machine2 respectively.
We are deploying the RAR in the GF admin console and when we do that we choose to target it
to the DAS as well as cluster1 and cluster2. We had to include the DAS since creating pools
threw ClassCastExceptions without it. But I'm wondering now where the connector connection
pool is actually held - in the DAS VM or in the instances (or both). The pool is not
targeted - only the connector resource (JNDI reference) to it. So where does the actual
connection originate from? I'll do a netstat and take a look. If they are in the DAS then
that would explain why bouncing the cluster had no effect. We never bounce the DAS.
One other thought related to the connection URL of mq://machine1:xxx/,mq://machine2:xxx.
We bounce our clusters by stopping/starting one instance and then the other. If the first
broker goes down, then connections go over to the second one. But then the second machine
goes down (though the first one is back up) do the connections try to get the next URL and
fail? Or does every get-connection-from-pool try to reconnect starting from the first one?
Brian
----- Original message -----
From: "Brian Repko" <brianrepko_at_fastmail.us>
To: users_at_jmsjca.dev.java.net
Date: Mon, 12 Jan 2009 14:32:15 -0600
Subject: Re: Sessions are already closed / now NPEs
Andres,
Yes - there is a big try block that is throwing the NPE and then the stack
trace gets swallowed by the exception handling block. I will be getting
the code from CVS because the source in the jar most likely doesn't include
any build process.
We are trying to connect to the existing clustered OpenMQ brokers that
exist with our Glassfish cluster. So I will try to mixing the JMS 1.1
and 1.0.2 syntax to see if that breaks and is the problem.
The difference between the failing scenario and my test scenarios are:
1. failing scenario has full code base / test scenario has code meant for you
2. failing scenario is cluster / test scenario is a DAS
3. failing scenario has a security manager / test scenario doesn't
Both pieces of code are doing outbound and inbound on the same CF/TCF
and Dest/Topic. Its not the same connection/session - just the same
administered objects. Just as I had documented before.
I don't recall any permissions that were required by the RA - if that is
not correct, please let me know.
I'm trying to deploy to a cluster but now I can't even get the RA to work
in a clustered environment and when I deploy my application the JNDI does
contain the CF nor the Topic.
I've not tried with the security manager but may depending on the test
above.
I can ask them to turn on logging in the failing scenario - that might
help a bit.
I will also download the source but we are not interested in running in
production with home grown patches.
Thanks!
Brian
----- Original message -----
From: "Andreas Loew" <Andreas.Loew_at_Sun.COM>
To: users_at_jmsjca.dev.java.net
Date: Mon, 12 Jan 2009 18:26:16 +0100
Subject: Re: Sessions are already closed / now NPEs
Sorry Brian,
I was even trying to make it more complex as it indeed is:
There is no NPE thrown from this:
Andreas Loew schrieb:
> throw Exc.jmsExc(LOCALE.x("E034: Could not create session {0}: {1}",
> sessionClass.getName(), ex), ex);
but rather, the hidden "ex" being thrown is the infamous NPE, as you can
see from the fact that the following ends up in the log:
2009-01-11 23:26:34,699 ERROR [httpSSLWorkerThread-50011-4]:cluster1svr3
(SpringJmsBroadcastListener.java:219) - unable to send message
javax.jms.JMSException: JMSJCA-E034: Could not create session
javax.jms.Session: java.lang.NullPointerException
So do an ex.printStackTrace() before line 153 and you'll find out about
the NPE.
And just one more important finding:
In your connection pool definition, you register a
javax.jms.TopicConnectionFactory in JNDI. Therefore, from the
SpringTemplate, you get a TopicConnectionFactory instance (and *not* the
generic javax.jms.ConnectionFactory from JMS 1.1).
From the way the old-style JMS 1.0.2 API had been designed, it is only
legal to call createTopicConnection() on this TopicConnectionFactory
(and not createConnection()), and on the topicConnection returned fron
this, you may only call createTopicSession() (and not createSession()).
Or - if you have a JMS 1.1 provider - simply change your connection pool
definition to provide the generic javax.jms.ConnectionFactory from the
pool - should be much easier... :-)
Maybe this is what got you into these troubles...
I wouldn't bet on it, but chances are not too bad... ;-)
Keeping my fingers crossed...
Best regards
Andreas
--
Andreas Loew
Senior Java Architect
Sun Microsystems (Germany)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jmsjca.dev.java.net
For additional commands, e-mail: users-help_at_jmsjca.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jmsjca.dev.java.net
For additional commands, e-mail: users-help_at_jmsjca.dev.java.net