[JBoss JIRA] Created: (JBREM-614) Client.invoke() should check isConnected().
by Ron Sigal (JIRA)
Client.invoke() should check isConnected().
-------------------------------------------
Key: JBREM-614
URL: http://jira.jboss.com/jira/browse/JBREM-614
Project: JBoss Remoting
Issue Type: Task
Security Level: Public (Everyone can see)
Affects Versions: 2.2.0.Beta1 (Bluto)
Reporter: Ron Sigal
Assigned To: Ron Sigal
Priority: Minor
Fix For: 2.2.0.Beta1 (Bluto)
This changed due to a leasing bug that Clebert found within messaging. The problem was that the isConnected() calls on it's invoker to see if it is connected (assuming the invoker is not null). So is possible that another Client is using the same client invoker and that invoker is already connected. This would cause the new Client to not set up leasing (which it would need to do).
I guess the isConnected() call could be added back in, but would need to change the Client.isConnected() to use an member variable keeping track of state (connect or not connected) instead of calling on the invoker to see if it's connect.
Ron Sigal wrote:
> Hi Tom,
>
> I noticed something about Client.connect() and CallbackPoller.start(). In particular, CallbackPoller.start() calls Client.connect(), as it should. If leasing is configured, the Client will be registered with the LeasePinger. When the application calls Client.connect(), the Client will be re-registered with the LeasePinger. It doesn't cause an error, but it's a bit redundant. Looks like Client.connect() should start with
>
> if (isConnected())
> return;
>
> ??
>
> -Ron
--
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
17 years, 4 months
[JBoss JIRA] Created: (JBREM-622) InvokerLocator already exists for listener
by Galen Dunkleberger (JIRA)
InvokerLocator already exists for listener
------------------------------------------
Key: JBREM-622
URL: http://jira.jboss.com/jira/browse/JBREM-622
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Environment: JBoss 4.0.5.GA
JBoss Messaging 1.0.1.GA
Linux
BEA Jrockit R26.0.0-jdk1.5.0_04_x86_64
Reporter: Galen Dunkleberger
Assigned To: Tom Elrod
When trying to send many small messsages very quickly through JBoss messaging I was getting the following error
javax.jms.IllegalStateException: InvokerLocator already exists for listener id 1436420135. Remove t
his listener before adding again.
at org.jboss.jms.client.container.ExceptionInterceptor.invoke(ExceptionInterceptor.java:91)
at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6
840474864420126404.invokeNext()Ljava.lang.Object;(ClientConnectionFactoryDelegate$createConnectionDe
legate_N6840474864420126404.java:???)
at org.jboss.jms.client.container.ClientLogInterceptor.invoke(ClientLogInterceptor.java:107)
at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate$createConnectionDelegate_N6
840474864420126404.invokeNext()Ljava.lang.Object;(ClientConnectionFactoryDelegate$createConnectionDe
legate_N6840474864420126404.java:???)
at org.jboss.jms.client.delegate.ClientConnectionFactoryDelegate.createConnectionDelegate(Lj
ava.lang.String;Ljava.lang.String;)Lorg.jboss.jms.delegate.ConnectionDelegate;(ClientConnectionFacto
ryDelegate.java:???)
at org.jboss.jms.client.JBossConnectionFactory.createConnectionInternal(JBossConnectionFacto
ry.java:202)
at org.jboss.jms.client.JBossConnectionFactory.createQueueConnection(JBossConnectionFactory.
java:108)
at org.jboss.jms.client.JBossConnectionFactory.createQueueConnection(JBossConnectionFactory.
java:103)
--
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
17 years, 4 months
[JBoss JIRA] Created: (JBREM-586) socket client invoker connection pooling not bounded
by Tom Elrod (JIRA)
socket client invoker connection pooling not bounded
----------------------------------------------------
Key: JBREM-586
URL: http://jira.jboss.com/jira/browse/JBREM-586
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: transport
Affects Versions: 2.0.0.GA (Boon)
Reporter: Tom Elrod
Assigned To: Tom Elrod
Fix For: 2.0.0.GA (Boon)
Due to code change for JBREM-576, the socket client invoker's bounded connection pooling was broken and the pool became unbounded (due to reducing the scope of the pool being sychronized within MicroSocketClientInvoker.getConnection(). The fix for JBREM-576 needs to remain (so do not get dealock on disconnect of one client invoker while another is still in use). However, will also need to synchronize the increase/decrease of number of pooled connections in use.
--
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
17 years, 4 months
[JBoss JIRA] Created: (JBREM-597) Allow access to underlying stream in marshaller with socket transport
by Tim Fox (JIRA)
Allow access to underlying stream in marshaller with socket transport
---------------------------------------------------------------------
Key: JBREM-597
URL: http://jira.jboss.com/jira/browse/JBREM-597
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Reporter: Tim Fox
Assigned To: Tom Elrod
Fix For: 2.2.0.Beta1 (Bluto)
Currently the ClientSocketWrapper::createOuputStream always returns an ObjectOutputStream wrapping the underlying socket ouput stream.
This ends up getting passed into the marshaller.
With messaging we'd like to use the underlying socket output stream directly in the marshaller - i.e. we don't want to have to write through an object output stream.
This is because the object output stream adds some overhead in terms of the amount of stuff written to the underlying stream..
A similar reasoning applies to InputStream too.
Any chance of changing the socket transport to pass in the underlying socket stream, not an object output/input stream?
--
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
17 years, 4 months