]
Ron Sigal commented on JBREM-1010:
----------------------------------
It is now possible to use the org.jboss.remoting.ServerInvoker.CONNECTION_LISTENER
parameter (actual value "connectionListener") to inject an
org.jboss.remoting.ConnectionListener into a ServerInvoker, which, together with setting
the ServerInvoker.CLIENT_LEASE_PERIOD (actual value "clientLeasePeriod")
parameter to a value greater than 0, will turn on leasing. [See "Chapter 8. Network
Connection Monitoring" of the Remoting guide for more details.]
The injection may be done through the org.jboss.remoting.transport.Connector's
configuration map or its XML configuration file. The value associated with
"connectionListener" may be either the ObjectName of an existing MBean or the
name of a class which implements ConnectionListener. In the latter case, the class must
have a default constructor.
Unit test: org.jboss.test.remoting.lease.InjectedConnectionListenerTestCase.
Add feature to declaratively turn on leasing for 2.2.2
------------------------------------------------------
Key: JBREM-1010
URL:
https://jira.jboss.org/jira/browse/JBREM-1010
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public(Everyone can see)
Components: general
Affects Versions: 2.2.2.SP7
Reporter: Jay Howell
Assignee: Ron Sigal
Fix For: 2.2.2.SP9
We have a request to declaratively turn on leasing. Currently you can only do it via
debugging.
Here's the conversation from Ron so far. It says more than I could.
--------------------------------------------------------------
The problem lies in org.jboss.aspects.remoting.InvokeRemoteInterceptor, which (1) opens
an org.jboss.remoting.Client, (2) makes the invocation, and (3) closes the Remoting
client. I guess that's because there's no notion of a "session" or a
"lifetime" with EJBs, so there's no other natural place to close the
Client.
The other part of the story is the relationship between Client and the actual invoker,
org.jboss.remoting.transport.socket.MicroSocketClientInvoker in this case. Multiple
Clients connected to the same server will share an invoker, increasing its reference
count. So if multiple threads were calling on the same EJB at the same time, closing the
connection after an invocation wouldn't close the MicroSocketClientInvoker (and its
cache of connections) if another thread was in the middle of another invocation.
The gap in my explanation is the lack of evidence of multithreading in the example. I
don't know what method1() is doing. But if there were some simultaneous processing
going on, then enabling leasing would add an extra invocation to the process of connecting
and disconnecting, thereby changing the timing of things, which might then lead to keeping
a MicroSocketClientInvoker alive long enough to be reused.
Unfortunately, there's no declarative way to turn on leasing. Just an oversight, I
guess, and it's never come up so I never thought about fixing it. I could, though.
However, there's a more direct approach. I put a feature in Remoting 2.4 which makes
it possible to configure Client.disconnect() to delay the destruction of the client
invoker by putting it in a TimerTask: JBREM-877 "New Socket Connection is being
Created for Every Client Request to the Server". On the EJB3 forum thread
http://www.jboss.com/index.html?module=bb&op=viewtopic&t=130264, I asked the EJB3
guys to create a JBPAPP issue if they wanted the same feature in Remoting 2.2, but it
never happened so I never did it.
Since it's certainly a Remoting feature, and not really an EJB3 bug, I guess it's
a judgment call whether to go ahead and make the change in Remoting 2.2. But Jay, if you
create the JIRA issue(s), I'll be happy to do it and attach a preview
jboss-remoting.jar.
--------------------------------------------------------------
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: