November 2009 - jboss-remoting-issues

[JBoss JIRA] Created: (JBREM-988) Watch org.jboss.test.remoting.stream.StreamingTestCase for failures

by Ron Sigal (JIRA)

Watch org.jboss.test.remoting.stream.StreamingTestCase for failures ------------------------------------------------------------------- Key: JBREM-988 URL: http://jira.jboss.com/jira/browse/JBREM-988 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.1.Beta org.jboss.test.remoting.stream.StreamingTestCase has failed a few times in hudson. Should watch for more failures. -- 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

12 years, 5 months

2
3
0 / 0

[JBoss JIRA] Created: (JBREM-1163) Evaluate FindBugs reports

by Ron Sigal (JIRA)

Evaluate FindBugs reports ------------------------- Key: JBREM-1163 URL: https://jira.jboss.org/jira/browse/JBREM-1163 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2.SP1 (Flounder) http://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-6.0.x-findbug... and http://hudson.jboss.org/hudson/view/JBoss%20AS/job/JBoss-AS-5.x-findbugs/... -- 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

12 years, 5 months

1
11
0 / 0

[JBoss JIRA] Created: (JBREM-1169) Bisocket connection won't be closed if pulling out the ethernet cable between client and server. The failure detection code won't close the failure connection, as a result, the subsequent requests will hang after connection account exceeds the threshold

by mingjun jiang (JIRA)

Bisocket connection won't be closed if pulling out the ethernet cable between client and server. The failure detection code won't close the failure connection, as a result, the subsequent requests will hang after connection account exceeds the threshold ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBREM-1169 URL: https://jira.jboss.org/jira/browse/JBREM-1169 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: detection Affects Versions: 2.2.3.SP1 Environment: OS: Windows Server 2003. JBoss App Server 4.2.3.GA, JBoss Messaging 1.4.5 GA, JBoss Remoting 2.2.3 SP1 Reporter: mingjun jiang We are using JBoss App Server 4.2.3.GA, JBoss Messaging 1.4.5 GA and JBoss Remoting 2.2.3 SP1. In our application, there are a lot of Message listeners running on the client side, these message listeners will receive messages from queue/topic deployed in JBoss Messaging Configuration: We created our own JMS Connection factory which uses the default remoting connector. As you know, the default remoting connector is configured to use the bisocket transport. We didn't change the default value of the remoting connector During we run our application, we open the JBoss web console to monitor the value of currentClientPoolSize under "Jboss.remoting" JMX MBean. How to reproduce this issue: 1. Run 5 message listeners in the client side to receive messages from JBoss Messaging, then we observe the value of currentClientPoolSize is 10 2. After processing several messages, we manually pull out the ethernet cable. The value of currentClientPoolSize is still 10. 3. We run another 5 message listeners in client side, then the value of currentClientPoolSize will become 20 4. After we do the same operations above several times, the value of currentClientPoolSize will increase continuously. Once the value of currentClientPoolSize is equal to the MaxPoolSize, then the subsequent incoming client requests will hang, and we will encounter the following exception in server side 2009-10-20 18:08:09,655 ERROR [org.jboss.remoting.transport.socket.ServerThread] Worker thread initialization failure java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) at java.io.BufferedInputStream.read(BufferedInputStream.java:235) at java.io.FilterInputStream.read(FilterInputStream.java:66) at org.jboss.remoting.transport.socket.ServerThread.readVersion(ServerThread.java:859) at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:545) at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:406) at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:173) Conclusion: JBoss Messaging won't close the failure connections if they are caused by manually pulling out ethernet cable. As a result, the value of currentClientPoolSize will increase continuously and finally the new client requests will hang Note: If we killed the process of message listener in client side, then the value of currentClientPoolSize will decrease to 0 immediately, it seems that the server could detect the failure connection and perform the corresponding resource releasing. -- 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, 1 month

4
5
0 / 0

[JBoss JIRA] Created: (JBREM-1054) Annotation to automatically return new transporters types

by David Lloyd (JIRA)

Annotation to automatically return new transporters types --------------------------------------------------------- Key: JBREM-1054 URL: https://jira.jboss.org/jira/browse/JBREM-1054 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: r3 api Reporter: David Lloyd Priority: Optional Fix For: 3.1.0.Beta1 It would be cool if a transporter interface (or an implementing class of that interface) could have methods which sport an annotation that indicates that the return value of that method, if it is an interface, should be automatically wrapped into a transporter (if invoked via a transporter). This way, complex remote object structures can be easily created and used. Also handy would be a simple way of notating such methods when the interface and implementation are already existent. -- 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, 1 month

3
14
0 / 0

[JBoss JIRA] Created: (JBREM-1074) Config Guide should clarify the HTTP transport vs Servlet

by Andrew Oliver (JIRA)

Config Guide should clarify the HTTP transport vs Servlet --------------------------------------------------------- Key: JBREM-1074 URL: https://jira.jboss.org/jira/browse/JBREM-1074 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Andrew Oliver http://docs.jboss.org/jbossas/unified_invoker/UnifiedInvoker_guide.html describes changing to use HTTP as a transport. Meaning JBoss remoting launches its own HTTP server. This is probably a pretty esoteric configuration and most people are probably looking for this: http://www.jboss.org/community/docs/DOC-9632 instead. The guide should clarify WHAT that is and where to find what you're probably REALLY looking for. (you probably don't want to run on some weird port if you're using HTTP and most installs probably run WITH tomcat which means you need to run through TC or have a totally separate IP which is pretty hard to do in most environments) -- 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, 11 months

2
1
0 / 0

[JBoss JIRA] Created: (JBREM-1144) Extend connection identity to server side

by Ron Sigal (JIRA)

Extend connection identity to server side ----------------------------------------- Key: JBREM-1144 URL: https://jira.jboss.org/jira/browse/JBREM-1144 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.2.3, 2.5.1 (Flounder) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 2.5.2 (Flounder), 2.2.3.SP1 In JBREM-1128 "Introduce connection identity concept" and JBREM-1132 "CLONE [JBREM-1128] - Introduce connection identity concept", the server was equipped to recognized when a client had been replaced by another client. In other words, clients were assigned an identity. This concept should be extended to the server side, so that ConnectionValidator can detect that a server has been replaced. -- 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, 11 months

1
9
0 / 0

[JBoss JIRA] Created: (JBREM-981) CLONE [JBREM-980] - ServerInvokerServlet should retrieve ServletServerInvoker based on updated InvokerLocator

by Ron Sigal (JIRA)

CLONE [JBREM-980] - ServerInvokerServlet should retrieve ServletServerInvoker based on updated InvokerLocator ------------------------------------------------------------------------------------------------------------- Key: JBREM-981 URL: http://jira.jboss.com/jira/browse/JBREM-981 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.4.0.CR2 Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.GA >From Galder: Consider <servlet> <servlet-name>Ejb3ServerInvokerServlet</servlet-name> <description>The ServerInvokerServlet receives requests via HTTP protocol from within a web container and passes it onto the ServletServerInvoker for processing. </description> <servlet-class>org.jboss.remoting.transport.servlet.web.ServerInvokerServlet</servlet-class> <init-param> <param-name>locatorUrl</param-name> <param-value>servlet://${jboss.bind.address}:8080/unified-invoker/Ejb3ServerInvokerServlet</param-value> <description>The servlet server invoker</description> </init-param> <load-on-startup>1</load-on-startup> </servlet> Now, let's say you bind to 0.0.0.0. You'll get an exception like this: 13:39:26,856 ERROR [ContainerBase] Servlet /unified-invoker threw load() exception javax.servlet.ServletException: Can not find servlet server invoker with same locator as specified (servlet://0.0.0.0:8080/unified-invoker/Ejb3ServerInvokerServlet) at org.jboss.remoting.transport.servlet.web.ServerInvokerServlet.getInvokerFromInvokerUrl(ServerInvokerServlet.java:198) at org.jboss.remoting.transport.servlet.web.ServerInvokerServlet.init(ServerInvokerServlet.java:66) The problem arises from the fact that Remoting is trying to compare: servlet://0.0.0.0:8080/unified-invoker/Ejb3ServerInvokerServlet with servlet://localhost.localdomain:8080/unified-invoker/Ejb3ServerInvokerServlet So either, ServerInvokerServlet should call ServerInvoker.validateLocator() with locatorUrl, take the return of that and compare that with the list of locators. Or validateLocator() is modified to have the real original host passed to the InvokerLocator constructor, rather than the transformed or newHost. -- 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

14 years, 6 months

2
4
0 / 0

[JBoss JIRA] Created: (JBREM-1080) Add support for future tasks to RequestContext

by David Lloyd (JIRA)

Add support for future tasks to RequestContext ---------------------------------------------- Key: JBREM-1080 URL: https://jira.jboss.org/jira/browse/JBREM-1080 Project: JBoss Remoting Issue Type: Feature Request Security Level: Public (Everyone can see) Components: r3 api Reporter: David Lloyd Fix For: 3.1.0.Beta1 Right now, the RequestContext keeps track of tasks and threads being used to process a request. If all tasks complete and no reply is sent, it makes sure that the requesting party receives an exception indicating that a reply was never sent. However, if the request listener may wish interact with another framework which uses some asynchronous callback mechanism, from which a reply is to be sent. In this case, all tasks terminate but the reply might still be sent. To solve this problem, RequestContext needs a method which can wrap a Runnable (or similar) with some type of cancellable Runnable or task object, which can then be called by other frameworks as needed later on. The RequestContext wouldn't consider a request "dead" until all tasks completed and all such wrapped Runnables have also been completed or GC'd. -- 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

14 years, 9 months

2
5
0 / 0

[JBoss JIRA] Created: (JBREM-1167) Add simple socket based protocol to Remoting 3 samples

by Ron Sigal (JIRA)

Add simple socket based protocol to Remoting 3 samples ------------------------------------------------------ Key: JBREM-1167 URL: https://jira.jboss.org/jira/browse/JBREM-1167 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assignee: Ron Sigal Fix For: 3.1.0.Beta1 A simple protocol might help to clarify the concepts of Remoting 3. -- 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

14 years, 9 months

2
4
0 / 0

[JBoss JIRA] Created: (JBREM-929) Secure remote classloading

by David Lloyd (JIRA)

Secure remote classloading -------------------------- Key: JBREM-929 URL: http://jira.jboss.com/jira/browse/JBREM-929 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.0.0-M3 Remote classloading should be allowed only if either (a) a security manager is installed (and thus the security manager would create the policy) or (b) a specific option is enabled (which would be disabled by default) to allow it. Also, the remote classloader needs to be able to work with the standard security manager policy - which is to say, that classes loaded from a remote service need to have a unique codeBase URL so that administrators can grant permission to remote classes based on the service from whence they came. -- 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

14 years, 9 months

1
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

jboss-remoting-issues November 2009