I have an application where a war is packaged in an ear together with an ejb3 jar. The application has worked fine before but suddenly when building a new version it started to cause problems. When trying to look up a session bean from a servlet in the war file I get the following exception: se.broaden.portal.t2.SubscriptionServiceException: Error performing 'se.broaden. | portal.t2.SubscriptionService.findSubscriptions(java.lang.String msisdn)' --> ja | vax.naming.CommunicationException: Receive timed out [Root exception is java.net | .SocketTimeoutException: Receive timed out] | .... | | Caused by: java.net.SocketTimeoutException: Receive timed out | at java.net.PlainDatagramSocketImpl.receive0(Native Method) | at java.net.PlainDatagramSocketImpl.receive(PlainDatagramSocketImpl.java | :136) | at java.net.DatagramSocket.receive(DatagramSocket.java:712) | at org.jnp.interfaces.NamingContext.discoverServer(NamingContext.java:12 | 87) | at org.jnp.interfaces.NamingContext.checkRef(NamingContext.java:1446) | at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:594) | at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587) | at javax.naming.InitialContext.lookup(InitialContext.java:351) | at se.broaden.portal.t2.tv.ServiceLocator.get_se_broaden_portal_t2_Subsc | riptionServiceBean_Remote(ServiceLocator.java:108) | at se.broaden.portal.t2.SubscriptionServiceDelegate.getSubscriptionServi | ceRemote(SubscriptionServiceDelegate.java:40) | at se.broaden.portal.t2.SubscriptionServiceDelegate.findSubscriptions(Su | bscriptionServiceDelegate.java:196) | ... 32 more What happens is that for some reason my web app tries to do a service discovery over multicast instead of using the local server in the same vm. I've run it with debugger and see that at line 1442 in NamingContext the localServer is null, hence it goes for discovery which doesn't work in my setup as I haven't deployed any HA stuff. The application is generated with AndroMDA 3.3-SNAPSHOT and obviously that has something to do with it as an older version of the same application which is generated with AndroMDA 3.2-SNAPSHOT works fine when deployed on the same jboss server. However, I've examined all deployment descriptors generated by AndroMDA and compared them to the ones that actually work and I can't find anything strange and nothing that has to do with naming. There is no jndi.properties or anything like that. I've also checked with the debugger what actually happens in the generated ServiceDelegate which is used to look up the session bean. It creates an InitialContext with null environment, exactly as the working app does, but fails when trying to look up the remote interface. What could possible cause this behavior when a war in the same ear file starts to try to discover naming service? No clustering what so ever is configured as far as I can see. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4039766#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...