April 2009 - jboss-remoting-issues

[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

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

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-1112) Potential race between ConnectionValidator and ConnectionListener upon connection failure

by Ron Sigal (JIRA)

Potential race between ConnectionValidator and ConnectionListener upon connection failure ----------------------------------------------------------------------------------------- Key: JBREM-1112 URL: https://jira.jboss.org/jira/browse/JBREM-1112 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP11, 2.5.0.SP2 (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.0.SP3 (Flounder), 2.2.2.SP12 When org.jboss.remoting.ConnectionValidator.WaitOnConnectionCheckTimerTask detects a connection failure, it informs all registered ConnectionListeners and then, if the parameter "stopLeaseOnFailure" is set to "true", it calls invoker.terminateLease(null, client.getDisconnectTimeout()); The idea is that a ConnectionListener might want to set the Client's disconnectTimeout value to limit the time spent on network i/o while shutting down a faulty connection. In particular, if disconectTimeout is set to 0, then Remoting will skip any i/o while shutting down a connection. The problem is that, in ConnectionValidator.notifyListeners(), each registered ConnectionListener is called in a separate thread, to avoid getting hung up in a particular ConnectionListener. As a result, it is possible for ConnectionValidator to call Client.getDisconnectTImeout() before any ConnectionListener gets a chance to call Client.setDisconnectTimeout(). In particular, this race has been discovered in the context of a JBossMessaging application. -- 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

2
7
0 / 0

[JBoss JIRA] Created: (JBREM-1114) Update servlet transport to support JBossMessaging

by Ron Sigal (JIRA)

Update servlet transport to support JBossMessaging -------------------------------------------------- Key: JBREM-1114 URL: https://jira.jboss.org/jira/browse/JBREM-1114 Project: JBoss Remoting Issue Type: Feature Request 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) In working on JBMESSAGING-1131 "Add configuration for Remoting servlet transport" and JBPAPP-1274 "Fix JBoss Messaging and JBoss Remoting so that servlet transport can be used", a couple of issues arose. 1. If the body of the request is null, a new InvocationRequest will be created. 2. javax.servlet.http.HttpServletRequest.getParameterMap() returns a map with keys of type String and values of type String[]. Currently, ServletServerInvoker just extracts the String[] values and passes them along in a metadata map. It is better, in the case of a String arrays of length one, to extract the value in the array. -- 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

1
2
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

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

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

1
4
0 / 0

[JBoss JIRA] Closed: (JBREM-139) need automated test for servlet server invoker

by Ron Sigal (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-139?page=com.atlassian.jira.plug... ] Ron Sigal closed JBREM-139. --------------------------- Resolution: Done > need automated test for servlet server invoker > ---------------------------------------------- > > Key: JBREM-139 > URL: https://jira.jboss.org/jira/browse/JBREM-139 > Project: JBoss Remoting > Issue Type: Task > Components: general > Affects Versions: 1.2.0 final, 2.5.0.SP2 (Flounder) , 2.2.2.SP11 > Reporter: Tom Elrod > Assignee: Ron Sigal > Priority: Minor > Fix For: 2.5.0.SP3 (Flounder), 2.2.2.SP12 > > > Tests for servlet invoker is manual since have to deploy servlet-invoker.war to jboss in order for it to work. Need to figure out if there > is an easy automated way to do this (since would currently require JBossAS, don't think realistic to run as unit test for JBossRemoting > test run). -- 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

1
0
0 / 0

[JBoss JIRA] Commented: (JBREM-139) need automated test for servlet server invoker

by Ron Sigal (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-139?page=com.atlassian.jira.plug... ] Ron Sigal commented on JBREM-139: --------------------------------- The changes have been applied to the 2.2 and 2.x branches. Note that on the 2.2 branch, build.xml assumes that the AS is from the 4.2 generation, and on the 2.x branch, build.xml assumes that the AS is from the 5.0 generation. > need automated test for servlet server invoker > ---------------------------------------------- > > Key: JBREM-139 > URL: https://jira.jboss.org/jira/browse/JBREM-139 > Project: JBoss Remoting > Issue Type: Task > Components: general > Affects Versions: 1.2.0 final, 2.5.0.SP2 (Flounder) , 2.2.2.SP11 > Reporter: Tom Elrod > Assignee: Ron Sigal > Priority: Minor > Fix For: 2.5.0.SP3 (Flounder), 2.2.2.SP12 > > > Tests for servlet invoker is manual since have to deploy servlet-invoker.war to jboss in order for it to work. Need to figure out if there > is an easy automated way to do this (since would currently require JBossAS, don't think realistic to run as unit test for JBossRemoting > test run). -- 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

1
0
0 / 0

[JBoss JIRA] Commented: (JBREM-139) need automated test for servlet server invoker

by Ron Sigal (JIRA)

[ https://jira.jboss.org/jira/browse/JBREM-139?page=com.atlassian.jira.plug... ] Ron Sigal commented on JBREM-139: --------------------------------- Other than assuming the existence of an Application Server, the tests are now automated. That is, an AS is configured and started, the tests are run, and the AS is restored to its original state and stopped. The tests are run by the "tests.functional.servlet" target in build.xml. One other necessary step is to set the values in the local.properties file in the main directory. > need automated test for servlet server invoker > ---------------------------------------------- > > Key: JBREM-139 > URL: https://jira.jboss.org/jira/browse/JBREM-139 > Project: JBoss Remoting > Issue Type: Task > Components: general > Affects Versions: 1.2.0 final, 2.5.0.SP2 (Flounder) , 2.2.2.SP11 > Reporter: Tom Elrod > Assignee: Ron Sigal > Priority: Minor > Fix For: 2.5.0.SP3 (Flounder), 2.2.2.SP12 > > > Tests for servlet invoker is manual since have to deploy servlet-invoker.war to jboss in order for it to work. Need to figure out if there > is an easy automated way to do this (since would currently require JBossAS, don't think realistic to run as unit test for JBossRemoting > test run). -- 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

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues April 2009