Link: Added: This issue is a dependency of JBESB-1777

Link: Added: This issue is related to SOA-509

Can we have confirmation that fixes are in place for 4.2CP03.

The JBESB issue was originally fixed in the ESB 4.2.1 CP3 release and should have been included into SOA 4.2CP2.  I have verified that the fixes are indeed present in the current branch.

Seeing this with 4.2CP03 CR5 - server.log is attached.

Steps to reproduce:

Set logging threshold to DEBUG

   <!-- A time/date based rolling appender -->
   <appender name="FILE" class="org.jboss.logging.appender.DailyRollingFileAppender">
      <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
      <param name="File" value="${jboss.server.log.dir}/server.log"/>
      <param name="Append" value="false"/>
      <param name="Threshold" value="DEBUG"/>

Start the server - after it's up - stop it and examine the log.


 grep "Unable to retrieve" ../server/default/log/server.log 
2008-12-09 16:25:06,635 DEBUG [org.jboss.web.tomcat.service.TomcatDeployer] Unable to retrieve orbjavax.management.InstanceNotFoundException: jboss:service=CorbaORB is not registered.
2008-12-09 16:25:09,262 DEBUG [org.jboss.web.tomcat.service.TomcatDeployer] Unable to retrieve orbjavax.management.InstanceNotFoundException: jboss:service=CorbaORB is not registered.
2008-12-09 16:25:12,025 DEBUG [org.jboss.web.tomcat.service.TomcatDeployer] Unable to retrieve orbjavax.management.InstanceNotFoundException: jboss:service=CorbaORB is not registered.
2008-12-09 16:25:15,119 DEBUG [org.jboss.web.tomcat.service.TomcatDeployer] Unable to retrieve orbjavax.management.InstanceNotFoundException: jboss:service=CorbaORB is not registered.
2008-12-09 16:25:16,722 DEBUG [org.jboss.web.tomcat.service.TomcatDeployer] Unable to retrieve orbjavax.management.InstanceNotFoundException: jboss:service=CorbaORB is not registered.
2008-12-09 16:25:18,156 DEBUG [org.jboss.web.tomcat.service.TomcatDeployer] Unable to retrieve orbjavax.management.InstanceNotFoundException: jboss:service=CorbaORB is not registered.
2008-12-09 16:25:41,752 DEBUG [org.jboss.web.tomcat.service.TomcatDeployer] Unable to retrieve orbjavax.management.InstanceNotFoundException: jboss:service=CorbaORB is not registered.
2008-12-09 16:25:42,144 DEBUG [org.jboss.web.tomcat.service.TomcatDeployer] Unable to retrieve orbjavax.management.InstanceNotFoundException: jboss:service=CorbaORB is not registered.
2008-12-09 16:25:42,801 DEBUG [org.jboss.web.tomcat.service.TomcatDeployer] Unable to retrieve orbjavax.management.InstanceNotFoundException: jboss:service=CorbaORB is not registered.
2008-12-09 16:26:25,143 DEBUG [org.jboss.web.tomcat.service.TomcatDeployer] Unable to retrieve orbjavax.management.InstanceNotFoundException: jboss:service=CorbaORB is not registered.
2008-12-09 16:26:45,219 DEBUG [org.jboss.web.tomcat.service.TomcatDeployer] Unable to retrieve orbjavax.management.InstanceNotFoundException: jboss:service=CorbaORB is not registered.

Attachment: Added: server.log.gz

I've emailed Kev to see if he's got any ideas.

The only ESB issue I can see in the original report is the third one, related to the database not closing

As for the other two, this is what I can find out.

"Unable to retrieve orbjavax.management.InstanceNotFoundException: jboss:service=CorbaORB is not registered. "
  This is generated by the TomcatDeployer if there is no Corba instance registered and appears to be reported for
  every war file deployed.  The deployer is attempting to map the ejb ORB into the war ENC.
  Nothing can be done about this, it is hardcoded and will always appear in a 'default' instance.

"[org.jboss.remoting.transport.socket.SocketServerInvoker] SocketServerInvoker[127.0.0.1:4457] caught exception in run() "

There are two of these within the log and it looks as if it may be due to an issue with JBoss Remoting.

2008-12-09 16:28:07,300 DEBUG [org.jboss.remoting.transport.socket.SocketServerInvoker] SocketServerInvoker[127.0.0.1:4457] caught exception in run()
java.net.SocketException: Socket closed
	at java.net.PlainSocketImpl.socketAccept(Native Method)
	at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
	at java.net.ServerSocket.implAccept(ServerSocket.java:450)
	at java.net.ServerSocket.accept(ServerSocket.java:421)
	at org.jboss.remoting.transport.socket.SocketServerInvoker.run(SocketServerInvoker.java:520)
	at java.lang.Thread.run(Thread.java:595)
2008-12-09 16:28:07,301 DEBUG [org.jboss.remoting.transport.socket.SocketServerInvoker] SocketServerInvoker[127.0.0.1:4446] caught exception in run()
java.net.SocketException: Socket closed
	at java.net.PlainSocketImpl.socketAccept(Native Method)
	at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:384)
	at java.net.ServerSocket.implAccept(ServerSocket.java:450)
	at java.net.ServerSocket.accept(ServerSocket.java:421)
	at org.jboss.remoting.transport.socket.SocketServerInvoker.run(SocketServerInvoker.java:520)
	at java.lang.Thread.run(Thread.java:595)

Both of these appear to have been stopped earlier but looks as if it may not have tidied up the socket accept.

2008-12-09 16:28:06,595 DEBUG [org.jboss.remoting.ServerInvoker] SocketServerInvoker[127.0.0.1:4457] stopped
2008-12-09 16:28:07,045 DEBUG [org.jboss.remoting.ServerInvoker] SocketServerInvoker[127.0.0.1:4446] stopped

Please note that JBESB-1777 was about a quickstart. The hudson job linked to in the Environment field doesn't run any quickstarts.

JBESB-1777 is about a quickstart and is the only ESB specific issue mentioned in the original report, SOA-509.

There are actually three issues raised, which has confused things.  The other two are as documented in my previous comment in this issue, the ESB one has been fixed.

No, in SOA-509 the messages were seen without running any quickstarts so any quickstart fix is not related IMHO. These are seen just by starting, querying for available mbeans, then stopping the server.

Still  the messages reported are in DEBUG so I don't have a strong opinion anything needs to be fixed. Just wanted to be clear what I have reported initially.

SOA-509 definitely mentions three issues and the ESB one is definitely related to the quickstarts.

The other two issues are not related to the ESB as they are in TomcatDeployer/Remoting.

I don't know how the remaining two were addressed as SOA-509 was closed a full month after JBESB-1777, with no further input.

I should add that the TomcatDeployer message cannot be resolved, but the JBR one may have been.

"SOA-509 definitely mentions three issues and the ESB one is definitely related to the quickstarts. "

Kevin, could you please explain why is it so? I can't see that in the description. As well I didn't run any quickstarts. So if it still is quickstart related, then be it :)
But I think it is not because JBESB-1777 is not linked to SOA-509 by me but Len https://jira.jboss.org/jira/browse/JBESB-1777?focusedCommentId=12414786#action_12414786

Furthermore I didn't create any ESB specific JIRA because I can't identify the correct component.

On your question why it was closed - I *believe* I have closed it because at one point I stopped checking DEBUG messages for exceptions and since these are on the DEBUG level I don't consider them relevant. Any comments about that are welcome!

I believe I have already done that, but if you feel something is missing then let me know.

Can I suggest that we split SOA-509 and this into two issues?  The ESB related bug was fixed, the tomcat one cannot be addressed and we have no idea about the JBR one.

Emailed Kev and Aleksandar to try to come up with plan to clear this.

Currently looking for a JBoss Remoting contact as ESB problem is fixed and the tomcat problem is not fixable.

Emailed Ron Sigal to see what he thinks about the JBR side.

Doesn't look like we're going to sort this for CP03 so I've move it up to CP04

Sorry for the delay - I was on vacation.

What's happening in Remoting is that the server's ServerSocket is closed when the server stops, and, as a result, the call to ServerSocket.accept() throws an exception which is logged at DEBUG level.  The situation is natural and harmless, but, if you'd prefer, I can change the log level to TRACE.  Just let me know.

-Ron

Hi Ron. No, it's fine as is. We'll make sure it's documented in the Release Notes though.

Link: Added: This issue is related to SOA-1219

Created separate doc JIRA to track.