Andreas,
I've changed my test code/environment to have a TCF (with Spring using
a CF). I've also changed the pool name (another difference in the
environments is that locally we use the JNDI name as the pool name and
in the failing environment they don't). With those changes, we are
still working fine locally and failing in the other environment.
The logs still show NPEs thrown by Glassfish so I'm going to do the
following:
* send this issue to the Glassfish email listserv
* completely shutdown/sync/restart our cluster
I should note that our JDBC pool keeps switching from XA to non-XA for
no known reason (in the failing environment) so clearly there is something
going on there. The only other difference is the SecurityManager which
I've not tried.
Thanks for all your help - I greatly appreciate it (and especially that
your hours seem to line up with ours but you are in Germany).
I'm still working on a more full test program and am hoping to include
the MessageEndpoint listener in Spring just to have a good test suite.
Let me know if you want that code.
Cheers,
Brian
----- Original message -----
From: "Andreas Loew" <Andreas.Loew_at_Sun.COM>
To: users_at_jmsjca.dev.java.net
Date: Tue, 13 Jan 2009 23:33:20 +0100
Subject: Re: Sessions are already closed / now NPEs
Brian,
sorry for the delays in my replies - I am quite busy and will be
travelling for the rest of this week, so I won't be too responsive...
My first question/request would still be:
Have you fixed the resource type in the connection pool definition to
become javax.jms.ConnectionFactory (from
javax.jms.TopicConnectionFactory)? Please do so immediately if you
haven't done so yet before trying anything else - this might well be the
root cause for the NPE!!!
And please bounce your complete cluster - i.e. all instances as well as
the DAS - afterwards, because (at least with AppServer 8.x) I know about
mysterious things going on if you modify the very basic settings within
existing pool or resource definitions (such as the resource type). You
can safely work around them by freshly starting everything.
More comments inline.
Brian Repko schrieb:
> 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.
Completely fine and as recommended.
> 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.
Also completely fine. The pool will be created within an instance if and
only if at least one resource referencing it is targeted into the instance.
> 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?
Sorry, this would be a question to our MQ folks. I tend to think that
the client JMS connection object should silently fail over without
needing client attention, but I have no experience so far with
SunMQ/OpenMQ clusters, so I cannot answer this :-(
> ----- 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
>
> 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.
My clear recommendation is: Don't try to fiddle with your code, but
change the JMS resource definition to refer to the 1.1 generic
ConnectionFactory, and you should be fine without any code changes :-)
> I don't recall any permissions that were required by the RA - if that is
> not correct, please let me know.
Why don't you simply try to deactivate the Security manager for a test
run and see whether it makes a difference? (But not that I am aware of
any potential permissions issue...)
> 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.
Looks like you solved that later (your more recent deployment as
described above sounds fine).
> 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.
I think that if you truly hit a JMSJCA issue (I still think this is a
configuration issue of some sort), Frank will take care of this! :-)
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