Hi Brian, hi Frank,
Brian Repko schrieb:
> The jmsra only delivers messages to one listener per app even with a Topic.
> The genericjmsra can't parse its parameters to work with a cluster. And
> now with jmsjca we are getting NPEs trying to send messages in both of our
> 2 scenarios.
to me a NPE sounds like something that should be trackable down to its
root cause - so please don't give up too early...
Using the 6.0.1 snapshot sources from
https://maven-repository.dev.java.net/nonav/repository/com.stc.jmsjca/java-sources/raunifiedjms-6.0.1-SNAPSHOT-sources.jar
com.stc.jmsjca.util.Exc.jmsExc(Exc.java:100)
points to the following statement:
ret = new JMSException(msg.toString());
so the only way this can throw a NPE is in case msg is null...
Next line in the call stack is
com.stc.jmsjca.core.JConnection.createSessionByApplication(JConnection.java:153)
which gives us:
throw Exc.jmsExc(LOCALE.x("E034: Could not create session {0}: {1}",
sessionClass.getName(), ex), ex);
This means that the call to LOCALE.x() would return have returned null -
but now I am at my wits' end, because I don't see from the code how
this would/should have happened...
My suggestion on how to move forward:
Patch class com.stc.jmsjca.core.JConnection to print the value of
sessionClass as well as the value of ex (using printStackTrace) before
reaching line 153, and tell us what you find.
Unfortunately, this will only help finding out about the NPE - what must
then be done is to address the underlying exception ex (which currently
unfortunately is hidden).
> Scenario 1 - sending the message via standard JMS code
> Scenario 2 - sending a message with Spring JmsTemplate
I fully agree that what you are seeing is the exact same exception,
which probably proves that it's not the Spring-style approach to blame,
but some interesting different issue, and from my guts feeling most
probably a configuration issue...
> I've tried to put sample code together but can't get it to fail but I'm not sure if its
> related to all the transients in the code or the fact that these errors are on the cluster
> and I'm running in the local DAS.
This statement also is most interesting: If you cant't get the sample
app that you have designed to reproduce the exact same error behaviour
to fail in the same way like your original app, then what other
differences between both are there regarding their setup?
> Any clues before we pull the plug and go with ActiveMQ?
Besides as stated above about the NPE: Yes, another one related to your
own statement below - see there for the details...
> How to turn on debugging for the RA code?
That's an easy one: Simply set the log level for the JMSJCA root package
(com.stc.jmsjca) to FINEST. This can be done through the admin console
even without requiring a GF instance restart.
> They did have the steady pool size set to 1 and validate connections turned off but we
> have since changed those to 0/true, rebooted and are still getting the same errors.
I think that this kind of connection pool details can safely be regarded
as being unrelated...
> My only thought is to change the listener to be as Andreas suggests - could this be
> based on our listener setup? All our errors are on the outbound side.
@Brian:
This might indeed be a valid starting point for the issue that leads to
the above hidden Exception ex being thrown - let me ask some more questions:
- Does the NPE only occur in those cases where you have been using the
same JMS Connection and Session instances as retrieved from the
*outbound* RA in order to receive messages before?
- Or do you also see the NPE when you refrain from receiving an inbound
message before and simply use the Connection/Session as retrieved from
the RA in order to send outbound messages?
- Would it even be possible that exactly this (using the outbound
Connection/Session to receive messages) makes up the difference between
the test case that cannot be made to fail and your real-world app?
@Frank:
1) Any known issues with the localization support that might cause the NPE?
2) Also, do you have any idea what might causing the hidden "ex" to be
thrown and caught at createSessionByApplication() line 143?
Hope this helps & best regards,
Andreas
--
Andreas Loew
Senior Java Architect
Sun Microsystems (Germany)