Nabble - Netty Developer Group

Re: Volatile fields in the decoders

2009-11-07T09:23:56Z

Hi Trustin,

For me; I agree that most of the time, Codec are before ExecutionHandler.

In fact, I have no real idea of other cases, except, if I search the extreme case, when one wants to "pipeline" two kinds of channels, for instance:

"network-channel -> one codec -> execution handler -> business handler which writes on local-channel -> another codec -> another execution handler -> another business handler"

I do this to pipeline several "business" stream into one network-channel.

My guess is that probably there the codec for the local channel (the one in the middle named another codec) must be ok for multiple thread suport.

Perhaps not all codec are necessary for that.

Also I'm not completely sure that my example is a good one.. Just a guess more than an example...

WDYT ?

Frederic

----- Original Message -----

From: [hidden email]

To: [hidden email]

Sent: Saturday, November 07, 2009 3:47 PM

Subject: Volatile fields in the decoders

Hi folks,

Currently, all decoders distributed with Netty define their state
fields as volatile, because I assumed that the decoders might be
placed after ExecutionHandler. However, nobody seem to place them
after ExecutionHandler because decoding is a CPU bound task.
Therefore, I'd like to remove the volatile modifier if I did not miss
anything. Please feel free to post your idea - it will be very
helpful regardless whether it's agreement or disagreement.

Thanks

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

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

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

Hardware/Software Architect

Volatile fields in the decoders

2009-11-07T06:47:19Z

Hi folks,

Currently, all decoders distributed with Netty define their state
fields as volatile, because I assumed that the decoders might be
placed after ExecutionHandler. However, nobody seem to place them
after ExecutionHandler because decoding is a CPU bound task.
Therefore, I'd like to remove the volatile modifier if I did not miss
anything. Please feel free to post your idea - it will be very
helpful regardless whether it's agreement or disagreement.

Thanks

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

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

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

Adopting Generics into Netty API

2009-11-06T18:41:55Z

Hi folks,

I'm considering to adopt Java 5 Generics into Netty API. Please let
me know if you have any idea about this. Let's brainstorm and see
what we can do about this.

What I can think of right now is to eliminate explicit down-cast in
the handler by adding type parameter for received message type.

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/

Re: HttpMessageDecoder - Skip the footer; does anyone use it?

2009-11-07T07:00:17Z

Hi Roger,

Oh, there was really someone who uses it! :)

I will try to add support for trailing headers in 3.2. Your patch
does look very helpful. Thanks a lot!

Cheers

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

On Thu, Nov 5, 2009 at 7:52 AM, Roger F <[hidden email]> wrote:

>
> Hi Trustin Lee,
>
> I have been trying to use TrailingHeaders after a Content-Transfer: chunked
> message, obviously it does not work, yet.
>
> This would be useful to allow large files, size unknown, to be streamed in
> chunks, followed by the MD5.
> This ensures data integrity and prevents out of memory in a server.
>
> Here is an example :
>
> PUT / HTTP/1.1
> Host: localhost:8081
> Transfer-Encoding: chunked
> Trailer: Content-MD5
>
> 64
> 1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
> 0
> Content-MD5: 4f30805221b29b36df636869549398fb
>
>
>
> The following code changes allow TrailingHeaders and seem to work so far in
> testing.
>
> In HttpMessageDecoder replacing in the decode method the following switch
> state READ_CHUNK_FOOTER :
>
> @Override
> protected Object decode(ChannelHandlerContext ctx, Channel channel,
> ChannelBuffer buffer, State state) throws Exception {
>
> ....
>
> case READ_CHUNK_FOOTER: {
> // Do not Skip the footer; some people use it!
>
> try {
>
> readFooterHeaders(buffer);
>
> if (maxChunkSize == 0) {
> // Chunked encoding disabled.
> return reset();
> } else {
> reset();
> // The last chunk, which is empty
> return HttpChunk.LAST_CHUNK;
> }
> } finally {
> checkpoint();
> }
> }
>
> ...
>
>
> Then also in HttpMessageDecoder adding the following method :
>
> private void readFooterHeaders(ChannelBuffer buffer) throws
> TooLongFrameException {
> HttpFooterHeaders footerHeaders = new HttpFooterHeaders();
> headerSize = 0;
> String line = readHeader(buffer);
> String lastHeader = null;
> if (line.length() != 0) {
> do {
> char firstChar = line.charAt(0);
> if (lastHeader != null && (firstChar == ' ' || firstChar ==
> '\t')) {
> List<String> current = footerHeaders.getHeaders(lastHeader);
> int lastPos = current.size() - 1;
> String newString = current.get(lastPos) + line.trim();
> current.set(lastPos, newString);
> } else {
> String[] header = splitHeader(line);
> footerHeaders.addHeader(header[0], header[1]);
> lastHeader = header[0];
> }
>
> line = readHeader(buffer);
> } while (line.length() != 0);
> }
>
> Set<String> headerNames = footerHeaders.getHeaderNames();
> for (Iterator<String> it = headerNames.iterator(); it.hasNext();) {
> String headerName = it.next();
> List<String> headerValues = footerHeaders.getHeaders(headerName);
> for (String headerValue : headerValues) {
> message.addHeader(headerName, headerValue);
> }
>
> }
>
> }
>
>
> The following class needs to then be added to the package
> org.jboss.netty.handler.codec.http :
>
> package org.jboss.netty.handler.codec.http;
>
> import java.util.ArrayList;
> import java.util.Collections;
> import java.util.List;
> import java.util.Map;
> import java.util.Set;
> import java.util.TreeMap;
>
> import org.jboss.netty.util.internal.CaseIgnoringComparator;
>
> public class HttpFooterHeaders {
>
> private final Map<String, List<String>> headers = new TreeMap<String,
> List<String>>(CaseIgnoringComparator.INSTANCE);
>
> public HttpFooterHeaders() {
> }
>
> public void addHeader(final String name, final String value) {
> validateHeaderName(name);
> validateHeaderValue(value);
> if (value == null) {
> throw new NullPointerException("value is null");
> }
> //RFC2616 section 14.40 footer headers MUST NOT contain
> Transfer-Encoding, Content-Length or Trailer
> if (name.equalsIgnoreCase("Transfer-Encoding") ||
> name.equalsIgnoreCase("Content-Length") || name.equalsIgnoreCase("Trailer"))
> {
> return;
> }
> if (headers.get(name) == null) {
> headers.put(name, new ArrayList<String>(1));
> }
> headers.get(name).add(value);
> }
>
> private static void validateHeaderName(String name) {
> if (name == null) {
> throw new NullPointerException("name");
> }
> for (int i = 0; i < name.length(); i++) {
> char c = name.charAt(i);
> if (c > 127) {
> throw new IllegalArgumentException(
> "name contains non-ascii character: " + name);
> }
>
> // Check prohibited characters.
> switch (c) {
> case '=':
> case ',':
> case ';':
> case ' ':
> case ':':
> case '\t':
> case '\r':
> case '\n':
> case '\f':
> case 0x0b: // Vertical tab
> throw new IllegalArgumentException(
> "name contains one of the following prohibited
> characters: " +
> "=,;: \\t\\r\\n\\v\\f: " + name);
> }
> }
> }
>
> private static void validateHeaderValue(String value) {
> if (value == null) {
> throw new NullPointerException("value");
> }
> for (int i = 0; i < value.length(); i++) {
> char c = value.charAt(i);
> // Check prohibited characters.
> switch (c) {
> case '\r':
> case '\n':
> case '\f':
> case 0x0b: // Vertical tab
> throw new IllegalArgumentException(
> "value contains one of the following prohibited
> characters: " +
> "\\r\\n\\v\\f: " + value);
> }
> }
> }
>
> public List<String> getHeaders(final String name) {
> List<String> values = headers.get(name);
> if (values == null) {
> return Collections.emptyList();
> } else {
> return values;
> }
> }
>
> public Set<String> getHeaderNames() {
> return headers.keySet();
> }
> }
>
>
> This is probably not the best way as it duplicates some of the code from
> HttpMessage as the headers and methods are built into the class.
> The problem is then adding the trailing headers to the HttpMessage headers
> without clearing them.
> This is a quick fix, maybe you understand a better way to implement it.
>
> I've not found the way to send chunked data from the client side, will
> continue looking.
>
> Thanks for the effort you've done so far on NIO frameworks.
> We've been using Mina for a while now and it has been working very well.
> We are now migrating onto Netty and so far it looks like you have done an
> excellent job.
>
>
> Regards
> Roger F
> --
> View this message in context: http://n2.nabble.com/HttpMessageDecoder-Skip-the-footer-does-anyone-use-it-tp3948901p3948901.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/

HttpMessageDecoder - Skip the footer; does anyone use it?

2009-11-04T14:52:51Z

Hi Trustin Lee,

I have been trying to use TrailingHeaders after a Content-Transfer: chunked message, obviously it does not work, yet.

This would be useful to allow large files, size unknown, to be streamed in chunks, followed by the MD5.
This ensures data integrity and prevents out of memory in a server.

Here is an example :

PUT / HTTP/1.1
Host: localhost:8081
Transfer-Encoding: chunked
Trailer: Content-MD5

64
1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890
0
Content-MD5: 4f30805221b29b36df636869549398fb

The following code changes allow TrailingHeaders and seem to work so far in testing.

In HttpMessageDecoder replacing in the decode method the following switch state READ_CHUNK_FOOTER :

@Override
protected Object decode(ChannelHandlerContext ctx, Channel channel, ChannelBuffer buffer, State state) throws Exception {

....

case READ_CHUNK_FOOTER: {
// Do not Skip the footer; some people use it!

try {

readFooterHeaders(buffer);

if (maxChunkSize == 0) {
// Chunked encoding disabled.
return reset();
} else {
reset();
// The last chunk, which is empty
return HttpChunk.LAST_CHUNK;
}
} finally {
checkpoint();
}
}

...

Then also in HttpMessageDecoder adding the following method :

private void readFooterHeaders(ChannelBuffer buffer) throws TooLongFrameException {
HttpFooterHeaders footerHeaders = new HttpFooterHeaders();
headerSize = 0;
String line = readHeader(buffer);
String lastHeader = null;
if (line.length() != 0) {
do {
char firstChar = line.charAt(0);
if (lastHeader != null && (firstChar == ' ' || firstChar == '\t')) {
List<String> current = footerHeaders.getHeaders(lastHeader);
int lastPos = current.size() - 1;
String newString = current.get(lastPos) + line.trim();
current.set(lastPos, newString);
} else {
String[] header = splitHeader(line);
footerHeaders.addHeader(header[0], header[1]);
lastHeader = header[0];
}

line = readHeader(buffer);
} while (line.length() != 0);
}

Set<String> headerNames = footerHeaders.getHeaderNames();
for (Iterator<String> it = headerNames.iterator(); it.hasNext();) {
String headerName = it.next();
List<String> headerValues = footerHeaders.getHeaders(headerName);
for (String headerValue : headerValues) {
message.addHeader(headerName, headerValue);
}

}

}

The following class needs to then be added to the package org.jboss.netty.handler.codec.http :

package org.jboss.netty.handler.codec.http;

import java.util.ArrayList;
import java.util.Collections;
import java.util.List;
import java.util.Map;
import java.util.Set;
import java.util.TreeMap;

import org.jboss.netty.util.internal.CaseIgnoringComparator;

public class HttpFooterHeaders {

private final Map<String, List<String>> headers = new TreeMap<String, List<String>>(CaseIgnoringComparator.INSTANCE);

public HttpFooterHeaders() {
}

public void addHeader(final String name, final String value) {
validateHeaderName(name);
validateHeaderValue(value);
if (value == null) {
throw new NullPointerException("value is null");
}
//RFC2616 section 14.40 footer headers MUST NOT contain Transfer-Encoding, Content-Length or Trailer
if (name.equalsIgnoreCase("Transfer-Encoding") || name.equalsIgnoreCase("Content-Length") || name.equalsIgnoreCase("Trailer")) {
return;
}
if (headers.get(name) == null) {
headers.put(name, new ArrayList<String>(1));
}
headers.get(name).add(value);
}

private static void validateHeaderName(String name) {
if (name == null) {
throw new NullPointerException("name");
}
for (int i = 0; i < name.length(); i++) {
char c = name.charAt(i);
if (c > 127) {
throw new IllegalArgumentException(
"name contains non-ascii character: " + name);
}

// Check prohibited characters.
switch (c) {
case '=':
case ',':
case ';':
case ' ':
case ':':
case '\t':
case '\r':
case '\n':
case '\f':
case 0x0b: // Vertical tab
throw new IllegalArgumentException(
"name contains one of the following prohibited characters: " +
"=,;: \\t\\r\\n\\v\\f: " + name);
}
}
}

private static void validateHeaderValue(String value) {
if (value == null) {
throw new NullPointerException("value");
}
for (int i = 0; i < value.length(); i++) {
char c = value.charAt(i);
// Check prohibited characters.
switch (c) {
case '\r':
case '\n':
case '\f':
case 0x0b: // Vertical tab
throw new IllegalArgumentException(
"value contains one of the following prohibited characters: " +
"\\r\\n\\v\\f: " + value);
}
}
}

public List<String> getHeaders(final String name) {
List<String> values = headers.get(name);
if (values == null) {
return Collections.emptyList();
} else {
return values;
}
}

public Set<String> getHeaderNames() {
return headers.keySet();
}
}

This is probably not the best way as it duplicates some of the code from HttpMessage as the headers and methods are built into the class.
The problem is then adding the trailing headers to the HttpMessage headers without clearing them.
This is a quick fix, maybe you understand a better way to implement it.

I've not found the way to send chunked data from the client side, will continue looking.

Thanks for the effort you've done so far on NIO frameworks.
We've been using Mina for a while now and it has been working very well.
We are now migrating onto Netty and so far it looks like you have done an excellent job.

Regards
Roger F

[JBoss JIRA] Updated: (NETTY-246) New full duplex HTTP tunnel implementation (client and server)

2009-11-02T13:56:07Z

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

Iain McGinniss updated NETTY-246:
---------------------------------

Attachment: netty_http_firstcut_20091102

Patch for the new transport, based on trunk. As mentioned in the description the jmock tests do not work and therefore have been annotated with @Ignore.

> New full duplex HTTP tunnel implementation (client and server)
> --------------------------------------------------------------
>
> Key: NETTY-246
> URL: https://jira.jboss.org/jira/browse/NETTY-246
> Project: Netty
> Issue Type: Patch
> Components: Core API, Transport
> Environment: Cross platform addition. Does not yet work with an HTTP proxy, however this should be a trivial addition (for basic/digest authentication at least, NTLM is a different matter)
> Reporter: Iain McGinniss
> Assignee: Trustin Lee
> Attachments: netty_http_firstcut_20091102
>
>
> As a contributor to the JXTA peer to peer networking framework, I have been tasked with replacing the HTTP based transport that exists in JXTA. I had recently completed the work to rewrite the TCP based transport to use Netty, and felt it would be a good idea to use Netty for HTTP too. However, I found the existing HTTP tunnel to be unsatisfactory, mostly because it required a servlet container on the server side.
> As such, I have create a new full duplex HTTP tunnel using Netty's low level HTTP support. It has been tested in relatively simple setups to date and there are a number of known areas for improvement or fixing, as I would not yet consider myself to be an expert in Netty's inner workings. The implementation uses two TCP connections per channel (two SocketChannels, in fact), one used for sending data from client to server (the "send" channel), the other used for sending data from server to client (the "poll" channel). The technique used is known as Comet, and is necessary to allow usage via a proxy - something which has not yet been implemented but has been planned. There are other intricacies in the implementation, such as an enforced upper limit of 16KB per message body, which is intended to average out the per-byte throughput rather than delivering highly inconsistent payloads. It is debatable whether this works in practice, and is something I would encourage the wider co!

mmunity to discuss and help choose an appropriate threshold.
> Issues with the implementation:
> 1. No proxy support. This isn't difficult, but has not been implemented yet. If this hasn't been picked up by others in the community within the next week, I will likely implement this as a patch extension.
> 2. Poor connection close handling. The tunnel should be resilient to requests, forceful or polite, to close a connection that is servicing the tunnel. While HTTP 1.1 connections can be long lived, some proxies will close them frequently / at regular intervals.
> 3. Write fragmenting / aggregating. As mentioned above, an upper limit is imposed on the size of message bodies sent in each direction. While the implementation works enforcing the upper limit, it does not attempt to reaggregate smaller fragments into larger bodies. As a result, the size of the message body sent may be wastefully small when there is other data in the outgoing queue.
> 4. Dealing with the synchronous nature of HTTP. While HTTP 1.1 should allow pipelining and full duplex communications, most firewalls / proxies don't like this and therefore we should adhere to a strict request / response ordering. The implementation does this, but I am unsure whether the implementation is a good expression of this logic in netty.
> 5. Correct handling of the various event types in Netty. This is probably the part I am least comfortable with. I make an effort to honour the semantics of ChannelFutures on writes, and deal with bind/unbind/connect/disconnect, but I am unsure whether these are correct. In depth review would be greatly beneficial here.
> 6. Unit tests use jmock - jmock is what I am used to in previous projects, but I see EasyMock is the testing tool of choice here. The jmock tests do not appear to run well within maven build of Netty, so these tests may need to be rewritten using EasyMock to pass QA.
> I may think of other issues as time goes on, but for now it is probably best if we get some wider exposure of this work and some testing in environments other than my own.

--
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-246) New full duplex HTTP tunnel implementation (client and server)

2009-11-02T13:54:06Z

New full duplex HTTP tunnel implementation (client and server)
--------------------------------------------------------------

Key: NETTY-246
URL: https://jira.jboss.org/jira/browse/NETTY-246
Project: Netty
Issue Type: Patch
Components: Core API, Transport
Environment: Cross platform addition. Does not yet work with an HTTP proxy, however this should be a trivial addition (for basic/digest authentication at least, NTLM is a different matter)
Reporter: Iain McGinniss
Assignee: Trustin Lee

As a contributor to the JXTA peer to peer networking framework, I have been tasked with replacing the HTTP based transport that exists in JXTA. I had recently completed the work to rewrite the TCP based transport to use Netty, and felt it would be a good idea to use Netty for HTTP too. However, I found the existing HTTP tunnel to be unsatisfactory, mostly because it required a servlet container on the server side.

As such, I have create a new full duplex HTTP tunnel using Netty's low level HTTP support. It has been tested in relatively simple setups to date and there are a number of known areas for improvement or fixing, as I would not yet consider myself to be an expert in Netty's inner workings. The implementation uses two TCP connections per channel (two SocketChannels, in fact), one used for sending data from client to server (the "send" channel), the other used for sending data from server to client (the "poll" channel). The technique used is known as Comet, and is necessary to allow usage via a proxy - something which has not yet been implemented but has been planned. There are other intricacies in the implementation, such as an enforced upper limit of 16KB per message body, which is intended to average out the per-byte throughput rather than delivering highly inconsistent payloads. It is debatable whether this works in practice, and is something I would encourage the wider comm!
unity to discuss and help choose an appropriate threshold.

Issues with the implementation:

1. No proxy support. This isn't difficult, but has not been implemented yet. If this hasn't been picked up by others in the community within the next week, I will likely implement this as a patch extension.
2. Poor connection close handling. The tunnel should be resilient to requests, forceful or polite, to close a connection that is servicing the tunnel. While HTTP 1.1 connections can be long lived, some proxies will close them frequently / at regular intervals.
3. Write fragmenting / aggregating. As mentioned above, an upper limit is imposed on the size of message bodies sent in each direction. While the implementation works enforcing the upper limit, it does not attempt to reaggregate smaller fragments into larger bodies. As a result, the size of the message body sent may be wastefully small when there is other data in the outgoing queue.
4. Dealing with the synchronous nature of HTTP. While HTTP 1.1 should allow pipelining and full duplex communications, most firewalls / proxies don't like this and therefore we should adhere to a strict request / response ordering. The implementation does this, but I am unsure whether the implementation is a good expression of this logic in netty.
5. Correct handling of the various event types in Netty. This is probably the part I am least comfortable with. I make an effort to honour the semantics of ChannelFutures on writes, and deal with bind/unbind/connect/disconnect, but I am unsure whether these are correct. In depth review would be greatly beneficial here.
6. Unit tests use jmock - jmock is what I am used to in previous projects, but I see EasyMock is the testing tool of choice here. The jmock tests do not appear to run well within maven build of Netty, so these tests may need to be rewritten using EasyMock to pass QA.

I may think of other issues as time goes on, but for now it is probably best if we get some wider exposure of this work and some testing in environments other than my own.

--
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-245) More convenience methods in CodecEmbedder

2009-11-02T04:38:06Z

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

Trustin Lee closed NETTY-245.
-----------------------------

Resolution: Done

Done

> More convenience methods in CodecEmbedder
> -----------------------------------------
>
> Key: NETTY-245
> URL: https://jira.jboss.org/jira/browse/NETTY-245
> Project: Netty
> Issue Type: Feature Request
> Components: Handler
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 3.2.0.ALPHA1
>
>
> It is sometimes useful to get the number of products in the CodecEmbedder queue -> add CodecEmbedder.size()
> If the number of products is known, it's much simpler to iterate over the array of the product than to call poll() many times. -> add CodecEmbedder.pollAll(T[])

--
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-245) More convenience methods in CodecEmbedder

2009-11-02T04:01:05Z

More convenience methods in CodecEmbedder
-----------------------------------------

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

It is sometimes useful to get the number of products in the CodecEmbedder queue -> add CodecEmbedder.size()
If the number of products is known, it's much simpler to iterate over the array of the product than to call poll() many times. -> addCodecEmbedder.pollAll(T[])

--
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-245) More convenience methods in CodecEmbedder

2009-11-02T04:01:05Z

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

Trustin Lee updated NETTY-245:
------------------------------

Description:
It is sometimes useful to get the number of products in the CodecEmbedder queue -> add CodecEmbedder.size()
If the number of products is known, it's much simpler to iterate over the array of the product than to call poll() many times. -> add CodecEmbedder.pollAll(T[])

was:
It is sometimes useful to get the number of products in the CodecEmbedder queue -> add CodecEmbedder.size()
If the number of products is known, it's much simpler to iterate over the array of the product than to call poll() many times. -> addCodecEmbedder.pollAll(T[])

Re: A couple of questions about Netty internals

2009-11-03T05:02:05Z

Hi Mert,

On Tue, Nov 3, 2009 at 7:52 PM, Mert İnan <[hidden email]> wrote:
>
> Thank you Truntin.
>
> First i post to "Netty Developer Group", due to lack of response i thougth
> may be i posted to wrong group. So i posted to "Netty User Group" and tried
> to delete first post. but could not delete.
>
> which group should newbies should post?
> here i tried to ask my questions in more detail.

Actually, Netty User Group is the correct place, but I'm just fine. :)

> Trustin Lee wrote:
>>
>> Thanks for your interest in Netty, but please do not double-post.
>> Your second duplicate post has been discarded.
>>
>> On Mon, Nov 2, 2009 at 3:44 PM, Mert İnan <[hidden email]> wrote:
>>>
>>> Hi Netty Developer Group,
>>>
>>> i am trying to get confortable with Netty(3.1.5). Here are a couple of
>>> questions i come up with.
>>>
>>> 1. Data comes into netty, it goes up and down through handlers. There may
>>> be
>>> many ChannelUpstreamHandler and ChannelDownstreamHandler handlers. In all
>>> those handlers,in general, should i use Channels.fireMessageReceived only
>>> once? if so when? what happens if Channels.fireMessageReceived is called
>>> more then once in up handlers?
>>
>>
>> Trustin Lee wrote:
>>>
>>> There's no restriction on how many times an event should be generated
>>> by a handler. This means, you can generate as many as events as you
>>> want
>>>
>> For example A handler fires X message, B handler receices it. B converts X
>> to Y message.
>> in B hanler X's lifecycle is over, Y message must go on to upper handlers.
>> Bu i can not code this approach.
>>
>> I could not find a way to kill X and forward Y from where X left.

1) In handler A, you could call Channels.fireMessageReceived(...) with
the message X.
2) In handler B, you could convert X to Y and then call
Channels.fireMessageReceived(...) with the message Y.

I'm not sure this is what you are looking for because this is a very
typical configuration.

>>> 2. What should i do when my decoder constructed by more than one handler?
>>> Is
>>> it required that Decoder must be implemented in one handler?
>>
>>
>> Trustin Lee wrote:
>>>
>>> You can write a complex decoder with more than one handler. That is,
>>> you can combine multiple decoders to decode multi-layered protocols
>>> for example.
>>>
>>
>> how can i forward both the half decoded message and renaming buffer?
>> Should i encupsulate them in a new class for example?

Yes. You can encapsulate them in a new class. There might be other
ways, but I think it is simple and clean.

>>> 3. Why FrameDecoder.callDecode throws this Exception?
>>>
>>> throw new IllegalStateException(
>>> "decode() method must read at least one byte " +
>>> "if it returned a frame (caused by: " + getClass()
>>> +
>>> ")");
>>
>>
>> Trustin Lee wrote:
>>>
>>> Decoding, by definition, reads something from the input and produces
>>> the decoded data. Therefore, you cannot create something from
>>> nothing.
>>>
>>
>> I want to separete roles of framer and decoder. As you said decoder always
>> should read data.
>> But framer should not i guess. Framer must ensure that enough data is
>> received.
>> in my case, i want to ensure that enough data is received without actually
>> reading it and forward that data to decoder .

Yes, of course. That's how it is implemented. Could you take a look
into the telnet example? Also, take a look at the source code of
frame decoder and string decoder.

>> i hope i could express myself.
>>
>>
>> Trustin Lee wrote:
>>>
>>> HTH
>>>
>>> — Trustin Lee, http://gleamynode.net/
>>>
>>> _______________________________________________
>>> netty-dev mailing list
>>> [hidden email]
>>> https://lists.jboss.org/mailman/listinfo/netty-dev
>>>
>>
>
> --
> View this message in context: http://n2.nabble.com/A-couple-of-questions-about-Netty-internals-tp3930218p3937712.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
>

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

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

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

Re: A couple of questions about Netty internals

2009-11-03T02:52:49Z

Thank you Truntin.

First i post to "Netty Developer Group", due to lack of response i thougth may be i posted to wrong group. So i posted to "Netty User Group" and tried to delete first post. but could not delete.

which group should newbies should post?
here i tried to ask my questions in more detail.

Trustin Lee wrote:

Thanks for your interest in Netty, but please do not double-post.
Your second duplicate post has been discarded.

On Mon, Nov 2, 2009 at 3:44 PM, Mert İnan <inanme@yahoo.com> wrote:
>
> Hi Netty Developer Group,
>
> i am trying to get confortable with Netty(3.1.5). Here are a couple of
> questions i come up with.
>
> 1. Data comes into netty, it goes up and down through handlers. There may be
> many ChannelUpstreamHandler and ChannelDownstreamHandler handlers. In all
> those handlers,in general, should i use Channels.fireMessageReceived only
> once? if so when? what happens if Channels.fireMessageReceived is called
> more then once in up handlers?

Trustin Lee wrote:

There's no restriction on how many times an event should be generated
by a handler. This means, you can generate as many as events as you
want

For example A handler fires X message, B handler receices it. B converts X to Y message.
in B hanler X's lifecycle is over, Y message must go on to upper handlers.
Bu i can not code this approach.

I could not find a way to kill X and forward Y from where X left.

> 2. What should i do when my decoder constructed by more than one handler? Is
> it required that Decoder must be implemented in one handler?

Trustin Lee wrote:

You can write a complex decoder with more than one handler. That is,
you can combine multiple decoders to decode multi-layered protocols
for example.

how can i forward both the half decoded message and renaming buffer? Should i encupsulate them in a new class for example?

> 3. Why FrameDecoder.callDecode throws this Exception?
>
> throw new IllegalStateException(
> "decode() method must read at least one byte " +
> "if it returned a frame (caused by: " + getClass() +
> ")");

Trustin Lee wrote:

Decoding, by definition, reads something from the input and produces
the decoded data. Therefore, you cannot create something from
nothing.

I want to separete roles of framer and decoder. As you said decoder always should read data.
But framer should not i guess. Framer must ensure that enough data is received.
in my case, i want to ensure that enough data is received without actually reading it and forward that data to decoder .

i hope i could express myself.

Trustin Lee wrote:

HTH

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

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

Re: A couple of questions about Netty internals

2009-11-03T01:23:13Z

Thanks for your interest in Netty, but please do not double-post.
Your second duplicate post has been discarded.

On Mon, Nov 2, 2009 at 3:44 PM, Mert İnan <[hidden email]> wrote:

>
> Hi Netty Developer Group,
>
> i am trying to get confortable with Netty(3.1.5). Here are a couple of
> questions i come up with.
>
> 1. Data comes into netty, it goes up and down through handlers. There may be
> many ChannelUpstreamHandler and ChannelDownstreamHandler handlers. In all
> those handlers,in general, should i use Channels.fireMessageReceived only
> once? if so when? what happens if Channels.fireMessageReceived is called
> more then once in up handlers?

There's no restriction on how many times an event should be generated
by a handler. This means, you can generate as many as events as you
want

> 2. What should i do when my decoder constructed by more than one handler? Is
> it required that Decoder must be implemented in one handler?

You can write a complex decoder with more than one handler. That is,
you can combine multiple decoders to decode multi-layered protocols
for example.

> 3. Why FrameDecoder.callDecode throws this Exception?
>
> throw new IllegalStateException(
> "decode() method must read at least one byte " +
> "if it returned a frame (caused by: " + getClass() +
> ")");

Decoding, by definition, reads something from the input and produces
the decoded data. Therefore, you cannot create something from
nothing.

HTH

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

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

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

A couple of questions about Netty internals

2009-11-01T22:44:22Z

Hi Netty Developer Group,

i am trying to get confortable with Netty(3.1.5). Here are a couple of questions i come up with.

1. Data comes into netty, it goes up and down through handlers. There may be many ChannelUpstreamHandler and ChannelDownstreamHandler handlers. In all those handlers,in general, should i use Channels.fireMessageReceived only once? if so when? what happens if Channels.fireMessageReceived is called more then once in up handlers?

2. What should i do when my decoder constructed by more than one handler? Is it required that Decoder must be implemented in one handler?

3. Why FrameDecoder.callDecode throws this Exception?

throw new IllegalStateException(
"decode() method must read at least one byte " +
"if it returned a frame (caused by: " + getClass() + ")");

Thank you very much.

[JBoss JIRA] Closed: (NETTY-244) ReceiveBufferSizePredictorFactory

2009-11-01T22:37:05Z

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

Trustin Lee closed NETTY-244.
-----------------------------

Resolution: Done

ReceiveBufferSizePredictorFactory has been added as described above.

I did not deprecate get/setReceiveBufferSizePredictor() though because it is still useful when a user wants to switch the predictor dynamically.

> ReceiveBufferSizePredictorFactory
> ---------------------------------
>
> Key: NETTY-244
> URL: https://jira.jboss.org/jira/browse/NETTY-244
> Project: Netty
> Issue Type: Bug
> Components: Core API
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Fix For: 3.2.0.ALPHA1
>
>
> Configuring a ReceiveBufferSizePredictor using Bootstrap.setOption() is practically impossible because a stateful ReceiveBufferSizePredictor such as AdaptiveReceiveBufferSizePredictor must be instantiated for each channel. Hence, we need ReceiveBufferSizePredictorFactory so that the transport implementations create a new predictor for each new channel.
> Implementation plan: Calling config.setReceiveBufferSizePredictorFactory() will instantiate a new ReceiveBufferSizePredictor immediately and call config.setReceiveBufferSizePredictor() with the new predictor if no predictor has been configured yet. To avoid unnecessary instantiation of the default ReceiveBufferSizePredictor, it should be set to null by default and the default instance should be created in a lazy manner. Deprecate get/setReceiveBufferSizePredictor() and store predictor instances in the

[JBoss JIRA] Updated: (NETTY-244) ReceiveBufferSizePredictorFactory

2009-10-27T20:07:05Z

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

Trustin Lee updated NETTY-244:
------------------------------

Description:
Configuring a ReceiveBufferSizePredictor using Bootstrap.setOption() is practically impossible because a stateful ReceiveBufferSizePredictor such as AdaptiveReceiveBufferSizePredictor must be instantiated for each channel. Hence, we need ReceiveBufferSizePredictorFactory so that the transport implementations create a new predictor for each new channel.

Implementation plan: Calling config.setReceiveBufferSizePredictorFactory() will instantiate a new ReceiveBufferSizePredictor immediately and call config.setReceiveBufferSizePredictor() with the new predictor if no predictor has been configured yet. To avoid unnecessary instantiation of the default ReceiveBufferSizePredictor, it should be set to null by default and the default instance should be created in a lazy manner. Deprecate get/setReceiveBufferSizePredictor() and store predictor instances in the

was:
Configuring a ReceiveBufferSizePredictor using Bootstrap.setOption() is practically impossible because a stateful ReceiveBufferSizePredictor such as AdaptiveReceiveBufferSizePredictor must be instantiated for each channel. Hence, we need ReceiveBufferSizePredictorFactory so that the transport implementations create a new predictor for each new channel.

Implementation plan: Calling config.setReceiveBufferSizePredictorFactory() will instantiate a new ReceiveBufferSizePredictor immediately and call config.setReceiveBufferSizePredictor() with the new predictor. To avoid unnecessary instantiation of the default ReceiveBufferSizePredictor, it should be set to null by default and the default instance should be created in a lazy manner.

[JBoss JIRA] Created: (NETTY-244) ReceiveBufferSizePredictorFactory

2009-10-27T19:47:05Z

ReceiveBufferSizePredictorFactory
---------------------------------

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

Configuring a ReceiveBufferSizePredictor using Bootstrap.setOption() is practically impossible because a stateful ReceiveBufferSizePredictor such as AdaptiveReceiveBufferSizePredictor must be instantiated for each channel. Hence, we need ReceiveBufferSizePredictorFactory so that the transport implementations create a new predictor for each new channel.

Implementation plan: Calling config.setReceiveBufferSizePredictorFactory() will instantiate a new ReceiveBufferSizePredictor immediately and call config.setReceiveBufferSizePredictor() with the new predictor. To avoid unnecessary instantiation of the default ReceiveBufferSizePredictor, it should be set to null by default and the default instance should be created in a lazy manner.

--
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: New branch httpPost

2009-11-07T02:00:10Z

Hi Trustin,

It's done for httpPost branch.
Cheers,

Frederic

Frederic Bregier wrote:

Hi Trustin,

The branch was up to date from the very first version of trunk pre 3.2.
I will take a look into the trunk if some changes were done (at least one in the snoop example I see) in order update the branch to make it easier for you to get it back into the trunk when you think it is ready.

Cheers,
Frederic

Trustin Lee wrote:

Hi Frederic,

Thank you very much for another big chunk of contribution! :)

I will take a look soon and get back to you! Meanwhile, please watch
out for my changes in the trunk, which might need to be merged into
your branch.

Cheers

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

On Sun, Oct 25, 2009 at 8:31 AM, Frederic Bregier <fredbregier@free.fr> wrote:
>
> Hi Trustin,
>
> I finally managed to get the time to upload the branch httpPost which
> contains the coder end decoder for Post Request in Http and the enhanced
> snoop example.
>
> Except of course if some improvements are still needed, with the two
> branches out there (one with IpFilter and Traffic, the other one with
> HttpPost), I can go back to my production qualification of my two projects.
>
> Just to let you know that OpenR66 passes all tests, including long term,
> huge load and high speed, thanks to Netty... and you and all of Netty's
> users and contributors !
> Now its the turn of GoldenGate FTP...
>
> Thank you all !
>
> Cheers,
> Frederic
>
> -----
> Hardware/Software Architect
> --
> View this message in context: http://n2.nabble.com/New-branch-httpPost-tp3885879p3885879.html
> Sent from the Netty Developer Group mailing list archive at Nabble.com.
> _______________________________________________
> netty-dev mailing list
> netty-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-dev
>

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

Hardware/Software Architect

Re: New branch httpPost

2009-11-03T01:52:52Z

Hi Trustin,

The branch was up to date from the very first version of trunk pre 3.2.
I will take a look into the trunk if some changes were done (at least one in the snoop example I see) in order update the branch to make it easier for you to get it back into the trunk when you think it is ready.

Cheers,
Frederic

Trustin Lee wrote:

Hi Frederic,

Thank you very much for another big chunk of contribution! :)

I will take a look soon and get back to you! Meanwhile, please watch
out for my changes in the trunk, which might need to be merged into
your branch.

Cheers

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

On Sun, Oct 25, 2009 at 8:31 AM, Frederic Bregier <fredbregier@free.fr> wrote:
>
> Hi Trustin,
>
> I finally managed to get the time to upload the branch httpPost which
> contains the coder end decoder for Post Request in Http and the enhanced
> snoop example.
>
> Except of course if some improvements are still needed, with the two
> branches out there (one with IpFilter and Traffic, the other one with
> HttpPost), I can go back to my production qualification of my two projects.
>
> Just to let you know that OpenR66 passes all tests, including long term,
> huge load and high speed, thanks to Netty... and you and all of Netty's
> users and contributors !
> Now its the turn of GoldenGate FTP...
>
> Thank you all !
>
> Cheers,
> Frederic
>
> -----
> Hardware/Software Architect
> --
> View this message in context: http://n2.nabble.com/New-branch-httpPost-tp3885879p3885879.html
> Sent from the Netty Developer Group mailing list archive at Nabble.com.
> _______________________________________________
> netty-dev mailing list
> netty-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-dev
>

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

Hardware/Software Architect

Re: New branch httpPost

2009-11-03T00:40:00Z

Hi Frederic,

Thank you very much for another big chunk of contribution! :)

I will take a look soon and get back to you! Meanwhile, please watch
out for my changes in the trunk, which might need to be merged into
your branch.

Cheers

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

On Sun, Oct 25, 2009 at 8:31 AM, Frederic Bregier <[hidden email]> wrote:

>
> Hi Trustin,
>
> I finally managed to get the time to upload the branch httpPost which
> contains the coder end decoder for Post Request in Http and the enhanced
> snoop example.
>
> Except of course if some improvements are still needed, with the two
> branches out there (one with IpFilter and Traffic, the other one with
> HttpPost), I can go back to my production qualification of my two projects.
>
> Just to let you know that OpenR66 passes all tests, including long term,
> huge load and high speed, thanks to Netty... and you and all of Netty's
> users and contributors !
> Now its the turn of GoldenGate FTP...
>
> Thank you all !
>
> Cheers,
> Frederic
>
> -----
> Hardware/Software Architect
> --
> View this message in context: http://n2.nabble.com/New-branch-httpPost-tp3885879p3885879.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/

New branch httpPost

2009-10-24T16:31:41Z

Hi Trustin,

I finally managed to get the time to upload the branch httpPost which contains the coder end decoder for Post Request in Http and the enhanced snoop example.

Except of course if some improvements are still needed, with the two branches out there (one with IpFilter and Traffic, the other one with HttpPost), I can go back to my production qualification of my two projects.

Just to let you know that OpenR66 passes all tests, including long term, huge load and high speed, thanks to Netty... and you and all of Netty's users and contributors !
Now its the turn of GoldenGate FTP...

Thank you all !

Cheers,
Frederic

Hardware/Software Architect

[JBoss JIRA] Created: (NETTY-243) Make the HTTP tunneling transport firewall-friendly

2009-10-21T07:05:05Z

Make the HTTP tunneling transport firewall-friendly
---------------------------------------------------

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

The current HTTP tunneling transport implementation will not work with strict HTTP firewalls as it uses infinitely long connection. Some advanced technique which is similar to Comet/Bayeux must be applied.

--
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] Commented: (NETTY-242) contribution: asynchronous hessian rpc + hessian encoder/decoder

2009-10-22T06:46:05Z

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

rr zo commented on NETTY-242:
-----------------------------

Hello, I have signed the contributor license agreement just before adding this patch

> contribution: asynchronous hessian rpc + hessian encoder/decoder
> ----------------------------------------------------------------
>
> Key: NETTY-242
> URL: https://jira.jboss.org/jira/browse/NETTY-242
> Project: Netty
> Issue Type: Patch
> Reporter: rr zo
> Assignee: Trustin Lee
> Priority: Optional
> Attachments: netty_hessian.zip
>
>
> encoder/decoder for hessian serialization
> asynchronous hessian rpc with the following features:
> support for sessions
> synchronous + asynchronous client side proxies
> synchronous + asynchronous + continutations support for server side services
> this is a full functional initial release for evaluation and for feedbck.
> package name does not contain jboss.netty yet. this could be changed once the package name has been decided.

[JBoss JIRA] Commented: (NETTY-242) contribution: asynchronous hessian rpc + hessian encoder/decoder

2009-10-21T07:26:05Z

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

Trustin Lee commented on NETTY-242:
-----------------------------------

By the way, please sign the contributor license agreement so that I can merge your contribution to JBoss.org source code repository: http://www.jboss.org/contribute/
Please let me know when you finished sign-up - I will try to expedite the approval process.

[JBoss JIRA] Commented: (NETTY-242) contribution: asynchronous hessian rpc + hessian encoder/decoder

2009-10-21T07:20:20Z

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

Trustin Lee commented on NETTY-242:
-----------------------------------

This is a very interesting contribution. Thank you very much! I'll make sure to review it soon and get back to you.

[JBoss JIRA] Updated: (NETTY-242) contribution: asynchronous hessian rpc + hessian encoder/decoder

2009-10-20T11:08:07Z

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

rr zo updated NETTY-242:
------------------------

Attachment: netty_hessian.zip

[JBoss JIRA] Created: (NETTY-242) contribution: asynchronous hessian rpc + hessian encoder/decoder

2009-10-20T11:03:05Z

contribution: asynchronous hessian rpc + hessian encoder/decoder
----------------------------------------------------------------

Key: NETTY-242
URL: https://jira.jboss.org/jira/browse/NETTY-242
Project: Netty
Issue Type: Patch
Reporter: rr zo
Assignee: Trustin Lee
Priority: Optional

encoder/decoder for hessian serialization
asynchronous hessian rpc with the following features:

support for sessions
synchronous + asynchronous client side proxies
synchronous + asynchronous + continutations support for server side services

this is a full functional initial release for evaluation and for feedbck.
package name does not contain jboss.netty yet. this could be changed once the package name has been decided.

--
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: Fix branch to last version of trunk

2009-10-25T11:05:38Z

Hi,

I applied a small fix on Traffic handler.

Cheers,
Frederic

Frederic Bregier [via Netty Forums and Mailing Lists] a écrit :

> Hi,
>
> It's me again. In fact I recover my passwd, so I was able to remove
> the two olds branches that were unified in one branch.
>
> Cheers,
> Frederic
>
> Frederic Bregier wrote:
> Hi Trustin,
>
> I did not know how to update the two branches up to the last
> version of trunk, so I decided to create a new one from the last
> current version of Trunk named trafficAndIpFilter.
> It includes both Traffic and IpFilter branches updated to last
> version of trunk and it includes a fix on Traffic where a bug (not
> really a bug) occurs when we change the bandwitdh.
>
> The fix covers the following:
> - If the bandwidth is changed (for instance dramatically lower
> than previous), the previous computations on limitation is
> sometimes very slow to reopen the write or read commands.
> - So when a change on the limitations is done, the limitation
> computations are cleaned in order that new bandwitdh takes effect
> correctly immediately.
>
> I do not know how to delete the two previous branches (I need to
> get again my svn password since it is only stored in Eclipse right
> now).
> So could you delete the two previous branches (Filter and Traffic) ?
> Sorry for this... ;-(
>
> I will start on a new branch named HttpPost which will include the
> latest revision of Http codec plus the proposed evolution on Post.
>
> Cheers,
> Frederic
>
> Hardware/Software Architect
>
>
> ------------------------------------------------------------------------
> View message @
> http://n2.nabble.com/Fix-branch-to-last-version-of-trunk-tp3856835p3856885.html
>
> To unsubscribe from Fix branch to last version of trunk, click here
> <<Link Removed>>.
>
>

Hardware/Software Architect

Re: Fix branch to last version of trunk

2009-10-19T22:47:14Z

Hi,

It's me again. In fact I recover my passwd, so I was able to remove the two olds branches that were unified in one branch.

Cheers,
Frederic

Frederic Bregier wrote:

Hi Trustin,

I did not know how to update the two branches up to the last version of trunk, so I decided to create a new one from the last current version of Trunk named trafficAndIpFilter.
It includes both Traffic and IpFilter branches updated to last version of trunk and it includes a fix on Traffic where a bug (not really a bug) occurs when we change the bandwitdh.

The fix covers the following:
- If the bandwidth is changed (for instance dramatically lower than previous), the previous computations on limitation is sometimes very slow to reopen the write or read commands.
- So when a change on the limitations is done, the limitation computations are cleaned in order that new bandwitdh takes effect correctly immediately.

I do not know how to delete the two previous branches (I need to get again my svn password since it is only stored in Eclipse right now).
So could you delete the two previous branches (Filter and Traffic) ?
Sorry for this... ;-(

I will start on a new branch named HttpPost which will include the latest revision of Http codec plus the proposed evolution on Post.

Cheers,
Frederic

Hardware/Software Architect

Fix branch to last version of trunk

2009-10-19T22:31:24Z

Hi Trustin,

I did not know how to update the two branches up to the last version of trunk, so I decided to create a new one from the last current version of Trunk named trafficAndIpFilter.
It includes both Traffic and IpFilter branches updated to last version of trunk and it includes a fix on Traffic where a bug (not really a bug) occurs when we change the bandwitdh.

The fix covers the following:
- If the bandwidth is changed (for instance dramatically lower than previous), the previous computations on limitation is sometimes very slow to reopen the write or read commands.
- So when a change on the limitations is done, the limitation computations are cleaned in order that new bandwitdh takes effect correctly immediately.

I do not know how to delete the two previous branches (I need to get again my svn password since it is only stored in Eclipse right now).
So could you delete the two previous branches (Filter and Traffic) ?
Sorry for this... ;-(

I will start on a new branch named HttpPost which will include the latest revision of Http codec plus the proposed evolution on Post.

Cheers,
Frederic

Hardware/Software Architect

Re: Open Source

2009-10-21T20:06:56Z

Thanks Trustin. We will give this careful consideration but value
your opinion

Sent from my iPhone

On Oct 21, 2009, at 6:22 PM, Trustin Lee (이희승)
<[hidden email]> wrote:

> Hey Mike,
>
> First of all, good luck to your new open source project!
>
> As to license, I would prefer LGPL or ALv2 but you should research
> carefully to find the best one for you. Try to consult
> [hidden email] mailing list.
>
> HTH
>
> — Trustin Lee, http://gleamynode.net/
>
>
>
> On Tue, Oct 20, 2009 at 2:31 AM, Michael McGrady
> <[hidden email]> wrote:
>> To All and Especially Trustin:
>>
>> I am going to open source a mobile object (agent) technology called
>> KARMA (Kolona Automated Resource Management Architecture) with Netty
>> as the default transport. Is there any advice out there, especially
>> from Trustin, regarding the appropriate license?
>>
>> Mike
>>
>> Mike McGrady
>> Principal Investigator AF081-028 AFRL SBIR
>> Senior Engineer
>> Topia Technology, Inc
>> 1.253.720.3365
>> [hidden email]
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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

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

Re: Open Source

2009-10-21T18:22:02Z

Hey Mike,

First of all, good luck to your new open source project!

As to license, I would prefer LGPL or ALv2 but you should research
carefully to find the best one for you. Try to consult
[hidden email] mailing list.

HTH

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

On Tue, Oct 20, 2009 at 2:31 AM, Michael McGrady
<[hidden email]> wrote:

> To All and Especially Trustin:
>
> I am going to open source a mobile object (agent) technology called
> KARMA (Kolona Automated Resource Management Architecture) with Netty
> as the default transport. Is there any advice out there, especially
> from Trustin, regarding the appropriate license?
>
> Mike
>
> Mike McGrady
> Principal Investigator AF081-028 AFRL SBIR
> Senior Engineer
> Topia Technology, Inc
> 1.253.720.3365
> [hidden email]
>
>
>
>
>
>
>
> _______________________________________________
> 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/

Open Source

2009-10-19T10:31:22Z

To All and Especially Trustin:

I am going to open source a mobile object (agent) technology called
KARMA (Kolona Automated Resource Management Architecture) with Netty
as the default transport. Is there any advice out there, especially
from Trustin, regarding the appropriate license?

Mike

Mike McGrady
Principal Investigator AF081-028 AFRL SBIR
Senior Engineer
Topia Technology, Inc
1.253.720.3365
[hidden email]

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

[JBoss JIRA] Closed: (NETTY-241) Add more ChannelBufferFactory.getBuffer() methods for less memory bandwidth consumption

2009-10-15T21:53:05Z

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

Trustin Lee closed NETTY-241.
-----------------------------

Resolution: Done

Done.

> Add more ChannelBufferFactory.getBuffer() methods for less memory bandwidth consumption
> ---------------------------------------------------------------------------------------
>
> Key: NETTY-241
> URL: https://jira.jboss.org/jira/browse/NETTY-241
> Project: Netty
> Issue Type: Task
> Components: Buffer
> Reporter: Trustin Lee
> Assignee: Trustin Lee
> Priority: Minor
> Fix For: 3.2.0.ALPHA1
>
>
> When using ChannelBufferFactory to create a new buffer, there's no way to wrap a byte array other than making a copy. The default factory (HeapChannelBufferFactory) could simply wrap the array if the methods for this purpose are provided.
> Before:
> byte[] array = ...;
> ChannelBuffer buf = factory.getBuffer(array.length);
> buf.writeBytes(array);
> After:
> byte[] array = ...;
> ChannelBuffer buf = factory.getBuffer(array, 0, array.length);
> And the same could be applied for wrapping NIO ByteBuffers.

[JBoss JIRA] Created: (NETTY-241) Add more ChannelBufferFactory.getBuffer() methods for less memory bandwidth consumption

2009-10-15T21:27:05Z

Add more ChannelBufferFactory.getBuffer() methods for less memory bandwidth consumption
---------------------------------------------------------------------------------------

Key: NETTY-241
URL: https://jira.jboss.org/jira/browse/NETTY-241
Project: Netty
Issue Type: Task
Components: Buffer
Reporter: Trustin Lee
Assignee: Trustin Lee
Priority: Minor
Fix For: 3.2.0.ALPHA1

When using ChannelBufferFactory to create a new buffer, there's no way to wrap a byte array other than making a copy. The default factory (HeapChannelBufferFactory) could simply wrap the array if the methods for this purpose are provided.

Before:

byte[] array = ...;
ChannelBuffer buf = factory.getBuffer(array.length);
buf.writeBytes(array);

After:

byte[] array = ...;
ChannelBuffer buf = factory.getBuffer(array, 0, array.length);

And the same could be applied for wrapping NIO ByteBuffers.

--
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