[Remoting] - Re: Exceptions in calls and callbacks
by ron.sigalï¼ jboss.com
"shdv" wrote : "tom.elrod(a)jboss.com" wrote : About the only thing can know for sure is if get a CannotConnectException, the call never reached the server. Anything else would be difficult to know for sure (i.e. if get SocketException, can't be certain that call didn't make it to server).
|
| Why does org.jboss.remoting.Client.invoke() throw Exception when client is not connected? According to the above description it should be CannotConnectExcetption.
|
| I was really disappointed when I got it. My code catches CannotConnectException to handle connection issues.
|
| Since Client is usually wrapped in a proxy, under some circumstances proxy class can wrap it into UndeclaredThrowableException making things even worse.
Well, when Client.invoke() throws Exception, it's not a *cannot* connect problem, it's a *did not* connect problem.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057960#4057960
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057960
19Â years
[JBoss Seam] - Re: Bug? Seam-2.0-Beta - HttpSession Creation
by PatrickMadden
Hi,
I have a workaround for this but I can't imagine that its something you all will be happy with.
For the sessionCreated and sessionDestroyed methods I simply put them in a runnable and called them later.
It appears that as soon as I call HttpSessionEvent.getSession() is when the recursive loop occurrs.
Anyway here is my workaround for now:
| public void sessionCreated(final HttpSessionEvent evt)
| {
| Runnable runner = new Runnable()
| {
| public void run()
| {
| XSystem.logInfo("Session Created = " + evt.getSession().getId());
| IdToSessionMap.getInstance().addHttpSession(evt.getSession());
| SessionController.getInstance(evt.getSession().getId());
| }
| };
|
| EventQueue.invokeLater(runner);
|
| }
|
| public void sessionDestroyed(final HttpSessionEvent evt)
| {
| Runnable runner = new Runnable()
| {
| public void run()
| {
| XSystem.logInfo("Session Destroyed = " + evt.getSession().getId());
| IdToSessionMap.getInstance().removeHttpSession(evt.getSession());
| SessionController.freeInstance(evt.getSession().getId());
| }
| };
|
| EventQueue.invokeLater(runner);
| }
|
Looking forward to know whether or not I'm crazy :)
Thanks,
PVM
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057957#4057957
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057957
19Â years
[Remoting] - Re: EJB3/Socket invoker - connection timeouts
by ron.sigalï¼ jboss.com
anonymous wrote :
| It appears that this thread, which ought to be quickly finding a ServerThread to handle the incoming request, calling ServerThread.start(), and getting back to the call to serverSocket.accept() as quickly as possible, is instead doing some socket I/O. ServerSocketWrapper.java has a method called createInputStream() that creates a new ObjectInputStream. The stack trace shows that the JBossObjectInputStream constructor is reading some bytes from the input stream, but I don't think that this problem is specific to JBoss Serialization, as java.io.ObjectInputStream's constructor also reads bytes from the stream.
|
| It seems to me that this could be the cause of the problem that we are seeing. Any time that you're doing a blocking socket read like this, you can potentially just sit for a while until the socket times out. When you've got a thread calling serverSocket.accept(), you can't normally afford to do something like this on that thread.
|
| Does this analysis make sense? Any thoughts/suggestions would be greatly appreciated.
|
It does indeed make sense. See JIRA issue JBREM-666 (http://jira.jboss.com/jira/browse/JBREM-666 ).
This problem was fixed in the Remoting 2.2.0 releases, the most recent of which is 2.2.0.SP4. Which version of the Application Server are you using? The latest GA release, 4.2.0.GA, comes with Remoting 2.2.0.SP4. If you can't upgrade that far, then you might try getting the latest version of EJB3, which, I believe, should work with Remoting 2.2.0. This could cause problems for other Remoting clients which depend on an older version of Remoting. In that case, look into scoped deployment, which allows different applications to use different library versions. See, for example, the wiki page "ClassLoadingConfiguration" (http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration).
-Ron
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4057954#4057954
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4057954
19Â years