Hello again,
Sorry for two posts in a row but I've been saving up my problems until
now. :-)
I have one Stateless Session Bean and three Entity Beans, two of which are
in use.
The Stateless Session Bean has a method like this:
public String foo(String) {
String response = "not foo";
try {
// lookup Entity Bean 1 via jndi
// use finder method to locate instance of EB1
// examine data in EB1 instance
if ( data from EB1 = something ) {
// lookup Entity Bean 2 via jndi
// use create method to create new isntance of EB2
response = eb2.getData();
}
} catch ( Exception e ) {
// dump exception data to log
}
// dump response text to log
return response;
}
>From my client app I access the SSB and everything works just fine.
Nothing out of the ordinary, in fact the only anomaly in the entire jboss
setup is a set of SQL NPE/JDBC NPE warnings when deploying the bean. A
search of the archives found the consensus that they were safe to ignore
and the fact that everything works fine makes me agree.
Out of curiosity I ran my client a few more times. In fact what I did was
place four calls to 'foo' in my client and then ran it five times in a
row. On the fifth call, the response is logged but all I get back at the
other end is:
java.rmi.ServerException: RemoteException occurred in server thread; nested exception
is:
java.rmi.ServerException: Exception occurred; nested exception is:
java.lang.NullPointerException
java.rmi.ServerException: Exception occurred; nested exception is:
java.lang.NullPointerException
java.lang.NullPointerException
at
sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:245)
at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:220)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:122)
<etc>
I've inserted many more trace messages into the code and have reduced the
situation down to happening in one of two locations--with no
predicatability as to when/where it will occur. It's important to note
that there aren't any decisions being made inside of the code, it is
executing the exact same path every single time. That conditional in the
above pseudocode always evaluates to true. After I solve my communication
problems the app logic will be added in. Here are the two types of errors
I'm encountering:
1) Somewhere after a return(); statement in a bean but before that return
'arrives' at the caller. It doesn't seem to matter if it is the return
from my client's call to the sesion bean or if it's my Entity beans
returning from a business method (well, accessor) to my Session bean.
The only weird part is that I am precluded from catching the exception in
the latter case as it bypasses my catch statement in the Session bean and
goes directly to the client.
2) JNDI failure looking up the Entity bean Home interface. This JNDI
error can occur in my client's attempt to find the Session bean's
interface but when that occurs I can see a nested socket exception:
javax.naming.ServiceUnavailableException: no further information (code=10055). Root
exception is java.net.SocketException: no further information (code=10055)
Here is where life gets interesting because that's the same 'code=10055' I
get when my client is unable to connect to jboss. Here is a full stack
trace of that event:
java.rmi.ConnectIOException: Exception creating connection to: localhost; nested
exception is:
java.net.SocketException: no further information (code=10055)
java.net.SocketException: no further information (code=10055)
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:312)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:125)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:112)
at java.net.Socket.<init>(Socket.java:273)
at java.net.Socket.<init>(Socket.java:100)
at
sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:25)
at
sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:120)
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:499)
at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:190)
at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:174)
at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:83)
at
org.jboss.ejb.plugins.jrmp.server.JRMPContainerInvoker_Stub.invokeHome(Unknown Source)
at org.jboss.ejb.plugins.jrmp.interfaces.HomeProxy.invoke(HomeProxy.java:221)
at $Proxy0.create(Unknown Source)
at
_jsp._test._jndi._jboss._TestJNDI__jsp._jspService(/test/jndi/jboss/TestJNDI.jsp:91)
at com.caucho.jsp.JavaPage.service(JavaPage.java:89)
at com.caucho.jsp.JavaPage.subservice(JavaPage.java:83)
at com.caucho.jsp.Page.service(Page.java:298)
at com.caucho.jsp.QServlet.service(QServlet.java:161)
at com.caucho.server.http.Invocation.service(Invocation.java:242)
at com.caucho.server.http.CacheInvocation.service(CacheInvocation.java:111)
at com.caucho.server.http.HttpRequest.handleRequest(HttpRequest.java:181)
at com.caucho.server.http.HttpRequest.handleConnection(HttpRequest.java:137)
at com.caucho.server.TcpConnection.run(TcpConnection.java:139)
at java.lang.Thread.run(Thread.java:484)
As near as I can tell, the heart and soul of the second error is either
socket resource exhaustion under windows 98 or the jboss server becoming
overloaded and not responding. Our deployment environment will be RedHat
6.x but our development environment (for various reasons) is currently
Win98/Win2K.
If the RMI code does not sanely check for certain types of errors, this
could also be the cause of the first error. I'm guessing it could either
an issue in sun's rmi code or in how it is wrappered and handled in the
container/dispatcher. I'm not keen on the "hey it's Window's fault"
explanation as it seems too simplistic.
I'm going to configure and deploy the beans under redhat 6.2 soon in order
to do further experimentation on the socket issue but I would greatly
appreciate any feedback from persons who know more about the internals of
how jboss handles JNDI lookups (under what circumstances jndi would fail
to respond) and how the container manages the rmi calls such that a return
statement could generate a null pointer exception which is un-catchable by
the caller of the RMI statement and the container passes that directly
back to the root-client.
As before, your help is greatly appreciated. I'm keen to make jboss work
in a production environment, believe that it can and until now every
failing I have come across has been due to my mis-configuration of one
aspect or another. This time, however I have exhausted my avenues of
exploration save for the source code. An endevour I'm not able to
undertake at this time.
As an aside--I'm curious if there are any other commercial ventures using
or attempting to use jboss as a production EJB server? I didn't see a
list of sites or companies that are doing so on the jboss web site and I'm
*extremely* interested in any jboss success stories.
C=)
--------------------------------------------------------------------------
There are no significant bugs in our released software that any significant
number of users want fixed. -Bill Gates, Focus Magazine, Oct 23, 1995
--------------------------------------------------------------------------
Caskey <caskey*technocage.com> /// TechnoCage Inc.
--------------------------------------------------------------------------
"Welcome to the slippery slope, here is your handbasket.
...say, can you work 70 hours this week?"
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
