Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipselink-users] Experiments with Glassfish and coordinated caching 
Hi List,
has anyone succeeded in setting up cache coordination in Glassfish? Elllen?
I'm using a session customizer and experimented a bit with RMI and JMS coordination. Here's what I did and the results I got. 

1. JMS

I see two approaches, but I'm not sure if both of them are sane.
First approach: Use a single JMS topic, perhaps on the DAS, and connect all cluster instances to this topic. I tried this:
RemoteCommandManager rcm = new RemoteCommandManager((CommandProcessor) session); 
Hashtable properties = new Hashtable(2);
properties.put(Context.PROVIDER_URL,"iiop://DAS.devel:3700");
properties.put (Context.INITIAL_CONTEXT_FACTORY,"com.sun.appserv.naming.S1ASCtxFactory" ); 
				
tm.setTopicHostUrl("tcp://DAS.devel:7676");
tm.setLocalContextProperties(properties);
tm.setRemoteContextProperties(properties);
tm.setTopicName("jms/cachecoordination");
tm.setTopicConnectionFactoryName("jms/connectionFactory");
tm.setUserName("guest");
tm.setPassword("guest");
	
rcm.setTransportManager(tm);
((DatabaseSession)session).setShouldPropagateChanges(false);
((DatabaseSession)session).setCommandManager(rcm);
rcm.initialize();
This didn't work out at all. For some reason, looking up the remote connection factory failed. Took me some time to figure out what was going on: Apparently, when Glassfish JARs are on the classpath , Context.PROVIDER_URL is ignored. At least in my case, the lookup always went to localhost:3700, no matter what I supplied as Context.PROVIDER_URL. So, no luck.
Second approach: Use factories and topics deployed to the cluster and do local lookups on the cluster instances, hoping that GF clustering will somehow figure out the details of passing messages around in the background. So I cluster-deployed the connection factory and the topic and replaced DAS.devel:3700 with 127.0.0.1:33700 and set the topic host to localhost:37676.
Lookup worked , but trying to use the same (clustered) application as a client for JMS seems to be a bad idea:
Exception Description: Could not create local JMS connection with Topic jms/cachecoordination, Topic Factory jms/connectionFactory, and Context properties {java.naming.factory.initial=com.sun.appserv.naming.S1ASCtxFactory, java.naming.provider.url=iiop://127.0.0.1:33700, java.naming.security.principal=guest, java.naming.security.credentials=24D77DC031B68CE91A372A5A33219416} Internal 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(36560)
Got it: Same client ID for all cluster instances, different IDs needed for durability. Unfortunately, I have no idea how to either turn off durability or set client IDs. 


2. RMI
Let's try RMI then, I thought, and, using code fragments posted to this list, came up with this code:
RemoteCommandManager rcm = new RemoteCommandManager((CommandProcessor) session); 
rcm.getDiscoveryManager().setMulticastGroupAddress("226.1.2.3");
rcm.getDiscoveryManager().setMulticastPort(3122);
rcm.setShouldPropagateAsynchronously(true);
rcm.getDiscoveryManager().setAnnouncementDelay(5);
rcm.getTransportManager().setNamingServiceType (TransportManager.REGISTRY_NAMING_SERVICE); 
rcm.setUrl("rmi://$HOST:33700");
rcm.setServerPlatform(session.getServerPlatform());
((DatabaseSession)session).setCommandManager(rcm);
((DatabaseSession)session).setShouldPropagateChanges(false);
rcm.initialize();
The session customizer terminates orderly, but after some time, I get the following exception:
Exception Description: Could not post connection in local naming service under name rmi://192.168.23.12:33700/11657788 Internal Exception: java.rmi.ConnectIOException: error during JRMP connection establishment; nested exception is: 
        java.io.EOFException
at org.eclipse.persistence.exceptions.RemoteCommandManagerException.errorBi ndingConnection(RemoteCommandManagerException.java:87) at org.eclipse.persistence.sessions.coordination.rmi.RMITransportManager.cr eateLocalConnectionInRegistry(RMITransportManager.java:160) at org.eclipse.persistence.sessions.coordination.rmi.RMITransportManager.cr eateLocalConnection(RMITransportManager.java:113) at org.eclipse.persistence.sessions.coordination.DiscoveryManager.run (DiscoveryManager.java:197) 
        at java.lang.Thread.run(Thread.java:619)
Caused by: java.rmi.ConnectIOException: error during JRMP connection establishment; nested exception is: 
        java.io.EOFException
at sun.rmi.transport.tcp.TCPChannel.createConnection (TCPChannel.java:286) at sun.rmi.transport.tcp.TCPChannel.newConnection (TCPChannel.java:184) 
        at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:322)
        at sun.rmi.registry.RegistryImpl_Stub.rebind(Unknown Source)
        at java.rmi.Naming.rebind(Naming.java:160)
at org.eclipse.persistence.sessions.coordination.rmi.RMITransportManager.cr eateLocalConnectionInRegistry(RMITransportManager.java:157) 
        ... 3 more
Caused by: java.io.EOFException
        at java.io.DataInputStream.readByte(DataInputStream.java:250)
at sun.rmi.transport.tcp.TCPChannel.createConnection (TCPChannel.java:228) 
        ... 8 more

I'm totally lost here. EOF? Uh? Probably RMI isn't at 3700 at all?
Perhaps somebody has already had more success and could help me out. I'd prefer the JMS solution in the long term, but for now, RMI would also do. If not, maybe I have at least documented the current state of things in the cache-coordination-with-GF case. 



Kind regards from Berlin,

rv

Back to the top