Andy: As we talked today:
If you change NettyConnection:
public MessagingBuffer createBuffer(final int size)
| + return new ChannelBufferWrapper(org.jboss.netty.buffer.ChannelBuffers.buffer(size));
| - return new ChannelBufferWrapper(org.jboss.netty.buffer.ChannelBuffers.dynamicBuffer(size));
org.jboss.messaging.tests.integration.http.NettyHttpTest would have a bunch of failures:
Exception in thread "pool-3-thread-23" java.lang.ArrayIndexOutOfBoundsException
| at org.jboss.netty.buffer.HeapChannelBuffer.setBytes(HeapChannelBuffer.java:130)
| at org.jboss.netty.buffer.HeapChannelBuffer.setBytes(HeapChannelBuffer.java:123)
| at org.jboss.netty.buffer.AbstractChannelBuffer.writeBytes(AbstractChannelBuffer.java:411)
| at org.jboss.netty.buffer.AbstractChannelBuffer.writeBytes(AbstractChannelBuffer.java:406)
| at org.jboss.netty.buffer.AbstractChannelBuffer.writeBytes(AbstractChannelBuffer.java:399)
| at org.jboss.messaging.integration.transports.netty.HttpAcceptorHandler$ResponseRunner.piggyBackResponses(HttpAcceptorHandler.java:202)
| at org.jboss.messaging.integration.transports.netty.HttpAcceptorHandler$ResponseRunner.run(HttpAcceptorHandler.java:181)
| at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
| at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
| at java.lang.Thread.run(Thread.java:619)
You probably need to call netty.Buffers.dynamic directly instead of using NettyConnection.createBuffer, or maybe we should create another method on Connection for createDynamicBuffer.
(I don't know if it would be possible to know the size of the buffer you need, since this will probably using HTTPEncoding)
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213867#4213867
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213867
I have done these following changes, as part of of MessagingBuffer refactoring, per https://jira.jboss.org/jira/browse/JBMESSAGING-1394
I have stripped down org.jboss.netty.buffer a bit, for what we needed.
I'm basically providing three types of buffers that exist on the original netty.buffer:
- HeapChannelBuffer - Which is a byte backed Buffer
- DynamicChannelBuffer - Which is using HeapChannelBuffer, and auto-extending it
- ByteBufferBackedChannelBuffer - Which will have a ByteBuffer inside.
All these classes are implementing ChannelBuffer and MessagingBuffer.
For creating a new buffer, you should use the methods provided by ChannelBuffers:
buffer(int capacity) - This method will create a fixed size MessagingBuffer
dynamicBuffer(final int estimatedLength) - This method will create a SelfExpandable MessagingBuffer
dynamicBuffer(final byte initialBuffer) - This method will create a SelfExpandable MessagingBuffer, but reusing the initialBuffer. Be careful though, the reference will be directly used on the createdBuffer. If your buffer will be used by other operations, you should instead create a new buffer and perform a write.
buffer(final int capacity) - This method will create a fixed size MessagingBuffer
wrappedBuffer(final byte array) - It will create a Buffer, with writePosition at the end, and readPosition at 0
wrappedBuffer(final ByteBuffer buffer) - It will wrap a Bytebuffer on a MessagingBuffer. The position on this buffer won't affect the position on the inner buffer
We are now using dynamicBuffers on the MessageBody.
And in a few places, where we are reading the body, we are wrapping a byte on a dynamicBuffer, avoiding this way an extra copy.
Also, there is one difference on the old ByteBufferWrapper, and the "new" ByteBufferBackedChannelBuffer.
ByteBufferWrapper would aways refer to the positioning inside the ByteBuffer, while the new one will have an independent positioning, and because of that I had to make a few changes on Journal and Paging, as we used ByteBufferWrapper since we need to play with ByteBuffer because NIO and AIO SequentialFiles.
I'm writing some of this information on the package.html, and I should commit shortly as soon as I finish some latest tests.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213829#4213829
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213829
This looks out of date at this point as the config-property is common across all of the jca deployment types and handled by the custom ConnectionFactoryProperty. I don't see any related failures in the profile service tests.
As Emanuel notes, there are some issues with essentially duplicate properties with different names when config-property is an alias for specifying another metadata property. Ideally the config-property would have those specified in a consistent manner as a MapCompositeType, and would incorporate cf specific property descriptions from the rar metadata, but that is another issue.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213820#4213820
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213820