May 2008 - jboss-remoting-issues - Jboss List Archives

[JBoss JIRA] Reopened: (JBREM-475) Eliminate ShutdownRequestThread in MultiplexingManager.

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-475?page=all ] Ron Sigal reopened JBREM-475: ----------------------------- > Eliminate ShutdownRequestThread in MultiplexingManager. > ------------------------------------------------------- > > Key: JBREM-475 > URL: http://jira.jboss.com/jira/browse/JBREM-475 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 2.4.0.Beta1 (Pinto) > Reporter: Ron Sigal > Assigned To: Ron Sigal > Priority: Minor > > When a MultiplexingManager is requesting permission from its remote counterpart to shut down, it periodically creates a ShutdownRequestThread to send a request permission message and wait for a response. It shoud be possible to handle the waiting on the pending action thread. -- 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

15 years, 11 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBREM-475) Eliminate ShutdownRequestThread in MultiplexingManager.

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-475?page=all ] Ron Sigal closed JBREM-475. --------------------------- Resolution: Won't Fix > Eliminate ShutdownRequestThread in MultiplexingManager. > ------------------------------------------------------- > > Key: JBREM-475 > URL: http://jira.jboss.com/jira/browse/JBREM-475 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 2.4.0.Beta1 (Pinto) > Reporter: Ron Sigal > Assigned To: Ron Sigal > Priority: Minor > > When a MultiplexingManager is requesting permission from its remote counterpart to shut down, it periodically creates a ShutdownRequestThread to send a request permission message and wait for a response. It shoud be possible to handle the waiting on the pending action thread. -- 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

15 years, 11 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBREM-554) Let virtual MultiplexServerInvokers share master MultiplexServerInvoker's thread pool.

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-554?page=all ] Ron Sigal reopened JBREM-554: ----------------------------- > Let virtual MultiplexServerInvokers share master MultiplexServerInvoker's thread pool. > -------------------------------------------------------------------------------------- > > Key: JBREM-554 > URL: http://jira.jboss.com/jira/browse/JBREM-554 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 2.2.0.Alpha3 (Bluto) > Reporter: Ron Sigal > Assigned To: Ron Sigal > > This is JBREM-402, broken out from JBREM-390. -- 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

15 years, 11 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBREM-554) Let virtual MultiplexServerInvokers share master MultiplexServerInvoker's thread pool.

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-554?page=all ] Ron Sigal closed JBREM-554. --------------------------- Resolution: Won't Fix > Let virtual MultiplexServerInvokers share master MultiplexServerInvoker's thread pool. > -------------------------------------------------------------------------------------- > > Key: JBREM-554 > URL: http://jira.jboss.com/jira/browse/JBREM-554 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 2.2.0.Alpha3 (Bluto) > Reporter: Ron Sigal > Assigned To: Ron Sigal > > This is JBREM-402, broken out from JBREM-390. -- 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

15 years, 11 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBREM-364) refactor client invoker config for common configurations

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-364?page=all ] Ron Sigal reopened JBREM-364: ----------------------------- > refactor client invoker config for common configurations > -------------------------------------------------------- > > Key: JBREM-364 > URL: http://jira.jboss.com/jira/browse/JBREM-364 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Components: general > Affects Versions: 1.4.0 final > Reporter: Tom Elrod > > Currently client invoker implementations all do their own configuration processing. Since many share the same configuration properties, need to standardize these and handle them in the RemoteClientInvoker instead of individual implementations (i.e. SocketClientInvoker, HTTPClientInvoker, etc.). Should follow same model that has been done for ServerInvoker. -- 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

15 years, 11 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBREM-729) Make multiplex server invoker more robust

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-729?page=all ] Ron Sigal closed JBREM-729. --------------------------- Resolution: Won't Fix > Make multiplex server invoker more robust > ----------------------------------------- > > Key: JBREM-729 > URL: http://jira.jboss.com/jira/browse/JBREM-729 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 2.4.0.Beta1 (Pinto) > Reporter: Ron Sigal > Assigned To: Ron Sigal > > Claudia Richter has reported some problems using Remoting JNDI detection with multiplex transport. If the JNDI heartbeat is looking for an old socket invoker at an address and port where a multiplex invoker currently runs, the multiplex invoker can get hung up trying to process in invocation intended for the socket invoker. It should be able to tolerate unexpected inputs. In particular, MultiplexServerInvoker should set a timeout on the MasterServerSocket so that it doesn't get hung up in accept(). -- 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

15 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-729) Make multiplex server invoker more robust

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-729?page=all ] Ron Sigal updated JBREM-729: ---------------------------- Fix Version/s: (was: 2.4.0.Beta1 (Pinto)) Removed fix version. > Make multiplex server invoker more robust > ----------------------------------------- > > Key: JBREM-729 > URL: http://jira.jboss.com/jira/browse/JBREM-729 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 2.4.0.Beta1 (Pinto) > Reporter: Ron Sigal > Assigned To: Ron Sigal > > Claudia Richter has reported some problems using Remoting JNDI detection with multiplex transport. If the JNDI heartbeat is looking for an old socket invoker at an address and port where a multiplex invoker currently runs, the multiplex invoker can get hung up trying to process in invocation intended for the socket invoker. It should be able to tolerate unexpected inputs. In particular, MultiplexServerInvoker should set a timeout on the MasterServerSocket so that it doesn't get hung up in accept(). -- 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

15 years, 11 months

1
0
0 / 0

[JBoss JIRA] Closed: (JBREM-729) Make multiplex server invoker more robust

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-729?page=all ] Ron Sigal closed JBREM-729. --------------------------- Resolution: Done > Make multiplex server invoker more robust > ----------------------------------------- > > Key: JBREM-729 > URL: http://jira.jboss.com/jira/browse/JBREM-729 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 2.4.0.Beta1 (Pinto) > Reporter: Ron Sigal > Assigned To: Ron Sigal > > Claudia Richter has reported some problems using Remoting JNDI detection with multiplex transport. If the JNDI heartbeat is looking for an old socket invoker at an address and port where a multiplex invoker currently runs, the multiplex invoker can get hung up trying to process in invocation intended for the socket invoker. It should be able to tolerate unexpected inputs. In particular, MultiplexServerInvoker should set a timeout on the MasterServerSocket so that it doesn't get hung up in accept(). -- 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

15 years, 11 months

1
0
0 / 0

[JBoss JIRA] Reopened: (JBREM-729) Make multiplex server invoker more robust

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-729?page=all ] Ron Sigal reopened JBREM-729: ----------------------------- > Make multiplex server invoker more robust > ----------------------------------------- > > Key: JBREM-729 > URL: http://jira.jboss.com/jira/browse/JBREM-729 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Affects Versions: 2.4.0.Beta1 (Pinto) > Reporter: Ron Sigal > Assigned To: Ron Sigal > > Claudia Richter has reported some problems using Remoting JNDI detection with multiplex transport. If the JNDI heartbeat is looking for an old socket invoker at an address and port where a multiplex invoker currently runs, the multiplex invoker can get hung up trying to process in invocation intended for the socket invoker. It should be able to tolerate unexpected inputs. In particular, MultiplexServerInvoker should set a timeout on the MasterServerSocket so that it doesn't get hung up in accept(). -- 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

15 years, 11 months

1
0
0 / 0

[JBoss JIRA] Updated: (JBREM-699) Extend the Marshaller/UnMarshaller interfaces by incorporating the PreferredStreamMarshaller/PreferredStreamUnMarshaller interfaces

by Ron Sigal (JIRA)

[ http://jira.jboss.com/jira/browse/JBREM-699?page=all ] Ron Sigal updated JBREM-699: ---------------------------- Fix Version/s: (was: 2.4.0.Beta1 (Pinto)) Removed fix version. > Extend the Marshaller/UnMarshaller interfaces by incorporating the PreferredStreamMarshaller/PreferredStreamUnMarshaller interfaces > ----------------------------------------------------------------------------------------------------------------------------------- > > Key: JBREM-699 > URL: http://jira.jboss.com/jira/browse/JBREM-699 > Project: JBoss Remoting > Issue Type: Task > Security Level: Public(Everyone can see) > Reporter: Ron Sigal > Assigned To: Ron Sigal > > It is reasonable for all marshallers/unmarshallers to construct the streams they which to use, but the org.jboss.remoting.marshal.PreferredStreamMarshaller and PreferredStreamUnMarshaller interfaces were introduced in response to JBREM-692 to avoid API changes in between major releases. Release 3.0 would be the right time to incorporate and eliminate PreferredStreamMarshaller and PreferredStreamUnMarshaller. -- 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

15 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues May 2008