October 2010 - jboss-remoting-issues

[JBoss JIRA] Created: (JBREM-1163) Evaluate FindBugs reports

by Ron Sigal (JIRA)

Evaluate FindBugs reports ------------------------- Key: JBREM-1163 URL: https://jira.jboss.org/jira/browse/JBREM-1163 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2.SP1 (Flounder) http://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-findbug... and http://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-5.x-findbugs/... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 4 months

1
11
0 / 0

[JBoss JIRA] Created: (JBREM-988) Watch org.jboss.test.remoting.stream.StreamingTestCase for failures

by Ron Sigal (JIRA)

Watch org.jboss.test.remoting.stream.StreamingTestCase for failures ------------------------------------------------------------------- Key: JBREM-988 URL: http://jira.jboss.com/jira/browse/JBREM-988 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.1.Beta org.jboss.test.remoting.stream.StreamingTestCase has failed a few times in hudson. Should watch for more failures. -- 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

12 years, 4 months

2
3
0 / 0

[JBoss JIRA] Created: (JBREM-1169) Bisocket connection won't be closed if pulling out the ethernet cable between client and server. The failure detection code won't close the failure connection, as a result, the subsequent requests will hang after connection account exceeds the threshold

by mingjun jiang (JIRA)

Bisocket connection won't be closed if pulling out the ethernet cable between client and server. The failure detection code won't close the failure connection, as a result, the subsequent requests will hang after connection account exceeds the threshold ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBREM-1169 URL: https://jira.jboss.org/jira/browse/JBREM-1169 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: detection Affects Versions: 2.2.3.SP1 Environment: OS: Windows Server 2003. JBoss App Server 4.2.3.GA, JBoss Messaging 1.4.5 GA, JBoss Remoting 2.2.3 SP1 Reporter: mingjun jiang We are using JBoss App Server 4.2.3.GA, JBoss Messaging 1.4.5 GA and JBoss Remoting 2.2.3 SP1. In our application, there are a lot of Message listeners running on the client side, these message listeners will receive messages from queue/topic deployed in JBoss Messaging Configuration: We created our own JMS Connection factory which uses the default remoting connector. As you know, the default remoting connector is configured to use the bisocket transport. We didn't change the default value of the remoting connector During we run our application, we open the JBoss web console to monitor the value of currentClientPoolSize under "Jboss.remoting" JMX MBean. How to reproduce this issue: 1. Run 5 message listeners in the client side to receive messages from JBoss Messaging, then we observe the value of currentClientPoolSize is 10 2. After processing several messages, we manually pull out the ethernet cable. The value of currentClientPoolSize is still 10. 3. We run another 5 message listeners in client side, then the value of currentClientPoolSize will become 20 4. After we do the same operations above several times, the value of currentClientPoolSize will increase continuously. Once the value of currentClientPoolSize is equal to the MaxPoolSize, then the subsequent incoming client requests will hang, and we will encounter the following exception in server side 2009-10-20 18:08:09,655 ERROR [org.jboss.remoting.transport.socket.ServerThread] Worker thread initialization failure java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read(BufferedInputStream.java:235) at java.io.FilterInputStream.read(FilterInputStream.java:66) at org.jboss.remoting.transport.socket.ServerThread.readVersion(ServerThread.java:859) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:545) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:406) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:173) Conclusion: JBoss Messaging won't close the failure connections if they are caused by manually pulling out ethernet cable. As a result, the value of currentClientPoolSize will increase continuously and finally the new client requests will hang Note: If we killed the process of message listener in client side, then the value of currentClientPoolSize will decrease to 0 immediately, it seems that the server could detect the failure connection and perform the corresponding resource releasing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

4
5
0 / 0

[JBoss JIRA] Created: (JBREM-1054) Annotation to automatically return new transporters types

by David Lloyd (JIRA)

Annotation to automatically return new transporters types --------------------------------------------------------- Key: JBREM-1054 URL: https://jira.jboss.org/jira/browse/JBREM-1054 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: r3 api Reporter: David Lloyd Priority: Optional Fix For: 3.1.0.Beta1 It would be cool if a transporter interface (or an implementing class of that interface) could have methods which sport an annotation that indicates that the return value of that method, if it is an interface, should be automatically wrapped into a transporter (if invoked via a transporter). This way, complex remote object structures can be easily created and used. Also handy would be a simple way of notating such methods when the interface and implementation are already existent. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

3
14
0 / 0

[JBoss JIRA] Created: (JBREM-1254) Should support SASL ANONYMOUS mechanism

by Ron Sigal (JIRA)

Should support SASL ANONYMOUS mechanism --------------------------------------- Key: JBREM-1254 URL: https://jira.jboss.org/browse/JBREM-1254 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: security Affects Versions: 3.1.0.Beta2 Reporter: Ron Sigal Fix For: 3.1.0.Beta3 Currently, creating a connection to a peer requires authenticating the user through an available SASL mechanism. The SASL provider from Sun supports, for example, CRAM-MD5 and DIGEST-MD5, which require the use of user names and passwords. The ANONYMOUS mechanism would allow the creation of connections without authentication. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
1
0 / 0

[JBoss JIRA] Created: (JBREM-1192) Detect and utilize confidentiality/integrity protection layer negotiated via SASL

by David Lloyd (JIRA)

Detect and utilize confidentiality/integrity protection layer negotiated via SASL --------------------------------------------------------------------------------- Key: JBREM-1192 URL: https://jira.jboss.org/jira/browse/JBREM-1192 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: r3 core: remote Reporter: David Lloyd Fix For: 3.1.0.CR1 When SASL negotiation is completed, an option should be consulted to determine whether the SASL wrap mechanism should be used. The option should default to true if SSL was not negotiation, and false if it was; however the user should be able to override this setting. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-1193) Make principal information available to Remoting clients and servers

by David Lloyd (JIRA)

Make principal information available to Remoting clients and servers -------------------------------------------------------------------- Key: JBREM-1193 URL: https://jira.jboss.org/jira/browse/JBREM-1193 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: r3 core Reporter: David Lloyd Fix For: 3.1.0.Beta2 Design an API which may be used to get the principals in force from any SSL or SASL session. On the server side, listeners should be executed with an authenticated Subject if possible; though it might be better to simply make the principal information available and let the application layer perform security duties. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-1190) Change logging to conform to standard

by David Lloyd (JIRA)

Change logging to conform to standard ------------------------------------- Key: JBREM-1190 URL: https://jira.jboss.org/jira/browse/JBREM-1190 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.1.0.GA Change logging to adhere to JBossAS standard. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-1197) JASPI/JBossSX Server Authentication Provider

by David Lloyd (JIRA)

JASPI/JBossSX Server Authentication Provider -------------------------------------------- Key: JBREM-1197 URL: https://jira.jboss.org/jira/browse/JBREM-1197 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: r3 core Reporter: David Lloyd Fix For: 3.1.0.CR1 Provide an implementation of ServerAuthenticationProvider which integrates with JBossAS using one of the available APIs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1194) SSL simulation mode

by David Lloyd (JIRA)

SSL simulation mode ------------------- Key: JBREM-1194 URL: https://jira.jboss.org/jira/browse/JBREM-1194 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: r3 core: remote Reporter: David Lloyd Fix For: 3.1.0.CR1 A session should be configured to be able to act as if SSL were in force even if it isn't. This allows SSL to be offloaded to appliances. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues October 2010