Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-users] Experiments with Glassfish and coordinated caching

I don't have any advice to offer--but instead a request. :-)  It would be great if you could capture what you have to do to get this working in GlassFish on the EclipseLink Examples Wiki page?  The mailing list postings are picked up by search engines but it's not fun trying to piece together a solution from a series of postings.  A wiki page with the final configuration instructions would be ideal for anyone looking to do this.  All you need is an Eclipse Bugzilla account create a page on the wiki.

--Shaun

wintermute@xxxxxxxxxxxxxxxxxx wrote:
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="" 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.errorBindingConnection(RemoteCommandManagerException.java:87)
        at org.eclipse.persistence.sessions.coordination.rmi.RMITransportManager.createLocalConnectionInRegistry(RMITransportManager.java:160)
        at org.eclipse.persistence.sessions.coordination.rmi.RMITransportManager.createLocalConnection(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.createLocalConnectionInRegistry(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
_______________________________________________
eclipselink-users mailing list
eclipselink-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-users

--


Oracle
Shaun Smith | Principal Product Manager, TopLink | +1.905.502.3094
Oracle Fusion Middleware
110 Matheson Boulevard West, Suite 100
Mississauga, Ontario, Canada L5R 3P4

Back to the top