1088463 – (6.4.0) If large parameters are given to an EJB method invocation the client show a EJBCLIENT000032 Exception - the OutOfMemoryError is swallowed

Bug 1088463 - (6.4.0) If large parameters are given to an EJB method invocation the client show a EJBCLIENT000032 Exception - the OutOfMemoryError is swallowed

Summary: (6.4.0) If large parameters are given to an EJB method invocation the client ...

Keywords:
Status:	CLOSED CURRENTRELEASE
Alias:	None
Product:	JBoss Enterprise Application Platform 6
Classification:	JBoss
Component:	EJB
Sub Component:
Version:	6.2.0
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	unspecified
Target Milestone:	ER1
Target Release:	EAP 6.4.0
Assignee:	Panagiotis Sotiropoulos
QA Contact:	Jan Martiska
Docs Contact:
URL:
Whiteboard:
Depends On:	1118892
Blocks:	1127593 1139680
TreeView+	depends on / blocked

Reported:	2014-04-16 16:41 UTC by wfink
Modified:	2019-08-19 12:43 UTC (History)
CC List:	4 users (show)
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:	In the previous version of JBoss EAP 6, when a large value is passed in a parameter for EJB invocation, the channel crashed and the out of memory error was not displayed on the server. On the ejb-client, an exception indictating the error occurred during the unmarshalling of some parameter with a possible OOM cause is displayed. This issue is now fixed in the current version of JBoss EAP 6. When a large value is passed in a parameter for EJB invocation, an out of memory exception is displayed on the server and a hint is displayed on the client side.
Clone Of:
Clones:	1127593 (view as bug list)
Environment:
Last Closed:	2019-08-19 12:38:25 UTC
Type:	Bug
Embargoed:

Attachments	(Terms of Use)

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Issue Tracker	EJBCLIENT-113	0	Major	Closed	(6.4.0) If large parameters are given to an EJB method invocation the client show a EJBCLIENT000032 Exception - the Out...	2018-01-05 05:07:58 UTC
Red Hat Issue Tracker	WFLY-3266	0	Critical	Closed	Exception are hidden by retry and end in a EJBCLIENT000032 Exception - the underlying client or server side cause is swa...	2018-01-05 05:07:58 UTC

Description wfink 2014-04-16 16:41:51 UTC

Description of problem:

In case of large parameter input for EJB invocations the ejb-client throw the Exception below.
The underlying OutOfMemory is complete hidden, neither in the server.log nor in the ejb-client with TRACE a hint will be found.


Steps to Reproduce:

Invoke an EJB with a large parameter Object, i.e. byte[] with a size of 400MB (the default server starts with Xmx512m).

Add bytman script
RULE Exception at MessageHandler
CLASS AbstractMessageHandler
METHOD writeException
AT ENTRY
IF TRUE
DO System.out.println("WOLF has seen Exception in MsgHandler"+ $t)
ENDRULE

The result is:
INFO [stdout] (default task-5) WOLF has seen entry processMessage
INFO [stdout] (default task-5) WOLF has seen Exception in MsgHandlerjava.lang.OutOfMemoryError: Java heap space
INFO [stdout] (default task-5) WOLF has seen exit processMessage

Actual results:
DEBUG [org.jboss.ejb.client] Retrying invocation org.jboss.ejb.client.EJBClientInvocationContext@4563b254 which failed on node: redhat due to:
org.jboss.ejb.client.RequestSendFailedException: Remote side closed the message stream
	at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.processInvocation(RemotingConnectionEJBReceiver.java:234)
	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181)
	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58)
	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)
	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83)
	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)
	at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42)
	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)
	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125)
	at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)
	at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:253)
	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198)
	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
	at com.sun.proxy.$Proxy6.uploadData(Unknown Source)
	at de.info.biene.konsens.TestServiceWithAPITest.testUploadData(TestServiceWithAPITest.java:81)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:606)
	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
	at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: org.xnio.BrokenPipeException: Remote side closed the message stream
	at org.jboss.remoting3.remote.OutboundMessage$1.accept(OutboundMessage.java:113)
	at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:126)
	at org.xnio.streams.BufferPipeOutputStream.send(BufferPipeOutputStream.java:114)
	at org.xnio.streams.BufferPipeOutputStream.getBuffer(BufferPipeOutputStream.java:78)
	at org.xnio.streams.BufferPipeOutputStream.write(BufferPipeOutputStream.java:96)
	at org.jboss.remoting3.remote.OutboundMessage.write(OutboundMessage.java:234)
	at java.io.DataOutputStream.write(DataOutputStream.java:107)
	at org.jboss.ejb.client.remoting.AbstractMessageWriter$1.write(AbstractMessageWriter.java:120)
	at org.jboss.marshalling.OutputStreamByteOutput.write(OutputStreamByteOutput.java:56)
	at org.jboss.marshalling.SimpleDataOutput.write(SimpleDataOutput.java:83)
	at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(RiverMarshaller.java:307)
	at org.jboss.marshalling.AbstractObjectOutput.writeObject(AbstractObjectOutput.java:62)
	at org.jboss.marshalling.AbstractMarshaller.writeObject(AbstractMarshaller.java:119)
	at org.jboss.ejb.client.remoting.MethodInvocationMessageWriter.writeMessage(MethodInvocationMessageWriter.java:101)
	at org.jboss.ejb.client.remoting.RemotingConnectionEJBReceiver.processInvocation(RemotingConnectionEJBReceiver.java:231)
	... 45 more
Caused by: an exception which occurred:
	in object (array of byte)@6160f16a



Expected results:
OutOfMemoryException at ServerSide and a hint for the client

Comment 1 baranowb 2014-08-07 08:20:23 UTC

Pushing to 6.4.0

Comment 4 Panagiotis Sotiropoulos 2014-09-02 16:02:34 UTC

PR sent : https://github.com/jbossas/jboss-ejb-client/pull/75

When large parameters are given to an EJB method invocation the channel crashes and the out of memory error is hidden.
At client side (ejb-client) an Exception is thrown indicating the the error occurred during the unmarshalling of some parameter with a possible OOM cause.

Comment 5 Panagiotis Sotiropoulos 2014-09-09 11:43:26 UTC

This is tracked by EJBCLIENT-113

Comment 8 Kabir Khan 2014-12-18 16:16:38 UTC

There is no 6.x PR for this, so I am setting back to ASSIGNED.

Comment 9 Panagiotis Sotiropoulos 2014-12-18 18:02:32 UTC

The PR is sent to ejb-client component : https://github.com/jbossas/jboss-ejb-client/pull/75

Comment 10 Panagiotis Sotiropoulos 2014-12-18 18:47:38 UTC

An update of ejb-client version is needed : https://github.com/jbossas/jboss-eap/pull/2176

Comment 11 Jan Martiska 2015-01-20 09:43:46 UTC

Verified in EAP 6.4.0.ER1 / jboss-ejb-client 1.0.28.Final

Note You need to log in before you can comment on or make changes to this bug.