June 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBREM-717) servlet invoker illegal state exception not serializable

by John Mazzitelli (JIRA)

servlet invoker illegal state exception not serializable -------------------------------------------------------- Key: JBREM-717 URL: http://jira.jboss.com/jira/browse/JBREM-717 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.GA (Boon) Reporter: John Mazzitelli Assigned To: Tom Elrod I have my server-side using the servlet invoker (I'm inside JBossAS 4.0.5). After I shutdown and try to restart, I think I might not be restarting properly. If a client sends in a message, I get this stack trace and an HTTP 500 error comes across on the client. Here's the server-side stack: 15:59:05,510 WARN [[ServerInvokerServlet]] Servlet.service() for servlet ServerInvokerServlet threw exception java.io.NotSerializableException: org.jboss.remoting.transport.servlet.ServletServerInvoker at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1075) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1369) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1341) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1284) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1073) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:291) at org.jboss.remoting.marshal.http.HTTPMarshaller.write(HTTPMarshaller.java:69) at org.jboss.remoting.transport.servlet.ServletServerInvoker.processRequest(ServletServerInvoker.java:257) at sun.reflect.GeneratedMethodAccessor183.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155) at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94) at org.jboss.mx.server.Invocation.invoke(Invocation.java:86) at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264) at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659) at javax.management.MBeanServerInvocationHandler.invoke(MBeanServerInvocationHandler.java:201) at $Proxy185.processRequest(Unknown Source) at org.jboss.remoting.transport.servlet.web.ServerInvokerServlet.processRequest(ServerInvokerServlet.java:127) at org.jboss.remoting.transport.servlet.web.ServerInvokerServlet.doPost(ServerInvokerServlet.java:156) at javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at javax.servlet.http.HttpServlet.service(HttpServlet.java:810) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112) at java.lang.Thread.run(Thread.java:595) So this IllegalStateException is thrown because something didn't get restarted. But the fact that this IllegalStateException is defined inside the ServerInvoker object makes it not serializable (ServerInvoker.IllegalStateException is not serializable because ServerInvoker is not serializable). This issue is to document the fact that this exception is not serializable - the whole "restart didn't fully restart" problem is something that may be my fault. Recommend that you split out IllegalStateException so you can send it over the wire - or thrown a java.lang.IllegalStateException. This is in 2.0.0.GA. I haven't tried to see if this is an issue in later versions. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 10 months

4
10
0 / 0

[JBoss JIRA] Created: (JBREM-731) Address of secondary server socket should be acquired each time a control connection is created.

by Ron Sigal (JIRA)

Address of secondary server socket should be acquired each time a control connection is created. ------------------------------------------------------------------------------------------------ Key: JBREM-731 URL: http://jira.jboss.com/jira/browse/JBREM-731 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.0.GA (Bluto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) Scenario: Client is connected to a server, server dies, and server is restarted (with same InvokerLocator). The new server creates a secondary server socket on a different port than the previous server, but the client invoker retains the old secondary server socket InvokerLocator. When a new Client is created, the old client invoker gets reused, and it isn't possible to create a control connection. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 10 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-756) CallbackPoller should shut down if too many errors occur.

by Ron Sigal (JIRA)

CallbackPoller should shut down if too many errors occur. --------------------------------------------------------- Key: JBREM-756 URL: http://jira.jboss.com/jira/browse/JBREM-756 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) org.jboss.remoting.callback.CallbackPoller will keep running even if the connection is broken or server crashes. It should be possible to specify a maximum number of errors, after which CallbackPoller will quit polling. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 10 months

1
5
0 / 0

[JBoss JIRA] Created: (HIBERNATE-55) No way to specify Connection Release Mode in HMBean

by Mohammed Sadiq (JIRA)

No way to specify Connection Release Mode in HMBean --------------------------------------------------- Key: HIBERNATE-55 URL: http://jira.jboss.com/jira/browse/HIBERNATE-55 Project: Hibernate Issue Type: Feature Request Reporter: Mohammed Sadiq Assigned To: Steve Ebersole In my application I have employed an Hibernate MBean for session factory creation and binding it to JNDI and I've added a new overload for the SessionFactory.openSession(Interceptor, ConnectionReleaseMode) method to oveeride the default connection release mode. The default connection release mode for any Hibernate session created using the session factory deployed through a Hibernate MBean configuration is taken as "after_statement". It will be more helpful, if there exists an MBean attribute "ConnectionReleaseMode" which can thake the enumerated values from the org.hibernate.ConnectionReleaseMode. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 10 months

2
1
0 / 0

[JBoss JIRA] Created: (JBREM-755) Make ConnectorValidator parameters configurable

by Ron Sigal (JIRA)

Make ConnectorValidator parameters configurable ----------------------------------------------- Key: JBREM-755 URL: http://jira.jboss.com/jira/browse/JBREM-755 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) Currently org.jboss.remoting.ConnectionValidator hard codes the timeout value (1000 ms) and the number of attempts (1) to get a socket (socket transport family only). It would be useful to be able to configure these parameters. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 10 months

1
7
0 / 0

[JBoss JIRA] Created: (JBREM-754) Reset timeout on each use of HttpURLConnection

by Ron Sigal (JIRA)

Reset timeout on each use of HttpURLConnection ---------------------------------------------- Key: JBREM-754 URL: http://jira.jboss.com/jira/browse/JBREM-754 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) Even though each call to org.jboss.remoting.transport.http.HTTPClientInvoker.invoke() creates a new HttpURLConnection, it seems that the HttpURLConnection implementation caches underlying connections. When an org.jboss.remoting.ConnectionValidator is running, it connects to the same server as ordinary HTTPClientInvokers used by the application, but it sets a timeout of 1000. If no timeout value is configured for application connections, then HTTPClientInvoker does not set a timeout on the HttpURLConnection, and a connection with a timeout of 1000 might get reused. If no timeout is configured, HTTPClientInvoker should explicitly set the HttpURLConnection connect and read timeouts to 0. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 10 months

1
5
0 / 0

[JBoss JIRA] Created: (JBREM-749) BisocketServerInvoker: Make configurable the address and port of secondary server socket

by Takayoshi Kimura (JIRA)

BisocketServerInvoker: Make configurable the address and port of secondary server socket ---------------------------------------------------------------------------------------- Key: JBREM-749 URL: http://jira.jboss.com/jira/browse/JBREM-749 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.2.0.GA (Bluto) Reporter: Takayoshi Kimura Assigned To: Ron Sigal This is a feature request for someone who needs to fix the secondary port used by the bisocket protocol. In 2.2.0.GA, it is not configurable: InetAddress host = getServerSocket().getInetAddress(); int freePort = PortUtil.findFreePort(host.getHostAddress()); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 10 months

2
5
0 / 0

[JBoss JIRA] Created: (JBREM-747) org.jboss.remoting.transport.Connector should unregister server invoker from MBeanServer

by Ron Sigal (JIRA)

org.jboss.remoting.transport.Connector should unregister server invoker from MBeanServer ---------------------------------------------------------------------------------------- Key: JBREM-747 URL: http://jira.jboss.com/jira/browse/JBREM-747 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) The JBossMessaging secure-socket smoke test uncovered the fact that Connector does not unregister its server invoker from the MBeanServer (if it has a reference to one). The problem detected by the JBossMessaging was that when secure-socket runs twice, the first execution passes and the second fails with the exception javax.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled. at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.checkEnabledSuites(SSLServerSocketImpl.java:303) at com.sun.net.ssl.internal.ssl.SSLServerSocketImpl.accept(SSLServerSocketImpl.java:253) at org.jboss.remoting.transport.bisocket.BisocketServerInvoker$SecondaryServerSocketThread.run(BisocketServerInvoker.java:799) The problem was that at the end of the first execution, Connector failed to unregister the server invoker, and during the second execution, it saw the ObjectName registered. The Connector.init() code then failed to pass a reference to the MBeanServer to the server invoker. As a result the server invoker was unable to access the SSLServerSocketFactory MBean configured by the test, and it used a default server socket factory instead. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 10 months

1
7
0 / 0

[JBoss JIRA] Created: (JBREM-743) For polling callback handler, org.jboss.remoting.Client.addListener() should create only one CallbackPoller per InvokerCallbackHandler

by Ron Sigal (JIRA)

For polling callback handler, org.jboss.remoting.Client.addListener() should create only one CallbackPoller per InvokerCallbackHandler -------------------------------------------------------------------------------------------------------------------------------------- Key: JBREM-743 URL: http://jira.jboss.com/jira/browse/JBREM-743 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.4.0.Beta1 (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.Beta1 (Pinto) If a given InvokerCallbackHandler is passed to Client.addListener() multiple times, a new CallbackPoller will be created each time, although only the first one leads to the registration of a new ServerInvokerCallbackHandler with ServerInvoker on the server side. The semantics, according to Chapter 5 of the Remoting guide, should be If there is no callback Connector, which is the case for pull callbacks and simulated push callbacks (see Section Registering callback handlers), then the callback connection is identified by the combination of the Client on which addListener() was invoked and the InvokerCallbackHandler. It follows that if an InvokerCallbackHandler is registered twice with the same Client for pull or simulated push callbacks, only a single callback connection is created. That is, the second call has no effect. So only one CallbackPoller should be created per (Client, InvokerCallbackHandler) pair. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 10 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-641) re-implement the callback polling for http transport to reduce latency

by Tom Elrod (JIRA)

re-implement the callback polling for http transport to reduce latency ---------------------------------------------------------------------- Key: JBREM-641 URL: http://jira.jboss.com/jira/browse/JBREM-641 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: callbacks Affects Versions: 2.0.0.GA (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.2.0.Beta1 (Bluto) Per forum thread, would be nice to have a more "real-time" way to get callbacks from server when using http transport so don't have to wait on ping period. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

18 years, 10 months

2
12
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2007