This discussion is archived
4 Replies Latest reply: Apr 6, 2011 2:13 PM by 802607 RSS

[C4003]: Error occurred on connection creation

802607 Explorer
Currently Being Moderated
I have an enterprise application containing an MDB deployed on Glassfish 2.1.1 (with OpenMQ 4.4). It needs to connect to a Topic on a remote Glassfish server (also 2.1.1). However, when the remote GF is down/unavailable, the application cannot be deployed on the local GF server. It reports the following error:

MQRA:EC:createRemoteMessageConsumer failed:aborting after 3 addressListIterations
*com.sun.messaging.jms.JMSException: [C4003]: Error occurred on connection creation [gsaka2:7676]. - cause: java.net.NoRouteToHostException: No route to host*

I've tried, in vain, for a few days trying to figure out how to have the application deploy and run on the local GF server when the remote GF is down (its part of our failure-mode testing), but I cannot seem to find the answer anywhere.

What methods are available to deal with this failure scenario? I'm sure this has been addressed, but for the life of me, I cannot find it. TIA.

Arshad
  • 1. Re: [C4003]: Error occurred on connection creation
    nigeldeakin Explorer
    Currently Being Moderated
    Can you clarify what behaviour you would like to see? You've manually configured a MDB to connect to a remote MQ broker. If that broker is not running the MDB cannot function and so throws the exception you observed.

    There will also be a MQ broker running on the local GF instance. Are you asking for the MDB to failover to using the local MQ broker? You can achieve that by configuring the addressList property of the connection factory. Note that this only makes sense if the two GF instances are running in a cluster.

    Note that if the two GF instances are running in a cluster there is no need to connect to the remote broker rather than the local broker: MQ will automatically route messages between brokers when necessary.

    Nigel
  • 2. Re: [C4003]: Error occurred on connection creation
    802607 Explorer
    Currently Being Moderated
    Thank you for your response, Nigel.

    The behavior I was expecting to see was that the MDB would report an exception, but the application would continue to load and the rest of the application (that does not depend on the remote GF host) would continue to operate normally. I find it extraordinary that this is not so.

    I am familiar with SunCluster - but not so much with GF Clustering. However, after a quick read of the architectural capabilities, I believe that GF Clustering is not for us - too many moving parts complicating setup and operations, and something that would require us to still come up with a DB and cryptographic-module clustering solution in addtion to GF clustering.

    Our design goal appears straightforward: to enable high-availability of the JEE5 application services using loosely coupled machines running Linux, GF and MySQL (cost is a significant constraint for the solutions we deploy). Our plan is to leverage JMS to replicate locally-committed transactions between nodes of the application-cluster. While this works very well when nodes are on the network, I am surprised by how MDB's dealing with connection failures (I wasn't expecting it).

    I don't see this behavior with EJBs when a database disappears under JPA or JDBC. Yes, there will be application level failures, but the application will continue to deploy correctly and the parts that don't depend on the DBMS will continue to operate. I had anticipated similar behavior of MDBs.

    From your answer, it appears that applications with MDBs will not deploy when a remote GF instance with the required Topic is unavailable. If I were to redesign the application to use normal EJBs (stateless or stateful) that setup their own MessageListeners, will this deploy normally (and fail gracefully on connection failures), or fail in the same manner as the MDBs do? Thanks.

    Arshad Noor
    StrongAuth, Inc.
  • 3. Re: [C4003]: Error occurred on connection creation
    nigeldeakin Explorer
    Currently Being Moderated
    A MDB is different to other kinds of EJB in that it starts working the moment you start the application, whereas a session bean only starts working (in loose terms) when it is invoked by a client.

    Your requirement is a reasonable one, however. A possible enhancement might be as follows: if the MDB cannot be started, it doesn't throw an exception. Instead it logs a warming message and spawns a thread which periodically attempts to start the MDB in the background. Would this meet your needs?

    Nigel

    P.S. Note that session beans are not allowed to set up MessageListeners. See section 21.3.5 "JMS 1.1 Requirements" of the EJB 3.1 specification.
  • 4. Re: [C4003]: Error occurred on connection creation
    802607 Explorer
    Currently Being Moderated
    nigeldeakin wrote:
    Your requirement is a reasonable one, however. A possible enhancement might be as follows: if the MDB cannot be started, it doesn't throw an exception. Instead it logs a warming message and spawns a thread which periodically attempts to start the MDB in the background. Would this meet your needs?
    Thanks again for your response, Nigel. This does, indeed, sound logical. Unfortunately, we need something that must be deployed within a month and available for GF 2.1.1, so it appears that we may have to solve this on our own with an enterprise application (given your comment about session beans and MessageListener). Please do update this thread when the MDB modification is avialable in a release version of GF so we can plan to take advantage of it going forward. Thanks.

    Arshad Noor
    StrongAuth, Inc.

Legend

  • Correct Answers - 10 points
  • Helpful Answers - 5 points