14 Replies Latest reply on Oct 30, 2012 1:44 PM by samavedulark

    Nessus scan makes JBoss 5.1.0.GA stop processing web requests

      We recently started getting an issue with our production JBoss server where a Nessus security scan stops the JBoss server from responding to web service requests. We've been doing Nessus scans for many months now, so I'm assuming that there's a new plugin that's causing the issue. When it happens we see this in the logs:

       

      {code}

      2010-02-16 02:03:07,511 ERROR [org.apache.coyote.ajp.AjpMessage] (ajp-0.0.0.0-8009-1) Invalid message received with signature 18245
      2010-02-16 02:03:28,589 ERROR [org.jboss.invocation.pooled.server.ServerThread] (PooledInvokerThread-172.20.2.5-0) Failed to initialize
      java.io.EOFException
          at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2281)
          at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2750)
          at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780)
          at java.io.ObjectInputStream.<init>(ObjectInputStream.java:280)
          at org.jboss.invocation.pooled.interfaces.OptimizedObjectInputStream.<init>(OptimizedObjectInputStream.java:147)
          at org.jboss.invocation.pooled.server.ServerThread.dorun(ServerThread.java:265)
          at org.jboss.invocation.pooled.server.ServerThread.run(ServerThread.java:156)
      2010-02-16 02:03:28,589 ERROR [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#34[172.20.2.5:33997]) WorkerThread#34[172.20.2.5:33997] exception occurred during first invocation
      java.io.EOFException
          at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:693)
          at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:524)
          at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
      2010-02-16 02:03:28,589 ERROR [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#51[172.20.2.5:35756]) WorkerThread#51[172.20.2.5:35756] exception occurred during first invocation
      java.lang.reflect.InvocationTargetException
          at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
          at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
          at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
          at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
          at org.jboss.remoting.transport.socket.ServerThread.createServerSocketWrapper(ServerThread.java:909)
          at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:491)
          at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
      Caused by: java.io.EOFException
          at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2281)
          at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2750)
          at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780)
          at java.io.ObjectInputStream.<init>(ObjectInputStream.java:280)
          at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.<init>(ObjectInputStreamWithClassLoader.java:100)
          at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.createInput(JavaSerializationManager.java:54)
          at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.getMarshallingStream(SerializableUnMarshaller.java:75)
          at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.getMarshallingStream(SerializableUnMarshaller.java:58)
          at org.jboss.remoting.transport.socket.ClientSocketWrapper.createInputStream(ClientSocketWrapper.java:179)
          at org.jboss.remoting.transport.socket.ClientSocketWrapper.createStreams(ClientSocketWrapper.java:162)
          at org.jboss.remoting.transport.socket.ClientSocketWrapper.<init>(ClientSocketWrapper.java:66)
          at org.jboss.remoting.transport.socket.ServerSocketWrapper.<init>(ServerSocketWrapper.java:46)
          ... 7 more
      2010-02-16 02:05:27,403 ERROR [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#51[172.20.2.5:34921]) WorkerThread#51[172.20.2.5:34921] exception occurred during first invocation
      java.lang.reflect.InvocationTargetException
          at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
          at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
          at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
          at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
          at org.jboss.remoting.transport.socket.ServerThread.createServerSocketWrapper(ServerThread.java:909)
          at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:491)
          at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)
      Caused by: java.net.SocketException: Connection reset by peer: socket write error
          at java.net.SocketOutputStream.socketWrite0(Native Method)
          at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
          at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
          at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
          at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
          at java.io.ObjectOutputStream$BlockDataOutputStream.flush(ObjectOutputStream.java:1784)
          at java.io.ObjectOutputStream.flush(ObjectOutputStream.java:691)
          at org.jboss.remoting.marshal.serializable.SerializableMarshaller.getMarshallingStream(SerializableMarshaller.java:90)
          at org.jboss.remoting.marshal.serializable.SerializableMarshaller.getMarshallingStream(SerializableMarshaller.java:72)
          at org.jboss.remoting.transport.socket.ClientSocketWrapper.createOutputStream(ClientSocketWrapper.java:198)
          at org.jboss.remoting.transport.socket.ClientSocketWrapper.createStreams(ClientSocketWrapper.java:161)
          at org.jboss.remoting.transport.socket.ClientSocketWrapper.<init>(ClientSocketWrapper.java:66)
          at org.jboss.remoting.transport.socket.ServerSocketWrapper.<init>(ServerSocketWrapper.java:46)
          ... 7 more
      2010-02-16 02:05:27,418 ERROR [org.jboss.invocation.pooled.server.ServerThread] (PooledInvokerThread-172.20.2.5-1) Failed to initialize
      java.net.SocketException: Connection reset by peer: socket write error
          at java.net.SocketOutputStream.socketWrite0(Native Method)
          at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
          at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
          at java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:65)
          at java.io.BufferedOutputStream.flush(BufferedOutputStream.java:123)
          at java.io.ObjectOutputStream$BlockDataOutputStream.flush(ObjectOutputStream.java:1784)
          at java.io.ObjectOutputStream.flush(ObjectOutputStream.java:691)
          at org.jboss.invocation.pooled.server.ServerThread.dorun(ServerThread.java:263)
          at org.jboss.invocation.pooled.server.ServerThread.run(ServerThread.java:156)
      2010-02-16 02:05:27,418 ERROR [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#44[172.20.2.5:36827]) WorkerThread#44[172.20.2.5:36827] exception occurred during first invocation
      java.net.SocketException: Connection reset
          at java.net.SocketInputStream.read(SocketInputStream.java:168)
          at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
          at java.io.BufferedInputStream.read(BufferedInputStream.java:237)
          at java.io.FilterInputStream.read(FilterInputStream.java:66)
          at org.jboss.remoting.transport.socket.ServerThread.readVersion(ServerThread.java:1038)
          at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:673)
          at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:524)
          at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)

      {code}

       

      After that, the JVM process is still running, and we can cleanly shut down JBoss, but it seems that the web stuff doesn't work anymore. I'm at a loss, so I've temporarily disabled the Nessus scan and that seems to have stopped the issue. Not scanning the server isn't a long-term solution, however, so I'd like to figure out what's going on here. I have a dev JBoss server that I can test against if anyone has any ideas...

       

      Thanks,

       

      Derek

       

        • 1. Re: Nessus scan makes JBoss 5.1.0.GA stop processing web requests

          Derek, have you had any luck resolving this issue?  We have recently upgraded to JBoss 5.1.0.GA and are experiencing the same problem.  Any ideas?

           

          Thanks,

          Tom

          • 2. Re: Nessus scan makes JBoss 5.1.0.GA stop processing web requests

            No, I haven't really had the time to dig into it much. At some point I'm going to set up a test JBoss instance and run each nessus plugin against it separately to see if I can find the one that causes the failure, but for now I'm too tied up with other things.

             

            Derek

            • 3. Re: Nessus scan makes JBoss 5.1.0.GA stop processing web requests
              snacker

              We are seeing a similar issue, but it is not caused by a scanning application.

               

              On the web server side we see occasionally see threads with this stack:

               

              75: [Thread[jrpp-1390,5,jrpp]]/id=49440/hc=13398717/shc=*/state=RUNNABLE/name=*
                      java.net.SocketInputStream.socketRead0(Native Method)
                      java.net.SocketInputStream.read(SocketInputStream.java:129)
                      java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
                      java.io.BufferedInputStream.read(BufferedInputStream.java:237)
                      java.io.ObjectInputStream$PeekInputStream.peek(ObjectInputStream.java:2249)
                      java.io.ObjectInputStream$BlockDataInputStream.readBlockHeader(ObjectInputStream.java:2429)
                      java.io.ObjectInputStream$BlockDataInputStream.refill(ObjectInputStream.java:2499)
                      java.io.ObjectInputStream$BlockDataInputStream.read(ObjectInputStream.java:2571)
                      java.io.ObjectInputStream.read(ObjectInputStream.java:820)
                      org.jboss.remoting.transport.socket.MicroSocketClientInvoker.readVersion(MicroSocketClientInvoker.java:1263)
                      org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:838)
                      org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:165)
                      org.jboss.remoting.Client.invoke(Client.java:1724)
                      org.jboss.remoting.Client.invoke(Client.java:629)
                      org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
                      org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
                      org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
                      org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
                      org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
                      org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
                      org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
                      org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
                      org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
                      $Proxy5.invoke(Unknown Source)
                      org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:207)
                      org.jboss.ejb3.proxy.impl.handler.session.SessionProxyInvocationHandlerBase.invoke(SessionProxyInvocationHandlerBase.java:164)
                      $Proxy1643.completeMyOrder(Unknown Source)

                      ... rest of our business process thread stack...

               

              On the jboss server for each thread above we usually see at least 2 jboss threads with the following stack:

               

              816: [WorkerThread#10[10.1.4.245:46454]]/id=6923/hc=1806701791/shc=*/state=RUNNABLE/name=*
                       java.net.SocketInputStream.socketRead0(Native Method)
                       java.net.SocketInputStream.read(SocketInputStream.java:129)
                       java.io.BufferedInputStream.fill(BufferedInputStream.java:218)
                       java.io.BufferedInputStream.read(BufferedInputStream.java:237)
                       java.io.ObjectInputStream$PeekInputStream.peek(ObjectInputStream.java:2249)
                       java.io.ObjectInputStream$BlockDataInputStream.readBlockHeader(ObjectInputStream.java:2429)
                       java.io.ObjectInputStream$BlockDataInputStream.refill(ObjectInputStream.java:2499)
                       java.io.ObjectInputStream$BlockDataInputStream.read(ObjectInputStream.java:2571)
                       java.io.ObjectInputStream.read(ObjectInputStream.java:820)
                       org.jboss.remoting.transport.socket.ServerThread.readVersion(ServerThread.java:1038)
                       org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:673)
                       org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:551)
                       org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)

               

              I am not sure what is going on, but it looks like there is something that occasionally gets messed up with these "readVersion(...)" methods.

               

              These threads will hang for hours and days.

               

              The only way we can get these to stop hanging is to send a Thread.interrupt() to the threads on the web server side.

               

              Sending the interrupt to the thread on the jboss side only moves the problem to a different thread and doesn't stop the web server threads from hanging.

               

              We are not sure what is causing this, but it appears to be a bug in jboss.

              We are using 5.1.0 GA as well.

              • 4. Re: Nessus scan makes JBoss 5.1.0.GA stop processing web requests
                snacker

                We just had 5 of these which were hung for over 4 hours.

                 

                They persisted on the web server side even after a restart of the jboss server processes.

                 

                Does anyone know what could be causing this?

                • 5. Re: Nessus scan makes JBoss 5.1.0.GA stop processing web requests
                  jaikiran

                  The root cause of this is something going wrong on the server (you'll probably have to dig into the logs). The hang is actually a side-effect and is a bug https://jira.jboss.org/browse/JBREM-1188. Ideally, the remoting threads should have timed out, but due to the bug, they just hang around. Do you see any exceptions in the logs which might cause this side effect? Also, when does this happen? During undeployment or during deployment or during runtime?

                  • 6. Re: Nessus scan makes JBoss 5.1.0.GA stop processing web requests
                    snacker

                    Our SA's can't find any problems on the servers nor the network.

                    What we're going to try is updating jboss-remoting.jar to 2.5.2.SP3 and see if that helps.

                     

                    I am open to suggestions if you know of any logs or other troubleshooting things we could try.

                     

                    It happens at random times during day (not every day though).

                     

                    I've seen at most 7 threads accross 4 servers hanging simultaneously.

                     

                    They were not all started at the same time though.

                     

                    I don't see anything significant in the logs.

                    • 7. Re: Nessus scan makes JBoss 5.1.0.GA stop processing web requests
                      izan

                      Hi all!

                       

                      I'm seeing this error also, and don't know how to get over it. I am using JBoss AS 5.1.0.GA with jboss-remoting 2.5.1, and also checked with jboss-remoting.jar 2.5.4.SP3 in client and common/lib folders (not sure if I should replace more JARs)

                       

                      These are the tests that I have done so far:

                       

                      1. Nessus scan on port 3873

                      2012-02-23 14:23:39,936 ERROR [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#4[xx.x.x.x:53826]) WorkerThread#4[x.x.x.x:53826] exception occurred during first invocation

                      java.lang.reflect.InvocationTargetException

                          at sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)

                          at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)

                          at java.lang.reflect.Constructor.newInstance(Constructor.java:513)

                          at org.jboss.remoting.transport.socket.ServerThread.createServerSocketWrapper(ServerThread.java:909)

                          at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:491)

                          at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)

                      Caused by: java.io.EOFException

                          at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2280)

                          at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2749)

                          at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:779)

                          at java.io.ObjectInputStream.<init>(ObjectInputStream.java:279)

                          at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.<init>(ObjectInputStreamWithClassLoader.java:100)

                          at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.createInput(JavaSerializationManager.java:54)

                          at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.getMarshallingStream(SerializableUnMarshaller.java:75)

                          at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.getMarshallingStream(SerializableUnMarshaller.java:58)

                          at org.jboss.remoting.transport.socket.ClientSocketWrapper.createInputStream(ClientSocketWrapper.java:179)

                          at org.jboss.remoting.transport.socket.ClientSocketWrapper.createStreams(ClientSocketWrapper.java:162)

                          at org.jboss.remoting.transport.socket.ClientSocketWrapper.<init>(ClientSocketWrapper.java:66)

                          at org.jboss.remoting.transport.socket.ServerSocketWrapper.<init>(ServerSocketWrapper.java:46)

                          ... 6 more

                       

                      2. telnet localhost 3873 throws the following exception

                       

                      2012-02-23 14:23:55,246 ERROR [org.jboss.remoting.transport.socket.ServerThread] (WorkerThread#4[x.x.x.x:54029]) WorkerThread#4[x.x.x.x:54029] exception occurred during first invocation

                      java.lang.reflect.InvocationTargetException

                          at sun.reflect.GeneratedConstructorAccessor199.newInstance(Unknown Source)

                          at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)

                          at java.lang.reflect.Constructor.newInstance(Constructor.java:513)

                          at org.jboss.remoting.transport.socket.ServerThread.createServerSocketWrapper(ServerThread.java:909)

                          at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:491)

                          at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:232)

                      Caused by: java.net.SocketException: Connection reset

                          at java.net.SocketInputStream.read(SocketInputStream.java:168)

                          at java.io.BufferedInputStream.fill(BufferedInputStream.java:218)

                          at java.io.BufferedInputStream.read1(BufferedInputStream.java:258)

                          at java.io.BufferedInputStream.read(BufferedInputStream.java:317)

                          at java.io.ObjectInputStream$PeekInputStream.read(ObjectInputStream.java:2265)

                          at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2278)

                          at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2749)

                          at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:779)

                          at java.io.ObjectInputStream.<init>(ObjectInputStream.java:279)

                          at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.<init>(ObjectInputStreamWithClassLoader.java:100)

                          at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.createInput(JavaSerializationManager.java:54)

                          at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.getMarshallingStream(SerializableUnMarshaller.java:75)

                          at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.getMarshallingStream(SerializableUnMarshaller.java:58)

                          at org.jboss.remoting.transport.socket.ClientSocketWrapper.createInputStream(ClientSocketWrapper.java:179)

                          at org.jboss.remoting.transport.socket.ClientSocketWrapper.createStreams(ClientSocketWrapper.java:162)

                          at org.jboss.remoting.transport.socket.ClientSocketWrapper.<init>(ClientSocketWrapper.java:66)

                          at org.jboss.remoting.transport.socket.ServerSocketWrapper.<init>(ServerSocketWrapper.java:46)

                       

                      Don't know if this was solved by the original poster somehow, but if someone has a clue where to keep looking, I'd be much obliged!

                      • 8. Re: Nessus scan makes JBoss 5.1.0.GA stop processing web requests
                        snacker

                        Is jboss hanging as in the original post or are you just seeing these errors in the logs?

                        • 9. Re: Nessus scan makes JBoss 5.1.0.GA stop processing web requests
                          izan

                          The server is not exactly hanging, since I can access local EJBs, and also access databases and so on. The problem is it looses all ability to invoke remote EJBs and viceversa. We have several AS deployed, and we've seen this behaviour in two machines. Any clues?

                          • 10. Re: Nessus scan makes JBoss 5.1.0.GA stop processing web requests
                            snacker

                            I have not seen this before, where it looses the ability to invoke EJBs.

                             

                            You are saying the jboss instance cannot invoke other EJB's from a different machine (likely running jboss also?) and clients are unable to remotely invoke EJBs on that jboss server that is having the problem after the Nessus scan?

                             

                            What are the errors you're seeing when the jboss server is unable to invoke a remote EJB running on another (jboss?) machine?

                             

                            What error do you see on the client side when it is unable to invoke EJBs running on the jboss instance that is having problems?

                            • 11. Re: Nessus scan makes JBoss 5.1.0.GA stop processing web requests
                              izan

                              Sorry, it was a typo on my side: it is Nagios, not nessus, what we use to monitor status of AS.

                               

                              We have the following setup:

                              • Several AS, each one in a different server.
                              • EAR deployed in each AS. Every app is the same (i.e. the same EAR copied in the deploy folder), and some parameters like address and some ids are configured to identify each app deployed in one AS from another. This application has a local EJB layer to serve information to a GUI, and a remote EJB to allow exchange of information between different applciations via EJB-RMI in ports 1098-1099-3873.

                               

                              Everything went well untill we started monitoring with Nagios on these ports, and we've discovered that it is port 3873 (EJB3 Remoting Connector) the one causing problems by doing these direct telnets. After some time, two of the AS stop sending or receiving information from other applications. We've been debugging, and the appliation can work normally with local EJBs and so on, accessing DBs, JMS queues... but when we get to send something, it hangs doing the context.lookup of the remote EJB.

                               

                              We are stucked at that point, trying to figure out what it is. Could it be that the connections stablished by Nagios are not closed correctly and the AS runs out of connections?

                              • 12. Re: Nessus scan makes JBoss 5.1.0.GA stop processing web requests
                                snacker

                                Can you get a stack trace of the threads that are hanging when they are hanging?

                                 

                                Unix : kill -QUIT <jboss-pid>

                                Windows : CTRL+BREAK in DOS window (if any)

                                jmx-console (jboss 5 or 6) : "jboss.system" -> "type=ServerInfo" -> click on button for "listThreadDump"

                                JDK jstack : jstack [-F] -l <pid>

                                 

                                You could also try jconsole, jvisualvm or MBean java.lang.Threading ("java.lant:type=Threading") "dumpAllThreads()".

                                 

                                That might give a bit more insight as to what is going on here.

                                • 13. Re: Nessus scan makes JBoss 5.1.0.GA stop processing web requests
                                  izan

                                  Sorry for the late reply. We've stopped monitoring those ports with Nagios, and the problem disappeared. I will try to set a test environment in a virtual machine to try and reproduce the problem, but I won't have it at least before a week, since we are quite busy at the moment. I will also try to reproduce the problem in a JBoss installed in my development machine. I tryed doing telnet to a local JBoss and the problem is the same, but I need another one running in a VM to see if they can communicate.

                                   

                                  Let's see if we can nail this down, 'cos now I'm really curious to find out what is happening!

                                   

                                  I'll write back when I have more info on the matter.

                                  • 14. Re: Nessus scan makes JBoss 5.1.0.GA stop processing web requests
                                    samavedulark

                                    Hi,

                                     

                                    We are facing similar issue, could some one help to resolve this issue?

                                    it is happening due to scans performed.

                                     

                                    Thanks