November 2013 - jboss-remoting-issues

[JBoss JIRA] (JBREM-1318) Zero is a valid value so SoLinger

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-1318?page=com.atlassian.jira.plugin... ] Ron Sigal closed JBREM-1318. ---------------------------- > Zero is a valid value so SoLinger > --------------------------------- > > Key: JBREM-1318 > URL: https://issues.jboss.org/browse/JBREM-1318 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: general > Affects Versions: 2.5.4.SP4 > Reporter: Doug Grove > Priority: Minor > Fix For: 2.5.4.SP5 > > > MicroSocketClientInvoker checks to see that SoLinger is greater than zero: > if (soLingerSet && > soLingerDuration > 0) s.setSoLinger(soLinger, soLingerDuration); > Zero is a valid value for SoLinger. > The code should be changed to greater than or equal to zero. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

[JBoss JIRA] (JBREM-1318) Zero is a valid value so SoLinger

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-1318?page=com.atlassian.jira.plugin... ] Ron Sigal resolved JBREM-1318. ------------------------------ Resolution: Done Fix committed. > Zero is a valid value so SoLinger > --------------------------------- > > Key: JBREM-1318 > URL: https://issues.jboss.org/browse/JBREM-1318 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: general > Affects Versions: 2.5.4.SP4 > Reporter: Doug Grove > Priority: Minor > Fix For: 2.5.4.SP5 > > > MicroSocketClientInvoker checks to see that SoLinger is greater than zero: > if (soLingerSet && > soLingerDuration > 0) s.setSoLinger(soLinger, soLingerDuration); > Zero is a valid value for SoLinger. > The code should be changed to greater than or equal to zero. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

[JBoss JIRA] (JBREM-1316) MicroSocketClientInvoker can could lead to a remote ejb being sent data twice to the same server

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-1316?page=com.atlassian.jira.plugin... ] Ron Sigal closed JBREM-1316. ---------------------------- > MicroSocketClientInvoker can could lead to a remote ejb being sent data twice to the same server > ------------------------------------------------------------------------------------------------ > > Key: JBREM-1316 > URL: https://issues.jboss.org/browse/JBREM-1316 > Project: JBoss Remoting > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: 2.5.4.SP4 > Reporter: Shaun Appleton > Assignee: Ron Sigal > Fix For: 2.5.4.SP5 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

[JBoss JIRA] (JBREM-1316) MicroSocketClientInvoker can could lead to a remote ejb being sent data twice to the same server

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-1316?page=com.atlassian.jira.plugin... ] Ron Sigal resolved JBREM-1316. ------------------------------ Resolution: Done > MicroSocketClientInvoker can could lead to a remote ejb being sent data twice to the same server > ------------------------------------------------------------------------------------------------ > > Key: JBREM-1316 > URL: https://issues.jboss.org/browse/JBREM-1316 > Project: JBoss Remoting > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: 2.5.4.SP4 > Reporter: Shaun Appleton > Assignee: Ron Sigal > Fix For: 2.5.4.SP5 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

[JBoss JIRA] (JBREM-1316) MicroSocketClientInvoker can could lead to a remote ejb being sent data twice to the same server

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-1316?page=com.atlassian.jira.plugin... ] Ron Sigal updated JBREM-1316: ----------------------------- Issue Type: Enhancement (was: Bug) > MicroSocketClientInvoker can could lead to a remote ejb being sent data twice to the same server > ------------------------------------------------------------------------------------------------ > > Key: JBREM-1316 > URL: https://issues.jboss.org/browse/JBREM-1316 > Project: JBoss Remoting > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Affects Versions: 2.5.4.SP4 > Reporter: Shaun Appleton > Assignee: Ron Sigal > Fix For: 2.5.4.SP5 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

[JBoss JIRA] (JBREM-1322) Cannot set up serverBindAddress for secondarySocket in bisocket transport

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-1322?page=com.atlassian.jira.plugin... ] Ron Sigal updated JBREM-1322: ----------------------------- Fix Version/s: (was: 2.5.4.SP5) > Cannot set up serverBindAddress for secondarySocket in bisocket transport > ------------------------------------------------------------------------- > > Key: JBREM-1322 > URL: https://issues.jboss.org/browse/JBREM-1322 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: transport > Affects Versions: 2.5.4.SP4 > Reporter: Igor Kostromin > Assignee: Ron Sigal > > Using IS_CALLBACK_SERVER = true. > In BisocketClientInvoker.java:355 > InvokerLocator getSecondaryLocator() throws Throwable { > ... > 355: Object o = invoke(r); > ... > } > It retrieves host from server, but if you want to use original client invoker host, you cannot do this (it is necessary if server is behind translating firewall). If you want to do this, you have to patch this code manually to > Object o = invoke(r); > // DZ: patch to use original server address for creating secondary connection > // instead of address retrieved from server (because server will return jboss bind address > // that can be local address, inaccessible from client) > InvokerLocator patchedLocator = new InvokerLocator( (( InvokerLocator ) o).getOriginalURI().replace( > (( InvokerLocator ) o).getHost(), this.getLocator().getHost() ) > ); > log.debug("secondary locator: " + o); > log.debug("patched secondary locator: " + patchedLocator); > return patchedLocator; > and rebuild jboss-remoting project. > For ports there are settings SECONDARY_BIND_PORT, SECONDARY_CONNECT_PORT allowing to set up them as you want. For address there is no one to do this. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

[JBoss JIRA] (JBREM-1316) MicroSocketClientInvoker can could lead to a remote ejb being sent data twice to the same server

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-1316?page=com.atlassian.jira.plugin... ] Ron Sigal reopened JBREM-1316: ------------------------------ > MicroSocketClientInvoker can could lead to a remote ejb being sent data twice to the same server > ------------------------------------------------------------------------------------------------ > > Key: JBREM-1316 > URL: https://issues.jboss.org/browse/JBREM-1316 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 2.5.4.SP4 > Reporter: Shaun Appleton > Assignee: Ron Sigal > Fix For: 2.5.4.SP5 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

[JBoss JIRA] (JBREM-1325) Release 2.5.4.SP5

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-1325?page=com.atlassian.jira.plugin... ] Ron Sigal updated JBREM-1325: ----------------------------- Fix Version/s: 2.5.4.SP5 > Release 2.5.4.SP5 > ----------------- > > Key: JBREM-1325 > URL: https://issues.jboss.org/browse/JBREM-1325 > Project: JBoss Remoting > Issue Type: Release > Security Level: Public(Everyone can see) > Reporter: Ron Sigal > Assignee: Ron Sigal > Fix For: 2.5.4.SP5 > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

[JBoss JIRA] (JBREM-1318) Zero is a valid value so SoLinger

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-1318?page=com.atlassian.jira.plugin... ] Ron Sigal updated JBREM-1318: ----------------------------- Fix Version/s: 2.5.4.SP5 Affects Version/s: 2.5.4.SP4 (was: 2.5.4.SP3) > Zero is a valid value so SoLinger > --------------------------------- > > Key: JBREM-1318 > URL: https://issues.jboss.org/browse/JBREM-1318 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: general > Affects Versions: 2.5.4.SP4 > Reporter: Doug Grove > Priority: Minor > Fix For: 2.5.4.SP5 > > > MicroSocketClientInvoker checks to see that SoLinger is greater than zero: > if (soLingerSet && > soLingerDuration > 0) s.setSoLinger(soLinger, soLingerDuration); > Zero is a valid value for SoLinger. > The code should be changed to greater than or equal to zero. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

[JBoss JIRA] (JBREM-1307) TimedOutputStream OutputTimerTask call to close on SSL OutputStream blocks

by Ron Sigal (JIRA)

[ https://issues.jboss.org/browse/JBREM-1307?page=com.atlassian.jira.plugin... ] Ron Sigal closed JBREM-1307. ---------------------------- > TimedOutputStream OutputTimerTask call to close on SSL OutputStream blocks > -------------------------------------------------------------------------- > > Key: JBREM-1307 > URL: https://issues.jboss.org/browse/JBREM-1307 > Project: JBoss Remoting > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: transport > Affects Versions: 2.2.3.SP2, 2.5.4.SP4 > Environment: JBoss EAP 4.3.0 CP08 and CP10 > Reporter: Doug Grove > Assignee: Ron Sigal > Labels: messaging > Fix For: 2.5.4.SP5 > > Attachments: jboss-remoting-src.jar, jboss-remoting.jar > > > In order to provide a mechanism for timing out a network/socket write operation, the org.jboss.remoting.transport.socket.TimedOutputStream class starts a timer. If the duration of the write operation exceeds the timer interval, then the timer will call close() on the output stream. This interrupts the output stream write() operation and causes the write operation to throw an IOException. > When the output stream uses secure sockets (SSL), however, the call to close() on the output stream can block indefinitely. The threads associated with the write() and close() operation will only clear when the tcp keepalive timeout mechanism in the operation system is invoked. > This appears to be related to a know bug in the java runtime: http://bugs.sun.com/view_bug.do?bug_id=6358629 > Specifically, in a thread dump you will see: > "Timer-9" daemon prio=10 tid=0x5016c400 nid=0x2638 waiting on condition [0x4cbad000] > java.lang.Thread.State: WAITING (parking) > at sun.misc.Unsafe.park(Native Method) > - parking to wait for <0x585021a0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync) > at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778) > at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114) > at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186) > at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262) > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:720) > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.sendAlert(SSLSocketImpl.java:1720) > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.warning(SSLSocketImpl.java:1564) > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.closeInternal(SSLSocketImpl.java:1362) > - locked <0x58502030> (a com.sun.net.ssl.internal.ssl.SSLSocketImpl) > at com.sun.net.ssl.internal.ssl.SSLSocketImpl.close(SSLSocketImpl.java:1301) > at com.sun.net.ssl.internal.ssl.AppOutputStream.close(AppOutputStream.java:80) > at org.jboss.remoting.transport.socket.TimedOutputStream.close(TimedOutputStream.java:57) > at org.jboss.remoting.transport.socket.TimedOutputStream$OutputTimerTask.run(TimedOutputStream.java:145) > at java.util.TimerThread.mainLoop(Timer.java:512) > at java.util.TimerThread.run(Timer.java:462) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues November 2013