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

d-rock Feb 16, 2010 3:47 PM

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

tgarcia Apr 30, 2010 9:27 AM (in response to d-rock)

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
Actions
2. Re: Nessus scan makes JBoss 5.1.0.GA stop processing web requests

d-rock May 27, 2010 11:07 AM (in response to tgarcia)

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
Actions
3. Re: Nessus scan makes JBoss 5.1.0.GA stop processing web requests

snacker Jun 16, 2010 8:49 PM (in response to d-rock)

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.
Actions
4. Re: Nessus scan makes JBoss 5.1.0.GA stop processing web requests

snacker Jun 17, 2010 2:51 PM (in response to 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?
Actions
5. Re: Nessus scan makes JBoss 5.1.0.GA stop processing web requests

jaikiran Jun 18, 2010 2:34 AM (in response to snacker)

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?
Actions
6. Re: Nessus scan makes JBoss 5.1.0.GA stop processing web requests

snacker Jun 18, 2010 7:43 PM (in response to jaikiran)

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.
Actions
7. Re: Nessus scan makes JBoss 5.1.0.GA stop processing web requests

izan Feb 23, 2012 9:57 AM (in response to snacker)

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!
Actions
8. Re: Nessus scan makes JBoss 5.1.0.GA stop processing web requests

snacker Feb 23, 2012 11:17 AM (in response to izan)

Is jboss hanging as in the original post or are you just seeing these errors in the logs?
Actions
9. Re: Nessus scan makes JBoss 5.1.0.GA stop processing web requests

izan Feb 23, 2012 11:29 AM (in response to snacker)

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?
Actions
10. Re: Nessus scan makes JBoss 5.1.0.GA stop processing web requests

snacker Feb 23, 2012 11:35 AM (in response to izan)

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?
Actions
11. Re: Nessus scan makes JBoss 5.1.0.GA stop processing web requests

izan Feb 23, 2012 12:15 PM (in response to snacker)
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?
Actions
12. Re: Nessus scan makes JBoss 5.1.0.GA stop processing web requests

snacker Feb 23, 2012 12:40 PM (in response to izan)

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.
Actions
13. Re: Nessus scan makes JBoss 5.1.0.GA stop processing web requests

izan Feb 27, 2012 5:52 AM (in response to snacker)

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.
Actions
14. Re: Nessus scan makes JBoss 5.1.0.GA stop processing web requests

samavedulark Oct 30, 2012 1:44 PM (in response to izan)

Hi,

We are facing similar issue, could some one help to resolve this issue?
it is happening due to scans performed.

Thanks
Actions

Go to original post