[JBoss JIRA] Created: (JBREM-1009) Streaming should work with packet-based channels as well as stream-based channels
by David Lloyd (JIRA)
Streaming should work with packet-based channels as well as stream-based channels
---------------------------------------------------------------------------------
Key: JBREM-1009
URL: http://jira.jboss.com/jira/browse/JBREM-1009
Project: JBoss Remoting
Issue Type: Task
Security Level: Public (Everyone can see)
Components: r3 api
Reporter: David Lloyd
Assigned To: David Lloyd
Fix For: 3.0.0-M3
OutputStreams and Writers are trivially implemented using streams - writes to the remote object are simply propagated across to channel. Other types of streams are more difficult to implement this way. InputStream for example has two types of messages - a data chunk and an exception chunk. Because of this, some basic framing is necessary; with only support for streams, this framing must take place within the stream handler which is a pain to implement.
So, a stream serializer should be able to register itself as a byte stream handler (using a StreamChannel) or a message stream handler (using a MessageChannel).
--
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, 7 months
[JBoss JIRA] Created: (JBREM-1000) CLONE [JBREM-962] - Remote classloading does not work with Isolated EARs
by Ron Sigal (JIRA)
CLONE [JBREM-962] - Remote classloading does not work with Isolated EARs
------------------------------------------------------------------------
Key: JBREM-1000
URL: http://jira.jboss.com/jira/browse/JBREM-1000
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 2.2.2.SP4
Environment: EAP4.3
Reporter: Magesh Kumar B
Assigned To: Ron Sigal
Fix For: 2.2.2.SP8
When user has enabled isolation in a ear file containing an EJB3 jar file, the implementation classes are not serialized and a ClassNotFoundException is thrown. I have attached a sample called HelloEJB3.zip that contains all files needed for deploying this test case. Using EAP4.3 do "ant deploy" and then do "ant test".
When the jboss-app.xml is removed the application client works fine. This fails in the isolated mode with the below exception:
Caused by: java.lang.ClassNotFoundException: org.jboss.ejb3.user.UserImpl
at org.jboss.remoting.serialization.ClassLoaderUtility.loadClass(ClassLoaderUtility.java:82)
at org.jboss.remoting.loading.RemotingClassLoader.loadClass(RemotingClassLoader.java:76)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at org.jboss.remoting.loading.ObjectInputStreamWithClassLoader.resolveClass(ObjectInputStreamWithClassLoader.java:174)
at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
at java.io.ObjectInputStream.readClassDesc(Unknown Source)
at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)
at org.jboss.aop.joinpoint.InvocationResponse.readExternal(InvocationResponse.java:122)
at java.io.ObjectInputStream.readExternalData(Unknown Source)
at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.defaultReadFields(Unknown Source)
at java.io.ObjectInputStream.readSerialData(Unknown Source)
at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
at java.io.ObjectInputStream.readObject0(Unknown Source)
at java.io.ObjectInputStream.readObject(Unknown Source)
at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObjectVersion2_2(JavaSerializationManager.java:239)
at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.receiveObject(JavaSerializationManager.java:133)
at org.jboss.remoting.marshal.serializable.SerializableUnMarshaller.read(SerializableUnMarshaller.java:120)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedRead(MicroSocketClientInvoker.java:919)
at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:613)
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.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:62)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.aspects.security.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:53)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:101)
at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:107)
--
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
[JBoss JIRA] Created: (JBREM-1012) CLONE [JBREM-1010] - Add feature to declaratively turn on leasing for 2.4.0
by Ron Sigal (JIRA)
CLONE [JBREM-1010] - Add feature to declaratively turn on leasing for 2.4.0
---------------------------------------------------------------------------
Key: JBREM-1012
URL: https://jira.jboss.org/jira/browse/JBREM-1012
Project: JBoss Remoting
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: general
Affects Versions: 2.2.2.SP7
Reporter: Ron Sigal
Assignee: Ron Sigal
Fix For: 2.2.2.SP9
We have a request to declaratively turn on leasing. Currently you can only do it via debugging.
Here's the conversation from Ron so far. It says more than I could.
--------------------------------------------------------------
The problem lies in org.jboss.aspects.remoting.InvokeRemoteInterceptor, which (1) opens an org.jboss.remoting.Client, (2) makes the invocation, and (3) closes the Remoting client. I guess that's because there's no notion of a "session" or a "lifetime" with EJBs, so there's no other natural place to close the Client.
The other part of the story is the relationship between Client and the actual invoker, org.jboss.remoting.transport.socket.MicroSocketClientInvoker in this case. Multiple Clients connected to the same server will share an invoker, increasing its reference count. So if multiple threads were calling on the same EJB at the same time, closing the connection after an invocation wouldn't close the MicroSocketClientInvoker (and its cache of connections) if another thread was in the middle of another invocation.
The gap in my explanation is the lack of evidence of multithreading in the example. I don't know what method1() is doing. But if there were some simultaneous processing going on, then enabling leasing would add an extra invocation to the process of connecting and disconnecting, thereby changing the timing of things, which might then lead to keeping a MicroSocketClientInvoker alive long enough to be reused.
Unfortunately, there's no declarative way to turn on leasing. Just an oversight, I guess, and it's never come up so I never thought about fixing it. I could, though.
However, there's a more direct approach. I put a feature in Remoting 2.4 which makes it possible to configure Client.disconnect() to delay the destruction of the client invoker by putting it in a TimerTask: JBREM-877 "New Socket Connection is being Created for Every Client Request to the Server". On the EJB3 forum thread http://www.jboss.com/index.html?module=bb&op=viewtopic&t=130264, I asked the EJB3 guys to create a JBPAPP issue if they wanted the same feature in Remoting 2.2, but it never happened so I never did it.
Since it's certainly a Remoting feature, and not really an EJB3 bug, I guess it's a judgment call whether to go ahead and make the change in Remoting 2.2. But Jay, if you create the JIRA issue(s), I'll be happy to do it and attach a preview jboss-remoting.jar.
--------------------------------------------------------------
--
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, 8 months
[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
[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