Size limit on Remote EJB Calls

[justinhayes]

I have a SLSB that I invoke remotely and there appears to be a limit on how large the argument I can pass in a method call is. I'm using EAP 6.0.1 (jboss as 7.1.2 Final) and deploying my ejb as part of an ear. My client runs in a separete JVM and uses jboss-ejb-client 1.0.5.Final.

EJB3 interface:

public String ingest(NATLog[] values);

EJB3 impl:

@Override

          public String ingest(NATLog[] values) {

    //do something

   }

NATLog is a simple POJO with 11 String member variables. The total size of one of these fully populated is about 300 bytes.

When I use an array up to about 150 NATLog objects, the EJB call works fine. When I pass in an array of 200 NATLog objects, the EJB call just hangs. And when I finally kill the client via ctrl-c, I get the following error message in the server's console.

15:49:56,740 ERROR [org.jboss.as.ejb3] (Remoting "cirries-3001" task-1) JBAS014248: Exception on channel Channel ID 699cd0be (inbound) of Remoting connection 58f368dc to null from message org.jboss.remoting3.remote.InboundMessage$3@41c61c91: org.jboss.remoting3.MessageCancelledException

        at org.xnio.streams.BufferPipeInputStream.checkFailure(BufferPipeInputStream.java:280) [xnio-api-3.0.7.GA-redhat-1.jar:3.0.7.GA-redhat-1]

        at org.xnio.streams.BufferPipeInputStream.read(BufferPipeInputStream.java:125) [xnio-api-3.0.7.GA-redhat-1.jar:3.0.7.GA-redhat-1]

        at org.jboss.remoting3.remote.InboundMessage$3.read(InboundMessage.java:122) [jboss-remoting-3.2.14.GA-redhat-1.jar:3.2.14.GA-redhat-1]

        at java.io.DataInputStream.readByte(DataInputStream.java:265) [rt.jar:1.6.0_24]

        at org.jboss.as.ejb3.remote.protocol.versionone.AbstractMessageHandler$2.read(AbstractMessageHandler.java:249)

        at java.io.InputStream.read(InputStream.java:170) [rt.jar:1.6.0_24]

        at java.io.FilterInputStream.read(FilterInputStream.java:133) [rt.jar:1.6.0_24]

        at org.jboss.marshalling.SimpleDataInput.read(SimpleDataInput.java:92) [jboss-marshalling-1.3.15.GA-redhat-1.jar:1.3.15.GA-redhat-1]

        at org.jboss.marshalling.UTFUtils.readUTFBytes(UTFUtils.java:155) [jboss-marshalling-1.3.15.GA-redhat-1.jar:1.3.15.GA-redhat-1]

        at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:281)

        at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)

        at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1678)

        at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1594)

        at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1236)

        at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:272)

        at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)

        at org.jboss.marshalling.river.RiverUnmarshaller.doReadCollectionObject(RiverUnmarshaller.java:180)

        at org.jboss.marshalling.river.RiverUnmarshaller.doReadObjectArray(RiverUnmarshaller.java:1503)

        at org.jboss.marshalling.river.RiverUnmarshaller.doReadArray(RiverUnmarshaller.java:1542)

        at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:326)

        at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)

        at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:37) [jboss-marshalling-1.3.15.GA-redhat-1.jar:1.3.15.GA-redhat-1]

        at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:162)

        at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:180)

        at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:435) [jboss-remoting-3.2.14.GA-redhat-1.jar:3.2.14.GA-redhat-1]

        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [rt.jar:1.6.0_24]

        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [rt.jar:1.6.0_24]

        at java.lang.Thread.run(Thread.java:679) [rt.jar:1.6.0_24]

Caused by: an exception which occurred:

        in field origIP

        in object of type org.jboss.tusk.juniper.ispn.NATLog

        in element at index [107] of size [200]

1. Is there a size limit for the data passed in via remote EJB3 calls?

2. Are there any settings I can do in JBoss to tune the behavior with regard to EJB calls?

Thanks,

Justin

[ricardotemporal]

I also have this problem with the nightly build of JBoss 7.2.0-Alpha1-SNAPSHOT of the last Saturday.

I have a method with a single parameter of type byte []. When the byte array is 10 Kb then the call works fine. When the byte array is 100 Kb then JBoss hangs.

I have used previous versions of JBoss 3,4 uploading and downloading large amounts of data without any problem or limit.

[maik.ebert.paysafecard]

I have the same problem in JBoss EAP 6.0.1.

Any new information on that topic?

Thanks, Maik

[ricardotemporal]

The problem still exist.

I ask if you or someone could please file a bug report at JIRA.

If we do not provide a very simple code that causes the problem then we have no chance to get it fixed. I suppose most of the people do not transfer large amount of data by parameter, because nobody cares.

One method call to a stateless bean with one parameter byte [] is enough to replicate the problem.

unfortunatly I am not able to file the bug report at JIRA.

[maik.ebert.paysafecard]

We fixed that problem.

Problem was that the client libraries for EJB remoting have not been in sync with server side.

Using the correct client libraries fixed it.

[shankar453]

Hi,

I am having the same issue while upgrading from Jboss5.0.1.GA to Wildfly9.0.1. May I know which specific libraries that caused the issue?

Regards,

Shankar