Steps to reproduce:

Use a computer running Windows XP which obtains its IP address using DHCP 
(i.e. a completely standard corporate PC which a large number of GlassFish users will be using for development)

Download the latest nightly build 
from http://dlc.sun.com.edgesuite.net/glassfish/3.1/nightly/
(I used glassfish-3.1-b31-11_22_2010.zip)

## Unzip the file to (say) C:\Sun\glassfish-3.1-b31-11_22_2010

## Navigate to C:\Sun\glassfish-3.1-b31-11_22_2010\glassfish3\bin and run the following commands:

asadmin start-domain
asadmin create-cluster cluster1
asadmin create-instance --cluster cluster1 --node localhost instance1
asadmin create-instance --cluster cluster1 --node localhost instance2
asadmin start-cluster cluster1

## create a topic resource 
asadmin create-jms-resource --restype javax.jms.Topic --target cluster1 --property Name=inboundTopic jms/inboundTopic

## deploy the attached MDB app
asadmin deploy --target cluster1 MDBConsumerOnly.jar

This triggers the lazy startup of the embeded brokers in each GlassGish instance.

After a minute or two, the server log of instance2 contains the error

[#|2010-11-23T10:50:21.234+0000|WARNING|glassfish3.1|javax.jms|_ThreadID=17;_ThreadName=Thread-1;|[I500]: Caught JVM Exception: com.sun.messaging.jms.JMSException: [CREATE_DESTINATION_REPLY(35)] [C4036]: A broker error occurred. :[503] [B4286]: [Thread-jms[0]]Auto-creation of destination inboundTopic is not allowed because service jms is currently in restricted service mode: Persistent store has not been synchronized with master broker [broker2(mq://192.168.1.108:27676/)] user=guest, broker=localhost:27677(1870)|#]

See server and broker logs (attached).

The cause of the problem can be seen by looking at the two broker logs. instance1 is the master broker, and instance2 has been unable to connect to it and so cannot allow the creation of a durable subscription.

This problem does not occur if lazy initialisation is disabled by setting lazy-init="false" in the <jms-host> element for the two instances. 
It also does not occur of the brokers are configured to be "local" by setting type="LOCAL" in the <jms-service> element for the two instances.

I think the cause of this bug is the grizzly proxy rejecting connections which don't use the expected hostname. 
This is https://glassfish.dev.java.net/issues/show_bug.cgi?id=11254
This issue has been marked as fixed, but is preventing this very simple test case working.

Note that any fix must work in the case when the IP address is obtained using DHCP and so may change each time the machine is booted.