jboss-remoting-issues
October 2010
jboss-remoting-issues@lists.jboss.org
- 1 participants
- 32 discussions
[JBoss JIRA] Created: (JBREM-1250) Buffer size mismatch between RemoteConnectionHandler and FramingChannelListener
by Ron Sigal (JIRA)
Buffer size mismatch between RemoteConnectionHandler and FramingChannelListener
-------------------------------------------------------------------------------
Key: JBREM-1250
URL: https://jira.jboss.org/browse/JBREM-1250
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 3.1.0.Beta2
Reporter: Ron Sigal
Fix For: 3.1.0.Beta3
Currently,
client.invoke(new byte[1024 * 8 - 6]);
works, but
client.invoke(new byte[1024 * 8 - 5]);
hangs.
The problem is that on the sending side,org.jboss.remoting3.remote.RemoteConnectionHandler hard codes a buffer size of 65536:
private final Pool<ByteBuffer> bufferPool = Buffers.createHeapByteBufferAllocator(65536);
so the sender can transmit up to 65535 bytes at a time. But on the receiving side, FramingChannelListener defaults to a buffer size of 4 * 2048:
FramingChannelListener(final OptionMap optionMap, final AbstractMessageHandler messageHandler) {
this.messageHandler = messageHandler;
maxSize = optionMap.get(Options.MAX_INBOUND_MESSAGE_SIZE, 2048);
receiveBuffer = ByteBuffer.allocate(Math.min(optionMap.get(RemotingOptions.BUFFER_SIZE, maxSize * 4), 4096));
}
Sending new byte[1024 * 8 - 5] results in a message with a 2 byte length field followed by 6 header bytes plus 8187 content bytes, where the length field holds 8193. On the receiver side,org.jboss.remoting3.remote.FramingChannelListener has a buffer of default size 8192. FramingChannelListener.handleEvent() wants to get 8193 bytes and it sits in a loop calling handleBufferedData(), which keeps returning because the 8192 byte buffer never holds 8193 bytes:
org.jboss.remoting3.remote.FramingChannelListener@1e81a197 [[org.jboss.remoting3.remote.RemoteMessageHandler@7a19a37a], remoteConnectionHandler: 589411738, remoteConnection: 1839586123].handleEvent(): receiveBuffer.remaining(): 0
org.jboss.remoting3.remote.FramingChannelListener@1e81a197 [[org.jboss.remoting3.remote.RemoteMessageHandler@7a19a37a], remoteConnectionHandler: 589411738, remoteConnection: 1839586123].handleBufferedData()
org.jboss.remoting3.remote.FramingChannelListener@1e81a197 [[org.jboss.remoting3.remote.RemoteMessageHandler@7a19a37a], remoteConnectionHandler: 589411738, remoteConnection: 1839586123] state: BODY
org.jboss.remoting3.remote.FramingChannelListener@1e81a197 [[org.jboss.remoting3.remote.RemoteMessageHandler@7a19a37a], remoteConnectionHandler: 589411738, remoteConnection: 1839586123] initial == BODY, size == 8193, remaining == 8192
org.jboss.remoting3.remote.FramingChannelListener@1e81a197 [[org.jboss.remoting3.remote.RemoteMessageHandler@7a19a37a], remoteConnectionHandler: 589411738, remoteConnection: 1839586123] returning because remaining < size
org.jboss.remoting3.remote.FramingChannelListener@1e81a197 [[org.jboss.remoting3.remote.RemoteMessageHandler@7a19a37a], remoteConnectionHandler: 589411738, remoteConnection: 1839586123].handleEvent(): receiveBuffer.remaining(): 0
org.jboss.remoting3.remote.FramingChannelListener@1e81a197 [[org.jboss.remoting3.remote.RemoteMessageHandler@7a19a37a], remoteConnectionHandler: 589411738, remoteConnection: 1839586123].handleBufferedData()
org.jboss.remoting3.remote.FramingChannelListener@1e81a197 [[org.jboss.remoting3.remote.RemoteMessageHandler@7a19a37a], remoteConnectionHandler: 589411738, remoteConnection: 1839586123] state: BODY
org.jboss.remoting3.remote.FramingChannelListener@1e81a197 [[org.jboss.remoting3.remote.RemoteMessageHandler@7a19a37a], remoteConnectionHandler: 589411738, remoteConnection: 1839586123] initial == BODY, size == 8193, remaining == 8192
org.jboss.remoting3.remote.FramingChannelListener@1e81a197 [[org.jboss.remoting3.remote.RemoteMessageHandler@7a19a37a], remoteConnectionHandler: 589411738, remoteConnection: 1839586123] returning because remaining < size
.
.
.
When the buffer size is changed to 4 * 16384
maxSize = optionMap.get(Options.MAX_INBOUND_MESSAGE_SIZE, 16384);
the problem goes away.
There should be two changes:
1. The default buffer sizes should be compatible.
2. The buffer size in RemoteConnectionHandler should be configurable.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
- 1
- 0
[JBoss JIRA] Created: (JBREM-1249) RequestContextImpl is unable to send an exception thrown while sending a reply
by Ron Sigal (JIRA)
RequestContextImpl is unable to send an exception thrown while sending a reply
------------------------------------------------------------------------------
Key: JBREM-1249
URL: https://jira.jboss.org/browse/JBREM-1249
Project: JBoss Remoting
Issue Type: Bug
Security Level: Public (Everyone can see)
Affects Versions: 3.1.0.Beta2
Reporter: Ron Sigal
Fix For: 3.1.0.Beta3
In org.jboss.remoting3.test.remote.RemoteMessageHandlerTestCase, test method testReplyExceptionAbort() (currently commented) sends an exception over the wire, and the request listener sends it back. But on the return trip, the exception's writeObject() method throws an exception. So
1. RequestContextImpl.sendReply() calls OutboundReplyHandler.sendReply() to write the exception for its return trip
2. OutboundReplyHandler.sendReply() tries to write the exception
2. the exception's writeObject() throws an exception
3. RequestContextImpl.sendReply() catches the exception and calls
SpiUtils.safeHandleException(replyHandler, new RemoteReplyException("Remote reply failed", e));
4. SpiUtils.safeHandleException() calls OutboundReplyHandler.handleException().
The problem is that the call to OutboundReplyHandler.sendReply() sets OutboundReplyHandler.done to true, and the call to OutboundReplyHandler.handleException() turns into a no-op.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 1 month
- 1
- 0