[i]"Certainly setting ClientID through the supported API would do a bit more than just set that field in the conneciton; for example it sends ClientID to the broker."
[/i]
I am unable to set the ClientID via the API. This is a slippery slope. To set a clientID on the connection I would need to set it in one of two ways:
1 - set it on the connection returned from the ConnectionFactory. To do this I would need to make code changes to EclipseLink. Not entirely out of the question but I have tried this. The end result was the Exception being thrown from the following code bock from the class com.sun.messaging.jms.ra.ConnectionAdapter:
145 public void
146 setClientID(String clientId)
147 throws JMSException
148 {
149 _loggerJC.entering(_className, "setClientID()", clientId);
150 //System.out.println("MQRA:CA:setClientID-to-"+clientId);
151 if (!inACC) {
152 [i]throw new com.sun.messaging.jms.JMSException("MQRA:CA:Unsupported-setClientID()");[/i]
153 }
154 checkClosed();
155 xac.setClientID(clientId);
156 }
2 - Set the clientID on the connection that is returned from the GlassFish container. This can be accomplished by specifying the clientID on the ConnectionFactory bound in JNDI and allowing GlassFish to set the clientID prior to returning it to the caller/client. This would work if only there were a way to have GlassFish create a unique ID or maybe simply assign the next number. But the way it works currently, GlassFish assigns the static value specified. This works if there is only one connection acquired from the ConnectionFactory. Otherwise the second connection gets the same clientID and an exception is raised by the broker stating that the ClientID is already in use.
[i]"is there a way of monitoring whether it is replicating data between the instance correctly?"[/i]
I have confirmed that EclipseLink is replicating the data between the instances. The easiest way to do this was to open two browsers, each pointing to the an application instance on the two GlassFish servers. I was able to perform an update within one instance of the application and see the changes in the other instance get propagated over. So it appears things are synchronizing across the Topic.
[i]"Do you mean "the second instance of Glassfish"?"[/i]
No, I mean the second instance of OpenMQ. We brought down one broker in the cluster, so there was only a single broker operating. We then brought up the GlassFish cluster, which contains two instances of GlassFish. This was able to provide us with stability.
[i]"I'll pass your comments on to management. "[/i]
Please do. It was very difficult getting GlassFish in house. (an uphill battle to put it lightly) And now when we need the support assistance we can't seem to get a prompt response. This doesn't sit well with some (like myself) while others are very pleased about it as it gives them a reason for getting Sun out of here.
Nigel, thank you again for giving me your assistance and patience. It's greatly appreciated.
Chris
[Message sent by forum member 'cmathrusse' (cmathrusse)]
http://forums.java.net/jive/thread.jspa?messageID=353801