7 Replies Latest reply on Jun 7, 2002 9:06 PM by 3004

    JMS instability

    3004
      Hi.
                
                We use weblogic as both our app server and the JMS server. For some time
                now we noticed that some times a client would stop receiving the JMS
                messages. Based on the clients that had this problems everything points to
                network issues in the client side. But the weird thing is that the client
                would lose connection only to the JMS messages. The t3 connection was still
                fine. All bean method calls would work, everything... the client only did
                not receive JMS messages.
                
                After a long support case with BEA we created a JMSExceptionListener and
                saw that, indeed, the client was getting a "PeerGoneException" with the
                stack trace below. So we decided do a reconnection to the JMS topics every
                time that we got the PeerGoneException. That and the use of durable
                subscribers are a nice workaround to the problem.
                
                But one question still remains: WHY is it that the JMS connection goes
                down while the t3 connection is still healthy? BEA Support says it is an
                "architectural" issue and suggested that I tried to get an answer from the
                newsgroups. Anyone?
                
                BEA says that "JMS is a 'higher-level' protocol than t3", but that still
                does not answer my question. Can anyone explain in more details as to WHY
                JMS is more unstable?
                
                Thanks,
                Marcelo Quintella
                
                
                
                Here is the stack trace:
                
                weblogic.jms.common.LostServerException:
                weblogic.rjvm.PeerGoneEvent[source=weblogic.rjvm.RJVMImpl@51f39a - id:
                '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1'
                connect time: 'Thu Mar 21 11:15:05 GMT 2002'] - id:
                '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1',
                reason: 'weblogic.rjvm.PeerGoneException: ; nested exception is:
                weblogic.utils.net.SocketResetException - with nested exception:
                [java.net.SocketException: Connection reset by peer: JVM_recv in socket
                input stream read]'
                
                Start server side stack trace:
                weblogic.jms.common.LostServerException:
                weblogic.rjvm.PeerGoneEvent[source=weblogic.rjvm.RJVMImpl@51f39a - id:
                '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1'
                connect time: 'Thu Mar 21 11:15:05 GMT 2002'] - id:
                '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1',
                reason: 'weblogic.rjvm.PeerGoneException: ; nested exception is:
                weblogic.utils.net.SocketResetException - with nested exception:
                [java.net.SocketException: Connection reset by peer: JVM_recv in socket
                input stream read]'
                at weblogic.jms.client.JMSConnection.jmsPeerGone(JMSConnection.java:654)
                at
                weblogic.jms.dispatcher.DispatcherWrapperState.peerGone(DispatcherWrapperSta
                te.java:435)
                at weblogic.rjvm.RJVMImpl$PeerGoneDeliverer.execute(RJVMImpl.java:1049)
                at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
                at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
                End server side stack trace
                
                
                
        • 1. Re: JMS instability
          3004
          How do you capture just "PeerGoneException" in Exception Listner. Can
                    you please provide some sample code.
                    
                    Thanks
                    
                    "Marcelo Quintella" <marcelo.quintella@sknt.com> wrote in message news:<3cae2f6d$1@newsgroups.bea.com>...
                    > Hi.
                    >
                    > We use weblogic as both our app server and the JMS server. For some time
                    > now we noticed that some times a client would stop receiving the JMS
                    > messages. Based on the clients that had this problems everything points to
                    > network issues in the client side. But the weird thing is that the client
                    > would lose connection only to the JMS messages. The t3 connection was still
                    > fine. All bean method calls would work, everything... the client only did
                    > not receive JMS messages.
                    >
                    > After a long support case with BEA we created a JMSExceptionListener and
                    > saw that, indeed, the client was getting a "PeerGoneException" with the
                    > stack trace below. So we decided do a reconnection to the JMS topics every
                    > time that we got the PeerGoneException. That and the use of durable
                    > subscribers are a nice workaround to the problem.
                    >
                    > But one question still remains: WHY is it that the JMS connection goes
                    > down while the t3 connection is still healthy? BEA Support says it is an
                    > "architectural" issue and suggested that I tried to get an answer from the
                    > newsgroups. Anyone?
                    >
                    > BEA says that "JMS is a 'higher-level' protocol than t3", but that still
                    > does not answer my question. Can anyone explain in more details as to WHY
                    > JMS is more unstable?
                    >
                    > Thanks,
                    > Marcelo Quintella
                    >
                    >
                    >
                    > Here is the stack trace:
                    >
                    > weblogic.jms.common.LostServerException:
                    > weblogic.rjvm.PeerGoneEvent[source=weblogic.rjvm.RJVMImpl@51f39a - id:
                    > '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1'
                    > connect time: 'Thu Mar 21 11:15:05 GMT 2002'] - id:
                    > '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1',
                    > reason: 'weblogic.rjvm.PeerGoneException: ; nested exception is:
                    > weblogic.utils.net.SocketResetException - with nested exception:
                    > [java.net.SocketException: Connection reset by peer: JVM_recv in socket
                    > input stream read]'
                    >
                    > Start server side stack trace:
                    > weblogic.jms.common.LostServerException:
                    > weblogic.rjvm.PeerGoneEvent[source=weblogic.rjvm.RJVMImpl@51f39a - id:
                    > '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1'
                    > connect time: 'Thu Mar 21 11:15:05 GMT 2002'] - id:
                    > '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1',
                    > reason: 'weblogic.rjvm.PeerGoneException: ; nested exception is:
                    > weblogic.utils.net.SocketResetException - with nested exception:
                    > [java.net.SocketException: Connection reset by peer: JVM_recv in socket
                    > input stream read]'
                    > at weblogic.jms.client.JMSConnection.jmsPeerGone(JMSConnection.java:654)
                    > at
                    > weblogic.jms.dispatcher.DispatcherWrapperState.peerGone(DispatcherWrapperSta
                    > te.java:435)
                    > at weblogic.rjvm.RJVMImpl$PeerGoneDeliverer.execute(RJVMImpl.java:1049)
                    > at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
                    > at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
                    > End server side stack trace
                    
          • 2. Re: JMS instability
            3004
            I don't really hava a mechanism to capture just "PeerGoneException". But so
                      far that is the only exception that I've been getting.
                      
                      Marcelo
                      
                      
                      "Rama" <ryammanuru@yahoo.com> wrote in message
                      news:936de5a4.0204080937.15d0094f@posting.google.com...
                      > How do you capture just "PeerGoneException" in Exception Listner. Can
                      > you please provide some sample code.
                      >
                      > Thanks
                      >
                      > "Marcelo Quintella" <marcelo.quintella@sknt.com> wrote in message
                      news:<3cae2f6d$1@newsgroups.bea.com>...
                      > > Hi.
                      > >
                      > > We use weblogic as both our app server and the JMS server. For some
                      time
                      > > now we noticed that some times a client would stop receiving the JMS
                      > > messages. Based on the clients that had this problems everything points
                      to
                      > > network issues in the client side. But the weird thing is that the
                      client
                      > > would lose connection only to the JMS messages. The t3 connection was
                      still
                      > > fine. All bean method calls would work, everything... the client only
                      did
                      > > not receive JMS messages.
                      > >
                      > > After a long support case with BEA we created a JMSExceptionListener
                      and
                      > > saw that, indeed, the client was getting a "PeerGoneException" with the
                      > > stack trace below. So we decided do a reconnection to the JMS topics
                      every
                      > > time that we got the PeerGoneException. That and the use of durable
                      > > subscribers are a nice workaround to the problem.
                      > >
                      > > But one question still remains: WHY is it that the JMS connection
                      goes
                      > > down while the t3 connection is still healthy? BEA Support says it is an
                      > > "architectural" issue and suggested that I tried to get an answer from
                      the
                      > > newsgroups. Anyone?
                      > >
                      > > BEA says that "JMS is a 'higher-level' protocol than t3", but that
                      still
                      > > does not answer my question. Can anyone explain in more details as to
                      WHY
                      > > JMS is more unstable?
                      > >
                      > > Thanks,
                      > > Marcelo Quintella
                      > >
                      > >
                      > >
                      > > Here is the stack trace:
                      > >
                      > > weblogic.jms.common.LostServerException:
                      > > weblogic.rjvm.PeerGoneEvent[source=weblogic.rjvm.RJVMImpl@51f39a - id:
                      > > '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1'
                      > > connect time: 'Thu Mar 21 11:15:05 GMT 2002'] - id:
                      > > '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1',
                      > > reason: 'weblogic.rjvm.PeerGoneException: ; nested exception is:
                      > > weblogic.utils.net.SocketResetException - with nested exception:
                      > > [java.net.SocketException: Connection reset by peer: JVM_recv in socket
                      > > input stream read]'
                      > >
                      > > Start server side stack trace:
                      > > weblogic.jms.common.LostServerException:
                      > > weblogic.rjvm.PeerGoneEvent[source=weblogic.rjvm.RJVMImpl@51f39a - id:
                      > > '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1'
                      > > connect time: 'Thu Mar 21 11:15:05 GMT 2002'] - id:
                      > > '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1',
                      > > reason: 'weblogic.rjvm.PeerGoneException: ; nested exception is:
                      > > weblogic.utils.net.SocketResetException - with nested exception:
                      > > [java.net.SocketException: Connection reset by peer: JVM_recv in socket
                      > > input stream read]'
                      > > at weblogic.jms.client.JMSConnection.jmsPeerGone(JMSConnection.java:654)
                      > > at
                      > >
                      weblogic.jms.dispatcher.DispatcherWrapperState.peerGone(DispatcherWrapperSta
                      > > te.java:435)
                      > > at weblogic.rjvm.RJVMImpl$PeerGoneDeliverer.execute(RJVMImpl.java:1049)
                      > > at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
                      > > at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
                      > > End server side stack trace
                      
                      
                      
            • 3. Re: JMS instability
              3004
              I am told that this is fixed in 7.0 (now out in beta).
                        
                        I am also told that the work-around may be this, from another WL engineer:
                        Set server value IdlePeriodsUntilTimeout (default 4) to be a larger value.
                        Care must be taken : DGCIdlePeriodsUntilTimeout (default 2) is
                        >=IdlePeriodsUntilTimeout
                        (The IdlePeriodUntilTimeout as far as I know is same for clientHeartbeats
                        ans clusterHeartbeats.)
                        
                        The idle period is configurable as well, it is called "PeriodLength" and
                        defaults to 60000 (60 seconds).
                        
                        If this doesn't fix the problem, please re-open your customer support case with
                        BEA. You should not need to work-around the problem in code. A solution is
                        out there.
                        
                        Tom
                        
                        Marcelo Quintella wrote:
                        
                        > Hi.
                        >
                        > We use weblogic as both our app server and the JMS server. For some time
                        > now we noticed that some times a client would stop receiving the JMS
                        > messages. Based on the clients that had this problems everything points to
                        > network issues in the client side. But the weird thing is that the client
                        > would lose connection only to the JMS messages. The t3 connection was still
                        > fine. All bean method calls would work, everything... the client only did
                        > not receive JMS messages.
                        >
                        > After a long support case with BEA we created a JMSExceptionListener and
                        > saw that, indeed, the client was getting a "PeerGoneException" with the
                        > stack trace below. So we decided do a reconnection to the JMS topics every
                        > time that we got the PeerGoneException. That and the use of durable
                        > subscribers are a nice workaround to the problem.
                        >
                        > But one question still remains: WHY is it that the JMS connection goes
                        > down while the t3 connection is still healthy? BEA Support says it is an
                        > "architectural" issue and suggested that I tried to get an answer from the
                        > newsgroups. Anyone?
                        >
                        > BEA says that "JMS is a 'higher-level' protocol than t3", but that still
                        > does not answer my question. Can anyone explain in more details as to WHY
                        > JMS is more unstable?
                        >
                        > Thanks,
                        > Marcelo Quintella
                        >
                        > Here is the stack trace:
                        >
                        > weblogic.jms.common.LostServerException:
                        > weblogic.rjvm.PeerGoneEvent[source=weblogic.rjvm.RJVMImpl@51f39a - id:
                        > '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1'
                        > connect time: 'Thu Mar 21 11:15:05 GMT 2002'] - id:
                        > '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1',
                        > reason: 'weblogic.rjvm.PeerGoneException: ; nested exception is:
                        > weblogic.utils.net.SocketResetException - with nested exception:
                        > [java.net.SocketException: Connection reset by peer: JVM_recv in socket
                        > input stream read]'
                        >
                        > Start server side stack trace:
                        > weblogic.jms.common.LostServerException:
                        > weblogic.rjvm.PeerGoneEvent[source=weblogic.rjvm.RJVMImpl@51f39a - id:
                        > '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1'
                        > connect time: 'Thu Mar 21 11:15:05 GMT 2002'] - id:
                        > '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1',
                        > reason: 'weblogic.rjvm.PeerGoneException: ; nested exception is:
                        > weblogic.utils.net.SocketResetException - with nested exception:
                        > [java.net.SocketException: Connection reset by peer: JVM_recv in socket
                        > input stream read]'
                        > at weblogic.jms.client.JMSConnection.jmsPeerGone(JMSConnection.java:654)
                        > at
                        > weblogic.jms.dispatcher.DispatcherWrapperState.peerGone(DispatcherWrapperSta
                        > te.java:435)
                        > at weblogic.rjvm.RJVMImpl$PeerGoneDeliverer.execute(RJVMImpl.java:1049)
                        > at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
                        > at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
                        > End server side stack trace
                        
                        
              • 4. Re: JMS instability
                3004
                I have these two properties set in the config.xml file(as told per customer
                          support):
                          
                          DGCIdlePeriodsUntilTimeout="60"
                          PeriodLength="60000"
                          
                          And these two properties set in the command line in startWeblogic.cmd AND
                          for the client application:
                          
                          -Dweblogic.system.idlePeriodsUntilTimeout=60 -Dweblogic.system.periodLen
                          gth=60000
                          
                          Should anything else be being set?
                          
                          Thanks,
                          Marcelo Quintella
                          
                          
                          "Tom Barnes" <please@replyinnewsgroup.com> wrote in message
                          news:3CB4C59C.A05A661@replyinnewsgroup.com...
                          > I am told that this is fixed in 7.0 (now out in beta).
                          >
                          > I am also told that the work-around may be this, from another WL engineer:
                          > Set server value IdlePeriodsUntilTimeout (default 4) to be a larger
                          value.
                          > Care must be taken : DGCIdlePeriodsUntilTimeout (default 2) is
                          > >=IdlePeriodsUntilTimeout
                          > (The IdlePeriodUntilTimeout as far as I know is same for
                          clientHeartbeats
                          > ans clusterHeartbeats.)
                          >
                          > The idle period is configurable as well, it is called "PeriodLength" and
                          > defaults to 60000 (60 seconds).
                          >
                          > If this doesn't fix the problem, please re-open your customer support case
                          with
                          > BEA. You should not need to work-around the problem in code. A solution
                          is
                          > out there.
                          >
                          > Tom
                          >
                          > Marcelo Quintella wrote:
                          >
                          > > Hi.
                          > >
                          > > We use weblogic as both our app server and the JMS server. For some
                          time
                          > > now we noticed that some times a client would stop receiving the JMS
                          > > messages. Based on the clients that had this problems everything points
                          to
                          > > network issues in the client side. But the weird thing is that the
                          client
                          > > would lose connection only to the JMS messages. The t3 connection was
                          still
                          > > fine. All bean method calls would work, everything... the client only
                          did
                          > > not receive JMS messages.
                          > >
                          > > After a long support case with BEA we created a JMSExceptionListener
                          and
                          > > saw that, indeed, the client was getting a "PeerGoneException" with the
                          > > stack trace below. So we decided do a reconnection to the JMS topics
                          every
                          > > time that we got the PeerGoneException. That and the use of durable
                          > > subscribers are a nice workaround to the problem.
                          > >
                          > > But one question still remains: WHY is it that the JMS connection
                          goes
                          > > down while the t3 connection is still healthy? BEA Support says it is an
                          > > "architectural" issue and suggested that I tried to get an answer from
                          the
                          > > newsgroups. Anyone?
                          > >
                          > > BEA says that "JMS is a 'higher-level' protocol than t3", but that
                          still
                          > > does not answer my question. Can anyone explain in more details as to
                          WHY
                          > > JMS is more unstable?
                          > >
                          > > Thanks,
                          > > Marcelo Quintella
                          > >
                          > > Here is the stack trace:
                          > >
                          > > weblogic.jms.common.LostServerException:
                          > > weblogic.rjvm.PeerGoneEvent[source=weblogic.rjvm.RJVMImpl@51f39a - id:
                          > > '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1'
                          > > connect time: 'Thu Mar 21 11:15:05 GMT 2002'] - id:
                          > > '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1',
                          > > reason: 'weblogic.rjvm.PeerGoneException: ; nested exception is:
                          > > weblogic.utils.net.SocketResetException - with nested exception:
                          > > [java.net.SocketException: Connection reset by peer: JVM_recv in socket
                          > > input stream read]'
                          > >
                          > > Start server side stack trace:
                          > > weblogic.jms.common.LostServerException:
                          > > weblogic.rjvm.PeerGoneEvent[source=weblogic.rjvm.RJVMImpl@51f39a - id:
                          > > '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1'
                          > > connect time: 'Thu Mar 21 11:15:05 GMT 2002'] - id:
                          > > '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1',
                          > > reason: 'weblogic.rjvm.PeerGoneException: ; nested exception is:
                          > > weblogic.utils.net.SocketResetException - with nested exception:
                          > > [java.net.SocketException: Connection reset by peer: JVM_recv in socket
                          > > input stream read]'
                          > > at weblogic.jms.client.JMSConnection.jmsPeerGone(JMSConnection.java:654)
                          > > at
                          > >
                          weblogic.jms.dispatcher.DispatcherWrapperState.peerGone(DispatcherWrapperSta
                          
                          > > te.java:435)
                          > > at weblogic.rjvm.RJVMImpl$PeerGoneDeliverer.execute(RJVMImpl.java:1049)
                          > > at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
                          > > at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
                          > > End server side stack trace
                          >
                          
                          
                          
                • 5. Re: JMS instability
                  3004
                  Also set IdlePeriodsUntilTimeout="60" in config.xml on server too.
                            If this does not work for you, reopen the customer case with BEA, while I look
                            into this
                            if the client side configurable parameter
                            -Dweblogic.system.idlePeriodsUntilTimeout=60 is being used
                            at all or it is still using the default which is 4.
                            Just as a note the default value of PeriodLength is 60000 for both server and
                            client
                            
                            What service pack are you on?
                            
                            -Kawaljit Singh Sunny
                            
                            Marcelo Quintella wrote:
                            
                            > I have these two properties set in the config.xml file(as told per customer
                            > support):
                            >
                            > DGCIdlePeriodsUntilTimeout="60"
                            > PeriodLength="60000"
                            >
                            > And these two properties set in the command line in startWeblogic.cmd AND
                            > for the client application:
                            >
                            > -Dweblogic.system.idlePeriodsUntilTimeout=60 -Dweblogic.system.periodLen
                            > gth=60000
                            >
                            > Should anything else be being set?
                            >
                            > Thanks,
                            > Marcelo Quintella
                            >
                            > "Tom Barnes" <please@replyinnewsgroup.com> wrote in message
                            > news:3CB4C59C.A05A661@replyinnewsgroup.com...
                            > > I am told that this is fixed in 7.0 (now out in beta).
                            > >
                            > > I am also told that the work-around may be this, from another WL engineer:
                            > > Set server value IdlePeriodsUntilTimeout (default 4) to be a larger
                            > value.
                            > > Care must be taken : DGCIdlePeriodsUntilTimeout (default 2) is
                            > > >=IdlePeriodsUntilTimeout
                            > > (The IdlePeriodUntilTimeout as far as I know is same for
                            > clientHeartbeats
                            > > ans clusterHeartbeats.)
                            > >
                            > > The idle period is configurable as well, it is called "PeriodLength" and
                            > > defaults to 60000 (60 seconds).
                            > >
                            > > If this doesn't fix the problem, please re-open your customer support case
                            > with
                            > > BEA. You should not need to work-around the problem in code. A solution
                            > is
                            > > out there.
                            > >
                            > > Tom
                            > >
                            > > Marcelo Quintella wrote:
                            > >
                            > > > Hi.
                            > > >
                            > > > We use weblogic as both our app server and the JMS server. For some
                            > time
                            > > > now we noticed that some times a client would stop receiving the JMS
                            > > > messages. Based on the clients that had this problems everything points
                            > to
                            > > > network issues in the client side. But the weird thing is that the
                            > client
                            > > > would lose connection only to the JMS messages. The t3 connection was
                            > still
                            > > > fine. All bean method calls would work, everything... the client only
                            > did
                            > > > not receive JMS messages.
                            > > >
                            > > > After a long support case with BEA we created a JMSExceptionListener
                            > and
                            > > > saw that, indeed, the client was getting a "PeerGoneException" with the
                            > > > stack trace below. So we decided do a reconnection to the JMS topics
                            > every
                            > > > time that we got the PeerGoneException. That and the use of durable
                            > > > subscribers are a nice workaround to the problem.
                            > > >
                            > > > But one question still remains: WHY is it that the JMS connection
                            > goes
                            > > > down while the t3 connection is still healthy? BEA Support says it is an
                            > > > "architectural" issue and suggested that I tried to get an answer from
                            > the
                            > > > newsgroups. Anyone?
                            > > >
                            > > > BEA says that "JMS is a 'higher-level' protocol than t3", but that
                            > still
                            > > > does not answer my question. Can anyone explain in more details as to
                            > WHY
                            > > > JMS is more unstable?
                            > > >
                            > > > Thanks,
                            > > > Marcelo Quintella
                            > > >
                            > > > Here is the stack trace:
                            > > >
                            > > > weblogic.jms.common.LostServerException:
                            > > > weblogic.rjvm.PeerGoneEvent[source=weblogic.rjvm.RJVMImpl@51f39a - id:
                            > > > '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1'
                            > > > connect time: 'Thu Mar 21 11:15:05 GMT 2002'] - id:
                            > > > '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1',
                            > > > reason: 'weblogic.rjvm.PeerGoneException: ; nested exception is:
                            > > > weblogic.utils.net.SocketResetException - with nested exception:
                            > > > [java.net.SocketException: Connection reset by peer: JVM_recv in socket
                            > > > input stream read]'
                            > > >
                            > > > Start server side stack trace:
                            > > > weblogic.jms.common.LostServerException:
                            > > > weblogic.rjvm.PeerGoneEvent[source=weblogic.rjvm.RJVMImpl@51f39a - id:
                            > > > '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1'
                            > > > connect time: 'Thu Mar 21 11:15:05 GMT 2002'] - id:
                            > > > '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1',
                            > > > reason: 'weblogic.rjvm.PeerGoneException: ; nested exception is:
                            > > > weblogic.utils.net.SocketResetException - with nested exception:
                            > > > [java.net.SocketException: Connection reset by peer: JVM_recv in socket
                            > > > input stream read]'
                            > > > at weblogic.jms.client.JMSConnection.jmsPeerGone(JMSConnection.java:654)
                            > > > at
                            > > >
                            > weblogic.jms.dispatcher.DispatcherWrapperState.peerGone(DispatcherWrapperSta
                            >
                            > > > te.java:435)
                            > > > at weblogic.rjvm.RJVMImpl$PeerGoneDeliverer.execute(RJVMImpl.java:1049)
                            > > > at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
                            > > > at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
                            > > > End server side stack trace
                            > >
                            
                            
                  • 6. Re: JMS instability
                    3004
                    wl 6.1 sp2
                              
                              Thanks,
                              Marcelo
                              
                              "Kawaljit Singh" <ksingh@beasys.com> wrote in message
                              news:3CB5E739.8BC16173@beasys.com...
                              > Also set IdlePeriodsUntilTimeout="60" in config.xml on server too.
                              > If this does not work for you, reopen the customer case with BEA, while I
                              look
                              > into this
                              > if the client side configurable parameter
                              > -Dweblogic.system.idlePeriodsUntilTimeout=60 is being used
                              > at all or it is still using the default which is 4.
                              > Just as a note the default value of PeriodLength is 60000 for both server
                              and
                              > client
                              >
                              > What service pack are you on?
                              >
                              > -Kawaljit Singh Sunny
                              >
                              > Marcelo Quintella wrote:
                              >
                              > > I have these two properties set in the config.xml file(as told per
                              customer
                              > > support):
                              > >
                              > > DGCIdlePeriodsUntilTimeout="60"
                              > > PeriodLength="60000"
                              > >
                              > > And these two properties set in the command line in startWeblogic.cmd
                              AND
                              > > for the client application:
                              > >
                              >
                              > -Dweblogic.system.idlePeriodsUntilTimeout=60 -Dweblogic.system.periodL
                              en
                              > > gth=60000
                              > >
                              > > Should anything else be being set?
                              > >
                              > > Thanks,
                              > > Marcelo Quintella
                              > >
                              > > "Tom Barnes" <please@replyinnewsgroup.com> wrote in message
                              > > news:3CB4C59C.A05A661@replyinnewsgroup.com...
                              > > > I am told that this is fixed in 7.0 (now out in beta).
                              > > >
                              > > > I am also told that the work-around may be this, from another WL
                              engineer:
                              > > > Set server value IdlePeriodsUntilTimeout (default 4) to be a larger
                              > > value.
                              > > > Care must be taken : DGCIdlePeriodsUntilTimeout (default 2) is
                              > > > >=IdlePeriodsUntilTimeout
                              > > > (The IdlePeriodUntilTimeout as far as I know is same for
                              > > clientHeartbeats
                              > > > ans clusterHeartbeats.)
                              > > >
                              > > > The idle period is configurable as well, it is called "PeriodLength"
                              and
                              > > > defaults to 60000 (60 seconds).
                              > > >
                              > > > If this doesn't fix the problem, please re-open your customer support
                              case
                              > > with
                              > > > BEA. You should not need to work-around the problem in code. A
                              solution
                              > > is
                              > > > out there.
                              > > >
                              > > > Tom
                              > > >
                              > > > Marcelo Quintella wrote:
                              > > >
                              > > > > Hi.
                              > > > >
                              > > > > We use weblogic as both our app server and the JMS server. For
                              some
                              > > time
                              > > > > now we noticed that some times a client would stop receiving the JMS
                              > > > > messages. Based on the clients that had this problems everything
                              points
                              > > to
                              > > > > network issues in the client side. But the weird thing is that the
                              > > client
                              > > > > would lose connection only to the JMS messages. The t3 connection
                              was
                              > > still
                              > > > > fine. All bean method calls would work, everything... the client
                              only
                              > > did
                              > > > > not receive JMS messages.
                              > > > >
                              > > > > After a long support case with BEA we created a
                              JMSExceptionListener
                              > > and
                              > > > > saw that, indeed, the client was getting a "PeerGoneException" with
                              the
                              > > > > stack trace below. So we decided do a reconnection to the JMS topics
                              > > every
                              > > > > time that we got the PeerGoneException. That and the use of durable
                              > > > > subscribers are a nice workaround to the problem.
                              > > > >
                              > > > > But one question still remains: WHY is it that the JMS
                              connection
                              > > goes
                              > > > > down while the t3 connection is still healthy? BEA Support says it
                              is an
                              > > > > "architectural" issue and suggested that I tried to get an answer
                              from
                              > > the
                              > > > > newsgroups. Anyone?
                              > > > >
                              > > > > BEA says that "JMS is a 'higher-level' protocol than t3", but
                              that
                              > > still
                              > > > > does not answer my question. Can anyone explain in more details as
                              to
                              > > WHY
                              > > > > JMS is more unstable?
                              > > > >
                              > > > > Thanks,
                              > > > > Marcelo Quintella
                              > > > >
                              > > > > Here is the stack trace:
                              > > > >
                              > > > > weblogic.jms.common.LostServerException:
                              > > > > weblogic.rjvm.PeerGoneEvent[source=weblogic.rjvm.RJVMImpl@51f39a -
                              id:
                              > > > >
                              '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1'
                              > > > > connect time: 'Thu Mar 21 11:15:05 GMT 2002'] - id:
                              > > > >
                              '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1',
                              > > > > reason: 'weblogic.rjvm.PeerGoneException: ; nested exception is:
                              > > > > weblogic.utils.net.SocketResetException - with nested exception:
                              > > > > [java.net.SocketException: Connection reset by peer: JVM_recv in
                              socket
                              > > > > input stream read]'
                              > > > >
                              > > > > Start server side stack trace:
                              > > > > weblogic.jms.common.LostServerException:
                              > > > > weblogic.rjvm.PeerGoneEvent[source=weblogic.rjvm.RJVMImpl@51f39a -
                              id:
                              > > > >
                              '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1'
                              > > > > connect time: 'Thu Mar 21 11:15:05 GMT 2002'] - id:
                              > > > >
                              '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1',
                              > > > > reason: 'weblogic.rjvm.PeerGoneException: ; nested exception is:
                              > > > > weblogic.utils.net.SocketResetException - with nested exception:
                              > > > > [java.net.SocketException: Connection reset by peer: JVM_recv in
                              socket
                              > > > > input stream read]'
                              > > > > at
                              weblogic.jms.client.JMSConnection.jmsPeerGone(JMSConnection.java:654)
                              > > > > at
                              > > > >
                              > >
                              weblogic.jms.dispatcher.DispatcherWrapperState.peerGone(DispatcherWrapperSta
                              > >
                              > > > > te.java:435)
                              > > > > at
                              weblogic.rjvm.RJVMImpl$PeerGoneDeliverer.execute(RJVMImpl.java:1049)
                              > > > > at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
                              > > > > at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
                              > > > > End server side stack trace
                              > > >
                              >
                              
                              
                              
                    • 7. Re: JMS instability
                      3004
                      Hi,
                                we are also experiancing similar problem with wl6.1 sp2,
                                Did it work after adding new properties?
                                
                                Thanks,
                                
                                Srini
                                
                                
                                
                                Marcelo Quintella wrote:
                                
                                > wl 6.1 sp2
                                >
                                > Thanks,
                                > Marcelo
                                >
                                > "Kawaljit Singh" <ksingh@beasys.com> wrote in message
                                > news:3CB5E739.8BC16173@beasys.com...
                                > > Also set IdlePeriodsUntilTimeout="60" in config.xml on server too.
                                > > If this does not work for you, reopen the customer case with BEA, while I
                                > look
                                > > into this
                                > > if the client side configurable parameter
                                > > -Dweblogic.system.idlePeriodsUntilTimeout=60 is being used
                                > > at all or it is still using the default which is 4.
                                > > Just as a note the default value of PeriodLength is 60000 for both server
                                > and
                                > > client
                                > >
                                > > What service pack are you on?
                                > >
                                > > -Kawaljit Singh Sunny
                                > >
                                > > Marcelo Quintella wrote:
                                > >
                                > > > I have these two properties set in the config.xml file(as told per
                                > customer
                                > > > support):
                                > > >
                                > > > DGCIdlePeriodsUntilTimeout="60"
                                > > > PeriodLength="60000"
                                > > >
                                > > > And these two properties set in the command line in startWeblogic.cmd
                                > AND
                                > > > for the client application:
                                > > >
                                > >
                                > > -Dweblogic.system.idlePeriodsUntilTimeout=60 -Dweblogic.system.periodL
                                > en
                                > > > gth=60000
                                > > >
                                > > > Should anything else be being set?
                                > > >
                                > > > Thanks,
                                > > > Marcelo Quintella
                                > > >
                                > > > "Tom Barnes" <please@replyinnewsgroup.com> wrote in message
                                > > > news:3CB4C59C.A05A661@replyinnewsgroup.com...
                                > > > > I am told that this is fixed in 7.0 (now out in beta).
                                > > > >
                                > > > > I am also told that the work-around may be this, from another WL
                                > engineer:
                                > > > > Set server value IdlePeriodsUntilTimeout (default 4) to be a larger
                                > > > value.
                                > > > > Care must be taken : DGCIdlePeriodsUntilTimeout (default 2) is
                                > > > > >=IdlePeriodsUntilTimeout
                                > > > > (The IdlePeriodUntilTimeout as far as I know is same for
                                > > > clientHeartbeats
                                > > > > ans clusterHeartbeats.)
                                > > > >
                                > > > > The idle period is configurable as well, it is called "PeriodLength"
                                > and
                                > > > > defaults to 60000 (60 seconds).
                                > > > >
                                > > > > If this doesn't fix the problem, please re-open your customer support
                                > case
                                > > > with
                                > > > > BEA. You should not need to work-around the problem in code. A
                                > solution
                                > > > is
                                > > > > out there.
                                > > > >
                                > > > > Tom
                                > > > >
                                > > > > Marcelo Quintella wrote:
                                > > > >
                                > > > > > Hi.
                                > > > > >
                                > > > > > We use weblogic as both our app server and the JMS server. For
                                > some
                                > > > time
                                > > > > > now we noticed that some times a client would stop receiving the JMS
                                > > > > > messages. Based on the clients that had this problems everything
                                > points
                                > > > to
                                > > > > > network issues in the client side. But the weird thing is that the
                                > > > client
                                > > > > > would lose connection only to the JMS messages. The t3 connection
                                > was
                                > > > still
                                > > > > > fine. All bean method calls would work, everything... the client
                                > only
                                > > > did
                                > > > > > not receive JMS messages.
                                > > > > >
                                > > > > > After a long support case with BEA we created a
                                > JMSExceptionListener
                                > > > and
                                > > > > > saw that, indeed, the client was getting a "PeerGoneException" with
                                > the
                                > > > > > stack trace below. So we decided do a reconnection to the JMS topics
                                > > > every
                                > > > > > time that we got the PeerGoneException. That and the use of durable
                                > > > > > subscribers are a nice workaround to the problem.
                                > > > > >
                                > > > > > But one question still remains: WHY is it that the JMS
                                > connection
                                > > > goes
                                > > > > > down while the t3 connection is still healthy? BEA Support says it
                                > is an
                                > > > > > "architectural" issue and suggested that I tried to get an answer
                                > from
                                > > > the
                                > > > > > newsgroups. Anyone?
                                > > > > >
                                > > > > > BEA says that "JMS is a 'higher-level' protocol than t3", but
                                > that
                                > > > still
                                > > > > > does not answer my question. Can anyone explain in more details as
                                > to
                                > > > WHY
                                > > > > > JMS is more unstable?
                                > > > > >
                                > > > > > Thanks,
                                > > > > > Marcelo Quintella
                                > > > > >
                                > > > > > Here is the stack trace:
                                > > > > >
                                > > > > > weblogic.jms.common.LostServerException:
                                > > > > > weblogic.rjvm.PeerGoneEvent[source=weblogic.rjvm.RJVMImpl@51f39a -
                                > id:
                                > > > > >
                                > '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1'
                                > > > > > connect time: 'Thu Mar 21 11:15:05 GMT 2002'] - id:
                                > > > > >
                                > '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1',
                                > > > > > reason: 'weblogic.rjvm.PeerGoneException: ; nested exception is:
                                > > > > > weblogic.utils.net.SocketResetException - with nested exception:
                                > > > > > [java.net.SocketException: Connection reset by peer: JVM_recv in
                                > socket
                                > > > > > input stream read]'
                                > > > > >
                                > > > > > Start server side stack trace:
                                > > > > > weblogic.jms.common.LostServerException:
                                > > > > > weblogic.rjvm.PeerGoneEvent[source=weblogic.rjvm.RJVMImpl@51f39a -
                                > id:
                                > > > > >
                                > '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1'
                                > > > > > connect time: 'Thu Mar 21 11:15:05 GMT 2002'] - id:
                                > > > > >
                                > '11299213239391533S:63.240.29.170:[80,80,443,443,80,443,-1]:Prod:Prod1',
                                > > > > > reason: 'weblogic.rjvm.PeerGoneException: ; nested exception is:
                                > > > > > weblogic.utils.net.SocketResetException - with nested exception:
                                > > > > > [java.net.SocketException: Connection reset by peer: JVM_recv in
                                > socket
                                > > > > > input stream read]'
                                > > > > > at
                                > weblogic.jms.client.JMSConnection.jmsPeerGone(JMSConnection.java:654)
                                > > > > > at
                                > > > > >
                                > > >
                                > weblogic.jms.dispatcher.DispatcherWrapperState.peerGone(DispatcherWrapperSta
                                > > >
                                > > > > > te.java:435)
                                > > > > > at
                                > weblogic.rjvm.RJVMImpl$PeerGoneDeliverer.execute(RJVMImpl.java:1049)
                                > > > > > at weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:139)
                                > > > > > at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:120)
                                > > > > > End server side stack trace
                                > > > >
                                > >