On 21/06/2011 02:47, Amy Kang wrote:
> On 11-06-20 07:36 AM, Eugene Kondrashev wrote:
>> Hi again
>> Thanks for the links but i still have a question
>>
>> I need to model the relationship between the jms server and the destionations having only domain.xml file.
>>
>> Let say I have three servers in domain1
>> dasServer
>> managedSrv01
>> managedSrv02 (lets say it is another physical node in the same domain)
Are managedSrv01 and managedSrv02 in the same cluster? (To do this, create each instance using "asadmin create-instance
instanceName -cluster clusterName"). If so, then you have:
1. managedSrv01 and managedSrv02 operate as a cluster. This means that if you have a producer connected to managedSrv01
which sends a message to a queue myQueue, and a consumer connected to managedSrv02 which receives messages from a queue
myQueue, then the message will automatically be routed from managedSrv01 to managedSrv02 without you having to configure
anything special. You can think of the queue as spanning the whole cluster.
2. dasServer operates as a standalone JMS server, completely unconnected to managedSrv01 and managedSrv02. This will
only be used if you deploy an application directly onto the DAS, which is typically not done when you're using a
cluster. In a typical clustered environment the JMS server running in the DAS is not used at all.
If managedSrv01 and managedSrv02 are NOT in the same cluster, then they work completely independently and messages will
not be passed between them.
GlassFish is designed to prevent you having to worry about which JMS server your application is connected to. By
default, an application will connect to the JMS server running in (or managed by) the same GlassFish instance where the
application is running. If the GlassFish instances are clustered then the JMS servers will be as well, so messages sent
by a producer running in one instance will be automatically delivered to a consumer running in another instance.
Nigel