January 2011 - jboss-remoting-issues

[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, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1182) Update testsuite to run under Hudson

by Richard Achmatowicz (JIRA)

Update testsuite to run under Hudson -------------------------------------- Key: JBREM-1182 URL: https://jira.jboss.org/jira/browse/JBREM-1182 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: general Affects Versions: 2.2.3.SP1 Reporter: Richard Achmatowicz Fix For: 2.2.3.SP2 Update the JBoss Remoting testsuite to run under Hudson. Some current problems include: (i) on Linux, JRunit based tests are failing due to members not finding each other (ii) on Linux, under JDK6, JRunit based tests are not able to create a JGroups stack (iii) JRunit system properties specified by the user on the command line are not being passed the the JUnit targets correctly, and so have no effect on the tests -- 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

2
26
0 / 0

[JBoss JIRA] Created: (JBREM-1271) Release 2.5.3.SP2

by Ron Sigal (JIRA)

Release 2.5.3.SP2 ----------------- Key: JBREM-1271 URL: https://issues.jboss.org/browse/JBREM-1271 Project: JBoss Remoting Issue Type: Release Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-1261) Prevent DOS attack on BisocketServerInvoker$SecondaryServerSocketThread

by Ron Sigal (JIRA)

Prevent DOS attack on BisocketServerInvoker$SecondaryServerSocketThread ----------------------------------------------------------------------- Key: JBREM-1261 URL: https://issues.jboss.org/browse/JBREM-1261 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.3.SP3, 2.5.3.SP1 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.3.SP2, 2.2.3.SP4 >From the original bug report: Exploiting and thus confirming this vulnerability is extremely simple: Simply connect to the bisocket control connection (ie. "telnet <jboss-host> <control-connection-port>") without sending any data on the connection. As long as this connection is open, no clients can connect to the bisocket control port because the connections are not accepted at server side. The cause of this vulnerability is found in method org.jboss.remoting.transport.bisocket.BisocketServerInvoker$SecondaryServerSocketThread.run(), which contains the accept-loop for the bisocket control connection. After having accepted a connection, the accept loop thread reads from the newly created connection expecting the client to send an action code and a listener id. If the client sends nothing, the accept loop thread will block in the read call, causing no other connections to be accepted. To fix, the accept loop thread should not do the read on the new connection. Instead it should start a new thread that does the read -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 9 months

1
5
0 / 0

[JBoss JIRA] Created: (JBREM-1263) ClientSocketWrapper.checkConnection() should check returned value

by Ron Sigal (JIRA)

ClientSocketWrapper.checkConnection() should check returned value ----------------------------------------------------------------- Key: JBREM-1263 URL: https://issues.jboss.org/browse/JBREM-1263 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.3.SP3, 2.5.3.SP1 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.3.SP2, 2.2.3.SP4 The old and new connection checking tests used by org.jboss.remoting.transport.socket.ClientSocketWrapper and ServerSocketWrapper interact in a negative way. In the old test, turned on when socket.check_connection is set to true, ClientSocketWrapper sends a 1, ServerSocketWrapper returns it, and if ClientSocketWrapper is able to read a byte, the test passes. But in the new test, ServerSocketWrapper writes two 254 bytes as it is closing. If ClientSocketWrapper is doing the old test and it reads one of these bytes, it thinks the test has passed. It should check for the actual value of the returned byte. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
4
0 / 0

[JBoss JIRA] Created: (JBREM-1245) Consider javax.net.ssl.SSLException("Connection has been shutdown")

by Ron Sigal (JIRA)

Consider javax.net.ssl.SSLException("Connection has been shutdown") ------------------------------------------------------------------- Key: JBREM-1245 URL: https://jira.jboss.org/browse/JBREM-1245 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.3.SP1, 2.2.3.SP3 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.3.SP3, 2.2.3.SP4 An SSLSocket whose remote counterpart has closed will throw javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLException: java.net.SocketException: Software caused connection abort: socket write error This should be considered a retriable exception, but the RETRIABLE_ERROR_MESSAGE regular expression in org.jboss.remoting.transport.MicroSocketClientInvoker doesn't match it. -- 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, 10 months

1
4
0 / 0

[JBoss JIRA] Created: (JBREM-1246) Can't authenticate using TransporterClient

by Sebastian Dietrich (JIRA)

Can't authenticate using TransporterClient ------------------------------------------ Key: JBREM-1246 URL: https://jira.jboss.org/browse/JBREM-1246 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.2.SP3 (Flounder) Reporter: Sebastian Dietrich I'd like to introduce basic authentication in my project which uses TransporterClient to connect to the server. According to the documentation (http://docs.jboss.org/jbossremoting/2.5.3.SP1/html_single/#d0e2251 5.4.11. HTTP(S) Client Invoker - proxy and basic authentication) this is not supported with TransporterClient, but only via response = client.invoke(payload, metadata); TransporterClient uses response = remotingClient.invoke(request); (see TransporterClient.class Line 321) Unfortunately I can neither subclass TransporterClient (since its constructors are private) nor decorate it (since its invoke method I'd like to change uses private attributes & methods). ==> Please provide a way to use basic authentication in TransporterClient This could be done easily via a further constructor/factory method which accepts metadata. -- 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, 10 months

2
4
0 / 0

[JBoss JIRA] Created: (JBREM-1262) Consider java.io.IOException("Software caused connection abort: socket write error") retriable

by Ron Sigal (JIRA)

Consider java.io.IOException("Software caused connection abort: socket write error") retriable ---------------------------------------------------------------------------------------------- Key: JBREM-1262 URL: https://issues.jboss.org/browse/JBREM-1262 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.3.SP3, 2.5.3.SP1 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.3.SP2, 2.2.3.SP4 Should be considered retriable. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-1238) Need invocation timeouts in synchronized blocks in MicroRemoteClientInvoker that create and terminate leases

by Ron Sigal (JIRA)

Need invocation timeouts in synchronized blocks in MicroRemoteClientInvoker that create and terminate leases ------------------------------------------------------------------------------------------------------------- Key: JBREM-1238 URL: https://jira.jboss.org/browse/JBREM-1238 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.3.SP1 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2.SP2 (Flounder) org.jboss.remoting.MicroRemoteClientInvoker.establishLease() and MicroRemoteClientInvoker.terminateLease() do network invocations inside synchronized blocks, and, if the invocations get hung up, then it becomes impossible to create new connections with leasing enabled. Setting the 'timeout" parameter appropriately would work around the problem, but some users, notably JBossMessaging, set "timeout" to 0. A speclal case timeout parameter should be used, along with the per invocation timeout facility, to prevent MicroRemoteClientInvoker from getting stuck in establishLease() or terminateLease(). -- 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, 10 months

1
6
0 / 0

[JBoss JIRA] Created: (JBREM-1266) Create Remoting users guide

by Ron Sigal (JIRA)

Create Remoting users guide --------------------------- Key: JBREM-1266 URL: https://issues.jboss.org/browse/JBREM-1266 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Components: docs Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.3.SP2 The Remoting Guide, while rich in information, is considered by some somewhat dense and hard to read. It would be helpful to have a simpler introduction, geared more to Application Server users. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 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 January 2011