You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Rick McGuire <ri...@gmail.com> on 2008/02/01 19:35:55 UTC
Re: [AsyncHttpClient] On bringing the code bases and communities
together
I had some time this morning, and decided to take a look at this. It
was fairly straightforward merging the changes back in to the 2.0
sandbox branch.
There's a bit of a problem going on here with the jsps used for the
tests. In the 1.1.5-based version, there was no eol-style property set
for the jsps. This caused the strings that were returned by the tests
to use \n for line terminators, which the unit tests expected to find in
the message responses. In the 2.0 version, the eol-style is set to
native, which causes the unit tests to fail when run on a Windows
system. I was able to hack these up so they're now running cleanly, but
I'm not terribly confident these won't end up breaking again in the
future. I suspect a less encoding-specific approach is going to be
needed for validating the responses should be used.
Rick
Jeff Genender wrote:
> Yes.. I think that is the best course of action. I think they are
> pretty similar since I created the mina 2 version in late December. I
> think the delta is rather small.
>
> Jeff
>
> On Jan 31, 2008, at 1:34 PM, "Sangjin Lee" <sj...@gmail.com> wrote:
>
>> Just so I understand...
>> What is the direction we're taking? Just for the terminology sake, I'll
>> call these versions
>>
>> - g-ahc-v1: Geronimo AHC based on Mina 1.1 (the one that Rick and I were
>> working on)
>> - g-ahc-v2: Geronimo AHC based on Mina trunk
>> - mina-ahc: Mina AHC that was refactored into asyncweb
>>
>> Are we migrating changes from g-ahc-v1 to g-ahc-v2 first and will try to
>> migrate them again from g-ahc-v2 to mina-ahc?
>>
>> Thanks,
>> Sangjin
>>
>>
>> On Jan 30, 2008 6:36 PM, Alex Karasulu <ak...@apache.org> wrote:
>>
>>> On Jan 30, 2008 1:49 PM, Jeff Genender <jg...@apache.org> wrote:
>>>
>>>> Being that its in the sandbox...anything goes. ;-)
>>>>
>>>> However...with that said...lets see what pans out here at Mina. I
>>>> would
>>>> certainly consider the delta now before we get 3 diverse versions ;-)
>>>>
>>>> Yes the preferred version is Mina 2.x.
>>>>
>>>>
>>> Indeed! We might want to first make sure the two Geronimo forks are
>>> merged
>>> and using MINA 2.0. Meaning all the features and fixes in the one
>>> based
>>> on
>>> MINA 1.1.x are put into the one based on MINA 2.0-M1.
>>>
>>> That might bring the consolidated Geronimo fork closer to the MINA
>>> version
>>> in Asyncweb trunk. Then we can focus on how to merge these two
>>> together?
>>>
>>> Alex
>>>
>
Re: [AsyncHttpClient] On bringing the code bases and communities together
Posted by Sangjin Lee <sj...@gmail.com>.
Thanks Rick! This was fast. I'll also take a quick look...
Regards,
Sangjin
On Feb 1, 2008 11:17 AM, Jeff Genender <jg...@apache.org> wrote:
> Or you can use Linux or Mac ;-)
>
> j/k!
>
> Thanks for looking into that Rick.
>
> Jeff
>
> Rick McGuire wrote:
> > I had some time this morning, and decided to take a look at this. It
> > was fairly straightforward merging the changes back in to the 2.0
> > sandbox branch.
> > There's a bit of a problem going on here with the jsps used for the
> > tests. In the 1.1.5-based version, there was no eol-style property set
> > for the jsps. This caused the strings that were returned by the tests
> > to use \n for line terminators, which the unit tests expected to find in
> > the message responses. In the 2.0 version, the eol-style is set to
> > native, which causes the unit tests to fail when run on a Windows
> > system. I was able to hack these up so they're now running cleanly, but
> > I'm not terribly confident these won't end up breaking again in the
> > future. I suspect a less encoding-specific approach is going to be
> > needed for validating the responses should be used.
> >
> > Rick
> >
> >
> > Jeff Genender wrote:
> >> Yes.. I think that is the best course of action. I think they are
> >> pretty similar since I created the mina 2 version in late December. I
> >> think the delta is rather small.
> >>
> >> Jeff
> >>
> >> On Jan 31, 2008, at 1:34 PM, "Sangjin Lee" <sj...@gmail.com> wrote:
> >>
> >>> Just so I understand...
> >>> What is the direction we're taking? Just for the terminology sake,
> I'll
> >>> call these versions
> >>>
> >>> - g-ahc-v1: Geronimo AHC based on Mina 1.1 (the one that Rick and I
> were
> >>> working on)
> >>> - g-ahc-v2: Geronimo AHC based on Mina trunk
> >>> - mina-ahc: Mina AHC that was refactored into asyncweb
> >>>
> >>> Are we migrating changes from g-ahc-v1 to g-ahc-v2 first and will try
> to
> >>> migrate them again from g-ahc-v2 to mina-ahc?
> >>>
> >>> Thanks,
> >>> Sangjin
> >>>
> >>>
> >>> On Jan 30, 2008 6:36 PM, Alex Karasulu <ak...@apache.org> wrote:
> >>>
> >>>> On Jan 30, 2008 1:49 PM, Jeff Genender <jg...@apache.org> wrote:
> >>>>
> >>>>> Being that its in the sandbox...anything goes. ;-)
> >>>>>
> >>>>> However...with that said...lets see what pans out here at Mina. I
> >>>>> would
> >>>>> certainly consider the delta now before we get 3 diverse versions
> ;-)
> >>>>>
> >>>>> Yes the preferred version is Mina 2.x.
> >>>>>
> >>>>>
> >>>> Indeed! We might want to first make sure the two Geronimo forks are
> >>>> merged
> >>>> and using MINA 2.0. Meaning all the features and fixes in the one
> >>>> based
> >>>> on
> >>>> MINA 1.1.x are put into the one based on MINA 2.0-M1.
> >>>>
> >>>> That might bring the consolidated Geronimo fork closer to the MINA
> >>>> version
> >>>> in Asyncweb trunk. Then we can focus on how to merge these two
> >>>> together?
> >>>>
> >>>> Alex
> >>>>
> >>
>
Re: [AsyncHttpClient] On bringing the code bases and communities together
Posted by Alex Karasulu <ak...@apache.org>.
Excellent thanks.
Alex
On Feb 5, 2008 9:50 AM, Maarten Bosteels <mb...@gmail.com> wrote:
> On Feb 5, 2008 10:07 AM, Alex Karasulu <ak...@apache.org> wrote:
>
> > Thanks Julien this is cool.
> >
> > Trustin why isn't any of this code documented? Would be nice if users
> can
> > see what this is about ... might make people use it more.
>
>
>
> see https://issues.apache.org/jira/browse/DIRMINA-92#action_12488311
> for more details
>
> Maarten
>
>
> >
> > Alex
> >
> > On Feb 5, 2008 3:07 AM, Julien Vermillard <jv...@archean.fr>
> wrote:
> >
> > > On Mon, 04 Feb 2008 22:02:19 -0700
> > > Jeff Genender <jg...@apache.org> wrote:
> > >
> > > >
> > > >
> > > > Mike Heath wrote:
> > > > > To clarify, my understanding of pipelining is that it is sending
> > > > > multiple requests and then waiting for the corresponding
> responses.
> > > > > This is more than HTTP keep alive which would also allow using a
> > > > > single connection for multiple requests but doesn't necessarily
> > > > > involve the batching of pipelining.
> > > >
> > > > I understand it slightly different..that you can send multiple
> > > > requests through the same socket. The difference between what you
> > > > said and what I said is I think pipelining does not have stacked
> > > > waiting.
> > > >
> > > > >
> > > > >> But if you are saying its possible, then great!
> > > > >
> > > > > What I'm saying is that in the AHC code at
> > > > >
> > >
> http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2
> > ,
> > > > > the HttpIoHandler.TimeoutTask is unaware of which request has been
> > > > > sent. It only knows which IoSession is being used (that's the only
> > > > > field in the TimeoutTask). So essentially the timeout logic as it
> > > > > is implemented in AHC is no different than using the MINA idle
> > > > > logic.
> > > > >
> > > > > Does the AHC client currently support pipelining? If I issue two
> > > > > pipelined requests, and the first one times out causing the
> session
> > > > > to close. How does the future of the second request get notified
> > > > > of the timeout? I only see code for working with CURRENT_REQUEST
> > > > > (from the IoSession attributes). I don't see any code for dealing
> > > > > with pending requests.
> > > > >
> > > >
> > > > You are right....no AHC does not support pipelining but we were
> coding
> > > > it to go in that direction so we could. We knew that it would be a
> > > > lot more complex to implement, but wanted to sow the seeds of the
> > > > code to handle it when we did.
> > > >
> > > > OTOH, I must admit I implemented the ScheduledExecutor based on the
> > > > FAQ and a few IRC discussions ;-) but if sessionIdle will work,
> then
> > > > that would be the way to go.
> > > >
> > > > > -Mike
> > > > >
> > > > > BTW - Thanks for the discussion, Jeff. It's really helped me to
> go
> > > > > back and look deeper in the AHC code.
> > > >
> > > > Thank you...and thanks for taking an interest...this is great ;-)
> > > >
> > > > >
> > > > > -Mike
> > >
> > > Hi,
> > >
> > > Just by the way, if you want to monitor a request/response behaviour
> you
> > > got the reqres filter :
> > >
> > >
> >
> http://svn.apache.org/viewvc/mina/trunk/core/src/main/java/org/apache/mina/filter/reqres/
> > >
> > > Julien
> > >
> >
>
Re: [AsyncHttpClient] On bringing the code bases and communities together
Posted by Maarten Bosteels <mb...@gmail.com>.
On Feb 5, 2008 10:07 AM, Alex Karasulu <ak...@apache.org> wrote:
> Thanks Julien this is cool.
>
> Trustin why isn't any of this code documented? Would be nice if users can
> see what this is about ... might make people use it more.
see https://issues.apache.org/jira/browse/DIRMINA-92#action_12488311
for more details
Maarten
>
> Alex
>
> On Feb 5, 2008 3:07 AM, Julien Vermillard <jv...@archean.fr> wrote:
>
> > On Mon, 04 Feb 2008 22:02:19 -0700
> > Jeff Genender <jg...@apache.org> wrote:
> >
> > >
> > >
> > > Mike Heath wrote:
> > > > To clarify, my understanding of pipelining is that it is sending
> > > > multiple requests and then waiting for the corresponding responses.
> > > > This is more than HTTP keep alive which would also allow using a
> > > > single connection for multiple requests but doesn't necessarily
> > > > involve the batching of pipelining.
> > >
> > > I understand it slightly different..that you can send multiple
> > > requests through the same socket. The difference between what you
> > > said and what I said is I think pipelining does not have stacked
> > > waiting.
> > >
> > > >
> > > >> But if you are saying its possible, then great!
> > > >
> > > > What I'm saying is that in the AHC code at
> > > >
> > http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2
> ,
> > > > the HttpIoHandler.TimeoutTask is unaware of which request has been
> > > > sent. It only knows which IoSession is being used (that's the only
> > > > field in the TimeoutTask). So essentially the timeout logic as it
> > > > is implemented in AHC is no different than using the MINA idle
> > > > logic.
> > > >
> > > > Does the AHC client currently support pipelining? If I issue two
> > > > pipelined requests, and the first one times out causing the session
> > > > to close. How does the future of the second request get notified
> > > > of the timeout? I only see code for working with CURRENT_REQUEST
> > > > (from the IoSession attributes). I don't see any code for dealing
> > > > with pending requests.
> > > >
> > >
> > > You are right....no AHC does not support pipelining but we were coding
> > > it to go in that direction so we could. We knew that it would be a
> > > lot more complex to implement, but wanted to sow the seeds of the
> > > code to handle it when we did.
> > >
> > > OTOH, I must admit I implemented the ScheduledExecutor based on the
> > > FAQ and a few IRC discussions ;-) but if sessionIdle will work, then
> > > that would be the way to go.
> > >
> > > > -Mike
> > > >
> > > > BTW - Thanks for the discussion, Jeff. It's really helped me to go
> > > > back and look deeper in the AHC code.
> > >
> > > Thank you...and thanks for taking an interest...this is great ;-)
> > >
> > > >
> > > > -Mike
> >
> > Hi,
> >
> > Just by the way, if you want to monitor a request/response behaviour you
> > got the reqres filter :
> >
> >
> http://svn.apache.org/viewvc/mina/trunk/core/src/main/java/org/apache/mina/filter/reqres/
> >
> > Julien
> >
>
Re: [AsyncHttpClient] On bringing the code bases and communities together
Posted by Alex Karasulu <ak...@apache.org>.
Thanks Julien this is cool.
Trustin why isn't any of this code documented? Would be nice if users can
see what this is about ... might make people use it more.
Alex
On Feb 5, 2008 3:07 AM, Julien Vermillard <jv...@archean.fr> wrote:
> On Mon, 04 Feb 2008 22:02:19 -0700
> Jeff Genender <jg...@apache.org> wrote:
>
> >
> >
> > Mike Heath wrote:
> > > To clarify, my understanding of pipelining is that it is sending
> > > multiple requests and then waiting for the corresponding responses.
> > > This is more than HTTP keep alive which would also allow using a
> > > single connection for multiple requests but doesn't necessarily
> > > involve the batching of pipelining.
> >
> > I understand it slightly different..that you can send multiple
> > requests through the same socket. The difference between what you
> > said and what I said is I think pipelining does not have stacked
> > waiting.
> >
> > >
> > >> But if you are saying its possible, then great!
> > >
> > > What I'm saying is that in the AHC code at
> > >
> http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2,
> > > the HttpIoHandler.TimeoutTask is unaware of which request has been
> > > sent. It only knows which IoSession is being used (that's the only
> > > field in the TimeoutTask). So essentially the timeout logic as it
> > > is implemented in AHC is no different than using the MINA idle
> > > logic.
> > >
> > > Does the AHC client currently support pipelining? If I issue two
> > > pipelined requests, and the first one times out causing the session
> > > to close. How does the future of the second request get notified
> > > of the timeout? I only see code for working with CURRENT_REQUEST
> > > (from the IoSession attributes). I don't see any code for dealing
> > > with pending requests.
> > >
> >
> > You are right....no AHC does not support pipelining but we were coding
> > it to go in that direction so we could. We knew that it would be a
> > lot more complex to implement, but wanted to sow the seeds of the
> > code to handle it when we did.
> >
> > OTOH, I must admit I implemented the ScheduledExecutor based on the
> > FAQ and a few IRC discussions ;-) but if sessionIdle will work, then
> > that would be the way to go.
> >
> > > -Mike
> > >
> > > BTW - Thanks for the discussion, Jeff. It's really helped me to go
> > > back and look deeper in the AHC code.
> >
> > Thank you...and thanks for taking an interest...this is great ;-)
> >
> > >
> > > -Mike
>
> Hi,
>
> Just by the way, if you want to monitor a request/response behaviour you
> got the reqres filter :
>
> http://svn.apache.org/viewvc/mina/trunk/core/src/main/java/org/apache/mina/filter/reqres/
>
> Julien
>
Re: [AsyncHttpClient] On bringing the code bases and communities
together
Posted by Rick McGuire <ri...@gmail.com>.
This sounds like an excellent approach to merging the efforts.
Rick
Mike Heath wrote:
> I've been looking into merging
> http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/
> into http://svn.apache.org/repos/asf/mina/asyncweb/trunk/client/ and I'm
> trying to figure out the best way to proceed. Here are some of the pain
> points I see:
> - The only redeeming quality about the AsyncWeb client is that it uses
> the AsyncWeb codec.
> - There are a few things in AHC that duplicate functionality already
> available in MINA (timeouts for example)
> - The AHC codec and the AsycnWeb codec have diverged quite a bit.
>
> To resolve these pain points, here is how I would like to proceed. I
> would like to copy the AHC async-http-client-mina2 code as is into the
> AsyncWeb client repository. Because AHC and AsyncWeb client use
> different package names, there shouldn't be any conflicts doing this.
> Once that is done, we can look at removing the AHC code that
> reimplements functionality available in MINA. As long as all the tests
> are passing, we should be fine and if there are gaps in testing, we
> should fill those.
>
> Once that is done, we can look at refactoring the AHC code base to use
> the AsyncWeb codec while at the same time, make sure that the AsyncWeb
> codec isn't missing any functionality that is implemented in AHC.
>
> I think at this point, we can rename the AHC packages and move it over
> top the current AsyncWeb client. Am I missing anything in AsyncWeb
> client that needs to merged into AHC? It's only four classes and I
> didn't see anything in there that isn't available in AHC.
>
> Before going ahead and doing this, I wanted to know what everyone else
> thinks of this plan. Does anyone else have a different idea as to how
> best to undertake this merge? Am I missing anything?
>
> -Mike
>
>
>
> Sangjin Lee wrote:
>
>> Yeah I believe so (as far as I can tell). It was more or less a
>> straightforward porting, so there might be interesting and subtle behavior
>> changes we may need to look at. But it should be a good solid baseline.
>> Thanks,
>> Sangjin
>>
>>
>> On Feb 4, 2008 2:50 PM, Mike Heath <mh...@apache.org> wrote:
>>
>>
>>> Rick McGuire wrote:
>>>
>>>> I had some time this morning, and decided to take a look at this. It
>>>> was fairly straightforward merging the changes back in to the 2.0
>>>> sandbox branch.
>>>> There's a bit of a problem going on here with the jsps used for the
>>>> tests. In the 1.1.5-based version, there was no eol-style property set
>>>> for the jsps. This caused the strings that were returned by the tests
>>>> to use \n for line terminators, which the unit tests expected to find in
>>>> the message responses. In the 2.0 version, the eol-style is set to
>>>> native, which causes the unit tests to fail when run on a Windows
>>>> system. I was able to hack these up so they're now running cleanly, but
>>>> I'm not terribly confident these won't end up breaking again in the
>>>> future. I suspect a less encoding-specific approach is going to be
>>>> needed for validating the responses should be used.
>>>>
>>>> Rick
>>>>
>>> Rick,
>>>
>>> Does
>>> http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/
>>> contain all the bug fixes and latest features of AsyncHttpClient? Can
>>> we use this to merge the changes over to the client under MINA?
>>>
>>> -Mike
>>>
>>> <snip>
>>>
>>>
>
>
>
Re: [AsyncHttpClient] On bringing the code bases and communities together
Posted by Sangjin Lee <sj...@gmail.com>.
Sounds good to me. The codec has evolved quite a bit, so yeah, we'd need to
pay attention to the codec to make sure all the features are properly
migrated... Please let me know how I can participate in this effort. We'll
open new JIRA issues as we identify individual tasks, no?
Thanks,
Sangjin
On Feb 4, 2008 4:45 PM, Mike Heath <mh...@apache.org> wrote:
> I've been looking into merging
> http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/
> into http://svn.apache.org/repos/asf/mina/asyncweb/trunk/client/ and I'm
> trying to figure out the best way to proceed. Here are some of the pain
> points I see:
> - The only redeeming quality about the AsyncWeb client is that it uses
> the AsyncWeb codec.
> - There are a few things in AHC that duplicate functionality already
> available in MINA (timeouts for example)
> - The AHC codec and the AsycnWeb codec have diverged quite a bit.
>
> To resolve these pain points, here is how I would like to proceed. I
> would like to copy the AHC async-http-client-mina2 code as is into the
> AsyncWeb client repository. Because AHC and AsyncWeb client use
> different package names, there shouldn't be any conflicts doing this.
> Once that is done, we can look at removing the AHC code that
> reimplements functionality available in MINA. As long as all the tests
> are passing, we should be fine and if there are gaps in testing, we
> should fill those.
>
> Once that is done, we can look at refactoring the AHC code base to use
> the AsyncWeb codec while at the same time, make sure that the AsyncWeb
> codec isn't missing any functionality that is implemented in AHC.
>
> I think at this point, we can rename the AHC packages and move it over
> top the current AsyncWeb client. Am I missing anything in AsyncWeb
> client that needs to merged into AHC? It's only four classes and I
> didn't see anything in there that isn't available in AHC.
>
> Before going ahead and doing this, I wanted to know what everyone else
> thinks of this plan. Does anyone else have a different idea as to how
> best to undertake this merge? Am I missing anything?
>
> -Mike
>
>
>
> Sangjin Lee wrote:
> > Yeah I believe so (as far as I can tell). It was more or less a
> > straightforward porting, so there might be interesting and subtle
> behavior
> > changes we may need to look at. But it should be a good solid baseline.
> > Thanks,
> > Sangjin
> >
> >
> > On Feb 4, 2008 2:50 PM, Mike Heath <mh...@apache.org> wrote:
> >
> >> Rick McGuire wrote:
> >>> I had some time this morning, and decided to take a look at this. It
> >>> was fairly straightforward merging the changes back in to the 2.0
> >>> sandbox branch.
> >>> There's a bit of a problem going on here with the jsps used for the
> >>> tests. In the 1.1.5-based version, there was no eol-style property
> set
> >>> for the jsps. This caused the strings that were returned by the tests
> >>> to use \n for line terminators, which the unit tests expected to find
> in
> >>> the message responses. In the 2.0 version, the eol-style is set to
> >>> native, which causes the unit tests to fail when run on a Windows
> >>> system. I was able to hack these up so they're now running cleanly,
> but
> >>> I'm not terribly confident these won't end up breaking again in the
> >>> future. I suspect a less encoding-specific approach is going to be
> >>> needed for validating the responses should be used.
> >>>
> >>> Rick
> >> Rick,
> >>
> >> Does
> >>
> http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/
> >> contain all the bug fixes and latest features of AsyncHttpClient? Can
> >> we use this to merge the changes over to the client under MINA?
> >>
> >> -Mike
> >>
> >> <snip>
> >>
> >
>
>
Re: [AsyncHttpClient] On bringing the code bases and communities
together
Posted by Jeff Genender <jg...@apache.org>.
Wow...this is awesome...I could have used this because this is
essentially the same mechanism I wrote in AHC ;-)
Yeah...this should be documented in the FAQ somewhere as this would come
in handy.
Jeff
Julien Vermillard wrote:
> Hi,
>
> Just by the way, if you want to monitor a request/response behaviour you
> got the reqres filter :
> http://svn.apache.org/viewvc/mina/trunk/core/src/main/java/org/apache/mina/filter/reqres/
>
> Julien
Re: [AsyncHttpClient] On bringing the code bases and communities
together
Posted by Julien Vermillard <jv...@archean.fr>.
On Mon, 04 Feb 2008 22:02:19 -0700
Jeff Genender <jg...@apache.org> wrote:
>
>
> Mike Heath wrote:
> > To clarify, my understanding of pipelining is that it is sending
> > multiple requests and then waiting for the corresponding responses.
> > This is more than HTTP keep alive which would also allow using a
> > single connection for multiple requests but doesn't necessarily
> > involve the batching of pipelining.
>
> I understand it slightly different..that you can send multiple
> requests through the same socket. The difference between what you
> said and what I said is I think pipelining does not have stacked
> waiting.
>
> >
> >> But if you are saying its possible, then great!
> >
> > What I'm saying is that in the AHC code at
> > http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2,
> > the HttpIoHandler.TimeoutTask is unaware of which request has been
> > sent. It only knows which IoSession is being used (that's the only
> > field in the TimeoutTask). So essentially the timeout logic as it
> > is implemented in AHC is no different than using the MINA idle
> > logic.
> >
> > Does the AHC client currently support pipelining? If I issue two
> > pipelined requests, and the first one times out causing the session
> > to close. How does the future of the second request get notified
> > of the timeout? I only see code for working with CURRENT_REQUEST
> > (from the IoSession attributes). I don't see any code for dealing
> > with pending requests.
> >
>
> You are right....no AHC does not support pipelining but we were coding
> it to go in that direction so we could. We knew that it would be a
> lot more complex to implement, but wanted to sow the seeds of the
> code to handle it when we did.
>
> OTOH, I must admit I implemented the ScheduledExecutor based on the
> FAQ and a few IRC discussions ;-) but if sessionIdle will work, then
> that would be the way to go.
>
> > -Mike
> >
> > BTW - Thanks for the discussion, Jeff. It's really helped me to go
> > back and look deeper in the AHC code.
>
> Thank you...and thanks for taking an interest...this is great ;-)
>
> >
> > -Mike
Hi,
Just by the way, if you want to monitor a request/response behaviour you
got the reqres filter :
http://svn.apache.org/viewvc/mina/trunk/core/src/main/java/org/apache/mina/filter/reqres/
Julien
Re: [AsyncHttpClient] On bringing the code bases and communities
together
Posted by Jeff Genender <jg...@apache.org>.
Mike Heath wrote:
> To clarify, my understanding of pipelining is that it is sending
> multiple requests and then waiting for the corresponding responses.
> This is more than HTTP keep alive which would also allow using a single
> connection for multiple requests but doesn't necessarily involve the
> batching of pipelining.
I understand it slightly different..that you can send multiple requests
through the same socket. The difference between what you said and what
I said is I think pipelining does not have stacked waiting.
>
>> But if you are saying its possible, then great!
>
> What I'm saying is that in the AHC code at
> http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2,
> the HttpIoHandler.TimeoutTask is unaware of which request has been sent.
> It only knows which IoSession is being used (that's the only field in
> the TimeoutTask). So essentially the timeout logic as it is implemented
> in AHC is no different than using the MINA idle logic.
>
> Does the AHC client currently support pipelining? If I issue two
> pipelined requests, and the first one times out causing the session to
> close. How does the future of the second request get notified of the
> timeout? I only see code for working with CURRENT_REQUEST (from the
> IoSession attributes). I don't see any code for dealing with pending
> requests.
>
You are right....no AHC does not support pipelining but we were coding
it to go in that direction so we could. We knew that it would be a lot
more complex to implement, but wanted to sow the seeds of the code to
handle it when we did.
OTOH, I must admit I implemented the ScheduledExecutor based on the FAQ
and a few IRC discussions ;-) but if sessionIdle will work, then that
would be the way to go.
> -Mike
>
> BTW - Thanks for the discussion, Jeff. It's really helped me to go back
> and look deeper in the AHC code.
Thank you...and thanks for taking an interest...this is great ;-)
>
> -Mike
Re: [AsyncHttpClient] On bringing the code bases and communities
together
Posted by Mike Heath <mh...@apache.org>.
Jeff Genender wrote:
>
>
> Mike Heath wrote:
>> What the FAQ is saying is that the idle event wont tell you which
>> request message was issued when the timeout occured. So using an idle
>> read to detect an unresponsive connection is perfectly legitimate.
>>
>> I don't see why using idle wouldn't work for pipelining. If the session
>> times out, it gets closed which would cause any pending requests to fail
>> anyway.
>>
>> I may just be presumptuous. Am I missing something?
>>
>
> This is pipelining...using a single connection for reuse for multiple
> requests, which tells me that a sessionIdle would probably not work.
To clarify, my understanding of pipelining is that it is sending
multiple requests and then waiting for the corresponding responses.
This is more than HTTP keep alive which would also allow using a single
connection for multiple requests but doesn't necessarily involve the
batching of pipelining.
> But if you are saying its possible, then great!
What I'm saying is that in the AHC code at
http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2,
the HttpIoHandler.TimeoutTask is unaware of which request has been sent.
It only knows which IoSession is being used (that's the only field in
the TimeoutTask). So essentially the timeout logic as it is implemented
in AHC is no different than using the MINA idle logic.
Does the AHC client currently support pipelining? If I issue two
pipelined requests, and the first one times out causing the session to
close. How does the future of the second request get notified of the
timeout? I only see code for working with CURRENT_REQUEST (from the
IoSession attributes). I don't see any code for dealing with pending
requests.
-Mike
BTW - Thanks for the discussion, Jeff. It's really helped me to go back
and look deeper in the AHC code.
-Mike
Re: [AsyncHttpClient] On bringing the code bases and communities
together
Posted by Jeff Genender <jg...@apache.org>.
Mike Heath wrote:
> What the FAQ is saying is that the idle event wont tell you which
> request message was issued when the timeout occured. So using an idle
> read to detect an unresponsive connection is perfectly legitimate.
>
> I don't see why using idle wouldn't work for pipelining. If the session
> times out, it gets closed which would cause any pending requests to fail
> anyway.
>
> I may just be presumptuous. Am I missing something?
>
This is pipelining...using a single connection for reuse for multiple
requests, which tells me that a sessionIdle would probably not work.
But if you are saying its possible, then great!
Jeff
> -Mike
Re: [AsyncHttpClient] On bringing the code bases and communities
together
Posted by Mike Heath <mh...@apache.org>.
Jeff Genender wrote:
>
>
> Mike Heath wrote:
>> Jeff Genender wrote:
>>
>> <snip>
>>> I think this timeout is a different timeout in implementation...that is
>>> unless this was added to 2.0, then duplication may be correct. Its a
>>> response timeout, not socket timeout...I think thats different.
>>
>> MINA has support for triggering events for read idle, write idle, or
>> both. See IoSession.setIdleTime(IdleStatus, int) in MINA 1.x and
>> IoSession.getConfig().setIdleTime(IdleStatus,int) in MINA 2. The idle
>> events get handled by IoHandler.sessionIdle(IoSession, IdleStatus) in
>> both versions.
>
> Will idle work here? The Mina FAQ states that sessionIdle cannot be
> used in a request-response timeout:
>
> http://tinyurl.com/25gnja
>
> Also, with pipelining, can idle time even be used?
What the FAQ is saying is that the idle event wont tell you which
request message was issued when the timeout occured. So using an idle
read to detect an unresponsive connection is perfectly legitimate.
I don't see why using idle wouldn't work for pipelining. If the session
times out, it gets closed which would cause any pending requests to fail
anyway.
I may just be presumptuous. Am I missing something?
-Mike
Re: [AsyncHttpClient] On bringing the code bases and communities
together
Posted by Jeff Genender <jg...@apache.org>.
Mike Heath wrote:
> Jeff Genender wrote:
>
> <snip>
>> I think this timeout is a different timeout in implementation...that is
>> unless this was added to 2.0, then duplication may be correct. Its a
>> response timeout, not socket timeout...I think thats different.
>
> MINA has support for triggering events for read idle, write idle, or
> both. See IoSession.setIdleTime(IdleStatus, int) in MINA 1.x and
> IoSession.getConfig().setIdleTime(IdleStatus,int) in MINA 2. The idle
> events get handled by IoHandler.sessionIdle(IoSession, IdleStatus) in
> both versions.
Will idle work here? The Mina FAQ states that sessionIdle cannot be
used in a request-response timeout:
http://tinyurl.com/25gnja
Also, with pipelining, can idle time even be used?
Jeff
Re: [AsyncHttpClient] On bringing the code bases and communities
together
Posted by Mike Heath <mh...@apache.org>.
Jeff Genender wrote:
<snip>
> I think this timeout is a different timeout in implementation...that is
> unless this was added to 2.0, then duplication may be correct. Its a
> response timeout, not socket timeout...I think thats different.
MINA has support for triggering events for read idle, write idle, or
both. See IoSession.setIdleTime(IdleStatus, int) in MINA 1.x and
IoSession.getConfig().setIdleTime(IdleStatus,int) in MINA 2. The idle
events get handled by IoHandler.sessionIdle(IoSession, IdleStatus) in
both versions.
<snip>
> I like the plan...seems like a good way to go.
Thanks for the feedback. I'll get started on this tomorrow.
-Mike
Re: [AsyncHttpClient] On bringing the code bases and communities
together
Posted by Jeff Genender <jg...@apache.org>.
Mike Heath wrote:
> I've been looking into merging
> http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/
> into http://svn.apache.org/repos/asf/mina/asyncweb/trunk/client/ and I'm
> trying to figure out the best way to proceed. Here are some of the pain
> points I see:
> - The only redeeming quality about the AsyncWeb client is that it uses
> the AsyncWeb codec.
> - There are a few things in AHC that duplicate functionality already
> available in MINA (timeouts for example)
I think this timeout is a different timeout in implementation...that is
unless this was added to 2.0, then duplication may be correct. Its a
response timeout, not socket timeout...I think thats different.
> - The AHC codec and the AsycnWeb codec have diverged quite a bit.
>
> To resolve these pain points, here is how I would like to proceed. I
> would like to copy the AHC async-http-client-mina2 code as is into the
> AsyncWeb client repository. Because AHC and AsyncWeb client use
> different package names, there shouldn't be any conflicts doing this.
> Once that is done, we can look at removing the AHC code that
> reimplements functionality available in MINA. As long as all the tests
> are passing, we should be fine and if there are gaps in testing, we
> should fill those.
>
> Once that is done, we can look at refactoring the AHC code base to use
> the AsyncWeb codec while at the same time, make sure that the AsyncWeb
> codec isn't missing any functionality that is implemented in AHC.
>
> I think at this point, we can rename the AHC packages and move it over
> top the current AsyncWeb client. Am I missing anything in AsyncWeb
> client that needs to merged into AHC? It's only four classes and I
> didn't see anything in there that isn't available in AHC.
>
> Before going ahead and doing this, I wanted to know what everyone else
> thinks of this plan. Does anyone else have a different idea as to how
> best to undertake this merge? Am I missing anything?
>
I like the plan...seems like a good way to go.
> -Mike
>
>
>
> Sangjin Lee wrote:
>> Yeah I believe so (as far as I can tell). It was more or less a
>> straightforward porting, so there might be interesting and subtle behavior
>> changes we may need to look at. But it should be a good solid baseline.
>> Thanks,
>> Sangjin
>>
>>
>> On Feb 4, 2008 2:50 PM, Mike Heath <mh...@apache.org> wrote:
>>
>>> Rick McGuire wrote:
>>>> I had some time this morning, and decided to take a look at this. It
>>>> was fairly straightforward merging the changes back in to the 2.0
>>>> sandbox branch.
>>>> There's a bit of a problem going on here with the jsps used for the
>>>> tests. In the 1.1.5-based version, there was no eol-style property set
>>>> for the jsps. This caused the strings that were returned by the tests
>>>> to use \n for line terminators, which the unit tests expected to find in
>>>> the message responses. In the 2.0 version, the eol-style is set to
>>>> native, which causes the unit tests to fail when run on a Windows
>>>> system. I was able to hack these up so they're now running cleanly, but
>>>> I'm not terribly confident these won't end up breaking again in the
>>>> future. I suspect a less encoding-specific approach is going to be
>>>> needed for validating the responses should be used.
>>>>
>>>> Rick
>>> Rick,
>>>
>>> Does
>>> http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/
>>> contain all the bug fixes and latest features of AsyncHttpClient? Can
>>> we use this to merge the changes over to the client under MINA?
>>>
>>> -Mike
>>>
>>> <snip>
>>>
Re: [AsyncHttpClient] On bringing the code bases and communities
together
Posted by Mike Heath <mh...@apache.org>.
I've been looking into merging
http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/
into http://svn.apache.org/repos/asf/mina/asyncweb/trunk/client/ and I'm
trying to figure out the best way to proceed. Here are some of the pain
points I see:
- The only redeeming quality about the AsyncWeb client is that it uses
the AsyncWeb codec.
- There are a few things in AHC that duplicate functionality already
available in MINA (timeouts for example)
- The AHC codec and the AsycnWeb codec have diverged quite a bit.
To resolve these pain points, here is how I would like to proceed. I
would like to copy the AHC async-http-client-mina2 code as is into the
AsyncWeb client repository. Because AHC and AsyncWeb client use
different package names, there shouldn't be any conflicts doing this.
Once that is done, we can look at removing the AHC code that
reimplements functionality available in MINA. As long as all the tests
are passing, we should be fine and if there are gaps in testing, we
should fill those.
Once that is done, we can look at refactoring the AHC code base to use
the AsyncWeb codec while at the same time, make sure that the AsyncWeb
codec isn't missing any functionality that is implemented in AHC.
I think at this point, we can rename the AHC packages and move it over
top the current AsyncWeb client. Am I missing anything in AsyncWeb
client that needs to merged into AHC? It's only four classes and I
didn't see anything in there that isn't available in AHC.
Before going ahead and doing this, I wanted to know what everyone else
thinks of this plan. Does anyone else have a different idea as to how
best to undertake this merge? Am I missing anything?
-Mike
Sangjin Lee wrote:
> Yeah I believe so (as far as I can tell). It was more or less a
> straightforward porting, so there might be interesting and subtle behavior
> changes we may need to look at. But it should be a good solid baseline.
> Thanks,
> Sangjin
>
>
> On Feb 4, 2008 2:50 PM, Mike Heath <mh...@apache.org> wrote:
>
>> Rick McGuire wrote:
>>> I had some time this morning, and decided to take a look at this. It
>>> was fairly straightforward merging the changes back in to the 2.0
>>> sandbox branch.
>>> There's a bit of a problem going on here with the jsps used for the
>>> tests. In the 1.1.5-based version, there was no eol-style property set
>>> for the jsps. This caused the strings that were returned by the tests
>>> to use \n for line terminators, which the unit tests expected to find in
>>> the message responses. In the 2.0 version, the eol-style is set to
>>> native, which causes the unit tests to fail when run on a Windows
>>> system. I was able to hack these up so they're now running cleanly, but
>>> I'm not terribly confident these won't end up breaking again in the
>>> future. I suspect a less encoding-specific approach is going to be
>>> needed for validating the responses should be used.
>>>
>>> Rick
>> Rick,
>>
>> Does
>> http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/
>> contain all the bug fixes and latest features of AsyncHttpClient? Can
>> we use this to merge the changes over to the client under MINA?
>>
>> -Mike
>>
>> <snip>
>>
>
Re: [AsyncHttpClient] On bringing the code bases and communities together
Posted by Sangjin Lee <sj...@gmail.com>.
Yeah I believe so (as far as I can tell). It was more or less a
straightforward porting, so there might be interesting and subtle behavior
changes we may need to look at. But it should be a good solid baseline.
Thanks,
Sangjin
On Feb 4, 2008 2:50 PM, Mike Heath <mh...@apache.org> wrote:
> Rick McGuire wrote:
> > I had some time this morning, and decided to take a look at this. It
> > was fairly straightforward merging the changes back in to the 2.0
> > sandbox branch.
> > There's a bit of a problem going on here with the jsps used for the
> > tests. In the 1.1.5-based version, there was no eol-style property set
> > for the jsps. This caused the strings that were returned by the tests
> > to use \n for line terminators, which the unit tests expected to find in
> > the message responses. In the 2.0 version, the eol-style is set to
> > native, which causes the unit tests to fail when run on a Windows
> > system. I was able to hack these up so they're now running cleanly, but
> > I'm not terribly confident these won't end up breaking again in the
> > future. I suspect a less encoding-specific approach is going to be
> > needed for validating the responses should be used.
> >
> > Rick
>
> Rick,
>
> Does
> http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/
> contain all the bug fixes and latest features of AsyncHttpClient? Can
> we use this to merge the changes over to the client under MINA?
>
> -Mike
>
> <snip>
>
Re: [AsyncHttpClient] On bringing the code bases and communities
together
Posted by Mike Heath <mh...@apache.org>.
Rick McGuire wrote:
> I had some time this morning, and decided to take a look at this. It
> was fairly straightforward merging the changes back in to the 2.0
> sandbox branch.
> There's a bit of a problem going on here with the jsps used for the
> tests. In the 1.1.5-based version, there was no eol-style property set
> for the jsps. This caused the strings that were returned by the tests
> to use \n for line terminators, which the unit tests expected to find in
> the message responses. In the 2.0 version, the eol-style is set to
> native, which causes the unit tests to fail when run on a Windows
> system. I was able to hack these up so they're now running cleanly, but
> I'm not terribly confident these won't end up breaking again in the
> future. I suspect a less encoding-specific approach is going to be
> needed for validating the responses should be used.
>
> Rick
Rick,
Does
http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/
contain all the bug fixes and latest features of AsyncHttpClient? Can
we use this to merge the changes over to the client under MINA?
-Mike
<snip>
Re: [AsyncHttpClient] On bringing the code bases and communities
together
Posted by Jeff Genender <jg...@apache.org>.
Or you can use Linux or Mac ;-)
j/k!
Thanks for looking into that Rick.
Jeff
Rick McGuire wrote:
> I had some time this morning, and decided to take a look at this. It
> was fairly straightforward merging the changes back in to the 2.0
> sandbox branch.
> There's a bit of a problem going on here with the jsps used for the
> tests. In the 1.1.5-based version, there was no eol-style property set
> for the jsps. This caused the strings that were returned by the tests
> to use \n for line terminators, which the unit tests expected to find in
> the message responses. In the 2.0 version, the eol-style is set to
> native, which causes the unit tests to fail when run on a Windows
> system. I was able to hack these up so they're now running cleanly, but
> I'm not terribly confident these won't end up breaking again in the
> future. I suspect a less encoding-specific approach is going to be
> needed for validating the responses should be used.
>
> Rick
>
>
> Jeff Genender wrote:
>> Yes.. I think that is the best course of action. I think they are
>> pretty similar since I created the mina 2 version in late December. I
>> think the delta is rather small.
>>
>> Jeff
>>
>> On Jan 31, 2008, at 1:34 PM, "Sangjin Lee" <sj...@gmail.com> wrote:
>>
>>> Just so I understand...
>>> What is the direction we're taking? Just for the terminology sake, I'll
>>> call these versions
>>>
>>> - g-ahc-v1: Geronimo AHC based on Mina 1.1 (the one that Rick and I were
>>> working on)
>>> - g-ahc-v2: Geronimo AHC based on Mina trunk
>>> - mina-ahc: Mina AHC that was refactored into asyncweb
>>>
>>> Are we migrating changes from g-ahc-v1 to g-ahc-v2 first and will try to
>>> migrate them again from g-ahc-v2 to mina-ahc?
>>>
>>> Thanks,
>>> Sangjin
>>>
>>>
>>> On Jan 30, 2008 6:36 PM, Alex Karasulu <ak...@apache.org> wrote:
>>>
>>>> On Jan 30, 2008 1:49 PM, Jeff Genender <jg...@apache.org> wrote:
>>>>
>>>>> Being that its in the sandbox...anything goes. ;-)
>>>>>
>>>>> However...with that said...lets see what pans out here at Mina. I
>>>>> would
>>>>> certainly consider the delta now before we get 3 diverse versions ;-)
>>>>>
>>>>> Yes the preferred version is Mina 2.x.
>>>>>
>>>>>
>>>> Indeed! We might want to first make sure the two Geronimo forks are
>>>> merged
>>>> and using MINA 2.0. Meaning all the features and fixes in the one
>>>> based
>>>> on
>>>> MINA 1.1.x are put into the one based on MINA 2.0-M1.
>>>>
>>>> That might bring the consolidated Geronimo fork closer to the MINA
>>>> version
>>>> in Asyncweb trunk. Then we can focus on how to merge these two
>>>> together?
>>>>
>>>> Alex
>>>>
>>