Simon- you're absolutely right.
It's clear from looking at the code that it's highly inefficient to allocate a
large buffer when perhaps as little as one byte is read from the stream.
I have refactored the code, so this is done more sensibly!
The fix will be in the next release (on Monday)
The loop in ClientProducerImpl seems to be responsible:
while (!lastChunk)
| {
| byte[] bytesRead = new byte[minLargeMessageSize];
| int numberOfBytesRead;
|
| try
| {
|numberOfBytesRead =
What is your windowSize?
I will make a few tests.
With LargeMessage, you should have a bunch of pending packets waiting to be
delivered on the NettyQueue, but you shouldn't have more than what's configured
on the windowSize. Otherwise you would get out of memory easily.
I would need to look
From my jbm-jms.xml
connection-factory name=SocketConnectionFactory
| connector-ref connector-name=netty/
| entries
| entry name=ConnectionFactory/
| entry name=XAConnectionFactory/
| /entries
| !-- 128K chunk size for large messages --
|
A single producer? Or you're opening several Producers? How many threads doing
this.. just one?
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4250909#4250909
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4250909
Yes a single producer on one thread from a junit test case.
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4250912#4250912
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=4250912
___
Can you send me a sample test showing this happening?
clebert at redhat dot com
or clebert dot suconic at jboss dot com
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=4250915#4250915
Reply to the post :
Did you make any changes on the windowSize?
You should have up to your WindowSize messages in memory. (We control that
thorugh flow control).
[url]
