February 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBREM-606) patch to 1.4.4.GA to include fix for socket server thread leak

by Tom Elrod (JIRA)

patch to 1.4.4.GA to include fix for socket server thread leak -------------------------------------------------------------- Key: JBREM-606 URL: http://jira.jboss.com/jira/browse/JBREM-606 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 1.4.4.GA Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 1.4.5.GA Need to back port fix for JBREM-409. -- 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, 7 months

2
4
0 / 0

[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

18 years, 7 months

4
3
0 / 0

[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

18 years, 7 months

4
8
0 / 0

[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

18 years, 7 months

4
5
0 / 0

[JBoss JIRA] Created: (JBREM-582) remove System.out.println and printStackTrace calls

by Tom Elrod (JIRA)

remove System.out.println and printStackTrace calls --------------------------------------------------- Key: JBREM-582 URL: http://jira.jboss.com/jira/browse/JBREM-582 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: general Affects Versions: 2.0.0.CR1 (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.0.0.GA (Boon) Need to remove any calls to System.out.println or printStackTrace within core code (samples, tests, and main() methods ok) -- 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, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (JBREM-590) SSL client socket invoker does not use configuration map for SSLSocketBuilder

by Tom Elrod (JIRA)

SSL client socket invoker does not use configuration map for SSLSocketBuilder ----------------------------------------------------------------------------- Key: JBREM-590 URL: http://jira.jboss.com/jira/browse/JBREM-590 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: security Affects Versions: 2.0.0.CR1 (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.0.0.GA (Boon) When SSLSocketClientInvoker creates its socket factory (see SSLSocketClientInvoker.createSocketFactory(Map configuration)), it does not pass the configuration map to the SSLSocketBuilder. Therefore the SSLSocketBuilder is not able to create custom socket factory based on configuration. -- 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, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (JBREM-594) invoker not torn down upon connector startup error

by Tom Elrod (JIRA)

invoker not torn down upon connector startup error -------------------------------------------------- Key: JBREM-594 URL: http://jira.jboss.com/jira/browse/JBREM-594 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: general Affects Versions: 2.0.0.GA (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.2.0.Beta1 (Bluto) If get a jvm bind error when starting connector, if stop connector and then re-create a new connector and try to start it, will get an exception saying invoker for connector has already been created and are basically stuck. -- 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, 7 months

2
4
0 / 0

[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

18 years, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (JBREM-580) detection can not be used with ssl based transports

by Tom Elrod (JIRA)

detection can not be used with ssl based transports --------------------------------------------------- Key: JBREM-580 URL: http://jira.jboss.com/jira/browse/JBREM-580 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: detection Affects Versions: 2.0.0.CR1 (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Priority: Critical Fix For: 2.0.0.GA (Boon) As part of detection process, the detector will try to make a ping invocation on a server when it suspects the server to have gone down. It does this by using the the locator url provided in the detection message broadcasted. However, with ssl transport, just having invoker locator url is not enough. Also need the ssl info, which can not be included in the detection message. -- 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, 7 months

2
3
0 / 0

[JBoss JIRA] Created: (JBREM-575) local client invoker should convert itself to remote client invoker when being serialized

by Tom Elrod (JIRA)

local client invoker should convert itself to remote client invoker when being serialized ----------------------------------------------------------------------------------------- Key: JBREM-575 URL: http://jira.jboss.com/jira/browse/JBREM-575 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: general Affects Versions: 2.0.0.CR1 (Boon) Reporter: Tom Elrod Assigned To: Tom Elrod Fix For: 2.0.0.GA (Boon) Is possible, especially if using transporters, to send a remoting client over the wire to be used somewhere else transparently. However, this currently only works if the client invoker is a remote client invoker. If is a local client invoker, then obviously won't be able to make local reference to the server since would be in another process. Need to change behavior of local client invoker to during serialization/deserialization to convert itself to a remote client invoker so can be passed around transparently over the network. -- 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, 7 months

2
4
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 February 2007