[JBoss JIRA] (JBREM-1307) TimedOutputStream OutputTimerTask call to close on SSL OutputStream blocks
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/JBREM-1307?page=com.atlassian.jira.plugin... ]
Ron Sigal resolved JBREM-1307.
------------------------------
Resolution: Done
> TimedOutputStream OutputTimerTask call to close on SSL OutputStream blocks
> --------------------------------------------------------------------------
>
> Key: JBREM-1307
> URL: https://issues.jboss.org/browse/JBREM-1307
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: transport
> Affects Versions: 2.2.3.SP2, 2.5.4.SP4
> Environment: JBoss EAP 4.3.0 CP08 and CP10
> Reporter: Doug Grove
> Assignee: Ron Sigal
> Labels: messaging
> Fix For: 2.5.4.SP5
>
> Attachments: jboss-remoting-src.jar, jboss-remoting.jar
>
>
> In order to provide a mechanism for timing out a network/socket write operation, the org.jboss.remoting.transport.socket.TimedOutputStream class starts a timer. If the duration of the write operation exceeds the timer interval, then the timer will call close() on the output stream. This interrupts the output stream write() operation and causes the write operation to throw an IOException.
> When the output stream uses secure sockets (SSL), however, the call to close() on the output stream can block indefinitely. The threads associated with the write() and close() operation will only clear when the tcp keepalive timeout mechanism in the operation system is invoked.
> This appears to be related to a know bug in the java runtime: http://bugs.sun.com/view_bug.do?bug_id=6358629
> Specifically, in a thread dump you will see:
> "Timer-9" daemon prio=10 tid=0x5016c400 nid=0x2638 waiting on condition [0x4cbad000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x585021a0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)
> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:720)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.sendAlert(SSLSocketImpl.java:1720)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.warning(SSLSocketImpl.java:1564)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.closeInternal(SSLSocketImpl.java:1362)
> - locked <0x58502030> (a com.sun.net.ssl.internal.ssl.SSLSocketImpl)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.close(SSLSocketImpl.java:1301)
> at com.sun.net.ssl.internal.ssl.AppOutputStream.close(AppOutputStream.java:80)
> at org.jboss.remoting.transport.socket.TimedOutputStream.close(TimedOutputStream.java:57)
> at org.jboss.remoting.transport.socket.TimedOutputStream$OutputTimerTask.run(TimedOutputStream.java:145)
> at java.util.TimerThread.mainLoop(Timer.java:512)
> at java.util.TimerThread.run(Timer.java:462)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (JBREM-1307) TimedOutputStream OutputTimerTask call to close on SSL OutputStream blocks
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/JBREM-1307?page=com.atlassian.jira.plugin... ]
Ron Sigal updated JBREM-1307:
-----------------------------
Fix Version/s: 2.5.4.SP5
Affects Version/s: 2.5.4.SP4
> TimedOutputStream OutputTimerTask call to close on SSL OutputStream blocks
> --------------------------------------------------------------------------
>
> Key: JBREM-1307
> URL: https://issues.jboss.org/browse/JBREM-1307
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: transport
> Affects Versions: 2.2.3.SP2, 2.5.4.SP4
> Environment: JBoss EAP 4.3.0 CP08 and CP10
> Reporter: Doug Grove
> Assignee: Ron Sigal
> Labels: messaging
> Fix For: 2.5.4.SP5
>
> Attachments: jboss-remoting-src.jar, jboss-remoting.jar
>
>
> In order to provide a mechanism for timing out a network/socket write operation, the org.jboss.remoting.transport.socket.TimedOutputStream class starts a timer. If the duration of the write operation exceeds the timer interval, then the timer will call close() on the output stream. This interrupts the output stream write() operation and causes the write operation to throw an IOException.
> When the output stream uses secure sockets (SSL), however, the call to close() on the output stream can block indefinitely. The threads associated with the write() and close() operation will only clear when the tcp keepalive timeout mechanism in the operation system is invoked.
> This appears to be related to a know bug in the java runtime: http://bugs.sun.com/view_bug.do?bug_id=6358629
> Specifically, in a thread dump you will see:
> "Timer-9" daemon prio=10 tid=0x5016c400 nid=0x2638 waiting on condition [0x4cbad000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x585021a0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)
> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:720)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.sendAlert(SSLSocketImpl.java:1720)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.warning(SSLSocketImpl.java:1564)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.closeInternal(SSLSocketImpl.java:1362)
> - locked <0x58502030> (a com.sun.net.ssl.internal.ssl.SSLSocketImpl)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.close(SSLSocketImpl.java:1301)
> at com.sun.net.ssl.internal.ssl.AppOutputStream.close(AppOutputStream.java:80)
> at org.jboss.remoting.transport.socket.TimedOutputStream.close(TimedOutputStream.java:57)
> at org.jboss.remoting.transport.socket.TimedOutputStream$OutputTimerTask.run(TimedOutputStream.java:145)
> at java.util.TimerThread.mainLoop(Timer.java:512)
> at java.util.TimerThread.run(Timer.java:462)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (JBREM-1307) TimedOutputStream OutputTimerTask call to close on SSL OutputStream blocks
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/JBREM-1307?page=com.atlassian.jira.plugin... ]
Ron Sigal updated JBREM-1307:
-----------------------------
Attachment: jboss-remoting.jar
jboss-remoting-src.jar
This fix will be in release 2.5.4.SP5. I'm attaching a jboss-remoting.jar in case someone wants to try it.
> TimedOutputStream OutputTimerTask call to close on SSL OutputStream blocks
> --------------------------------------------------------------------------
>
> Key: JBREM-1307
> URL: https://issues.jboss.org/browse/JBREM-1307
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: transport
> Affects Versions: 2.2.3.SP2
> Environment: JBoss EAP 4.3.0 CP08 and CP10
> Reporter: Doug Grove
> Assignee: Ron Sigal
> Labels: messaging
> Attachments: jboss-remoting-src.jar, jboss-remoting.jar
>
>
> In order to provide a mechanism for timing out a network/socket write operation, the org.jboss.remoting.transport.socket.TimedOutputStream class starts a timer. If the duration of the write operation exceeds the timer interval, then the timer will call close() on the output stream. This interrupts the output stream write() operation and causes the write operation to throw an IOException.
> When the output stream uses secure sockets (SSL), however, the call to close() on the output stream can block indefinitely. The threads associated with the write() and close() operation will only clear when the tcp keepalive timeout mechanism in the operation system is invoked.
> This appears to be related to a know bug in the java runtime: http://bugs.sun.com/view_bug.do?bug_id=6358629
> Specifically, in a thread dump you will see:
> "Timer-9" daemon prio=10 tid=0x5016c400 nid=0x2638 waiting on condition [0x4cbad000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x585021a0> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:158)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:747)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:778)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1114)
> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:186)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:262)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:720)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.sendAlert(SSLSocketImpl.java:1720)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.warning(SSLSocketImpl.java:1564)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.closeInternal(SSLSocketImpl.java:1362)
> - locked <0x58502030> (a com.sun.net.ssl.internal.ssl.SSLSocketImpl)
> at com.sun.net.ssl.internal.ssl.SSLSocketImpl.close(SSLSocketImpl.java:1301)
> at com.sun.net.ssl.internal.ssl.AppOutputStream.close(AppOutputStream.java:80)
> at org.jboss.remoting.transport.socket.TimedOutputStream.close(TimedOutputStream.java:57)
> at org.jboss.remoting.transport.socket.TimedOutputStream$OutputTimerTask.run(TimedOutputStream.java:145)
> at java.util.TimerThread.mainLoop(Timer.java:512)
> at java.util.TimerThread.run(Timer.java:462)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (JBREM-1324) Always hit OutOfMemoryError If I try to invoke ejb method with large object as its parameter at the marshlling step
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/JBREM-1324?page=com.atlassian.jira.plugin... ]
Ron Sigal closed JBREM-1324.
----------------------------
> Always hit OutOfMemoryError If I try to invoke ejb method with large object as its parameter at the marshlling step
> -------------------------------------------------------------------------------------------------------------------
>
> Key: JBREM-1324
> URL: https://issues.jboss.org/browse/JBREM-1324
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: marshall
> Affects Versions: 2.2.2.SP10
> Environment: WindowsXP + jdk1.6
> Reporter: licheng cheng
> Attachments: SerializableInputStream.java
>
>
> In our stateless EJB, there is one API defined as below.
> public void modelSave(SerializableInputStream model) throws java.rmi.RemoteException;
> The SerializableInputStream is defined as below and its whole definition is attached. The intent of defining such class is that sometimes we need to pass through large object (its content may be more than 300M) as parameter to remote ejb, while the -Xmx of the JVM is only 512M by default. With such serializable inputstream, expect JBoss not to load the whole object into JVM before invoking ejb method to avoid the OutOfMemoryError issue.
> public class SerializableInputStream extends InputStream implements Serializable {
> private InputStream stream;
> ....
> //---------------------------< Serializable >-------------------------------
> private void writeObject(ObjectOutputStream out)
> throws IOException {
> byte[] buffer = new byte[4096];
> int bytes;
> while ((bytes = stream.read(buffer)) >= 0) {
> // Write a segment of the input stream
> if (bytes > 0) {
> // just to ensure that no 0 is written
> out.writeInt(bytes);
> out.write(buffer, 0, bytes);
> }
> }
> // Write the end of stream marker
> out.writeInt(0);
> // close stream
> stream.close();
> }
> private void readObject(ObjectInputStream in)
> throws IOException {
> final File file = File.createTempFile("serializable-stream", "bin");
> OutputStream out = new FileOutputStream(file);
> byte[] buffer = new byte[4096];
> for (int bytes = in.readInt(); bytes > 0; bytes = in.readInt()) {
> if (buffer.length < bytes) {
> buffer = new byte[bytes];
> }
> in.readFully(buffer, 0, bytes);
> out.write(buffer, 0, bytes);
> }
> out.close();
> stream = new FileInputStream(file) {
> private boolean closed = false;
> public void close() throws IOException {
> super.close();
> closed = true;
> file.delete();
> }
> ...
> };
> }
> }
> But from the test result, I can that JBoss marshaller first read its content (the serializable inputstream) into a byte array, which means the big object is loaded into memory. With our default JVM setting, we always hit OOM issue as below
> 2013-08-07 14:30:21,001 ERROR [STDERR] Caused by: java.lang.Exception: java.lang.OutOfMemoryError: Java heap space
> 2013-08-07 14:30:21,001 ERROR [STDERR] at org.jboss.invocation.unified.interfaces.UnifiedInvokerProxy.invoke(UnifiedInvokerProxy.java:222)
> 2013-08-07 14:30:21,001 ERROR [STDERR] at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:112)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
> 2013-08-07 14:30:21,016 ERROR [STDERR] ... 39 more
> 2013-08-07 14:30:21,016 ERROR [STDERR] Caused by: java.lang.OutOfMemoryError: Java heap space
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.util.Arrays.copyOf(Arrays.java:2786)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ByteArrayOutputStream.toByteArray(ByteArrayOutputStream.java:133)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledValue.<init>(MarshalledValue.java:72)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledValueEX.<init>(MarshalledValueEX.java:47)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.unified.interfaces.JavaSerializationManager.createdMarshalledValue(JavaSerializationManager.java:105)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledInvocation.createMarshalledValue(MarshalledInvocation.java:628)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledInvocation.writeExternal(MarshalledInvocation.java:570)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1429)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1398)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObjectVersion2_2(JavaSerializationManager.java:119)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObject(JavaSerializationManager.java:94)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.marshal.serializable.SerializableMarshaller.write(SerializableMarshaller.java:120)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.unified.marshall.InvocationMarshaller.write(InvocationMarshaller.java:75)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedWrite(MicroSocketClientInvoker.java:969)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:606)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.Client.invoke(Client.java:1634)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.Client.invoke(Client.java:548)
> Although passing big object with Remote ejb call is not a common use case, but I think it will be better if JBoss could consider such case.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (JBREM-1324) Always hit OutOfMemoryError If I try to invoke ejb method with large object as its parameter at the marshlling step
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/JBREM-1324?page=com.atlassian.jira.plugin... ]
Ron Sigal resolved JBREM-1324.
------------------------------
Resolution: Rejected
It looks like the issue is in org.jboss.invocation.MarshalledValue():
{code}
public MarshalledValue(Object obj) throws IOException
{
ByteArrayOutputStream baos = new ByteArrayOutputStream();
MarshalledValueOutputStream mvos = new MarshalledValueOutputStream(baos);
{code}
which is part of the JBoss Application Server, not the Remoting project.
> Always hit OutOfMemoryError If I try to invoke ejb method with large object as its parameter at the marshlling step
> -------------------------------------------------------------------------------------------------------------------
>
> Key: JBREM-1324
> URL: https://issues.jboss.org/browse/JBREM-1324
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: marshall
> Affects Versions: 2.2.2.SP10
> Environment: WindowsXP + jdk1.6
> Reporter: licheng cheng
> Attachments: SerializableInputStream.java
>
>
> In our stateless EJB, there is one API defined as below.
> public void modelSave(SerializableInputStream model) throws java.rmi.RemoteException;
> The SerializableInputStream is defined as below and its whole definition is attached. The intent of defining such class is that sometimes we need to pass through large object (its content may be more than 300M) as parameter to remote ejb, while the -Xmx of the JVM is only 512M by default. With such serializable inputstream, expect JBoss not to load the whole object into JVM before invoking ejb method to avoid the OutOfMemoryError issue.
> public class SerializableInputStream extends InputStream implements Serializable {
> private InputStream stream;
> ....
> //---------------------------< Serializable >-------------------------------
> private void writeObject(ObjectOutputStream out)
> throws IOException {
> byte[] buffer = new byte[4096];
> int bytes;
> while ((bytes = stream.read(buffer)) >= 0) {
> // Write a segment of the input stream
> if (bytes > 0) {
> // just to ensure that no 0 is written
> out.writeInt(bytes);
> out.write(buffer, 0, bytes);
> }
> }
> // Write the end of stream marker
> out.writeInt(0);
> // close stream
> stream.close();
> }
> private void readObject(ObjectInputStream in)
> throws IOException {
> final File file = File.createTempFile("serializable-stream", "bin");
> OutputStream out = new FileOutputStream(file);
> byte[] buffer = new byte[4096];
> for (int bytes = in.readInt(); bytes > 0; bytes = in.readInt()) {
> if (buffer.length < bytes) {
> buffer = new byte[bytes];
> }
> in.readFully(buffer, 0, bytes);
> out.write(buffer, 0, bytes);
> }
> out.close();
> stream = new FileInputStream(file) {
> private boolean closed = false;
> public void close() throws IOException {
> super.close();
> closed = true;
> file.delete();
> }
> ...
> };
> }
> }
> But from the test result, I can that JBoss marshaller first read its content (the serializable inputstream) into a byte array, which means the big object is loaded into memory. With our default JVM setting, we always hit OOM issue as below
> 2013-08-07 14:30:21,001 ERROR [STDERR] Caused by: java.lang.Exception: java.lang.OutOfMemoryError: Java heap space
> 2013-08-07 14:30:21,001 ERROR [STDERR] at org.jboss.invocation.unified.interfaces.UnifiedInvokerProxy.invoke(UnifiedInvokerProxy.java:222)
> 2013-08-07 14:30:21,001 ERROR [STDERR] at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:112)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
> 2013-08-07 14:30:21,016 ERROR [STDERR] ... 39 more
> 2013-08-07 14:30:21,016 ERROR [STDERR] Caused by: java.lang.OutOfMemoryError: Java heap space
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.util.Arrays.copyOf(Arrays.java:2786)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ByteArrayOutputStream.toByteArray(ByteArrayOutputStream.java:133)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledValue.<init>(MarshalledValue.java:72)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledValueEX.<init>(MarshalledValueEX.java:47)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.unified.interfaces.JavaSerializationManager.createdMarshalledValue(JavaSerializationManager.java:105)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledInvocation.createMarshalledValue(MarshalledInvocation.java:628)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledInvocation.writeExternal(MarshalledInvocation.java:570)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1429)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1398)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObjectVersion2_2(JavaSerializationManager.java:119)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObject(JavaSerializationManager.java:94)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.marshal.serializable.SerializableMarshaller.write(SerializableMarshaller.java:120)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.unified.marshall.InvocationMarshaller.write(InvocationMarshaller.java:75)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedWrite(MicroSocketClientInvoker.java:969)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:606)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.Client.invoke(Client.java:1634)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.Client.invoke(Client.java:548)
> Although passing big object with Remote ejb call is not a common use case, but I think it will be better if JBoss could consider such case.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (JBREM-1324) Always hit OutOfMemoryError If I try to invoke ejb method with large object as its parameter at the marshlling step
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/JBREM-1324?page=com.atlassian.jira.plugin... ]
Ron Sigal updated JBREM-1324:
-----------------------------
Fix Version/s: (was: 2.2.2.SP10)
> Always hit OutOfMemoryError If I try to invoke ejb method with large object as its parameter at the marshlling step
> -------------------------------------------------------------------------------------------------------------------
>
> Key: JBREM-1324
> URL: https://issues.jboss.org/browse/JBREM-1324
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: marshall
> Affects Versions: 2.2.2.SP10
> Environment: WindowsXP + jdk1.6
> Reporter: licheng cheng
> Attachments: SerializableInputStream.java
>
>
> In our stateless EJB, there is one API defined as below.
> public void modelSave(SerializableInputStream model) throws java.rmi.RemoteException;
> The SerializableInputStream is defined as below and its whole definition is attached. The intent of defining such class is that sometimes we need to pass through large object (its content may be more than 300M) as parameter to remote ejb, while the -Xmx of the JVM is only 512M by default. With such serializable inputstream, expect JBoss not to load the whole object into JVM before invoking ejb method to avoid the OutOfMemoryError issue.
> public class SerializableInputStream extends InputStream implements Serializable {
> private InputStream stream;
> ....
> //---------------------------< Serializable >-------------------------------
> private void writeObject(ObjectOutputStream out)
> throws IOException {
> byte[] buffer = new byte[4096];
> int bytes;
> while ((bytes = stream.read(buffer)) >= 0) {
> // Write a segment of the input stream
> if (bytes > 0) {
> // just to ensure that no 0 is written
> out.writeInt(bytes);
> out.write(buffer, 0, bytes);
> }
> }
> // Write the end of stream marker
> out.writeInt(0);
> // close stream
> stream.close();
> }
> private void readObject(ObjectInputStream in)
> throws IOException {
> final File file = File.createTempFile("serializable-stream", "bin");
> OutputStream out = new FileOutputStream(file);
> byte[] buffer = new byte[4096];
> for (int bytes = in.readInt(); bytes > 0; bytes = in.readInt()) {
> if (buffer.length < bytes) {
> buffer = new byte[bytes];
> }
> in.readFully(buffer, 0, bytes);
> out.write(buffer, 0, bytes);
> }
> out.close();
> stream = new FileInputStream(file) {
> private boolean closed = false;
> public void close() throws IOException {
> super.close();
> closed = true;
> file.delete();
> }
> ...
> };
> }
> }
> But from the test result, I can that JBoss marshaller first read its content (the serializable inputstream) into a byte array, which means the big object is loaded into memory. With our default JVM setting, we always hit OOM issue as below
> 2013-08-07 14:30:21,001 ERROR [STDERR] Caused by: java.lang.Exception: java.lang.OutOfMemoryError: Java heap space
> 2013-08-07 14:30:21,001 ERROR [STDERR] at org.jboss.invocation.unified.interfaces.UnifiedInvokerProxy.invoke(UnifiedInvokerProxy.java:222)
> 2013-08-07 14:30:21,001 ERROR [STDERR] at org.jboss.invocation.InvokerInterceptor.invokeInvoker(InvokerInterceptor.java:365)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.InvokerInterceptor.invoke(InvokerInterceptor.java:197)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.TransactionInterceptor.invoke(TransactionInterceptor.java:61)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.SecurityInterceptor.invoke(SecurityInterceptor.java:70)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.ejb.StatelessSessionInterceptor.invoke(StatelessSessionInterceptor.java:112)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.proxy.ClientContainer.invoke(ClientContainer.java:100)
> 2013-08-07 14:30:21,016 ERROR [STDERR] ... 39 more
> 2013-08-07 14:30:21,016 ERROR [STDERR] Caused by: java.lang.OutOfMemoryError: Java heap space
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.util.Arrays.copyOf(Arrays.java:2786)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ByteArrayOutputStream.toByteArray(ByteArrayOutputStream.java:133)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledValue.<init>(MarshalledValue.java:72)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledValueEX.<init>(MarshalledValueEX.java:47)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.unified.interfaces.JavaSerializationManager.createdMarshalledValue(JavaSerializationManager.java:105)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledInvocation.createMarshalledValue(MarshalledInvocation.java:628)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.MarshalledInvocation.writeExternal(MarshalledInvocation.java:570)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeExternalData(ObjectOutputStream.java:1429)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1398)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObjectVersion2_2(JavaSerializationManager.java:119)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.serialization.impl.java.JavaSerializationManager.sendObject(JavaSerializationManager.java:94)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.marshal.serializable.SerializableMarshaller.write(SerializableMarshaller.java:120)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.invocation.unified.marshall.InvocationMarshaller.write(InvocationMarshaller.java:75)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.versionedWrite(MicroSocketClientInvoker.java:969)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.transport.socket.MicroSocketClientInvoker.transport(MicroSocketClientInvoker.java:606)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:122)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.Client.invoke(Client.java:1634)
> 2013-08-07 14:30:21,016 ERROR [STDERR] at org.jboss.remoting.Client.invoke(Client.java:548)
> Although passing big object with Remote ejb call is not a common use case, but I think it will be better if JBoss could consider such case.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (JBREM-1318) Zero is a valid value so SoLinger
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/JBREM-1318?page=com.atlassian.jira.plugin... ]
Ron Sigal commented on JBREM-1318:
----------------------------------
Isn't calling Socket.setSoLinger(true, 0) the same as not calling it all?
> Zero is a valid value so SoLinger
> ---------------------------------
>
> Key: JBREM-1318
> URL: https://issues.jboss.org/browse/JBREM-1318
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: general
> Affects Versions: 2.5.4.SP3
> Reporter: Doug Grove
> Priority: Minor
>
> MicroSocketClientInvoker checks to see that SoLinger is greater than zero:
> if (soLingerSet &&
> soLingerDuration > 0) s.setSoLinger(soLinger, soLingerDuration);
> Zero is a valid value for SoLinger.
> The code should be changed to greater than or equal to zero.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (JBREM-1317) BisocketClientInvoker waits for failed clients
by Ron Sigal (JIRA)
[ https://issues.jboss.org/browse/JBREM-1317?page=com.atlassian.jira.plugin... ]
Ron Sigal resolved JBREM-1317.
------------------------------
Resolution: Rejected
> BisocketClientInvoker waits for failed clients
> ----------------------------------------------
>
> Key: JBREM-1317
> URL: https://issues.jboss.org/browse/JBREM-1317
> Project: JBoss Remoting
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: callbacks
> Affects Versions: 2.5.4.SP3
> Environment: JBoss EAP 5.1.2
> Reporter: Doug Grove
> Assignee: Ron Sigal
> Priority: Minor
>
> When a client dies or is killed, the failure is actually detected in org.jboss.remoting.transport.socket.MicroSocketClientInvoker:
> (NEW ClientSocketWrapper[Socket[addr=/10.0.0.212,port=36600,localport=4458].d3e837]) got Exception: java.io.IOException: Broken pipe
> The "Broken pipe" exception means that the client has disconnected and can not return. This exception is treated in the code a retry-able, however.
> The code carries on, finally calling BisocketClientInvoker.createSocket(). This code then waits for a socket to appear in a list. I can see no way for a new socket to ever appear in the list.
> This results in the code waiting for the full duration of the configured timeout.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months