Norman Maurer
08b75e594c
[ #1519 ] VoidChannelPromise don't fire CancellationException anymore which was incorrect
2013-07-04 09:32:38 +02:00
Norman Maurer
cea873286e
[ #1517 ] Only fire the exception throught the pipeline if the channel is registered when using VoidChannelPromise
2013-07-04 09:20:24 +02:00
Trustin Lee
998b408db3
Fix NPE in OioByteStreamChannel
...
- Do not assign null to 'is' and 'os' but assign an alternative stream implementation
2013-07-04 12:04:28 +09:00
Norman Maurer
7ec12d327f
Remove deprecated ByteBufUtil.release(..) and ByteBufUtil.retain(..) methods and its usage. Also fix a problem where an object would have been released two times.
...
* The problem with the release(..) calls here was that it would have called release on an unsupported message and then throw an exception. This exception will trigger ChannelOutboundBuffer.fail(..), which will also try to release the message again.
* Also use the same exception type for unsupported messages as in other channel impls.
2013-07-03 10:00:13 +02:00
Norman Maurer
ec5e793a2f
[maven-release-plugin] prepare for next development iteration
2013-07-02 11:41:18 +02:00
Norman Maurer
ca73eaef0d
[maven-release-plugin] prepare release netty-4.0.0.CR9
2013-07-02 11:41:09 +02:00
Norman Maurer
830c559405
[maven-release-plugin] rollback the release of netty-4.0.0.CR9
2013-07-02 11:34:29 +02:00
Norman Maurer
66a16b133c
[maven-release-plugin] prepare release netty-4.0.0.CR9
2013-07-02 10:45:12 +02:00
Trustin Lee
956c0f8b90
Better explanation of reentrance issue of ChannelOutboundBuffer
2013-07-02 17:22:56 +09:00
Norman Maurer
5437835832
[ #1501 ] Fix NPE correctly which could accour if ChannelOutboundBuffer.fail(..) triggered another call to ChannelOutboundBuffer.fail(...)
2013-07-02 09:58:41 +02:00
Norman Maurer
8dfbcbda29
[ #1501 ] Fix NPE which could accour if ChannelOutboundBuffer.fail(..) triggered another call to ChannelOutboundBuffer.fail(...)
2013-07-02 09:32:34 +02:00
Trustin Lee
7e3a01cc51
[maven-release-plugin] prepare for next development iteration
2013-07-02 10:26:48 +09:00
Trustin Lee
149db34c19
[maven-release-plugin] prepare release netty-4.0.0.CR8
2013-07-02 10:26:32 +09:00
Trustin Lee
efd9c94775
Use higher maxMessagesPerRead as default for ServerChannels
...
- Fixes #1493
2013-07-02 10:20:15 +09:00
Trustin Lee
26b56d3add
Fix a bug in MessageList.add(T[])
...
- where it uses incorrect source index while iteration
2013-07-02 10:11:17 +09:00
Trustin Lee
720de2e6cc
Add missing sanity check for DefaultChannelHandlerContext.write(...)
2013-07-02 09:36:01 +09:00
Trustin Lee
4b11aff08f
Less confusing log messages for system properties
...
- Fixes #1502
2013-07-02 09:23:29 +09:00
Norman Maurer
5d88c423df
[ #1500 ] Remove @deprecated methods
2013-07-01 08:53:02 +02:00
Norman Maurer
617ab6321b
[ #1489 ] Correctly handle channelReadSuspended and channelWritabilityChanged in CombinedChannelDuplexHandler
2013-06-30 17:18:33 +02:00
Trustin Lee
613547b0b9
[maven-release-plugin] prepare for next development iteration
2013-06-28 22:15:33 +09:00
Trustin Lee
a6abd2feb2
[maven-release-plugin] prepare release netty-4.0.0.CR7
2013-06-28 22:15:20 +09:00
Trustin Lee
ea963c25c9
Improve Javadoc of ChannelPipeline
...
- Fixes #1226
2013-06-28 22:09:00 +09:00
Trustin Lee
5f1aa6afde
Remove potentially misleading exception message
...
.. because the MessageList itself is not read-only.
2013-06-28 21:25:15 +09:00
Trustin Lee
591dce565a
checkExclusive() -> checkIndex()
2013-06-28 21:17:18 +09:00
Trustin Lee
d4665f1703
Fix test failures
2013-06-28 21:14:23 +09:00
Trustin Lee
1e0146da3e
Optimize MessageList.add(MessageList, int, int)
2013-06-28 20:53:57 +09:00
Trustin Lee
7cf88a1a3c
Add MessageList.array() / Rewrite MessageList.add(T[], int, int)
...
- MessageList.array() should give better performance + concise code
- MessageList.add(T[], int, int) iterated over the source array 3 times at worst case. This commit reduces that to 1 time.
2013-06-28 20:47:19 +09:00
Trustin Lee
0dcf352f4c
Vastly simplified ByteBufProcessor and MessageListProcessor
...
- Related: #1378
- They now accept only one argument.
- A user who wants to use a buffer for more complex use cases, he or she can always access the buffer directly via memoryAddress() and array()
2013-06-28 20:29:00 +09:00
Trustin Lee
52691488ee
Update Javadoc of ByteBufProcessor and MessageListProcessor
...
- in response to @shacharo's suggestion
2013-06-27 19:01:01 +09:00
Trustin Lee
4dd9b6ef2e
Add ByteBufProcessor and ByteBuf.forEach(...)
...
- Fixes #1378
- Needs to provide optimized forEach implementations though.
2013-06-27 13:55:42 +09:00
Trustin Lee
734ec51ac9
Allow specifying 0 as the default number of threads when instantiating an EventLoopGroup
...
- Fixes #1426
- We already allow a user instantiate an EventLoopGroup with the default number of threads via the default constructor, so I think it's OK although it's not always optimal.
2013-06-27 10:39:39 +09:00
Trustin Lee
bc483724f4
Improve the documentation of MessageList
...
- Fixes #1459
2013-06-25 18:27:29 +09:00
Trustin Lee
1f27c3b390
Make NioByteUnsafe.read() respect ChannelConfig.maxMessagesPerRead and adjust the default from 16 to 1
...
- Fixes #1486
- Decreased the default from 16 to 1 because unnecessary extra read on req-res protocols results in lower throughput due to extra syscalls.
2013-06-25 18:08:39 +09:00
Trustin Lee
a1632e7d15
Add ChannelConfig.maxMessagesPerRead and ChannelOption.MAX_MESSAGES_PER_READ
...
- Fixes #1486
- Make sure AbstractNioMessageChannel.NioMessageUnsafe.read() only up to maxMessagesPerRead
2013-06-25 17:49:28 +09:00
Trustin Lee
a6795d7780
[maven-release-plugin] prepare for next development iteration
2013-06-25 11:07:15 +09:00
Trustin Lee
2221446425
[maven-release-plugin] prepare release netty-4.0.0.CR6
2013-06-25 11:07:15 +09:00
Trustin Lee
c77f03d886
Fix AdaptiveRecvByteBufAllocator.getSizeTableIndex()
2013-06-25 11:07:15 +09:00
Norman Maurer
c9d01b2fb5
[ #1461 ] Correctly handle DefaultChannelGroup.write(..) of ByteBuf and ByteBufHolder
2013-06-25 11:07:14 +09:00
Trustin Lee
cfb3b977a1
Fix the catastrophic failure caused by AdaptiveRecvByteBufAllocator.getSizeTableIndex()
2013-06-25 11:07:14 +09:00
Trustin Lee
a2f232720b
Make AdaptiveRecvByteBufAllocator's lookup table simpler / Optimize buffer size normalization
...
- No need to have fine-grained lookup table because the buffer pool has
much more coarse capacities available
- No need to use a loop to normalize a buffer capacity
2013-06-25 11:07:14 +09:00
Trustin Lee
a969613540
Merge ChannelInboundConsumingHandler into SimpleChannelInboundHandler
...
- SimpleChannelInboundHandler now has a constructor parameter to let a
user decide to enable automatic message release. (the default is to
enable), which makes ChannelInboundConsumingHandler of less value.
2013-06-25 11:07:14 +09:00
Norman Maurer
bfc9c6d80d
Add ChannelInboundConsumingHandler
...
..which is useful when the handler is placed at the last position of the
pipeline because it releases the received messages automatically.
2013-06-25 11:07:14 +09:00
Tony Rice
6c5c119f8c
Fix incorrect parameter validation in DefaultFileRegion
2013-06-25 11:07:14 +09:00
Norman Maurer
cce74efded
[ #1448 ] Don't print failure if VoidChannelPromise is used
2013-06-16 14:25:02 +02:00
Norman Maurer
6a9f965f9b
Introduce new utility class calles ReferenceCountUtil and move utility methods from ByteBufUtil to it.
...
The ones in ByteBufUtil were marked as @deprecated
2013-06-14 07:07:33 +02:00
Norman Maurer
4bf5003f76
Don't release messages before throw UnsupportedOperationException, as the caller method will take care
2013-06-14 06:41:27 +02:00
Trustin Lee
a5871dfd86
[maven-release-plugin] prepare for next development iteration
2013-06-14 12:55:15 +09:00
Trustin Lee
f5377cc8d7
[maven-release-plugin] prepare release netty-4.0.0.CR5
2013-06-14 12:55:05 +09:00
Trustin Lee
fe40d4b67f
Make sure writing to a closed channel does not trigger an UnsupportedOperationException
...
- Fixes #1442
2013-06-14 11:15:46 +09:00
Trustin Lee
25c51279cf
Revert "[ #1442 ] Make sure closing the channel will not cause an UnsupportedOperationException"
...
This reverts commit a1a86b9de4
because the
semantic of ctx.isRemoved() is confusing to a user - why is
ctx.isRemoved() false when handlerRemoved() is invoked? A better
solution would be check if the connection is inactive and mark the
promise as failure before attempting to write anything.
2013-06-14 10:47:31 +09:00