Motivation:
Some duplicated methods in message types of codec-memcache can be cleaned using AbstractReferenceCounted.
Modifications:
Use AbstractReferenceCounted to avoid duplicated methods.
Result:
Duplicated methods are cleaned.
Motivation:
BinaryMemcacheObjectAggregator doesn't retain ByteBuf `extras`. So `io.netty.util.IllegalReferenceCountException: refCnt: 0, decrement: 1` will be thrown when aggregating a message containing `extras`. See the unit test for an example.
Modifications:
`ratain` extras to fix IllegalReferenceCountException.
Result:
`extras` is retained.
Motivation:
AbstractBinaryMemcacheDecoder.currentMessage is not retained after sending it out. Hence, if a message contains `extras`, `io.netty.util.IllegalReferenceCountException` will be thrown in `channelInactive`.
Modifications:
Retain AbstractBinaryMemcacheDecoder.currentMessage After putting it to `out` and release it when it's not used.
Result:
No IllegalReferenceCountException or leak.
Motivation
----------
Currently, only the fixed 24 bytes are allocated for the header and
then all the params as well as the optional extras and key are written
into the header section.
It is very likely that the buffer needs to expand at least two times
if either the extras and/or the key take up more space.
Modifications
-------------
Since at the point of allocation we know the key and extras length,
the buffer can be preallocated with the exact size, avoiding unnecessary
resizing and even allocating too much (since it uses power of two
internally).
Result
------
Less buffer resizing needed when encoding a memcache operation.
Motivation:
ChannelInboundHandler and ChannelOutboundHandler both can implement exceptionCaught(...) method and so we need to dispatch to both of them.
Modifications:
- Correctly first dispatch exceptionCaught to the ChannelInboundHandler but also make sure the next handler it will be dispatched to will be the ChannelOutboundHandler
- Add removeInboundHandler() and removeOutboundHandler() which allows to remove one of the combined handlers
- Let *Codec extends it and not ChannelHandlerAppender
- Remove ChannelHandlerAppender
Result:
Correctly handle events and also have same behavior as in 4.0
Motivation:
As part of merging / cherry-picking there were some Erroneous imports added to AbstractMemcacheObjectAggregator.
Modifications:
- Remove Imports from AbstractMemcacheObjectAggregator.
Result:
Code now builds.
Motivation:
The HttpObjectAggregator always responds with a 100-continue response. It should check the Content-Length header to see if the content length is OK, and if not responds with a 417.
Modifications:
- HttpObjectAggregator checks the Content-Length header in the case of a 100-continue.
Result:
HttpObjectAggregator responds with 417 if content is known to be too big.
Motivation:
Current AbstractMemcacheObjectEncoder does unnecessary message type checking if the message is MemcacheMessage type.
Modifications:
Returns after encoding MemcacheMessage message.
Result:
Small performance improvement for this encoder.
Related issue: #1133
Motivation:
There is no support for client socket connections via a proxy server in
Netty.
Modifications:
- Add a new module 'handler-proxy'
- Add ProxyHandler and its subclasses to support SOCKS 4a/5 and HTTP(S)
proxy connections
- Add a full parameterized test for most scenarios
- Clean up pom.xml
Result:
A user can make an outgoing connection via proxy servers with only
trivial effort.
If a connection is closed unexpectedly while
AbstractBinaryMemcacheDecoder decodes a message, the half-constructed
message's content might not be released.
Motivation:
Persuit for consistent method naming across all classes
Modifications:
Remove 'get' prefix for the getter methods in codec-memcache
Result:
More consistent method naming
Motivation:
DefaultFullBinaryMemcacheRequest/Response overrides release(), retain(),
and touch() methods without calling its super, resulting in a leak of
the extras.
Modifications:
When overriding release(), retain(), and touch(), ensure to call super.
Result:
Fixes#2533 by fixing the buffer leak
Motivation:
We have different message aggregator implementations for different
protocols, but they are very similar with each other. They all stems
from HttpObjectAggregator. If we provide an abstract class that provide
generic message aggregation functionality, we will remove their code
duplication.
Modifications:
- Add MessageAggregator which provides generic message aggregation
- Reimplement all existing aggregators using MessageAggregator
- Add DecoderResultProvider interface and extend it wherever possible so
that MessageAggregator respects the state of the decoded message
Result:
Less code duplication
Motivation:
4 and 5 were diverged long time ago and we recently reverted some of the
early commits in master. We must make sure 4.1 and master are not very
different now.
Modification:
Fix found differences
Result:
4.1 and master got closer.
Motivation:
When no currentMessage has been set and the channel is inactive, a NPE is raised.
Modification:
Make sure that a currentMessage is available before checking the extras.
Result:
No more NPE raised potentially.
This changeset removes the separate message headers and merges the
field directly into the messages. This greatly simplifies the
object hierachy and also saves header allocations in the pipeline.
This changeset is related to #2182, which exposes the failure in
the http codec, but the memcache codec works very similar. In addition,
better failure handling in the decoder has been added.
- Related: #2163
- Add ResourceLeakHint to allow a user to provide a meaningful information about the leak when touching it
- DefaultChannelHandlerContext now implements ResourceLeakHint to tell where the message is going.
- Cleaner resource leak report by excluding noisy stack trace elements
This changeset implements the full memcache binary protocol spec, including
a first batch of tests. Ascii protocol and more coverage and helper classes
will follow.
