Hi Pablo,
Did you get any responses on this issue yet? What do you mean with your
PS line at the and by switching the the MQ to EMBEDDED exactyl?
I am planning for a similar setup actually (GFv3 + Eclipselink +
Terracotta). After I learned that the v3perlude does not have cluster
support and I heard of some rumors of issues clustering v2.1 I decided
to wait till v3.
I really wonder now how good the cluster support of glassfish &
eclipliselink will be.
Have you considered integrating the JPA provider with Terracotta? Last
time I checked they did not support it officially but I really think
this would ease up a lot of things also for monitoring and
maintainability.
Cheers Ben
-----Original Message-----
From: glassfish_at_javadesktop.org [mailto:glassfish_at_javadesktop.org]
Sent: Mittwoch, 4. November 2009 04:43
To: users_at_glassfish.dev.java.net
Subject: Has anyone managed to set cache coordination in cluster? Hard
to believe!!!
Hi guys
When it comes to choose an application server for your production
environment, there are a few choices. We went for Glassfish (Reference
Implementation).
When it came to choosing a persistence provider, we went for EclipseLink
(RI).
When it came to set up the cache co-ordination in our cluster, we went
for the JMS option (as per EclipseLink recommendation)
GlassFish 2.1 (in cluster with two node agents in two separate machines,
one instance each nodeagent) (JEE5 reference implementation) EclipseLink
1.2 (JPA reference implementation) JMS resources for the cache
coordination
As per the recommendation, I went for the JMS option: On the book, this
task can be accomplised by either setting up a bunch of properties in
persistence.xml or implementing a SesisonCustomizer
After realising that the Persistence Unit Propeties where not always
being processed, I decided to go for the session customizer option ,
this meant goind to the pretty bad docs at eclipse.org wiki, a bit of
fortune telling and days of waiting for help from the forums
after that I managed to get it more or less like this:
------------------------------------------------------------------------
--------
public void customize(Session session) throws Exception {
RemoteCommandManager rcm = new RemoteCommandManager((CommandProcessor)
session); java.util.Properties props = new java.util.Properties();
props.put(Context.PROVIDER_URL, );
props.put(Context.INITIAL_CONTEXT_FACTORY, getInitialContextFactory());
JMSTopicTransportManager tm = new JMSTopicTransportManager(rcm);
tm.setTopicHostUrl(getTopicHostURL());
tm.setInitialContextFactoryName("com.sun.appserv.naming.S1ASCtxFactory")
;
tm.setTopicName(getJmsTopicName());
tm.setTopicConnectionFactoryName(getJmsConnectionFactoryName());
tm.setUserName(getUserName());
tm.setPassword(getPassword());
------------------------------------------------------------------------
--------
The first couple of days, me and a couple of mates here, broke our heads
trying to work out the right url for the getTopicHostURL(), As we are
deploying to a cluster, we didn't know which of the instances in the
cluster should we use as the "TopicHost" and what where we going to do
if that instance failed. In the beggining we thought that the url for
looking up the jms resources would ve like mq://machine:7676 or like.
For any application running in glassfish (weather clustered or not), to
find these two JMS resources it is as easy as
new InitialContext().lookup("jms/myTopic")
new InitialContext().lookup("jms/myConnectionFactory")
Jet, for EclipseLink seems to see a hell of a lot more complex:
If I don't provide the
tm.setInitialContextFactoryName("com.sun.appserv.naming.S1ASCtxFactory")
;
it will use a WebLogic InitialContextFactory for the InitialContext
lookup
If I dont' provide the getTopicHostURL() It will use some other
missleading value, starting with ormi:// and the name of the machine in
which it is running If I don't provide the user name, it will use
"admin" while glassfish prefers "guest"
And a series of other make it more difficult and complex than what it
really is.
After a few days, not being eabke ti get the thing going, I downloaded
the EclipseLink sources, which I thought would be more informative than
the wiki or the docs.
In the end, as I couldn't understand at the time which topicHostURL to
use and for me it was so easy to find these resources I overrided the
method where the Eclipselink JMSTransportManager looks up for the
resources and avoiding the lookup I would pass it the resources I had
already looked up: It came to something like this:
final TopicConnectionFactory connectionFactory =
(TopicConnectionFactory) ic.lookup(cfName); final Topic topic = (Topic)
ic.lookup(topicName);
JMSTopicTransportManager jmsTtm = new JMSTopicTransportManager(cm2) {
@Override
protected JMSTopicRemoteConnection createConnection(boolean
isLocalConnectionBeingCreated) throws RemoteCommandManagerException {
Context remoteHostContext = null; try {
TopicConnection topicConnection =
connectionFactory.createTopicConnection();
// external connection is a puiblisher; local connection is a subscriber
return new JMSTopicRemoteConnection(rcm, topicConnection, topic,
isLocalConnectionBeingCreated); } catch (Exception ex) {
ex.printStackTrace(); RemoteCommandManagerException rcmException; if
(isLocalConnectionBeingCreated) { rcmException =
RemoteCommandManagerException.errorCreatingLocalJMSConnection(topicName,
connectionFactoryName, getRemoteContextProperties(), ex); } else {
rcmException =
RemoteCommandManagerException.errorCreatingJMSConnection(topicName,
connectionFactoryName, getRemoteContextProperties(), ex); } throw
rcmException; } finally { if (remoteHostContext != null) { try {
remoteHostContext.close(); } catch (NamingException namingException) {
// ignore } } } }
@Override
public Context getRemoteHostContext(String url) {
throw new RuntimeException("This method should never be called");
try {
//return super.getRemoteHostContext(url);
return new InitialContext();
} catch (Exception e) {
e.printStackTrace();
throw new RuntimeException();
}
}
@Override
protected Topic getTopic(Context remoteHostContext) {
log.info("JMSTopicTransportManager patch returning topic: " + topic);
return topic; }
@Override
protected TopicConnectionFactory getTopicConnectionFactory(Context
remoteHostContext) { log.info("JMSTopicTransportManager patch returning
cf: " + tcf); return connectionFactory; } };
Anyways, Once I managed to let this JMSTopicTransportManager find its
Topic and TopicConnectionFactory, the connection tries to start, but
this is what happens:
Exception: com.sun.messaging.jms.JMSException: ADD_CONSUMER_REPLY(15)
C4036: A broker error occurred. :412 B4135: Cannot add durable consumer
null. No ClientID was set on connection. user=guest,
broker=localhost:37676(59279)
As usual, I copy the exception, paste it on google search box, click
search, first result: open bug in glassfish, one year ago, still not
resolved. And as it has "apparently already been addressed in V3" why
bother with V2.
Apparently, eventhough eclipselink tries to create a basic JMS consumer
MQ attempts to create a "durable-Consumer" (this only happens when
running in clustered environment), for which it needs a connection Id,
(that you basically can't set unless you are in an application client
container, there you go)
https://glassfish.dev.java.net/issues/show_bug.cgi?id=6580
Spent another bunch of hours trying to get my head around the "work
around's" but I tell you it wasn't easy. At this point it was like... So
now what... now that we have spent three good months building our
application on glassfish+eclipselink, what do we do? try to switch to
Jboss?, try to switch to Hibernate?, get rid of the cluster and deploy
to a standalone server?
Now guys, tell me the truth, has anyone been eable to set this JMS cache
coordination in a glassfish cluster? It seems really hard to believe.
Pablo.
p.s. apparently swictching the MQ to EMBEDDED solves the problem
[Message sent by forum member 'pablopina' (roastedbanana_at_yahoo.com)]
http://forums.java.net/jive/thread.jspa?messageID=370411
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
For additional commands, e-mail: users-help_at_glassfish.dev.java.net