Nabble - Netty Developer Group

My little announce

2009-11-22T03:28:11Z

Hi all,

I just want to share with all Netty team and users that I finally got my two projects into production this last week. All tests were passed with success, thanks to Netty which makes easier for us to develop our network tools.

The two main projects now in production are:

- OpenR66: a file transfer monitor, which can handle a lot of file transfer, restarting, including SSL and multiplexing of socket, a database support for monitoring (several JDBC database are supported). This project is more or less close to the CFT proprietary software (banking exchange) but does not implement the Pesit protocol (a new protocol was designed to be as possible efficient and secure).

Netty was quite impressive to help us to include all of the functionalities (specifically multiplexing, SSL, HTTP/HTTPS, bandwidth limitation usage) and of course its stability, memory usage, performance were quite important for us. The main development duration was about 2 months for the network model (mainly on multiplexing and HTTP support) and 3 months more for finishing the business model and fixing bugs.

- GoldenGate FTP (and its sub project Ftp Exec): a sort of passive gateway which can transform a FTP file transfer into another protocol or simply do a pre action (before RETRieve command) or post action (after STORe like commands). In our case, we use it to be able to receive from users that do not have a file transfer monitor (even simple PC), but have to transfer to a mainframe some files using FTP. The frontal FTP server written in java with Netty receive files from FTP then forward them to the mainframe using OpenR66.

Again, Netty was quite impressive too, specifically there for its facility to implement some special functionality in the "business" model (mixing Command and Data network connections in the business model). Contrary to other FTP server projects using NIO, both Command and Data connections are using Nio thanks to Netty. The main development duration was about 2 months for the network model and 1 months more for finishing the business model and fixing bugs.

You can have some picture (and a benchmark on the FTP server) on my home page: http://openr66.free.fr

I really want to thank you all, and of course with a special thank to Trustin!

Cheers,
Frederic

Hardware/Software Architect

Re: HttpCodec

2009-11-22T16:05:02Z

Thank you very much! I will do take a look as soon as I'm done with
Iain's HTTP tunneling transport. Obviously my backlog is getting
longer..

Regards

— Trustin Lee, http://gleamynode.net/

On Sun, Nov 22, 2009 at 8:09 PM, Frederic Bregier <[hidden email]> wrote:

>
> Hi Trustin,
>
> I try to follow as much as possible the change from the trunk.
> I saw another change in trunk, so I apply this to the branch too in order to
> make it easier for you to get the branch back into the trunk. ;-)
>
> Cheers,
> Frederic
>
>
> Frederic Bregier wrote:
>>
>> Hi Trustin,
>>
>> I've updated again the branch HttpPost with the last changes of the http
>> codec.
>>
>> I create a new snoop example named snoopPost in order to have two kinds of
>> example, one like the original one, and the other one using the Post
>> facilities proposed in the branch.
>>
>> I also updated the HttpChunkAggregator and HttpMessageDecoder by using
>> Composite buffers instead of dynamic, since dynamix are not necessary
>> there. But if you think this is bad, you can revert it. The main interest
>> is to allow to quickly consume bytes from HttpChunkAggregator or
>> HttpMessageDecoder, specialy when considering Post like File Upload. It
>> prevents as much as possible real copy by "composite" results.
>>
>> Also in HttpMessage and its DefaultHttpMessage impl, I added (was in the
>> branch already) some convenient methods (get/setHeaders and getCookies).
>>
>> I think it could be integrated in the 3.2 versions when you fill it ok.
>> Of course, there is also the other branch (trafficAndIpfilter) which I use
>> a lot the traffic one for a while now in all of my projects.
>>
>> HTH,
>> Cheers,
>> Frederic
>>
>
>
> -----
> Hardware/Software Architect
> --
> View this message in context: http://n2.nabble.com/HttpCodec-tp4042357p4045783.html
> Sent from the Netty Developer Group mailing list archive at Nabble.com.
> _______________________________________________
> netty-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/netty-dev
>

_______________________________________________
netty-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/netty-dev

— Trustin Lee, http://gleamynode.net/

Re: HttpCodec

2009-11-22T03:09:04Z

Hi Trustin,

I try to follow as much as possible the change from the trunk.
I saw another change in trunk, so I apply this to the branch too in order to make it easier for you to get the branch back into the trunk. ;-)

Cheers,
Frederic

Frederic Bregier wrote:

Hi Trustin,

I've updated again the branch HttpPost with the last changes of the http codec.

I create a new snoop example named snoopPost in order to have two kinds of example, one like the original one, and the other one using the Post facilities proposed in the branch.

I also updated the HttpChunkAggregator and HttpMessageDecoder by using Composite buffers instead of dynamic, since dynamix are not necessary there. But if you think this is bad, you can revert it. The main interest is to allow to quickly consume bytes from HttpChunkAggregator or HttpMessageDecoder, specialy when considering Post like File Upload. It prevents as much as possible real copy by "composite" results.

Also in HttpMessage and its DefaultHttpMessage impl, I added (was in the branch already) some convenient methods (get/setHeaders and getCookies).

I think it could be integrated in the 3.2 versions when you fill it ok.
Of course, there is also the other branch (trafficAndIpfilter) which I use a lot the traffic one for a while now in all of my projects.

HTH,
Cheers,
Frederic

Hardware/Software Architect

HttpCodec

2009-11-21T03:57:15Z

Hi Trustin,

I've updated again the branch HttpPost with the last changes of the http codec.

I create a new snoop example named snoopPost in order to have two kinds of example, one like the original one, and the other one using the Post facilities proposed in the branch.

I also updated the HttpChunkAggregator and HttpMessageDecoder by using Composite buffers instead of dynamic, since dynamix are not necessary there. But if you think this is bad, you can revert it. The main interest is to allow to quickly consume bytes from HttpChunkAggregator or HttpMessageDecoder, specialy when considering Post like File Upload. It prevents as much as possible real copy by "composite" results.

Also in HttpMessage and its DefaultHttpMessage impl, I added (was in the branch already) some convenient methods (get/setHeaders and getCookies).

I think it could be integrated in the 3.2 versions when you fill it ok.
Of course, there is also the other branch (trafficAndIpfilter) which I use a lot the traffic one for a while now in all of my projects.

HTH,
Cheers,
Frederic

Hardware/Software Architect

[JBoss JIRA] Closed: (NETTY-255) Make CookieDecoder more robust

2009-11-19T01:47:29Z

[ https://jira.jboss.org/jira/browse/NETTY-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee closed NETTY-255.
-----------------------------

Resolution: Done

Done. The Google Analytics cookie is decoded without an error now.

> Make CookieDecoder more robust
> ------------------------------
>
> Key: NETTY-255
> URL: https://jira.jboss.org/jira/browse/NETTY-255
> Project: Netty
> Issue Type: Feature Request
> Components: Handler
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 3.2.0.ALPHA2
>
>
> The following Google Analytics cookie violates the RFC, but it should be decoded without an error:
> String source =
> "ARPT=LWUKQPSWRTUN04CKKJI; " +
> "kw-2E343B92-B097-442c-BFA5-BE371E0325A2=unfinished furniture; " +
> "__utma=48461872.1094088325.1258140131.1258140131.1258140131.1; " +
> "__utmb=48461872.13.10.1258140131; __utmc=48461872; " +
> "__utmz=48461872.1258140131.1.1.utmcsr=overstock.com|utmccn=(referral)|" +
> "utmcmd=referral|utmcct=/Home-Garden/Furniture/Clearance,/clearance,/32/dept.html";
> What's causing the problem is the comma (,) in the "__utmz" attribute. According to the relevant RFCs, the cookie value should not contain a comma or should be quoted. CookieDecoder considers comma as an attribute separator unless it appears as a part of a quoted string. Hence "/clearance,/32/dept.html" becomes an orphan.
> CookieDecoder could become more robust if it does not recognize commas and semicolons as attribute separators if it's impossible to decode the next entry.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

_______________________________________________
netty-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/netty-dev

[JBoss JIRA] Created: (NETTY-255) Make CookieDecoder more robust

2009-11-19T01:45:30Z

Make CookieDecoder more robust
------------------------------

Key: NETTY-255
URL: https://jira.jboss.org/jira/browse/NETTY-255
Project: Netty
Issue Type: Feature Request
Components: Handler
Reporter: Trustin Lee
Assignee: Trustin Lee
Fix For: 3.2.0.ALPHA2

The following Google Analytics cookie violates the RFC, but it should be decoded without an error:

String source =
"ARPT=LWUKQPSWRTUN04CKKJI; " +
"kw-2E343B92-B097-442c-BFA5-BE371E0325A2=unfinished furniture; " +
"__utma=48461872.1094088325.1258140131.1258140131.1258140131.1; " +
"__utmb=48461872.13.10.1258140131; __utmc=48461872; " +
"__utmz=48461872.1258140131.1.1.utmcsr=overstock.com|utmccn=(referral)|" +
"utmcmd=referral|utmcct=/Home-Garden/Furniture/Clearance,/clearance,/32/dept.html";

What's causing the problem is the comma (,) in the "__utmz" attribute. According to the relevant RFCs, the cookie value should not contain a comma or should be quoted. CookieDecoder considers comma as an attribute separator unless it appears as a part of a quoted string. Hence "/clearance,/32/dept.html" becomes an orphan.

CookieDecoder could become more robust if it does not recognize commas and semicolons as attribute separators if it's impossible to decode the next entry.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

_______________________________________________
netty-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/netty-dev

[JBoss JIRA] Updated: (NETTY-255) Make CookieDecoder more robust

2009-11-19T01:45:30Z

[ https://jira.jboss.org/jira/browse/NETTY-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee updated NETTY-255:
------------------------------

JBoss Forum Reference: http://n2.nabble.com/CookieDecoder-issues-with-Google-Analytics-tp4018428p4018428.html

[JBoss JIRA] Closed: (NETTY-254) Do not do lazy-initialization in dynamic buffer

2009-11-19T00:41:29Z

[ https://jira.jboss.org/jira/browse/NETTY-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee closed NETTY-254.
-----------------------------

Resolution: Done

Done. No more lazy initialization.

> Do not do lazy-initialization in dynamic buffer
> -----------------------------------------------
>
> Key: NETTY-254
> URL: https://jira.jboss.org/jira/browse/NETTY-254
> Project: Netty
> Issue Type: Bug
> Components: Buffer
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 3.2.0.ALPHA2
>
>
> Any newly created dynamic buffer has 0 capacity, and a new space is allocated on demand (i.e. lazily). However, this causes a lot of confusion to users. For example: The following code fails with IndexOutOfBoundsException:
> ChannelBuffer buf = ChannelBufers.dynamicBuffer(1500);
> buf.setIndex(0, 1000);
> where it should not fail because user asked for at least 1600 bytes. There's not much gain from the lazy initialization - it just gives user confusion, hence the internal buffer should be initialized immediately.

[JBoss JIRA] Updated: (NETTY-254) Do not do lazy-initialization in dynamic buffer

2009-11-19T00:39:29Z

[ https://jira.jboss.org/jira/browse/NETTY-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee updated NETTY-254:
------------------------------

Summary: Do not do lazy-initialization in dynamic buffer (was: ChannelBuffer.setIndex() fails with a dynamic buffer )
Description:
Any newly created dynamic buffer has 0 capacity, and a new space is allocated on demand (i.e. lazily). However, this causes a lot of confusion to users. For example: The following code fails with IndexOutOfBoundsException:

ChannelBuffer buf = ChannelBufers.dynamicBuffer(1500);
buf.setIndex(0, 1000);

where it should not fail because user asked for at least 1600 bytes. There's not much gain from the lazy initialization - it just gives user confusion, hence the internal buffer should be initialized immediately.

was:
The following code fails with IndexOutOfBoundsException:

ChannelBuffer buf = ChannelBufers.dynamicBuffer(1500);
buf.setIndex(0, 1000);

where it should not fail.

I'm not sure setIndex() should increase the capacity yet, but at least it should not fail when there's no need for capacity increment.

[JBoss JIRA] Created: (NETTY-254) ChannelBuffer.setIndex() fails with a dynamic buffer

2009-11-18T08:34:30Z

ChannelBuffer.setIndex() fails with a dynamic buffer
-----------------------------------------------------

Key: NETTY-254
URL: https://jira.jboss.org/jira/browse/NETTY-254
Project: Netty
Issue Type: Bug
Components: Buffer
Reporter: Trustin Lee
Assignee: Trustin Lee
Fix For: 3.2.0.ALPHA2

The following code fails with IndexOutOfBoundsException:

ChannelBuffer buf = ChannelBufers.dynamicBuffer(1500);
buf.setIndex(0, 1000);

where it should not fail.

I'm not sure setIndex() should increase the capacity yet, but at least it should not fail when there's no need for capacity increment.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

_______________________________________________
netty-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/netty-dev

Re: CookieDecoder issues with Google Analytics

2009-11-19T01:51:24Z

I've just checked in the fix for this issue.

Here's the related JIRA issue which describes how I fixed it:

https://jira.jboss.org/jira/browse/NETTY-255

And here's the JUnit test case:

http://fisheye.jboss.org/browse/Netty/trunk/src/test/java/org/jboss/netty/handler/codec/http/CookieDecoderTest.java?r1=1783&r2=1899

Could you please confirm my fix works for you? Get the build here:

http://hudson.jboss.org/hudson/view/Netty/job/netty/871/

This fix will not be included in 3.1 but in 3.2, as it's not really a
bug but really an improvement. You can backport the change by
yourself though.

Thanks!

— Trustin Lee, http://gleamynode.net/

On Thu, Nov 19, 2009 at 6:09 PM, Trustin Lee (이희승) <[hidden email]> wrote:

> The cookie violated the RFC because:
>
> 1) it does not have $Version attribute (see RFC 2109)
> 2) comma (,) is prohibited in a cookie value unless it's surrounded by
> double quotes (") (See the definition of 'token' in RFC 2068. value is
> either a token or a quoted string, and token cannot have comma.)
>
> I concur with you that we can't argue with Google anyway, so let me
> think of a good idea to make CookieDecoder more robust.
>
> Thanks!
>
> — Trustin Lee, http://gleamynode.net/
>
> On Tue, Nov 17, 2009 at 10:44 PM, Dave Siracusa
> <[hidden email]> wrote:
>>
>>
>>
>> Dave Siracusa wrote:
>>>
>>> I'm getting the following exception:
>>> java.lang.IllegalArgumentException: name contains one of the following
>>> prohibited characters: =,; \t\r\n\v\f: /clearance,/32/dept.html
>>> at
>>> org.jboss.netty.handler.codec.http.DefaultCookie.<init>(DefaultCookie.java:89)
>>> at
>>> org.jboss.netty.handler.codec.http.CookieDecoder.decode(CookieDecoder.java:129)
>>>
>>> Sample cookie:
>>> __utma=48461872.1094088325.1258140131.1258140131.1258140131.1
>>> __utmb=48461872.13.10.1258140131
>>> __utmc=48461872
>>>
>>> __utmz=48461872.1258140131.1.1.utmcsr=overstock.com|utmccn=(referral)|utmcmd=referral|utmcct=/Home-Garden/Furniture/Clearance,/clearance,/32/dept.html
>>>
>>> Google Analytics uses commas in their cookie value, and who can argue with
>>> Google.
>>>
>>> I looked at the w3c rfc 2109 and it appears (I guess) that ;, are
>>> legitimate delimiters.
>>> An excerpt from the rfc:
>>> The syntax for the header is:
>>> cookie = "Cookie:" cookie-version
>>> 1*((";" | ",") cookie-value)
>>> cookie-value = NAME "=" VALUE [";" path] [";" domain]
>>> cookie-version = "$Version" "=" value
>>> NAME = attr
>>> VALUE = value
>>> path = "$Path" "=" value
>>> domain = "$Domain" "=" value
>>>
>>> So do we ignore commas? Do we establish precedence with the first
>>> encountered delimiter and ignore the other?
>>>
>>> BTW - I didn't look at the cookeencoder.
>>>
>>>
>>
>> Via ReflectionToStringBuilder:
>> HttpRequest:org.jboss.netty.handler.codec.http.DefaultHttpRequest@6c8dc7fe[
>> method=GET
>> uri=/custom-wood-furniture.html
>> version=HTTP/1.1
>> headers={Accept=[image/gif, image/jpeg, image/pjpeg,
>> application/x-ms-application, application/vnd.ms-xpsdocument,
>> application/xaml+xml, application/x-ms-xbap, application/x-shockwave-flash,
>> application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword,
>> application/x-silverlight, */*], Accept-Encoding=[gzip, deflate],
>> Accept-Language=[en-us], Connection=[Keep-Alive],
>> Cookie=[ARPT=LWUKQPSWRTUN04CKKJI;
>> kw-2E343B92-B097-442c-BFA5-BE371E0325A2=unfinished furniture;
>> __utma=48461872.1094088325.1258140131.1258140131.1258140131.1;
>> __utmb=48461872.13.10.1258140131; __utmc=48461872;
>> __utmz=48461872.1258140131.1.1.utmcsr=overstock.com|utmccn=(referral)|utmcmd=referral|utmcct=/Home-Garden/Furniture/Clearance,/clearance,/32/dept.html],
>> Host=[gelcowoodcraft.yb-masked-domain.com],
>> Referer=[http://gelcowoodcraft.yb-masked-domain.com/finished-unfinished-furniture-accessories.html],
>> User-Agent=[Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0;
>> SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729;
>> OfficeLiveConnector.1.4; OfficeLivePatch.1.3; .NET CLR 3.0.30729)]}
>> content=BigEndianHeapChannelBuffer(ridx=0, widx=0, cap=0) ]
>>
>> --
>> View this message in context: http://n2.nabble.com/CookieDecoder-issues-with-Google-Analytics-tp4018428p4018612.html
>> Sent from the Netty Developer Group mailing list archive at Nabble.com.
>> _______________________________________________
>> netty-dev mailing list
>> [hidden email]
>> https://lists.jboss.org/mailman/listinfo/netty-dev
>>
>

_______________________________________________
netty-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/netty-dev

— Trustin Lee, http://gleamynode.net/

Re: CookieDecoder issues with Google Analytics

2009-11-19T01:09:01Z

The cookie violated the RFC because:

1) it does not have $Version attribute (see RFC 2109)
2) comma (,) is prohibited in a cookie value unless it's surrounded by
double quotes (") (See the definition of 'token' in RFC 2068. value is
either a token or a quoted string, and token cannot have comma.)

I concur with you that we can't argue with Google anyway, so let me
think of a good idea to make CookieDecoder more robust.

Thanks!

— Trustin Lee, http://gleamynode.net/

On Tue, Nov 17, 2009 at 10:44 PM, Dave Siracusa
<[hidden email]> wrote:

>
>
>
> Dave Siracusa wrote:
>>
>> I'm getting the following exception:
>> java.lang.IllegalArgumentException: name contains one of the following
>> prohibited characters: =,; \t\r\n\v\f: /clearance,/32/dept.html
>> at
>> org.jboss.netty.handler.codec.http.DefaultCookie.<init>(DefaultCookie.java:89)
>> at
>> org.jboss.netty.handler.codec.http.CookieDecoder.decode(CookieDecoder.java:129)
>>
>> Sample cookie:
>> __utma=48461872.1094088325.1258140131.1258140131.1258140131.1
>> __utmb=48461872.13.10.1258140131
>> __utmc=48461872
>>
>> __utmz=48461872.1258140131.1.1.utmcsr=overstock.com|utmccn=(referral)|utmcmd=referral|utmcct=/Home-Garden/Furniture/Clearance,/clearance,/32/dept.html
>>
>> Google Analytics uses commas in their cookie value, and who can argue with
>> Google.
>>
>> I looked at the w3c rfc 2109 and it appears (I guess) that ;, are
>> legitimate delimiters.
>> An excerpt from the rfc:
>> The syntax for the header is:
>> cookie = "Cookie:" cookie-version
>> 1*((";" | ",") cookie-value)
>> cookie-value = NAME "=" VALUE [";" path] [";" domain]
>> cookie-version = "$Version" "=" value
>> NAME = attr
>> VALUE = value
>> path = "$Path" "=" value
>> domain = "$Domain" "=" value
>>
>> So do we ignore commas? Do we establish precedence with the first
>> encountered delimiter and ignore the other?
>>
>> BTW - I didn't look at the cookeencoder.
>>
>>
>
> Via ReflectionToStringBuilder:
> HttpRequest:org.jboss.netty.handler.codec.http.DefaultHttpRequest@6c8dc7fe[
> method=GET
> uri=/custom-wood-furniture.html
> version=HTTP/1.1
> headers={Accept=[image/gif, image/jpeg, image/pjpeg,
> application/x-ms-application, application/vnd.ms-xpsdocument,
> application/xaml+xml, application/x-ms-xbap, application/x-shockwave-flash,
> application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword,
> application/x-silverlight, */*], Accept-Encoding=[gzip, deflate],
> Accept-Language=[en-us], Connection=[Keep-Alive],
> Cookie=[ARPT=LWUKQPSWRTUN04CKKJI;
> kw-2E343B92-B097-442c-BFA5-BE371E0325A2=unfinished furniture;
> __utma=48461872.1094088325.1258140131.1258140131.1258140131.1;
> __utmb=48461872.13.10.1258140131; __utmc=48461872;
> __utmz=48461872.1258140131.1.1.utmcsr=overstock.com|utmccn=(referral)|utmcmd=referral|utmcct=/Home-Garden/Furniture/Clearance,/clearance,/32/dept.html],
> Host=[gelcowoodcraft.yb-masked-domain.com],
> Referer=[http://gelcowoodcraft.yb-masked-domain.com/finished-unfinished-furniture-accessories.html],
> User-Agent=[Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0;
> SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729;
> OfficeLiveConnector.1.4; OfficeLivePatch.1.3; .NET CLR 3.0.30729)]}
> content=BigEndianHeapChannelBuffer(ridx=0, widx=0, cap=0) ]
>
> --
> View this message in context: http://n2.nabble.com/CookieDecoder-issues-with-Google-Analytics-tp4018428p4018612.html
> Sent from the Netty Developer Group mailing list archive at Nabble.com.
> _______________________________________________
> netty-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/netty-dev
>

_______________________________________________
netty-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/netty-dev

— Trustin Lee, http://gleamynode.net/

Re: CookieDecoder issues with Google Analytics

2009-11-17T05:44:53Z

Dave Siracusa wrote:

I'm getting the following exception:
java.lang.IllegalArgumentException: name contains one of the following prohibited characters: =,; \t\r\n\v\f: /clearance,/32/dept.html
at org.jboss.netty.handler.codec.http.DefaultCookie.<init>(DefaultCookie.java:89)
at org.jboss.netty.handler.codec.http.CookieDecoder.decode(CookieDecoder.java:129)

Sample cookie:
__utma=48461872.1094088325.1258140131.1258140131.1258140131.1
__utmb=48461872.13.10.1258140131
__utmc=48461872
__utmz=48461872.1258140131.1.1.utmcsr=overstock.com|utmccn=(referral)|utmcmd=referral|utmcct=/Home-Garden/Furniture/Clearance,/clearance,/32/dept.html

Google Analytics uses commas in their cookie value, and who can argue with Google.

I looked at the w3c rfc 2109 and it appears (I guess) that ;, are legitimate delimiters.
An excerpt from the rfc:
The syntax for the header is:
cookie = "Cookie:" cookie-version
1*((";" | ",") cookie-value)
cookie-value = NAME "=" VALUE [";" path] [";" domain]
cookie-version = "$Version" "=" value
NAME = attr
VALUE = value
path = "$Path" "=" value
domain = "$Domain" "=" value

So do we ignore commas? Do we establish precedence with the first encountered delimiter and ignore the other?

BTW - I didn't look at the cookeencoder.

Via ReflectionToStringBuilder:
HttpRequest:org.jboss.netty.handler.codec.http.DefaultHttpRequest@6c8dc7fe[
method=GET
uri=/custom-wood-furniture.html
version=HTTP/1.1
headers={Accept=[image/gif, image/jpeg, image/pjpeg, application/x-ms-application, application/vnd.ms-xpsdocument, application/xaml+xml, application/x-ms-xbap, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-silverlight, */*], Accept-Encoding=[gzip, deflate], Accept-Language=[en-us], Connection=[Keep-Alive],
Cookie=[ARPT=LWUKQPSWRTUN04CKKJI; kw-2E343B92-B097-442c-BFA5-BE371E0325A2=unfinished furniture; __utma=48461872.1094088325.1258140131.1258140131.1258140131.1; __utmb=48461872.13.10.1258140131; __utmc=48461872; __utmz=48461872.1258140131.1.1.utmcsr=overstock.com|utmccn=(referral)|utmcmd=referral|utmcct=/Home-Garden/Furniture/Clearance,/clearance,/32/dept.html], Host=[gelcowoodcraft.yb-masked-domain.com], Referer=[http://gelcowoodcraft.yb-masked-domain.com/finished-unfinished-furniture-accessories.html], User-Agent=[Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; Media Center PC 5.0; .NET CLR 3.5.30729; OfficeLiveConnector.1.4; OfficeLivePatch.1.3; .NET CLR 3.0.30729)]}
content=BigEndianHeapChannelBuffer(ridx=0, widx=0, cap=0) ]

Re: CookieDecoder issues with Google Analytics

2009-11-17T05:35:44Z

Hi Dave,

Could you post the full HTTP header?

Thanks in advance

— Trustin Lee, http://gleamynode.net/

On Tue, Nov 17, 2009 at 10:06 PM, Dave Siracusa
<[hidden email]> wrote:

>
> I'm getting the following exception:
> java.lang.IllegalArgumentException: name contains one of the following
> prohibited characters: =,; \t\r\n\v\f: /clearance,/32/dept.html
> at
> org.jboss.netty.handler.codec.http.DefaultCookie.<init>(DefaultCookie.java:89)
> at
> org.jboss.netty.handler.codec.http.CookieDecoder.decode(CookieDecoder.java:129)
>
> Sample cookie:
> __utma=48461872.1094088325.1258140131.1258140131.1258140131.1
> __utmb=48461872.13.10.1258140131
> __utmc=48461872
>
> __utmz=48461872.1258140131.1.1.utmcsr=overstock.com|utmccn=(referral)|utmcmd=referral|utmcct=/Home-Garden/Furniture/Clearance,/clearance,/32/dept.html
>
> Google Analytics uses commas in their cookie value, and who can argue with
> Google.
>
> I looked at the w3c rfc 2109 and it appears (I guess) that ;, are legitimate
> delimiters.
> An excerpt from the rfc:
> The syntax for the header is:
> cookie = "Cookie:" cookie-version
> 1*((";" | ",") cookie-value)
> cookie-value = NAME "=" VALUE [";" path] [";" domain]
> cookie-version = "$Version" "=" value
> NAME = attr
> VALUE = value
> path = "$Path" "=" value
> domain = "$Domain" "=" value
>
> So do we ignore commas? Do we establish precedence with the first
> encountered delimiter and ignore the other?
>
> BTW - I didn't look at the cookeencoder.
>
> --
> View this message in context: http://n2.nabble.com/CookieDecoder-issues-with-Google-Analytics-tp4018428p4018428.html
> Sent from the Netty Developer Group mailing list archive at Nabble.com.
> _______________________________________________
> netty-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/netty-dev
>

_______________________________________________
netty-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/netty-dev

— Trustin Lee, http://gleamynode.net/

CookieDecoder issues with Google Analytics

2009-11-17T05:06:49Z

I'm getting the following exception:
java.lang.IllegalArgumentException: name contains one of the following prohibited characters: =,; \t\r\n\v\f: /clearance,/32/dept.html
at org.jboss.netty.handler.codec.http.DefaultCookie.<init>(DefaultCookie.java:89)
at org.jboss.netty.handler.codec.http.CookieDecoder.decode(CookieDecoder.java:129)

Sample cookie:
__utma=48461872.1094088325.1258140131.1258140131.1258140131.1
__utmb=48461872.13.10.1258140131
__utmc=48461872
__utmz=48461872.1258140131.1.1.utmcsr=overstock.com|utmccn=(referral)|utmcmd=referral|utmcct=/Home-Garden/Furniture/Clearance,/clearance,/32/dept.html

Google Analytics uses commas in their cookie value, and who can argue with Google.

I looked at the w3c rfc 2109 and it appears (I guess) that ;, are legitimate delimiters.
An excerpt from the rfc:
The syntax for the header is:
cookie = "Cookie:" cookie-version
1*((";" | ",") cookie-value)
cookie-value = NAME "=" VALUE [";" path] [";" domain]
cookie-version = "$Version" "=" value
NAME = attr
VALUE = value
path = "$Path" "=" value
domain = "$Domain" "=" value

So do we ignore commas? Do we establish precedence with the first encountered delimiter and ignore the other?

BTW - I didn't look at the cookeencoder.

[JBoss JIRA] Commented: (NETTY-253) Add several usefull getters and setters to ChannelBuffer class

2009-11-17T04:14:29Z

[ https://jira.jboss.org/jira/browse/NETTY-253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12494974#action_12494974 ]

Tuomas Kiviaho commented on NETTY-253:
--------------------------------------

I would be delighted if java.nio.charset.Charset would be added to the list although this request isn't amongst ByteBuffer methods. Currently toString() only accepts string value but at implementation level String generation would allow direct usage of Charset (thus not swallowing possible UnsupportedEncodingException).

> Add several usefull getters and setters to ChannelBuffer class
> --------------------------------------------------------------
>
> Key: NETTY-253
> URL: https://jira.jboss.org/jira/browse/NETTY-253
> Project: Netty
> Issue Type: Feature Request
> Components: Core API
> Affects Versions: 3.1.5.GA
> Reporter: Ruslan Shostak
> Assignee: Trustin Lee
>
> The proposal is to implement the following methods in ChannelBuffer.
> (comments taken from ByteBuffer class (http://java.sun.com/j2se/1.5.0/docs/api/java/nio/ByteBuffer.html)
> 1) getChar()
> Reads the next two bytes at this buffer's current position
> 2) getFloat()
> Reads the next four bytes at this buffer's current position,
> composing them into a float value according to the current byte order,
> and then increments the position by four.
> 3) getDouble()
> Reads the next eight bytes at this buffer's current position,
> composing them into a double value according to the current byte order,
> and then increments the position by eight.
> 4) putChar()
> Relative put method for writing a char value
> -putFloat()
> Writes four bytes containing the given float value, in the current byte order, into this buffer at the given index.
> 5) putDouble()
> Writes eight bytes containing the given double value, in the current byte order, into this buffer at the current position, and then increments the position by eight.
> 6) array()
> Returns the byte array that backs this buffer

[JBoss JIRA] Created: (NETTY-253) Add several usefull getters and setters to ChannelBuffer class

2009-11-17T02:33:29Z

Add several usefull getters and setters to ChannelBuffer class
--------------------------------------------------------------

Key: NETTY-253
URL: https://jira.jboss.org/jira/browse/NETTY-253
Project: Netty
Issue Type: Feature Request
Components: Core API
Affects Versions: 3.1.5.GA
Reporter: Ruslan Shostak
Assignee: Trustin Lee

The proposal is to implement the following methods in ChannelBuffer.
(comments taken from ByteBuffer class (http://java.sun.com/j2se/1.5.0/docs/api/java/nio/ByteBuffer.html)

1) getChar()
Reads the next two bytes at this buffer's current position
2) getFloat()
Reads the next four bytes at this buffer's current position,
composing them into a float value according to the current byte order,
and then increments the position by four.
3) getDouble()
Reads the next eight bytes at this buffer's current position,
composing them into a double value according to the current byte order,
and then increments the position by eight.
4) putChar()
Relative put method for writing a char value
-putFloat()
Writes four bytes containing the given float value, in the current byte order, into this buffer at the given index.
5) putDouble()
Writes eight bytes containing the given double value, in the current byte order, into this buffer at the current position, and then increments the position by eight.
6) array()
Returns the byte array that backs this buffer

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

_______________________________________________
netty-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/netty-dev

[JBoss JIRA] Closed: (NETTY-252) Remove the deprecated types and methods

2009-11-16T19:31:29Z

[ https://jira.jboss.org/jira/browse/NETTY-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee closed NETTY-252.
-----------------------------

Resolution: Done

> Remove the deprecated types and methods
> ---------------------------------------
>
> Key: NETTY-252
> URL: https://jira.jboss.org/jira/browse/NETTY-252
> Project: Netty
> Issue Type: Task
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 3.2.0.ALPHA2
>
>
> As discussed in the mailing list, the types and methods which were deprecated in 3.0 and 3.1 should be removed in 3.2.

[JBoss JIRA] Created: (NETTY-252) Remove the deprecated types and methods

2009-11-16T19:13:29Z

Remove the deprecated types and methods
---------------------------------------

Key: NETTY-252
URL: https://jira.jboss.org/jira/browse/NETTY-252
Project: Netty
Issue Type: Task
Reporter: Trustin Lee
Assignee: Trustin Lee
Fix For: 3.2.0.ALPHA2

As discussed in the mailing list, the types and methods which were deprecated in 3.0 and 3.1 should be removed in 3.2.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

_______________________________________________
netty-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/netty-dev

[JBoss JIRA] Closed: (NETTY-251) Add support for HTTP trailing headers

2009-11-16T23:17:29Z

[ https://jira.jboss.org/jira/browse/NETTY-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee closed NETTY-251.
-----------------------------

Resolution: Done

HttpChunkTrailer (the subtype of HttpChunk) has been added to represent the trailer. HttpMessageDecoder now fully decodes the trailing headesr and generates a new HttpChunkTrailer that contains the decoded trailing headers.

> Add support for HTTP trailing headers
> -------------------------------------
>
> Key: NETTY-251
> URL: https://jira.jboss.org/jira/browse/NETTY-251
> Project: Netty
> Issue Type: Feature Request
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 3.2.0.ALPHA2
>
>
> The last HTTP chunk can have trailing headers which could be useful to provide additional information that could be computed from the content of the HTTP message, such as 'Content-MD5'. The current HttpMessageDecoder implementation simply discards the trailing headers, but they should be decoded correctly. The decoded trailer should be part of the last chunk, which means a new subtype of HttpChunk (or HttpPartialMessage) must be introduced to provide additional header access methods and to represent the end of the content.

[JBoss JIRA] Updated: (NETTY-251) Add support for HTTP trailing headers

2009-11-16T07:49:29Z

[ https://jira.jboss.org/jira/browse/NETTY-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee updated NETTY-251:
------------------------------

JBoss Forum Reference: http://n2.nabble.com/HttpMessageDecoder-Skip-the-footer-does-anyone-use-it-tp3948901p3964402.html

[JBoss JIRA] Created: (NETTY-251) Add support for HTTP trailing headers

2009-11-16T07:47:29Z

Add support for HTTP trailing headers
-------------------------------------

Key: NETTY-251
URL: https://jira.jboss.org/jira/browse/NETTY-251
Project: Netty
Issue Type: Feature Request
Reporter: Trustin Lee
Assignee: Trustin Lee
Fix For: 3.2.0.ALPHA2

The last HTTP chunk can have trailing headers which could be useful to provide additional information that could be computed from the content of the HTTP message, such as 'Content-MD5'. The current HttpMessageDecoder implementation simply discards the trailing headers, but they should be decoded correctly. The decoded trailer should be part of the last chunk, which means a new subtype of HttpChunk (or HttpPartialMessage) must be introduced to provide additional header access methods and to represent the end of the content.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

_______________________________________________
netty-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/netty-dev

[JBoss JIRA] Closed: (NETTY-250) HttpMessageDecoder violates HTTP/1.0 by converting a message into chunked encoding

2009-11-16T23:53:29Z

[ https://jira.jboss.org/jira/browse/NETTY-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee closed NETTY-250.
-----------------------------

Resolution: Done

HttpMessageDecoder does not add or update the Transfer-Encoding header anymore. Instead, HttpMessage maintains an additional boolean flag to determine if the content is being split.

I did not rename HttpMessage.isChunked() and HttpChunk yet because I don't like the proposed names. Javadoc has been updated to reflect the changes related with this issue for less confusion. Please feel free to suggest the better names for HttpMessage.isChunked(), HttpChunk, and HttpChunkTrailer.

There's no need for user code change regarding this issue as long as the user uses HttpMessage.isChunked() to determine the transfer encoding rather than scanning the header manually.

> HttpMessageDecoder violates HTTP/1.0 by converting a message into chunked encoding
> ----------------------------------------------------------------------------------
>
> Key: NETTY-250
> URL: https://jira.jboss.org/jira/browse/NETTY-250
> Project: Netty
> Issue Type: Bug
> Components: Handler
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 3.2.0.ALPHA2
>
>
> If HttpMessageDecoder encounters a message with large content, it automatically converts the message into chunked encoding by 1) adding 'Transfer-Encoding: chunked' header and 2) splitting the content into multiple HttpChunk messages. However, this behavior violates the HTTP/1.0 specification because there's no chunked encoding in HTTP/1.0 - it's introduced in 1.1.
> To address this issue:
> 1) HttpMessageDecoder should not add or alter the 'Transfer-Encoding' header, so that the original headers are retained,
> 2) HttpMessage.isChunked() should be replaced with HttpMessage.hasPartialContents()
> 3) HttpChunk has to be replaced with HttpPartialContent to detach the message model from the protocol encoding
> To support trailing headers, HttpChunk could be retained and some header manipulation and retrieval methods could be added there, but it needs to be resolved in another issue.

[JBoss JIRA] Created: (NETTY-250) HttpMessageDecoder violates HTTP/1.0 by converting a message into chunked encoding

2009-11-16T07:26:29Z

HttpMessageDecoder violates HTTP/1.0 by converting a message into chunked encoding
----------------------------------------------------------------------------------

Key: NETTY-250
URL: https://jira.jboss.org/jira/browse/NETTY-250
Project: Netty
Issue Type: Bug
Components: Handler
Reporter: Trustin Lee
Assignee: Trustin Lee
Fix For: 3.2.0.ALPHA2

If HttpMessageDecoder encounters a message with large content, it automatically converts the message into chunked encoding by 1) adding 'Transfer-Encoding: chunked' header and 2) splitting the content into multiple HttpChunk messages. However, this behavior violates the HTTP/1.0 specification because there's no chunked encoding in HTTP/1.0 - it's introduced in 1.1.

To address this issue:

1) HttpMessageDecoder should not add or alter the 'Transfer-Encoding' header, so that the original headers are retained,
2) HttpMessage.isChunked() should be replaced with HttpMessage.hasPartialContents()
3) HttpChunk has to be replaced with HttpPartialContent to detach the message model from the protocol encoding

To support trailing headers, HttpChunk could be retained and some header manipulation and retrieval methods could be added there, but it needs to be resolved in another issue.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

_______________________________________________
netty-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/netty-dev

[JBoss JIRA] Created: (NETTY-249) Suppress the sudden spike of the open file descriptor numbers on many short-living connections

2009-11-16T06:08:29Z

Suppress the sudden spike of the open file descriptor numbers on many short-living connections
----------------------------------------------------------------------------------------------

Key: NETTY-249
URL: https://jira.jboss.org/jira/browse/NETTY-249
Project: Netty
Issue Type: Feature Request
Components: Transport
Reporter: Trustin Lee
Assignee: Trustin Lee
Fix For: 3.2.0.ALPHA1

When a connection is closed and its selection key is cancelled, some selector provider does not release the file descriptor immediately but release it during the next Selector.select() call. This behavior can lead to sudden spike of open file descriptor numbers, which can result in the 'too many open files' error, because the actual number of open files can be multitude of the expected number of open files. Therefore, NioWorker and NioDatagramWorker must call Selector.selectNow() for every N cancelled keys so that the actual number of open files do not exceed (the number of the expected number of open files) + N.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

_______________________________________________
netty-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/netty-dev

[JBoss JIRA] Closed: (NETTY-249) Suppress the sudden spike of the open file descriptor numbers on many short-living connections

2009-11-16T06:08:29Z

[ https://jira.jboss.org/jira/browse/NETTY-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee closed NETTY-249.
-----------------------------

Resolution: Done

Selector.selectNow() is called every 256 cancelled keys now. The value 256 is hard-coded, but should work in most circumstances.

> Suppress the sudden spike of the open file descriptor numbers on many short-living connections
> ----------------------------------------------------------------------------------------------
>
> Key: NETTY-249
> URL: https://jira.jboss.org/jira/browse/NETTY-249
> Project: Netty
> Issue Type: Feature Request
> Components: Transport
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 3.2.0.ALPHA1
>
>
> When a connection is closed and its selection key is cancelled, some selector provider does not release the file descriptor immediately but release it during the next Selector.select() call. This behavior can lead to sudden spike of open file descriptor numbers, which can result in the 'too many open files' error, because the actual number of open files can be multitude of the expected number of open files. Therefore, NioWorker and NioDatagramWorker must call Selector.selectNow() for every N cancelled keys so that the actual number of open files do not exceed (the number of the expected number of open files) + N.

Netty 3.2.0.ALPHA1 released: New Journey to the Next Level

2009-11-16T05:39:55Z

Hi folks,

Netty 3.2.0.ALPHA1, the first milestone in the 3.2 branch, has been released.

The Netty project is an effort to provide an asynchronous,
event-driven network application framework and tools for rapid
development of maintainable, high-performance, high-scalability
protocol servers and clients.

In other words, Netty is a NIO client server framework that enables
quick and easy development of network applications such as protocol
servers and clients. It simplifies and streamlines network programming
such as TCP and UDP socket servers

Please visit our web site to download it. Your feed back is more than
appreciated - please visit the discussion forum and leave some
comments and questions:

* http://www.jboss.org/netty/

Compression Handlers
====================
The ability to compress and decompress a connection transparently was
one of the early feature requests in Netty development. The
compression handlers introduced in this release add complete support
for both GZIP and ZLIB compression encoding, which is not found in any
other NIO application frameworks. For more information, please look
at the org.jboss.netty.handler.codec.compression package.

On top of the new compression handlers, HTTP content compression /
decompression support has been added, too. Please take a look at the
HTTP snoop client / server example for more information.

New Testimonial
===============
Dave Siracusa from Perfware LLC sent a nice testimonial for Netty
recently. You will find it very interesting; he succeeded to write an
HTTP server which is capable of processing 15,000 messages per second
on top of Netty. Check his recommendation and other testimonials
here: http://www.jboss.org/netty/testimonials.html

Upcoming Releases
=================
Although we did not add many new features in this first alpha, we have
bunch of new features planned, and they are all public in our issue
tracker and mailing list. Please feel free to join the discussion and
keep us updated with any ideas for new features, bugs, design issues,
API usability feed back, and questions - your idea is the future of
Netty!

Miscellaneous
=============
For the full changelog, please visit here:

* http://jira.jboss.org/jira/browse/NETTY

Cheers,
Trustin

— Trustin Lee, http://gleamynode.net/

_______________________________________________
netty-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/netty-dev

— Trustin Lee, http://gleamynode.net/

[JBoss JIRA] Closed: (NETTY-248) ChannelFuture of connect() operation is not notified if a user closes the channel explicitly.

2009-11-15T21:42:29Z

[ https://jira.jboss.org/jira/browse/NETTY-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee closed NETTY-248.
-----------------------------

Resolution: Done

Fixed in revision 1874 & 1875

> ChannelFuture of connect() operation is not notified if a user closes the channel explicitly.
> ---------------------------------------------------------------------------------------------
>
> Key: NETTY-248
> URL: https://jira.jboss.org/jira/browse/NETTY-248
> Project: Netty
> Issue Type: Bug
> Components: Transport
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 3.2.0.ALPHA1
>
>
> If a user closes the channel whose connection attempt is in progress, the ChannelFuture associated with the connection attempt is never notified. That is, the following code never finishes:
> ChannelFuture cf = bootstrap.connect();
> cf.getChannel().close();
> cf.awaitUninterruptibly(); // never returns
> The workaround is to cancel the connection attempt before closing the channel.
> ChannelFuture cf = bootstrap.connect();
> cf.cancel();
> cf.getChannel().close();

[JBoss JIRA] Created: (NETTY-248) ChannelFuture of connect() operation is not notified if a user closes the channel explicitly.

2009-11-15T21:39:29Z

ChannelFuture of connect() operation is not notified if a user closes the channel explicitly.
---------------------------------------------------------------------------------------------

Key: NETTY-248
URL: https://jira.jboss.org/jira/browse/NETTY-248
Project: Netty
Issue Type: Bug
Components: Transport
Reporter: Trustin Lee
Assignee: Trustin Lee
Fix For: 3.2.0.ALPHA1

If a user closes the channel whose connection attempt is in progress, the ChannelFuture associated with the connection attempt is never notified. That is, the following code never finishes:

ChannelFuture cf = bootstrap.connect();
cf.getChannel().close();
cf.awaitUninterruptibly(); // never returns

The workaround is to cancel the connection attempt before closing the channel.

ChannelFuture cf = bootstrap.connect();
cf.cancel();
cf.getChannel().close();

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

_______________________________________________
netty-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/netty-dev

Re: Removing deprecated types and methods

2009-11-11T19:57:10Z

+1

On Nov 11, 2009, at 7:46 PM, Trustin Lee (이희승) wrote:

> Hi folks,
>
> If there's no reasonable objection, I'd like to get rid of the types,
> methods, and configuration properties which were deprecated in 3.0.x
> and 3.1.x. Here's the list of deprecated entities:
>
> * About 20 methods in Channels
> * CompatibleObjectDecoder
> * ChannelConfig.writeTimeoutMillis
> * NioSocketChannelConfig.readWriteFair
>
> All of them except CompatibleObjectDecoder have replacement, so it
> should not hurt.
>
> CompatibleObjectDecoder has been deprecated because its implementation
> is broken with no known fix. I'm not sure it is a good idea to remove
> it without any compatible replacement. I'd like to retain it in the
> hope that a fix is found.
>
> Cheers
>
> — Trustin Lee, http://gleamynode.net/
>
> _______________________________________________
> netty-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/netty-dev

_______________________________________________
netty-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/netty-dev

Removing deprecated types and methods

2009-11-11T19:46:49Z

Hi folks,

If there's no reasonable objection, I'd like to get rid of the types,
methods, and configuration properties which were deprecated in 3.0.x
and 3.1.x. Here's the list of deprecated entities:

* About 20 methods in Channels
* CompatibleObjectDecoder
* ChannelConfig.writeTimeoutMillis
* NioSocketChannelConfig.readWriteFair

All of them except CompatibleObjectDecoder have replacement, so it
should not hurt.

CompatibleObjectDecoder has been deprecated because its implementation
is broken with no known fix. I'm not sure it is a good idea to remove
it without any compatible replacement. I'd like to retain it in the
hope that a fix is found.

Cheers

— Trustin Lee, http://gleamynode.net/

_______________________________________________
netty-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/netty-dev

— Trustin Lee, http://gleamynode.net/

[JBoss JIRA] Closed: (NETTY-247) Make HttpMessage, HttpChunk and their default implementation completely mutable

2009-11-19T20:20:30Z

[ https://jira.jboss.org/jira/browse/NETTY-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee closed NETTY-247.
-----------------------------

Resolution: Done

Done! I did not add the default constructors though because it results in the inconsistent state.

> Make HttpMessage, HttpChunk and their default implementation completely mutable
> -------------------------------------------------------------------------------
>
> Key: NETTY-247
> URL: https://jira.jboss.org/jira/browse/NETTY-247
> Project: Netty
> Issue Type: Feature Request
> Components: Handler
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 3.2.0.ALPHA2
>
>
> HttpMessage is a partially mutable type. There's no reason to keep the immutable properties immutable.
> HttpChunk is an immutable type. However, considering that it's being used in parallel with HttpMessage, it should also be mutable.

[JBoss JIRA] Updated: (NETTY-247) Make HttpMessage, HttpChunk and their default implementation completely mutable

2009-11-16T04:34:43Z

[ https://jira.jboss.org/jira/browse/NETTY-247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Trustin Lee updated NETTY-247:
------------------------------

Fix Version/s: 3.2.0.ALPHA2
(was: 3.2.0.ALPHA1)

[JBoss JIRA] Created: (NETTY-247) Make HttpMessage, HttpChunk and their default implementation completely mutable

2009-11-11T00:21:18Z

Make HttpMessage, HttpChunk and their default implementation completely mutable
-------------------------------------------------------------------------------

Key: NETTY-247
URL: https://jira.jboss.org/jira/browse/NETTY-247
Project: Netty
Issue Type: Feature Request
Components: Handler
Reporter: Trustin Lee
Assignee: Trustin Lee
Fix For: 3.2.0.ALPHA1

HttpMessage is a partially mutable type. There's no reason to keep the immutable properties immutable.
HttpChunk is an immutable type. However, considering that it's being used in parallel with HttpMessage, it should also be mutable.

--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

_______________________________________________
netty-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/netty-dev

Re: Multicast receiver issue

2009-11-23T01:33:22Z

Thank you very much Trustin, now the code works fine.

Regards, David

Trustin Lee wrote:

In your Netty code, you bound to the wrong port (0) while you bound to
the correct port (2222) in the old code. After changing 0 to 2222, it
works fine for me. Let me attach the working code for you.

— Trustin Lee, http://gleamynode.net/

_______________________________________________
netty-dev mailing list
netty-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/netty-dev