October 2008 - jboss-dev-forums - Jboss List Archives

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Netty HTTP transport

by trustin

"ataylor" wrote : How did you envisage this working from the client side, were you just going to build on top of URLConnection or one of the Http client API's or write something from scratch? The plan is to write a codec for both client and server side, which means we need two encoders and two decoders - HttpRequestEncoder, HttpResponseEncoder, HttpRequestDecoder and HttpResponseDecoder. So, it's writing something from scratch. Implementation of an encoder is pretty straighforward, but it's not for decoders. I think we can use ReplayingDecoder to minimize the decoder implementation time. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183750#4183750 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183750

16 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Netty HTTP transport

by trustin

Bad news: My local copy has gone. I can't find it anymore from my disk. *sigh* Here's what I have been doing to implement HTTP on top of Netty. 1) A codec is basically an implementation of the ChannelHandler interface. Therefore, HTTP codec classes should be placed in the org.jboss.netty.handler.codec.http package. 2) We should have at least three types: HttpRequest, HttpResponse and HttpMethod. HttpMethod should be an enum of all available HTTP methods like GET, POST, etc. HttpRequest and HttpResponse will represent an actual HTTP request and response respectively. They will provide essential getters that are required to implement an HTTP server and client. (We could add some convenience access methods like cookie accessors, but that's another story.) According to the HTTP spec, HTTP request and respose share a couple properties such as header, and therefore it would be a better idea to start from a super interface whose name is 'HttpMessage' IMHO. 3) There's no need to implement HTTP codec to support large chunk of data directly, which means a HttpRequest.getContent() can just return a complete ChannelBuffer instead of a special stream type. However, Chunked encoding should be supported instead to enable COMET, which will eventually allow us to use HTTP as a connection-oriented socket. (Bill Burke is also interested in this.) Supporting chunked encoding is an interesting problem though because the codec should generate additional messages to encode or decode the chunk which is not first. Probably we will need a new type to support chunked encoding, such as 'HttpChunk' and let the user (higher level HTTP client/server implementor) maintain the state by oneself. Once, this codec is ready, I think implementing a highly customized HTTP server shouldn't be difficult at all. WDYT? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183749#4183749 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183749

16 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Netty HTTP transport

by ataylor

How did you envisage this working from the client side, were you just going to build on top of URLConnection or one of the Http client API's or write something from scratch? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183747#4183747 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183747

16 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Ordering Group -- Transaction Scenario Analysis (Typical

by gaohoward

Correction: On XAResJms.rollback(), M1 will be PUT BACK to the ordering group and M2 stay blocked still. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183742#4183742 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183742

16 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Netty HTTP transport

by trustin

Good start. To write a HTTP codec, we need message classes that represents HTTP requests and responses. It will resemble that of Servlets, but it should be more user-friendly than that. Actually I have a draft implementation of the message model in my local copy. Let me check it in soon and ping here. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183740#4183740 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183740

16 years, 3 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Remoting 3: One-way requests are still the black sheep

by trustin

Who initiated the requirement for one-way messaging BTW? We could ask him/her/them first? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183739#4183739 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183739

16 years, 3 months

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Netty HTTP transport

by ataylor

A starter for 10. I guess the first thing we need is a Http Codec. I guess the codec just needs to decipher the headers and then the buffer content will be held in the body. Once we have the codec then we can build an engine that takes the http requests and translates into Netty Buffers. As mentioned on IRC we probably need to support the client both polling for responses and keeping the connection open but i guess it makes sense to concentrate on one or the other first. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183736#4183736 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183736

16 years, 3 months

1
0
0 / 0

[Design of EJB 3.0] - Re: EJB3 Core Release

by ALRubinger

I've released EJB3 Core 1.0.0-Beta5. Integration TestSuite now standing at 179 Failures. http://jboss.hudson.alrubinger.com/job/EJB3_Integration_TestSuite_AS_TRUN... S, ALR View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183723#4183723 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183723

16 years, 3 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Remoting 3: One-way requests are still the black sheep

by david.lloyd＠jboss.com

Well, modulo one slight correction. I want to remove it from Client now either way - the question would be to put them back now or later. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183708#4183708 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183708

16 years, 3 months

1
0
0 / 0

[Design of JBoss Remoting, Unified Invokers] - Re: Remoting 3: One-way requests are still the black sheep

by david.lloyd＠jboss.com

Yeah, that's basically what I meant. I become less coherent as my rant gains momentum. :) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4183707#4183707 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4183707

16 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums October 2008