Stop receiving requests

[Johnny Luong]

If you need to recover from a case where the application failed to
properly format the data or the transport fails to deliver the formatted
data to your application, then a binary length may not be enough and a
custom framing + timeout is probably what you would need.  My thinking
was that since you have a close available (like a tcp socket close) then
  you had an issue with the length being read...  So I was thinking that
you had a simpler problem rather than a somewhat pain in the ass
application state problem. :)

-Johnny

Shay Banon wrote:
> Not talking about a bogus length, talking about failure to deserialize the
> object "in the middle" and wanting to keep that connection open. In this
> case, you have to read the rest of the bytes up to the length otherwise the
> FrameDecoder will fall over and play dead.
> 
> shay.banon
> 
> On Thu, May 13, 2010 at 9:19 PM, Johnny Luong <
> johnny.luong at trustcommerce.com> wrote:
> 
>> Hi,
>>
>> Well I think the example pulls out the length for you and does the
>> mark/reset logic; the javadoc doesn't really say if you pass it a bogus
>> value like negative length but you would either see that as an exception
>> or possibly an empty frame which your application would handle in the
>> normal course of things.
>>
>> Best,
>> Johnny
>>
>>
>> Shay Banon wrote:
>>> So, I had a chat with trustin over IRC. You do need to skipBytes or
>>> reposition the reader index to the originalReaderIndex + length if in
>> your
>>> exception handler you don't close the connection.
>>>
>>> Shay
>>>
>>> On Thu, May 13, 2010 at 8:32 PM, Johnny Luong <
>>> johnny.luong at trustcommerce.com> wrote:
>>>
>>>> Class FrameDecoder;
>>>>
>>>>
>>>>
>> http://docs.jboss.org/netty/3.1/api/org/jboss/netty/handler/codec/frame/FrameDecoder.html
>>>>
>>>> Shay Banon wrote:
>>>>> Where is it exactly?
>>>>>
>>>>> On Thu, May 13, 2010 at 4:33 AM, Johnny Luong <
>>>>> johnny.luong at trustcommerce.com> wrote:
>>>>>
>>>>>> Hi Shay,
>>>>>>
>>>>>> I think the example provided in the javadoc under Decoder
>> Implementation
>>>>>> is what your trying to do and provides clarity...
>>>>>>
>>>>>> http://docs.jboss.org/netty/3.1/api/
>>>>>>
>>>>>> Best,
>>>>>> Johnny
>>>>>>
>>>>>>
>>>>>> Shay Banon wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>    I have a problem and am trying to find the best solution for. In
>>>>>> netty, I
>>>>>>> am using a FrameDecoder that simply does the following:
>>>>>>>
>>>>>>>     protected Object decode(ChannelHandlerContext ctx, Channel
>> channel,
>>>>>>> ChannelBuffer buffer) throws Exception {
>>>>>>>
>>>>>>>         if (buffer.readableBytes() < 4) {
>>>>>>>             return null;
>>>>>>>         }
>>>>>>>
>>>>>>>         int dataLen = buffer.getInt(buffer.readerIndex());
>>>>>>>         if (dataLen <= 0) {
>>>>>>>             throw new StreamCorruptedException("invalid data length:
>> "
>>>> +
>>>>>>> dataLen);
>>>>>>>         }
>>>>>>>
>>>>>>>         if (buffer.readableBytes() < dataLen + 4) {
>>>>>>>             return null;
>>>>>>>         }
>>>>>>>
>>>>>>>         buffer.skipBytes(4);
>>>>>>>
>>>>>>>         return buffer;
>>>>>>>     }
>>>>>>>
>>>>>>> On the next handler, I use the buffer to extract the request from
>> (and
>>>>>> other
>>>>>>> information). The problem I have is that something might fail and I
>>>> won't
>>>>>>> read the whole buffer. In this case, things gets corrupted for
>> requests
>>>>>> that
>>>>>>> follow. Once I do read the whole buffer, things works correctly. I
>> can
>>>>>>> skipBytes in the size of (writerIndex - readerIndex) in case of an
>>>>>>> exception, but then I wonder how does the built in ObjectDecoder
>>>> handles
>>>>>>> this case..., maybe I am missing something?
>>>>>>>
>>>>>>> cheers,
>>>>>>> shay.banon
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>> ------------------------------------------------------------------------
>>>>>>> _______________________________________________
>>>>>>> netty-users mailing list
>>>>>>> netty-users at lists.jboss.org
>>>>>>> https://lists.jboss.org/mailman/listinfo/netty-users
>>>>>> _______________________________________________
>>>>>> netty-users mailing list
>>>>>> netty-users at lists.jboss.org
>>>>>> https://lists.jboss.org/mailman/listinfo/netty-users
>>>>>>
>>>>>
>> ------------------------------------------------------------------------
>>>>> _______________________________________________
>>>>> netty-users mailing list
>>>>> netty-users at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/netty-users
>>>> _______________________________________________
>>>> netty-users mailing list
>>>> netty-users at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/netty-users
>>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> netty-users mailing list
>>> netty-users at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/netty-users
>> _______________________________________________
>> netty-users mailing list
>> netty-users at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/netty-users
>>
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users