Re: "Handle that can't be resolved"

"Julien Schreiber" <julien.schreiber-JhP/[email protected]>
Newsgroups gmane.comp.java.openjms.devel
Message-ID <[email protected]>
Thanks Tim !

It works fine now !
  ----- Original Message ----- 
  From: Tim Anderson 
  To: openjms-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org 
  Sent: Wednesday, February 11, 2004 1:08 PM
  Subject: RE: [openjms-developer] "Handle that can't be resolved"


  Hmm - the garbage collector might be kicking in to remove
  expired messages, at the same time the message is being queued
  to be dispatched to the client. If so, the error message is misleading, 
  but can be ignored.
  This would only occur if your client has a backlog of messages 
  of >= 30 seconds. 
  The following code will give an indication of the delay between a
  message being published and it being received in your subscriber:
    long milliseconds = System.currentTimeMillis() - message.getJMSTimestamp();

  If 'milliseconds' is near 30000, then it is likely that the errors relate to messages expiring.

  -Tim
    -----Original Message-----
    From: openjms-developer-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org [mailto:openjms-developer-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org]On Behalf Of Julien Schreiber
    Sent: Wednesday, 11 February 2004 2:26 AM
    To: openjms-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
    Subject: [openjms-developer] "Handle that can't be resolved"


    Dear all,

    First, I would like to say that OpenJms 0.7.6 works fine with TCp connector.
    The exception I had "java.lang.OutOfMemoryError" appeared because of a large amount of connections I used in background....

    I have another question :

    I have run a test using one sender and one receiver and 2 OpenJMS Servers running on 2 servers.

    I have sent 1000 requests. 1 request is sent every 2 seconds.

    On the standard Output I observe this kind of message :


    12:06:53.945 ERROR [Scheduler-Worker-3] - Dropping handle Handle : 1:107641121
    29:1344:ID:baed9888-b93c-1004-8816-0a9059dfe1ed since we cannot resolve it.

    This append 1 to 5 times during the test.
    I oberve that the connection and the session opened with the OpenJMS server is opened once, when the application is started.
    When this Error message appear, it corresponds to a message lost in the MOM (message never forwarded by the OpenJMS server : the receiver never receives the message).

    - Is it a problem of connection lost during the test ?
    - Is it a problem of the Time To live parameter of the messages I send ? I have set the TTL parameter to 30 seconds. 
    - Have you got any idea about this problem ?

    Regards,

    Julien Schreiber
    Cap Gemini Telecom


      ----- Original Message ----- 
      From: Julien Schreiber 
      To: openjms-developer-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org 
      Sent: Friday, January 30, 2004 3:01 PM
      Subject: java.lang.OutOfMemoryError


      Dear all,

      I am using OpenJMS Server version 0.7.5.
      I have just installed version 0.7.6

      The Open Jms Server is running on a Sun Fire V120 on Solaris 8.0

      I observe the following exception on the standard Output (when I am connected using the console mode) :

      java.lang.OutOfMemoryError
              <<no stack trace available>>

      a couple of seconds after having established a connection from my application to the Open JMS server.

      I am using a TCP connector to establish the connection.


      Once the exception is raised, all the JVM (even the one in which the Open Jms Server is running) remain alive. But the connection seems to be "blocked", so no more JMS message can be sent from my application towards the OpenJMS server.


      Have you got any idea on this problem ?


      Regards,
      ___________________________ 
      Julien Schreiber 
      Cap Gemini Telecom Media & Networks 
      +33 (0)1 49 00 47 60
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.