March 2009 - jboss-remoting-issues

[JBoss JIRA] Created: (JBREM-1082) Allow ConnectionValidator to access InvokerLocator parameters

by Ron Sigal (JIRA)

Allow ConnectionValidator to access InvokerLocator parameters ------------------------------------------------------------- Key: JBREM-1082 URL: https://jira.jboss.org/jira/browse/JBREM-1082 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.2.SP12, 2.5.0.SP3 (Flounder) When org.jboss.remoting.Client.addConnectionListener() creates an org.jboss.remoting.ConnectionValidator, it passes in a reference to itself and the ConnectionValidator accesses the Client's configuration map. However, the Client's configuration map doesn't include (without some action on the part of the calling application) the InvokerLocator parameters. It follows that parameters configured on the server side (e.g., in a *-service.xml or *-beans.xml file in the context of the Application Server) don't get passed to the ConnectionValidator. -- 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

15 years, 7 months

1
5
0 / 0

[JBoss JIRA] Created: (JBREM-1084) Allow CallbackPoller to access Client and InvokerLocator parameters

by Ron Sigal (JIRA)

Allow CallbackPoller to access Client and InvokerLocator parameters ------------------------------------------------------------------- Key: JBREM-1084 URL: https://jira.jboss.org/jira/browse/JBREM-1084 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.2.SP12, 2.5.0.SP2 (Flounder) When org.jboss.remoting.Client.addListener() creates an org.jboss.remoting.callbackCallbackPoller, it passes in a reference to itself and a metadata map. Currently, the CallbackPoller accesses parameters only in the metadata map, which means that the Client's configuration map and InvokerLocator parameters (which might be configured declaratively on the server side) are not used. -- 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

15 years, 7 months

1
7
0 / 0

[JBoss JIRA] Created: (JBREM-1104) Identity.get() should create a more meaningful RuntimeException message

by Ron Sigal (JIRA)

Identity.get() should create a more meaningful RuntimeException message ----------------------------------------------------------------------- Key: JBREM-1104 URL: https://jira.jboss.org/jira/browse/JBREM-1104 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11 Reporter: Ron Sigal Assignee: Ron Sigal Priority: Minor Fix For: 2.2.2.SP12, 2.5.0.SP3 (Flounder) When org.jboss.remoting.ident.Identity.get() fails in the call to InetAddress.getLocalHost(), it throws a RuntimeException like: java.lang.RuntimeException: Exception creating identity: myhost: myhost This problem has been associated, at least in some cases, with problems in the /etc/hosts file. The problem is that the message gives no clue that the underlying problem is a host name problem. -- 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

15 years, 7 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-1088) MicroSocketClientInvoker(InvokerLocator locator, Map configuration) ctor - not propagating exceptions (only message is wrapped)

by Developer JBoss (JIRA)

MicroSocketClientInvoker(InvokerLocator locator, Map configuration) ctor - not propagating exceptions (only message is wrapped) ------------------------------------------------------------------------------------------------------------------------------- Key: JBREM-1088 URL: https://jira.jboss.org/jira/browse/JBREM-1088 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.4.0.SP1 (Pinto) Environment: Windows Reporter: Developer JBoss Priority: Minor During org.jboss.remoting.Client.connect() call, if server "hostname" DNS mapping is not available at client, org.jboss.remoting.transport.socket.MicroSocketClientInvoker.setup() getAddressByName throws : java.net.UnknownHostException: <hostname> However, calling method: org.jboss.remoting.transport.socket.MicroSocketClientInvoker(InvokerLocator locator, Map configuration) catches this exception and wraps it as new RuntimeException(ex.getMessage()). This looses rootcause exception stack. It is difficult for caller client code to understand the cause of the exception (UnknownHostException). -- 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

15 years, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (JBREM-1108) Warn against making ConnectionValidator.validatorPingPeriod shorter than ConnectionValidator.validatorPingTimeout

by Ron Sigal (JIRA)

Warn against making ConnectionValidator.validatorPingPeriod shorter than ConnectionValidator.validatorPingTimeout ----------------------------------------------------------------------------------------------------------------- Key: JBREM-1108 URL: https://jira.jboss.org/jira/browse/JBREM-1108 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11 Reporter: Ron Sigal Assignee: Ron Sigal Priority: Minor Fix For: 2.2.2.SP12, 2.5.0.SP3 (Flounder) If the parameter org.jboss.remoting.ConnectionValidator.VALIDATOR_PING_PERIOD (actual value "validatorPingPeriod") is set to a value less than the value of ConnectionValidator.VALIDATOR_PING_TIMEOUT (actual value "validatorPingTimeout"), the connection validation process can fail. ConnectionValidator.run() sets the variable isValid to false, sends a PING, and starts an instance of WaitOnConnectionCheckTimerTask. If the PING invocation succeeds, run() sets isValid to true, and WaitOnConnectionCheckTimerTask quietly returns. However, if the response to the PING invocation is delayed, and the ping timeout value is long enough, it is possible for ConnectionValidator.run() to set isValid to false and start a second WaitOnConnectionCheckTimerTask while the first WaitOnConnectionCheckTimerTask is still waiting. Then, if the response to the first PING arrives, the first WaitOnConnectionCheckTimerTask will see that isValid is false and it will declare a connection failure. There's no reason to start a new WaitOnConnectionCheckTimerTask while an existing WaitOnConnectionCheckTimerTask is still running. The point is that validatorPingPeriod should be longer than validatorPingTimeout, so that, if a PING fails, there is time to notify any listeners of the failure and to shut down the ConnectionValidator before sending another PING. -- 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

15 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1083) Each Client creates a new invokerDestructionTimer

by Ron Sigal (JIRA)

Each Client creates a new invokerDestructionTimer ------------------------------------------------- Key: JBREM-1083 URL: https://jira.jboss.org/jira/browse/JBREM-1083 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11 Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.2.2.SP12, 2.5.0.SP3 (Flounder) When the parameter "invokerDestructionDelay" is greater than 0, org.jboss.remoting.Client.disconnect() creates a new TImer. There should be one static Timer. -- 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

15 years, 7 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-1103) Correct javadoc for Client.invokeOneway()

by Ron Sigal (JIRA)

Correct javadoc for Client.invokeOneway() ----------------------------------------- Key: JBREM-1103 URL: https://jira.jboss.org/jira/browse/JBREM-1103 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11 Reporter: Ron Sigal Assignee: Ron Sigal Priority: Minor Fix For: 2.2.2.SP12, 2.5.0.SP3 (Flounder) The javadoc discussion on org.jboss.remoting.Client.invokeOneway() is no longer correct when the value of clientSide is false. In particular, it is incorrect for the socket transport, since org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport() returns immediately after sending an invocation when it detects a oneway invocation. This behavior has been true since the implementation of JBREM-548 "Support one way invocations with no response". -- 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

15 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1076) SocketServerInvoker.processInvocation() should return if running == false

by Ron Sigal (JIRA)

SocketServerInvoker.processInvocation() should return if running == false ------------------------------------------------------------------------- Key: JBREM-1076 URL: https://jira.jboss.org/jira/browse/JBREM-1076 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.0.SP3 (Flounder) The while(worker == null && running) loop can end with worker == null, in which case processRequest() should return instead of proceeding. -- 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

15 years, 7 months

1
5
0 / 0

[JBoss JIRA] Created: (JBREM-1099) Make MulticastDetector detection message send buffer size configurable

by Galder Zamarreno (JIRA)

Make MulticastDetector detection message send buffer size configurable ---------------------------------------------------------------------- Key: JBREM-1099 URL: https://jira.jboss.org/jira/browse/JBREM-1099 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP12 Reporter: Galder Zamarreno The multicast detector does not work properly in environments where plenty Remoting invokers are used, such as the case of EAP 4.3 where you have invokers for EJB3, EJB2, JMS...etc. What happens is that org.jboss.remoting.detection.AbstractDetector.createDetection(), it creates a detection message based on the server invokers registered locally. As there's one more invoker in EAP 4.3.x, the message size exceeds the 4000 limit. This leads to errors like: 2009-02-12 15:19:26,846 DEBUG [org.jboss.remoting.detection.multicast.MulticastDetector] heartbeat failed java.io.IOException: Message too long at java.net.PlainDatagramSocketImpl.send(Native Method) at java.net.DatagramSocket.send(DatagramSocket.java:612) at org.jboss.remoting.detection.multicast.MulticastDetector.heartbeat(MulticastDetector.java:226) at org.jboss.remoting.detection.AbstractDetector$Heartbeat.run(AbstractDetector.java:716) at java.util.TimerThread.mainLoop(Timer.java:512) at java.util.TimerThread.run(Timer.java:462) The size of the buffer where the Detection message is sent comes from: private final class Listener extends Thread { boolean running = true; public Listener(String name) { super(name); } public void run() { byte[] buf = new byte[4000]; DatagramPacket p = new DatagramPacket(buf, 0, buf.length); //p.setAddress(addr); //p.setPort(port); while(running) { listen(p, buf); } } } The size of the buffer needs to be made configurable. -- 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

15 years, 7 months

2
8
0 / 0

[JBoss JIRA] Created: (JBREM-1109) Eliminate race in MicroRemoteClientInvoker.getDataType()

by Ron Sigal (JIRA)

Eliminate race in MicroRemoteClientInvoker.getDataType() -------------------------------------------------------- Key: JBREM-1109 URL: https://jira.jboss.org/jira/browse/JBREM-1109 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.5.0.SP2 (Flounder) , 2.2.2.SP11 Reporter: Ron Sigal Fix For: 2.2.2.SP12, 2.5.0.SP3 (Flounder) In org.jboss.remoting.MicroRemoteClientInvoker.getDataType(): private String getDataType() { if (dataType == null) { dataType = getDataType(getLocator()); if (dataType == null) { dataType = getDefaultDataType(); } } return dataType; } the line dataType = getDataType(getLocator()); would temporarily set dataType to null if, as is usually the case, the InvokerLocator has no datatype parameter. A second thread might see dataType != null and then return null. A solution is to use a local variable while checking InvokerLocator for a datatype value. -- 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

15 years, 7 months

1
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues March 2009