June 2008 - jboss-remoting-issues

[JBoss JIRA] Created: (JBREM-991) Investigate MulticastDetector message flood

by Ron Sigal (JIRA)

Investigate MulticastDetector message flood ------------------------------------------- Key: JBREM-991 URL: http://jira.jboss.com/jira/browse/JBREM-991 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.2.2.SP8 A use has reported that org.jboss.remoting.detection.multicast.MulticastDetector is flooding the network with messages. The problem might lie MulticastDetector.listen(): else { // for now, assume anything *not* of type Detection // is a prompt to send out detection msg heartbeat(); } -- 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, 8 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-999) Make sure all fixes on 2.2 branch are ported to 2.x branch.

by Ron Sigal (JIRA)

Make sure all fixes on 2.2 branch are ported to 2.x branch. ----------------------------------------------------------- Key: JBREM-999 URL: http://jira.jboss.com/jira/browse/JBREM-999 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.SP1 -- 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, 8 months

1
1
0 / 0

[JBoss JIRA] Created: (JBREM-963) Work out a mechanism to handle protocol message ordering issues across multiple channels

by David Lloyd (JIRA)

Work out a mechanism to handle protocol message ordering issues across multiple channels ---------------------------------------------------------------------------------------- Key: JBREM-963 URL: http://jira.jboss.com/jira/browse/JBREM-963 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.0.0-M3 When dealing with a protocol using multiple channels (HTTP for example, and possibly a future multi-channel JRPP variant), sending two messages on two different channels can cause ordering issues if the second message sent arrives first. For example, sending a context open on channel A, and a request on channel B, may cause the request to be received before the context open message, resulting in the request being rejected with a "no such context" error. Another example is that stream messages must be handled sequentially. There are several possible solutions, including but not limited to: * for any message B that must come after A, always send A and B on the same channel (problem: HTTP channels are transient, so this won't work for HTTP) (problem: this could load up one channel while leaving other channels empty, even if load-balancing is used) * don't send B until after A is acknowledged (problem: acknowledging A might not be possible within the underlying protocol, like if A is sent in an HTTP reply, requiring a separate ACK message, which can lead to performance problems) * if a message comes in seemingly unsolicited (like a request on a nonexistant context) or out of sequence (like in a stream), queue the message for some fixed amount of time to see if the context open message arrives (problem: could be a source of DoS on the server; also this is a duplication of what protocols like TCP already do, which means that all the same problems must be in effect re-solved) Starting a forum thread to discuss the topic. -- 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, 8 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-990) CLONE [JBREM-960] - Remoting configured with Servlet invoker can return misleading Exceptions when Servlet path is incorrect

by Ron Sigal (JIRA)

CLONE [JBREM-960] - Remoting configured with Servlet invoker can return misleading Exceptions when Servlet path is incorrect ---------------------------------------------------------------------------------------------------------------------------- Key: JBREM-990 URL: http://jira.jboss.com/jira/browse/JBREM-990 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Components: transport Affects Versions: 2.4.0.GA (Pinto), 2.2.2.SP8, 2.4.1.Beta Reporter: Galder Zamarreno Assigned To: Ron Sigal Fix For: 2.2.2.SP8 I've been struggling to set up a ServletInvoker in Remoting to be able to use the unified invoker to talk to EJB2 beans in AS/EAP 4.x. I had the Connector set up like this: <mbean code="org.jboss.remoting.transport.Connector" name="jboss.remoting:service=connector,transport=servlet" display-name="Servlet transport Connector"> <attribute name="Configuration"> <config> <invoker transport="servlet"> <attribute name="dataType" isParam="true">invocation</attribute> <attribute name="marshaller" isParam="true">org.jboss.invocation.unified.marshall.InvocationMarshaller</attribute> <attribute name="unmarshaller" isParam="true">org.jboss.invocation.unified.marshall.InvocationUnMarshaller</attribute> <attribute name="serverBindAddress">${jboss.bind.address}</attribute> <attribute name="serverBindPort">8080</attribute> <attribute name="path">unified-http-invoker/ServerInvokerServlet</attribute> </invoker> <handlers> <handler subsystem="invoker">jboss:service=invoker,type=unified-http</handler> </handlers> </config> </attribute> </mbean> But the path attribute was incorrect. Remoting was coming back with something like this: org.jboss.remoting.CannotConnectException: Can not connect http client invoker. at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:333) at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:135) at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122) at org.jboss.remoting.Client.invoke(Client.java:1634) at org.jboss.remoting.Client.invoke(Client.java:548) at org.jboss.invocation.unified.interfaces.UnifiedInvokerProxy.invoke(UnifiedInvokerProxy.java:183) at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365) at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197) at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61) at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70) at org.jboss.proxy.ejb.HomeInterceptor.invoke(HomeInterceptor.java:184) at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100) at $Proxy0.create(Unknown Source) at com.acme.ejb2.slsb.TimerEnquirerHttpTest.test000(TimerEnquirerHttpTest.java:34) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:164) at junit.framework.TestCase.runBare(TestCase.java:130) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:120) at junit.framework.TestSuite.runTest(TestSuite.java:230) at junit.framework.TestSuite.run(TestSuite.java:225) at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196) Caused by: java.io.StreamCorruptedException: invalid stream header at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:764) at java.io.ObjectInputStream.<init>(ObjectInputStream.java:277) at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.<init>(ObjectInputStreamWithClassLoader.java:95) at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.createInput(JavaSerializationManager.java:54) at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.getMarshallingStream(SerializableUnMarshaller.java:72) at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:119) at org.jboss.invocation.unified.marshall.InvocationUnMarshaller.read(InvocationUnMarshaller.java:59) at org.jboss.remoting.transport.http.HTTPClientInvoker.readResponse(HTTPClientInvoker.java:471) at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:305) ... 31 more Now, to get this Exception is very misleading. It generally means that either you have different client and server side Remoting versions, or you're using different serialization methods on either side. Once I started to dig into what Remoting was doing, I spotted HTTPClientInvoker does the following in useHttpURLConnection() method: if (sendingData) { //POST or PUT conn.setDoOutput(true); conn.setDoInput(true); conn.setRequestMethod(type); OutputStream stream = conn.getOutputStream(); if (marshaller instanceof VersionedMarshaller) ((VersionedMarshaller) marshaller).write(invocation, stream, Version.getDefaultVersion()); else marshaller.write(invocation, stream); responseCode = conn.getResponseCode(); InputStream is = (responseCode < 400) ? conn.getInputStream() : conn.getErrorStream(); Map headers = conn.getHeaderFields(); if (metadata == null) { metadata = new HashMap(); } // sometimes I get headers with "null" keys (I don't know who's fault is it), so I need // to clean the header map, unless I want to get an NPE thrown by metadata.putAll() if (headers != null) { for(Iterator i = headers.entrySet().iterator(); i.hasNext(); ) { Map.Entry e = (Map.Entry)i.next(); if (e.getKey() != null) { metadata.put(e.getKey(), e.getValue()); } } } metadata.put(HTTPMetadataConstants.RESPONSE_CODE_MESSAGE, conn.getResponseMessage()); metadata.put(HTTPMetadataConstants.RESPONSE_CODE, new Integer(responseCode)); result = readResponse(metadata, headers, unmarshaller, is); } The Exception reported is coming from readResponse() but before that if the Servlet was not available, like in my case, conn.getResponseCode() was returning 404. Remoting code should check what the response code was, whether this is an invalid code, i.e. does not exist...etc, and throw an Exception if invalid, like in this case, giving the caller much better clue of what is going on. Thoughts? -- 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, 9 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-961) Context closing handshake is broken

by David Lloyd (JIRA)

Context closing handshake is broken ----------------------------------- Key: JBREM-961 URL: http://jira.jboss.com/jira/browse/JBREM-961 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.0.0-M3 Guess I just half-finished it. It needs to be rethought/fixed. See ContextClient.handlerClosing(boolean). -- 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, 9 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-1005) Prevent build up of cancelled TimerTasks in bisocket transport

by Ron Sigal (JIRA)

Prevent build up of cancelled TimerTasks in bisocket transport -------------------------------------------------------------- Key: JBREM-1005 URL: http://jira.jboss.com/jira/browse/JBREM-1005 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.2.2.SP8, 2.4.0.GA (Pinto) Reporter: Ron Sigal Assigned To: Ron Sigal Fix For: 2.4.0.SP1, 2.2.2.SP9 The behavior of java.util.Timer and java.util.TimerThread is such that a cancelled java.util.TimerTask is removed from the Timer's queue the next time it is executed after being cancelled. JBossMessaging has effectively disabled the bisocket control connection ping mechanism by setting the parameter "pingFrequency" to 214748364, which means that the org.jboss.remoting.transport.bisocket.BisocketServerInvoker.ControlMonitorTimerTask gets created but essentially "never" runs. So when a JBM connection closes, it also shuts down the Remoting bisocket connection, which causes the ControlMonitorTimerTask to get cancelled, but it remains in the Timer queue "forever". -- 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, 9 months

2
6
0 / 0

[JBoss JIRA] Created: (JBREM-941) SRP SASL integrity/confidentiality protection is failing

by David Lloyd (JIRA)

SRP SASL integrity/confidentiality protection is failing -------------------------------------------------------- Key: JBREM-941 URL: http://jira.jboss.com/jira/browse/JBREM-941 Project: JBoss Remoting Issue Type: Bug Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.0.0-M3 See JrppConnection.java (getSaslProperties) - enable the commented-out line and watch SRP blow up. -- 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, 9 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-1007) Change all logging to use XNIO Logger class

by David Lloyd (JIRA)

Change all logging to use XNIO Logger class ------------------------------------------- Key: JBREM-1007 URL: http://jira.jboss.com/jira/browse/JBREM-1007 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.0.0-M3 Once conversion is complete, the Logger classes and the corresponding log build modules should be removed from the project. -- 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, 9 months

1
2
0 / 0

[JBoss JIRA] Created: (JBREM-993) Change stream handler API to use XNIO handlers

by David Lloyd (JIRA)

Change stream handler API to use XNIO handlers ---------------------------------------------- Key: JBREM-993 URL: http://jira.jboss.com/jira/browse/JBREM-993 Project: JBoss Remoting Issue Type: Task Security Level: Public (Everyone can see) Reporter: David Lloyd Fix For: 3.0.0-M3 The stream handler API should be changed to use XNIO IoHandlers instead of the existing StreamHandlers. -- 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, 9 months

1
3
0 / 0

[JBoss JIRA] Created: (JBREM-948) Release 2.2.0.SP8

by Ron Sigal (JIRA)

Release 2.2.0.SP8 ----------------- Key: JBREM-948 URL: http://jira.jboss.com/jira/browse/JBREM-948 Project: JBoss Remoting Issue Type: Release Security Level: Public (Everyone can see) Reporter: Ron Sigal -- 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, 10 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 June 2008