I would need more info on what you are doing (assume is ejb3 call), but from the stack trace, it looks like the client is no longer available (hence the Connection reset) while during the keep alive. The socket server sends a byte to the client periodically to try to keep the socket alive so the client doesn't have to recreate one for each client call.
This is not an error (as denoted by the log level being outputed at DEBUG level), and is expected. However, since this does show up in the log and assume many see this as an error since a stack trace is being logged, I have changed this to trace (there is a jira issue on it somewhere and can look it up if you need). Sorry about the confusion.
If there is an actual bug (meaning something did not work as expected), please let me know (along with a little more detail).
the client closes the connection (in fact terminates) because the server have a problem with the null value of my Calendar attribute.
so I believe the problem is around the unmarshaller error. As I said the
problem appears only when I have a value in it.
I will try to build a simple example app.
Hi Noel. Some other people have seen problems with the 1.4.0 beta release of remoting as well. It has been fixed and the updated jar is in http://repository.jboss.com, under remoting snapshot version (also HEAD was updated to use this snapshot version).
I am not positive this will fix your issue, but was hoping you might could give it a test. If you find that it does not, could you open a jira issue?
the result is a clearer stacktrace with a nullpointer exception. BUT the problem is that my Calendar wasn't null in the client side.
22:17:32,374 INFO [STDOUT] ScheduleOnce toString startDate : null 22:17:32,374 INFO [STDOUT] java.lang.NullPointerException 22:17:32,374 INFO [STDOUT] at org.jboss.reporting.api.schedule.ScheduleOnce.toString(ScheduleOnce.java:44) 22:17:32,374 INFO [STDOUT] at java.lang.String.valueOf(Unknown Source) 22:17:32,374 INFO [STDOUT] at java.lang.StringBuffer.append(Unknown Source) 22:17:32,374 INFO [STDOUT] at org.jboss.reporting.api.ReportTaskImpl.toString(ReportTaskImpl.java:151) 22:17:32,374 INFO [STDOUT] at java.lang.String.valueOf(Unknown Source) 22:17:32,384 INFO [STDOUT] at java.lang.StringBuffer.append(Unknown Source) 22:17:32,384 INFO [STDOUT] at org.jboss.reporting.server.remoting.ReportRequestHandler.invoke(ReportRequestHandler.java:46) 22:17:32,384 INFO [STDOUT] at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:328) 22:17:32,384 INFO [STDOUT] at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:204) 22:17:32,384 INFO [STDOUT] at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:259) 22:17:32,384 INFO [STDOUT] at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:313) 22:17:32,384 INFO [STDOUT] at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:147)
from the server logs
2005-11-03 22:17:32,184 DEBUG [org.jboss.remoting.transport.socket.ServerThread] beginning dorun 2005-11-03 22:17:32,304 DEBUG [org.jboss.remoting.marshal.MarshalFactory] Could not find data type to lookup by unmarshaller class 2005-11-03 22:17:32,304 DEBUG [org.jboss.remoting.marshal.MarshalFactory] Tried to find unmarshaller from locator by both data type and class name but was unsuccessful.
what means "Tried to find unmarshaller from locator by both data type and class name but was unsuccessful." ?
Did I miss to configure something ?
I'm running this as a service (sar) in jboss4 with jdk 1.5
using a modified version of the complex2 example, the Calendar attribute value is received by the server and the sent back to the client without any problem.
I'm going further in my jboss4 config.
Think might be worth opening a jira issue on this. Do you mind doing that and including a way I can reproduce?
doing a testcase, I can't reproduce it.
I'm checking the differences and libs used.
Got it !
the root class in the class hierarchy of objects I'm sending with JB Remoting wasn't serializable. This was the cause.
Thanks Tom for the time spent.