[jira] Commented: (ASYNCWEB-2) Merge AHC into AsyncWeb client

[Mike Heath (JIRA)]

[ 
https://issues.apache.org/jira/browse/ASYNCWEB-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566010#action_12566010
 ] 

Mike Heath commented on ASYNCWEB-2:
---

I renamed SessionCache to ConnectionPool since that's more indicative of what 
it's doing and there's no ambiguity as to whether its caching HTTP session data 
or caching IoSessions.

> Merge AHC into AsyncWeb client
> --
>
> Key: ASYNCWEB-2
> URL: https://issues.apache.org/jira/browse/ASYNCWEB-2
> Project: Asyncweb
>  Issue Type: Task
>Reporter: Mike Heath
>Assignee: Mike Heath
>
> We need to merge the AHC code in 
> http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/ 
> into the AsyncWeb code in 
> http://svn.apache.org/repos/asf/mina/asyncweb/trunk/client/
> There's a considerable gap between the AHC codec and the AsyncWeb codec.  We 
> need to move the AHC code over to the AsyncWeb while at the same time make 
> sure that we haven't lost any features in AHC that are missing in AsyncWeb.  
> Once we have the AHC code using the AsyncWeb codec, we should be able to 
> replace the AsyncWeb client with the modified AHC client.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: MINA 2.0 IPv6 NioDatagramAcceptor

[agrabil]

FYI, 
I've discovered that this problem is due to a bug with Sun's JRE on Windows:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6230761

I also get this exception on a FreeBSD VMWare running on Windows.  However,
it seems to bind fine on Linux, and I'm sure it's okay on Solaris.

Regards,
Greg


agrabil wrote:
> 
> Using MINA 2.0, I cannot seem to create and bind to the local IPv6
> wildcard address:
> 
> org.apache.mina.transport.socket.nio.NioDatagramAcceptor acceptor =
> new org.apache.mina.transport.socket.nio.NioDatagramAcceptor();
> acceptor.setDefaultLocalAddress(new java.net.InetSocketAddress("::0",
> 555));
> acceptor.setHandler(new org.apache.mina.common.IoHandlerAdapter());
> acceptor.bind();
> 
> java.net.SocketException: Address family not supported by protocol family:
> bind
>   at sun.nio.ch.Net.bind(Native Method)
>   at sun.nio.ch.DatagramChannelImpl.bind(DatagramChannelImpl.java:495)
>   at sun.nio.ch.DatagramSocketAdaptor.bind(DatagramSocketAdaptor.java:79)
>   at
> org.apache.mina.transport.socket.nio.NioDatagramAcceptor.open(NioDatagramAcceptor.java:117)
>   at
> org.apache.mina.transport.socket.nio.NioDatagramAcceptor.open(NioDatagramAcceptor.java:46)
>   at
> org.apache.mina.common.AbstractPollingConnectionlessIoAcceptor.registerHandles(AbstractPollingConnectionlessIoAcceptor.java:505)
>   at
> org.apache.mina.common.AbstractPollingConnectionlessIoAcceptor.access$500(AbstractPollingConnectionlessIoAcceptor.java:48)
>   at
> org.apache.mina.common.AbstractPollingConnectionlessIoAcceptor$Worker.run(AbstractPollingConnectionlessIoAcceptor.java:334)
>   at
> org.apache.mina.util.NamePreservingRunnable.run(NamePreservingRunnable.java:51)
>   at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
>   at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
>   at java.lang.Thread.run(Thread.java:595)
> 
> Is this something that is supposed to work, or is this not available in
> MINA?
> 
> Regards,
> Greg
> 

-- 
View this message in context: 
http://www.nabble.com/MINA-2.0-IPv6-NioDatagramAcceptor-tp15282319s16868p15302866.html
Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.

[jira] Commented: (ASYNCWEB-2) Merge AHC into AsyncWeb client

[Mike Heath (JIRA)]

[ 
https://issues.apache.org/jira/browse/ASYNCWEB-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565961#action_12565961
 ] 

Mike Heath commented on ASYNCWEB-2:
---

I refactored the AHC code to use the o.a.a.common.Cookie in revision 618826, 
http://svn.apache.org/viewvc?view=rev&revision=618826

> Merge AHC into AsyncWeb client
> --
>
> Key: ASYNCWEB-2
> URL: https://issues.apache.org/jira/browse/ASYNCWEB-2
> Project: Asyncweb
>  Issue Type: Task
>Reporter: Mike Heath
>Assignee: Mike Heath
>
> We need to merge the AHC code in 
> http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/ 
> into the AsyncWeb code in 
> http://svn.apache.org/repos/asf/mina/asyncweb/trunk/client/
> There's a considerable gap between the AHC codec and the AsyncWeb codec.  We 
> need to move the AHC code over to the AsyncWeb while at the same time make 
> sure that we haven't lost any features in AHC that are missing in AsyncWeb.  
> Once we have the AHC code using the AsyncWeb codec, we should be able to 
> replace the AsyncWeb client with the modified AHC client.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (DIRMINA-528) NioSocketConnector has a public constructor that takes a package scoped argument

[Sangjin Lee (JIRA)]

[ 
https://issues.apache.org/jira/browse/DIRMINA-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565898#action_12565898
 ] 

Sangjin Lee commented on DIRMINA-528:
-

Yeah I noticed that too...

> NioSocketConnector has a public constructor that takes a package scoped 
> argument
> 
>
> Key: DIRMINA-528
> URL: https://issues.apache.org/jira/browse/DIRMINA-528
> Project: MINA
>  Issue Type: Bug
>Affects Versions: 2.0.0-M1
>Reporter: Mike Heath
>
> NioSocketConnector has the public constructors:
> NioSocketConnector(IoProcessor processor)
> and
> NioSocketConnector(Executor executor, IoProcessor processor)
> however NioSession and the two classes that extend it are all package scoped. 
>  This makes it impossible to pass in an IoProcessor implementation without 
> getting a warning.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (DIRMINA-528) NioSocketConnector has a public constructor that takes a package scoped argument

[Mike Heath (JIRA)]

NioSocketConnector has a public constructor that takes a package scoped argument


 Key: DIRMINA-528
 URL: https://issues.apache.org/jira/browse/DIRMINA-528
 Project: MINA
  Issue Type: Bug
Affects Versions: 2.0.0-M1
Reporter: Mike Heath


NioSocketConnector has the public constructors:

NioSocketConnector(IoProcessor processor)

and

NioSocketConnector(Executor executor, IoProcessor processor)

however NioSession and the two classes that extend it are all package scoped.  
This makes it impossible to pass in an IoProcessor implementation without 
getting a warning.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (ASYNCWEB-2) Merge AHC into AsyncWeb client

[Mike Heath (JIRA)]

[ 
https://issues.apache.org/jira/browse/ASYNCWEB-2?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12565892#action_12565892
 ] 

Mike Heath commented on ASYNCWEB-2:
---

AHC has been merged into AsyncWeb Client as revision 618773, 
http://svn.apache.org/viewvc?view=rev&revision=618773

> Merge AHC into AsyncWeb client
> --
>
> Key: ASYNCWEB-2
> URL: https://issues.apache.org/jira/browse/ASYNCWEB-2
> Project: Asyncweb
>  Issue Type: Task
>Reporter: Mike Heath
>Assignee: Mike Heath
>
> We need to merge the AHC code in 
> http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/ 
> into the AsyncWeb code in 
> http://svn.apache.org/repos/asf/mina/asyncweb/trunk/client/
> There's a considerable gap between the AHC codec and the AsyncWeb codec.  We 
> need to move the AHC code over to the AsyncWeb while at the same time make 
> sure that we haven't lost any features in AHC that are missing in AsyncWeb.  
> Once we have the AHC code using the AsyncWeb codec, we should be able to 
> replace the AsyncWeb client with the modified AHC client.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (ASYNCWEB-2) Merge AHC into AsyncWeb client

[Mike Heath (JIRA)]

 [ 
https://issues.apache.org/jira/browse/ASYNCWEB-2?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mike Heath reassigned ASYNCWEB-2:
-

Assignee: Mike Heath

> Merge AHC into AsyncWeb client
> --
>
> Key: ASYNCWEB-2
> URL: https://issues.apache.org/jira/browse/ASYNCWEB-2
> Project: Asyncweb
>  Issue Type: Task
>Reporter: Mike Heath
>Assignee: Mike Heath
>
> We need to merge the AHC code in 
> http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/ 
> into the AsyncWeb code in 
> http://svn.apache.org/repos/asf/mina/asyncweb/trunk/client/
> There's a considerable gap between the AHC codec and the AsyncWeb codec.  We 
> need to move the AHC code over to the AsyncWeb while at the same time make 
> sure that we haven't lost any features in AHC that are missing in AsyncWeb.  
> Once we have the AHC code using the AsyncWeb codec, we should be able to 
> replace the AsyncWeb client with the modified AHC client.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-527) should be able to set connect timeout in milliseconds

[Sangjin Lee (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sangjin Lee updated DIRMINA-527:


Attachment: DIRMINA-527.patch

> should be able to set connect timeout in milliseconds
> -
>
> Key: DIRMINA-527
> URL: https://issues.apache.org/jira/browse/DIRMINA-527
> Project: MINA
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.0.8, 1.1.5, 2.0.0-M1
>Reporter: Sangjin Lee
> Attachments: DIRMINA-527.patch
>
>
> Currently, IoConnector allows setting connect timeouts only in seconds.  The 
> minimum value of allowed connect timeout is 1 second.  There are cases where 
> one needs to have a shorter connect timeout than 1 second and will finer 
> granularity than seconds.
> I suggest introducing the ability to set connect timeout in milliseconds and 
> deprecating the getter/setter in seconds in favor of the ms getter/setter.
> See the discussion thread at 
> http://www.nabble.com/connect-timeout-to15281787s16868.html.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-527) should be able to set connect timeout in milliseconds

[Sangjin Lee (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sangjin Lee updated DIRMINA-527:


Attachment: (was: DIRMINA-527.patch)

> should be able to set connect timeout in milliseconds
> -
>
> Key: DIRMINA-527
> URL: https://issues.apache.org/jira/browse/DIRMINA-527
> Project: MINA
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.0.8, 1.1.5, 2.0.0-M1
>Reporter: Sangjin Lee
> Attachments: DIRMINA-527.patch
>
>
> Currently, IoConnector allows setting connect timeouts only in seconds.  The 
> minimum value of allowed connect timeout is 1 second.  There are cases where 
> one needs to have a shorter connect timeout than 1 second and will finer 
> granularity than seconds.
> I suggest introducing the ability to set connect timeout in milliseconds and 
> deprecating the getter/setter in seconds in favor of the ms getter/setter.
> See the discussion thread at 
> http://www.nabble.com/connect-timeout-to15281787s16868.html.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (DIRMINA-527) should be able to set connect timeout in milliseconds

[Sangjin Lee (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DIRMINA-527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sangjin Lee updated DIRMINA-527:


Attachment: DIRMINA-527.patch

A proposed patch (based on the trunk).

- Introduces IoConnector.setConnectTimeoutMillis(), and deprecates 
getConnectTimeout()/setConnectTimeout().
- Adjust the select timeout to be the smaller of the connectTimeout() or 1 
second.

Please review the changes, and accept them if you guys are OK with it.  I'd 
also like to see the changes propagated to 1.1.x (and 1.0.x too?).  Do we need 
separate JIRA issues for them?

Thanks,
Sangjin



> should be able to set connect timeout in milliseconds
> -
>
> Key: DIRMINA-527
> URL: https://issues.apache.org/jira/browse/DIRMINA-527
> Project: MINA
>  Issue Type: Improvement
>  Components: Core
>Affects Versions: 1.0.8, 1.1.5, 2.0.0-M1
>Reporter: Sangjin Lee
> Attachments: DIRMINA-527.patch
>
>
> Currently, IoConnector allows setting connect timeouts only in seconds.  The 
> minimum value of allowed connect timeout is 1 second.  There are cases where 
> one needs to have a shorter connect timeout than 1 second and will finer 
> granularity than seconds.
> I suggest introducing the ability to set connect timeout in milliseconds and 
> deprecating the getter/setter in seconds in favor of the ms getter/setter.
> See the discussion thread at 
> http://www.nabble.com/connect-timeout-to15281787s16868.html.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (DIRMINA-527) should be able to set connect timeout in milliseconds

[Sangjin Lee (JIRA)]

should be able to set connect timeout in milliseconds
-

 Key: DIRMINA-527
 URL: https://issues.apache.org/jira/browse/DIRMINA-527
 Project: MINA
  Issue Type: Improvement
  Components: Core
Affects Versions: 1.1.5, 1.0.8, 2.0.0-M1
Reporter: Sangjin Lee


Currently, IoConnector allows setting connect timeouts only in seconds.  The 
minimum value of allowed connect timeout is 1 second.  There are cases where 
one needs to have a shorter connect timeout than 1 second and will finer 
granularity than seconds.

I suggest introducing the ability to set connect timeout in milliseconds and 
deprecating the getter/setter in seconds in favor of the ms getter/setter.

See the discussion thread at 
http://www.nabble.com/connect-timeout-to15281787s16868.html.



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [Asyncweb] Recent additions & Who work on what ? roadmap ?

[Alex Karasulu]

I just added all of us to the MINA group which asyncweb uses the permissions
scheme for.  Looks like most people were still in the directory group.
Anyways let me know if there are problems.

We still need someone to go after these issues that need now to be moved
into the ASYNCWEB project.


... ooops people having trouble with this on IRC.  Will fix and post back.

Alex

On Feb 5, 2008 1:58 PM, Mike Heath <[EMAIL PROTECTED]> wrote:

> Julien Vermillard wrote:
> > Hi,
> >
> > I commited a few change to aweb :
> >  - a ServiceResolver who use regexp for match service :
> > org.apache.asyncweb.server.resolver.PatternMatchResolver
> >  - a HttpService for simply serving static files
> > org.apache.asyncweb.examples.file.FileHttpService
> > with it's FileMain for running a test server
> >
> > What I'm going to work on :
> >  - good caching policies for FileHttpService because today it's always
> > a cache miss
> >  - changing the API for serving http content per chunk and not in a big
> > IoBuffer
> >
> > I'm commiting changes, but I'm just figured we don't really have a
> > roadmap, and I don't exacly who is working on what for Asyncweb.
> >
> > Except Alex directory refactoring, which look good and finished who is
> > working on what on the Asyncweb subject (server related not AHC
> > because it's pretty clear now on this subject) ?
> >
> > The idea is to know the step to achieve before firing a vote
> > for a release, or Asyncweb will starve in the trunk..
>
> We have a JIRA project https://issues.apache.org/jira/browse/ASYNCWEB.
> We should start using it.  I haven't checked but I would imagine that
> there are issues at Safehaus that should be moved over.  There are
> probably issues in Geronimo that should be moved over for AHC too.
>
> -Mike
>

Re: Mina and YAWS

[Mike Heath]

We don't have any any real benchmarks for AsyncWeb yet.  At least, I'm
not aware of any extensive benchamrks.  I would like to see this change
in the near future.  After all, you can't improve performance if you're
not measuring it.

That being said, the Yaws benchmark you sent is contrived and I don't
understand what they're trying to demonstrate with it.  From the page:

   Each session makes a very slow request to fetch a one byte file from
   machine 1. This is done by sending very slow HTTP GET requests (we
   break up the GET requests and send them character at a time, with
   about ten seconds between each character).

Where would you ever see traffic like that?  Nobody sends HTTP requests
one character at a time.  This is tomfoolery.  I'm not trying to defend
Apache or discredit Yaws.  I would just like to see a real benchmark.

-Mike


Ashish Sharma wrote:
> Hi guys
> 
> Has anyone done any benchmark comparison of Asynweb (or mina) with YAWS (web
> server in erlang).
> 
> This one compares Apache with YAWS.
> http://www.sics.se/~joe/apachevsyaws.html
> 
> 
> Thanks
> Ashish
> 

Re: [Asyncweb] Recent additions & Who work on what ? roadmap ?

[Mike Heath]

Julien Vermillard wrote:
> Hi,
> 
> I commited a few change to aweb :
>  - a ServiceResolver who use regexp for match service :
> org.apache.asyncweb.server.resolver.PatternMatchResolver
>  - a HttpService for simply serving static files
> org.apache.asyncweb.examples.file.FileHttpService
> with it's FileMain for running a test server
> 
> What I'm going to work on : 
>  - good caching policies for FileHttpService because today it's always
> a cache miss
>  - changing the API for serving http content per chunk and not in a big
> IoBuffer
> 
> I'm commiting changes, but I'm just figured we don't really have a
> roadmap, and I don't exacly who is working on what for Asyncweb.
> 
> Except Alex directory refactoring, which look good and finished who is
> working on what on the Asyncweb subject (server related not AHC
> because it's pretty clear now on this subject) ?
> 
> The idea is to know the step to achieve before firing a vote
> for a release, or Asyncweb will starve in the trunk..

We have a JIRA project https://issues.apache.org/jira/browse/ASYNCWEB.
We should start using it.  I haven't checked but I would imagine that
there are issues at Safehaus that should be moved over.  There are
probably issues in Geronimo that should be moved over for AHC too.

-Mike

Mina and YAWS

[Ashish Sharma]

Hi guys

Has anyone done any benchmark comparison of Asynweb (or mina) with YAWS (web
server in erlang).

This one compares Apache with YAWS.
http://www.sics.se/~joe/apachevsyaws.html


Thanks
Ashish

[jira] Created: (ASYNCWEB-2) Merge AHC into AsyncWeb client

[Mike Heath (JIRA)]

Merge AHC into AsyncWeb client
--

 Key: ASYNCWEB-2
 URL: https://issues.apache.org/jira/browse/ASYNCWEB-2
 Project: Asyncweb
  Issue Type: Task
Reporter: Mike Heath


We need to merge the AHC code in 
http://svn.apache.org/repos/asf/geronimo/sandbox/async-http-client-mina2/ into 
the AsyncWeb code in http://svn.apache.org/repos/asf/mina/asyncweb/trunk/client/

There's a considerable gap between the AHC codec and the AsyncWeb codec.  We 
need to move the AHC code over to the AsyncWeb while at the same time make sure 
that we haven't lost any features in AHC that are missing in AsyncWeb.  Once we 
have the AHC code using the AsyncWeb codec, we should be able to replace the 
AsyncWeb client with the modified AHC client.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[Asyncweb] Recent additions & Who work on what ? roadmap ?

[Julien Vermillard]

Hi,

I commited a few change to aweb :
 - a ServiceResolver who use regexp for match service :
org.apache.asyncweb.server.resolver.PatternMatchResolver
 - a HttpService for simply serving static files
org.apache.asyncweb.examples.file.FileHttpService
with it's FileMain for running a test server

What I'm going to work on : 
 - good caching policies for FileHttpService because today it's always
a cache miss
 - changing the API for serving http content per chunk and not in a big
IoBuffer

I'm commiting changes, but I'm just figured we don't really have a
roadmap, and I don't exacly who is working on what for Asyncweb.

Except Alex directory refactoring, which look good and finished who is
working on what on the Asyncweb subject (server related not AHC
because it's pretty clear now on this subject) ?

The idea is to know the step to achieve before firing a vote
for a release, or Asyncweb will starve in the trunk..

Julien

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Alex Karasulu]

Excellent thanks.

Alex

On Feb 5, 2008 9:50 AM, Maarten Bosteels <[EMAIL PROTECTED]> wrote:

> On Feb 5, 2008 10:07 AM, Alex Karasulu <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> wrote:
> >
> > > On Mon, 04 Feb 2008 22:02:19 -0700
> > > Jeff Genender <[EMAIL PROTECTED]> 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 rightno 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: connect timeout

[Sangjin Lee]

Right, that's why I said the connect timeout limitation seems tied to the
select timeout...
Hard-coded 1 second select timeout will interfere with sub-second connect
timeout value.  One obvious suggestion is to set the select timeout to be
the same as the connect timeout.  That way, we're pretty sure that the
connect timeout will be honored.

One small drawback is that we'd end up with a busy select loop if the
connect timeout is too small.  This could be prevented by having a minimum
connect/select timeout value...

Also, note that the 1-second timeout is pervasive elsewhere (like processor,
etc.).  Not sure if we need to change them also.  Maybe not right now...

If you guys don't mind, I'll file a bug (both for 1.1.x and 2.x) and submit
a patch also...  How's that sound?

BTW, what is up with the 1 second sleep in the try-catch clause in the same
code area?  We can leave it as is?

} catch (Throwable e) {

ExceptionMonitor.getInstance().exceptionCaught(e);


try {

Thread.sleep(1000);

} catch (InterruptedException e1) {

ExceptionMonitor.getInstance().exceptionCaught(e1);

}

}

Thanks,
Sangjin


On Feb 5, 2008 7:29 AM, Julien Vermillard <[EMAIL PROTECTED]> wrote:

> On Tue, 05 Feb 2008 13:55:15 +0100
> Niklas Therning <[EMAIL PROTECTED]> wrote:
> > You would also need to make sure that the current IoConnector
> > implementations can support millisecond timeouts. I think that would
> > mean that AbstractPollingIoConnector.Worker needs to be changed.
> > Specifically the line
> >
> > boolean selected = select(1000);
> >
> > To support milliseconds we could simply change this into
> >
> > boolean selected = select(1);
> >
> > but that would be very bad for performance.
> >
> > Instead, one could use an adaptive timeout in the call to select()
> > which depends on the current ConnectRequests' timeouts. Or totally
> > redesign things to use a ScheduledExecutorService or similar instead.
> >
>
> Yes Niklas is right, I forgot the impact on worker loop.
>
> At first look an adaptive select timeout or a redesign using some kind
> of ExecutorService doesn't look like a trivial move..
>
> Whats the lowest connect timeout needed if it's under 1 seconds ?
>
> Julien
>

Re: connect timeout

[Julien Vermillard]

On Tue, 05 Feb 2008 13:55:15 +0100
Niklas Therning <[EMAIL PROTECTED]> wrote:
> You would also need to make sure that the current IoConnector 
> implementations can support millisecond timeouts. I think that would 
> mean that AbstractPollingIoConnector.Worker needs to be changed. 
> Specifically the line
> 
> boolean selected = select(1000);
> 
> To support milliseconds we could simply change this into
> 
> boolean selected = select(1);
> 
> but that would be very bad for performance.
> 
> Instead, one could use an adaptive timeout in the call to select()
> which depends on the current ConnectRequests' timeouts. Or totally
> redesign things to use a ScheduledExecutorService or similar instead.
>
 
Yes Niklas is right, I forgot the impact on worker loop.

At first look an adaptive select timeout or a redesign using some kind
of ExecutorService doesn't look like a trivial move..

Whats the lowest connect timeout needed if it's under 1 seconds ?

Julien

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Maarten Bosteels]

On Feb 5, 2008 10:07 AM, Alex Karasulu <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 04 Feb 2008 22:02:19 -0700
> > Jeff Genender <[EMAIL PROTECTED]> 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 rightno 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

[Jeff Genender]

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

[Rick McGuire]

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 <[EMAIL PROTECTED]> 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



  



  

Re: connect timeout

[Niklas Therning]

Maarten Bosteels wrote:

On Feb 5, 2008 11:07 AM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:

  

Maarten Bosteels wrote:


I agree that nobody will pass in hours or days, but IMHO  it improves
readability a lot:

connector.setConnectTimeout(250, TimeUnit.MILLISECONDS);
or
connector.setConnectTimeout(250);

Especially when one is changing the API from seconds to millis, we
  

should


try to make
it unambiguous and it's inline with a lot of the java.util.concurrentAPI.

  

The problem with changing the method parameters semantic is that it does
not align anymore with the underlying semantic of the select( timeout )
method :


 select

public abstract int *select*(long timeout)
   throws IOException <
http://java.sun.com/j2se/1.4.2/docs/api/java/io/IOException.html>

...

*Parameters:*
   |timeout| - If positive, block for up to timeout milliseconds, more
   or less...

The method should use milliseconds, no need to be explicit with that,
IMHO. I agree with Julien on that.





ok, I can live with that.
But you wouldn't even change the metod name ?
So users who are porting there code from mina 1.x to 2.x
will have to be very careful, or their timeouts will shrink with a factor of
1000.


Maarten

  
You would also need to make sure that the current IoConnector 
implementations can support millisecond timeouts. I think that would 
mean that AbstractPollingIoConnector.Worker needs to be changed. 
Specifically the line


   boolean selected = select(1000);

To support milliseconds we could simply change this into

   boolean selected = select(1);

but that would be very bad for performance.

Instead, one could use an adaptive timeout in the call to select() which 
depends on the current ConnectRequests' timeouts. Or totally redesign 
things to use a ScheduledExecutorService or similar instead.


--
Niklas Therning
www.spamdrain.net

Re: connect timeout

[Maarten Bosteels]

On Feb 5, 2008 11:07 AM, Emmanuel Lecharny <[EMAIL PROTECTED]> wrote:

> Maarten Bosteels wrote:
> >>
> >
> > I agree that nobody will pass in hours or days, but IMHO  it improves
> > readability a lot:
> >
> > connector.setConnectTimeout(250, TimeUnit.MILLISECONDS);
> > or
> > connector.setConnectTimeout(250);
> >
> > Especially when one is changing the API from seconds to millis, we
> should
> > try to make
> > it unambiguous and it's inline with a lot of the java.util.concurrentAPI.
> >
> The problem with changing the method parameters semantic is that it does
> not align anymore with the underlying semantic of the select( timeout )
> method :
>
>
>  select
>
> public abstract int *select*(long timeout)
>throws IOException <
> http://java.sun.com/j2se/1.4.2/docs/api/java/io/IOException.html>
>
> ...
>
> *Parameters:*
>|timeout| - If positive, block for up to timeout milliseconds, more
>or less...
>
> The method should use milliseconds, no need to be explicit with that,
> IMHO. I agree with Julien on that.
>


ok, I can live with that.
But you wouldn't even change the metod name ?
So users who are porting there code from mina 1.x to 2.x
will have to be very careful, or their timeouts will shrink with a factor of
1000.


Maarten

Re: connect timeout

[Emmanuel Lecharny]

Maarten Bosteels wrote:



I agree that nobody will pass in hours or days, but IMHO  it improves
readability a lot:

connector.setConnectTimeout(250, TimeUnit.MILLISECONDS);
or
connector.setConnectTimeout(250);

Especially when one is changing the API from seconds to millis, we should
try to make
it unambiguous and it's inline with a lot of the java.util.concurrent API.
  
The problem with changing the method parameters semantic is that it does 
not align anymore with the underlying semantic of the select( timeout ) 
method :



 select

public abstract int *select*(long timeout)
   throws IOException 


...

*Parameters:*
   |timeout| - If positive, block for up to timeout milliseconds, more
   or less...

The method should use milliseconds, no need to be explicit with that, 
IMHO. I agree with Julien on that.




--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re : connect timeout

[Edouard De Oliveira]

connector.setConnectTimeoutInMillis(250);

This satisfies both of you :) 
My 2 cents ^^
 
Cordialement, Regards,
-Edouard De Oliveira-
http://tedorg.free.fr/en/main.php

- Message d'origine 
De : Maarten Bosteels <[EMAIL PROTECTED]>
À : dev@mina.apache.org
Envoyé le : Mardi, 5 Février 2008, 10h25mn 01s
Objet : Re: connect timeout

On 
Feb 
5, 
2008 
10:04 
AM, 
Julien 
Vermillard 
<[EMAIL PROTECTED]> 
wrote:

> 
On 
Tue, 
5 
Feb 
2008 
09:53:27 
+0100
> 
"Maarten 
Bosteels" 
<[EMAIL PROTECTED]> 
wrote:
>
> 
> 
On 
Feb 
5, 
2008 
9:17 
AM, 
Julien 
Vermillard 
<[EMAIL PROTECTED]>
> 
> 
wrote:
> 
>
> 
> 
> 
On 
Mon, 
04 
Feb 
2008 
18:52:37 
-0700
> 
> 
> 
Jeff 
Genender 
<[EMAIL PROTECTED]> 
wrote:
> 
> 
>
> 
> 
> 
> 
great 
question..Im 
interested 
in 
this 
as 
well.
> 
> 
> 
>
> 
> 
> 
> 
Jeff
> 
> 
> 
>
> 
> 
> 
> 
Sangjin 
Lee 
wrote:
> 
> 
> 
> 
> 
I 
had 
a 
quick 
question 
on 
the 
connect 
timeout...
> 
> 
> 
> 
> 
The 
connect 
timeout 
supplied 
to 
connectors 
is 
in 
the 
unit 
of
> 
> 
> 
> 
> 
seconds, 
and 
it 
appears 
the 
minimum 
value 
you 
can 
use 
is 
1
> 
> 
> 
> 
> 
second 
( 
AbstractIoConnector.setConnectTimeout() 
in 
the 
case 
of
> 
> 
> 
> 
> 
the 
trunk). 
Is 
this 
by 
design?  
I 
can 
see 
cases 
where 
one 
needs
> 
> 
> 
> 
> 
to 
have 
a 
shorter 
connect 
timeout, 
but 
it 
seems 
it 
is 
not
> 
> 
> 
> 
> 
possible 
today. 
One 
solution 
might 
be 
to 
use
> 
> 
> 
> 
> 
ConnectFuture.join() 
with 
a 
timeout, 
but 
that 
works 
only 
if 
you
> 
> 
> 
> 
> 
want 
to 
block 
until 
it 
times 
out...
> 
> 
> 
> 
>
> 
> 
> 
> 
> 
It 
also 
seems 
that 
this 
minimum 
timeout 
value 
is 
somewhat 
tied
> 
> 
> 
> 
> 
to 
the 
timeout 
value 
used 
in 
the 
select() 
loop 
in 
the
> 
> 
> 
> 
> 
connector, 
which 
is 
hard 
coded 
to 
be 
1 
second.  
Would 
it 
be 
a
> 
> 
> 
> 
> 
good 
idea 
to 
support 
connect 
timeout 
values 
in 
milliseconds,
> 
> 
> 
> 
> 
and 
make 
it 
shorter 
than 
1 
second?
> 
> 
> 
> 
>
> 
> 
> 
> 
> 
Thanks,
> 
> 
> 
> 
> 
Sangjin
> 
> 
> 
> 
>
> 
> 
>
> 
> 
> 
Hi,
> 
> 
>
> 
> 
> 
Apparently 
it's 
doable, 
the 
timeout 
value 
is 
multiplicated 
by 
1000
> 
> 
> 
before 
being 
placed 
in 
the 
ConnectionRequest 
deadline.
> 
> 
> 
As 
far 
I 
understand 
it, 
it's 
not 
a 
big 
deal 
but 
an 
API 
change.
> 
>
> 
>
> 
> 
+1 
for 
sub-second 
timeout 
values
> 
> 
And 
I 
think 
it's 
best 
to 
change 
the 
API 
now, 
before 
cutting 
2.0-M1
> 
> 
How 
about 
adding 
a 
java.util.concurrent.TimeUnit 
parameter 
to
> 
> 
setConnectTimeout() 
?
> 
>
> 
> 
Maarten
> 
>
> 
>
> 
> 
>
> 
> 
> 
Julien
> 
> 
>
>
> 
I 
think 
specifying 
a 
millisecond 
param 
is 
enough, 
nobody 
will 
pass
> 
hour/day/month/picosecond 
based 
timeout 
values. 
It'll 
complexify 
the
> 
API 
for 
no 
much 
gain.
>

I 
agree 
that 
nobody 
will 
pass 
in 
hours 
or 
days, 
but 
IMHO  
it 
improves
readability 
a 
lot:

connector.setConnectTimeout(250, 
TimeUnit.MILLISECONDS);
or
connector.setConnectTimeout(250);

Especially 
when 
one 
is 
changing 
the 
API 
from 
seconds 
to 
millis, 
we 
should
try 
to 
make
it 
unambiguous 
and 
it's 
inline 
with 
a 
lot 
of 
the 
java.util.concurrent 
API.

Maarten

>
> 
Julien
>





  
_ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail 
http://mail.yahoo.fr

Re: connect timeout

[Maarten Bosteels]

On Feb 5, 2008 10:04 AM, Julien Vermillard <[EMAIL PROTECTED]> wrote:

> On Tue, 5 Feb 2008 09:53:27 +0100
> "Maarten Bosteels" <[EMAIL PROTECTED]> wrote:
>
> > On Feb 5, 2008 9:17 AM, Julien Vermillard <[EMAIL PROTECTED]>
> > wrote:
> >
> > > On Mon, 04 Feb 2008 18:52:37 -0700
> > > Jeff Genender <[EMAIL PROTECTED]> wrote:
> > >
> > > > great question..Im interested in this as well.
> > > >
> > > > Jeff
> > > >
> > > > Sangjin Lee wrote:
> > > > > I had a quick question on the connect timeout...
> > > > > The connect timeout supplied to connectors is in the unit of
> > > > > seconds, and it appears the minimum value you can use is 1
> > > > > second ( AbstractIoConnector.setConnectTimeout() in the case of
> > > > > the trunk). Is this by design?  I can see cases where one needs
> > > > > to have a shorter connect timeout, but it seems it is not
> > > > > possible today. One solution might be to use
> > > > > ConnectFuture.join() with a timeout, but that works only if you
> > > > > want to block until it times out...
> > > > >
> > > > > It also seems that this minimum timeout value is somewhat tied
> > > > > to the timeout value used in the select() loop in the
> > > > > connector, which is hard coded to be 1 second.  Would it be a
> > > > > good idea to support connect timeout values in milliseconds,
> > > > > and make it shorter than 1 second?
> > > > >
> > > > > Thanks,
> > > > > Sangjin
> > > > >
> > >
> > > Hi,
> > >
> > > Apparently it's doable, the timeout value is multiplicated by 1000
> > > before being placed in the ConnectionRequest deadline.
> > > As far I understand it, it's not a big deal but an API change.
> >
> >
> > +1 for sub-second timeout values
> > And I think it's best to change the API now, before cutting 2.0-M1
> > How about adding a java.util.concurrent.TimeUnit parameter to
> > setConnectTimeout() ?
> >
> > Maarten
> >
> >
> > >
> > > Julien
> > >
>
> I think specifying a millisecond param is enough, nobody will pass
> hour/day/month/picosecond based timeout values. It'll complexify the
> API for no much gain.
>

I agree that nobody will pass in hours or days, but IMHO  it improves
readability a lot:

connector.setConnectTimeout(250, TimeUnit.MILLISECONDS);
or
connector.setConnectTimeout(250);

Especially when one is changing the API from seconds to millis, we should
try to make
it unambiguous and it's inline with a lot of the java.util.concurrent API.

Maarten

>
> Julien
>

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Alex Karasulu]

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 <[EMAIL PROTECTED]> wrote:

> On Mon, 04 Feb 2008 22:02:19 -0700
> Jeff Genender <[EMAIL PROTECTED]> 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 rightno 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: connect timeout

[Julien Vermillard]

On Tue, 5 Feb 2008 09:53:27 +0100
"Maarten Bosteels" <[EMAIL PROTECTED]> wrote:

> On Feb 5, 2008 9:17 AM, Julien Vermillard <[EMAIL PROTECTED]>
> wrote:
> 
> > On Mon, 04 Feb 2008 18:52:37 -0700
> > Jeff Genender <[EMAIL PROTECTED]> wrote:
> >
> > > great question..Im interested in this as well.
> > >
> > > Jeff
> > >
> > > Sangjin Lee wrote:
> > > > I had a quick question on the connect timeout...
> > > > The connect timeout supplied to connectors is in the unit of
> > > > seconds, and it appears the minimum value you can use is 1
> > > > second ( AbstractIoConnector.setConnectTimeout() in the case of
> > > > the trunk). Is this by design?  I can see cases where one needs
> > > > to have a shorter connect timeout, but it seems it is not
> > > > possible today. One solution might be to use
> > > > ConnectFuture.join() with a timeout, but that works only if you
> > > > want to block until it times out...
> > > >
> > > > It also seems that this minimum timeout value is somewhat tied
> > > > to the timeout value used in the select() loop in the
> > > > connector, which is hard coded to be 1 second.  Would it be a
> > > > good idea to support connect timeout values in milliseconds,
> > > > and make it shorter than 1 second?
> > > >
> > > > Thanks,
> > > > Sangjin
> > > >
> >
> > Hi,
> >
> > Apparently it's doable, the timeout value is multiplicated by 1000
> > before being placed in the ConnectionRequest deadline.
> > As far I understand it, it's not a big deal but an API change.
> 
> 
> +1 for sub-second timeout values
> And I think it's best to change the API now, before cutting 2.0-M1
> How about adding a java.util.concurrent.TimeUnit parameter to
> setConnectTimeout() ?
> 
> Maarten
> 
> 
> >
> > Julien
> >

I think specifying a millisecond param is enough, nobody will pass
hour/day/month/picosecond based timeout values. It'll complexify the
API for no much gain.

Julien

Re: connect timeout

[Alex Karasulu]

+1 - not enough granularity with seconds.

Alex

On Feb 5, 2008 3:53 AM, Maarten Bosteels <[EMAIL PROTECTED]> wrote:

> On Feb 5, 2008 9:17 AM, Julien Vermillard <[EMAIL PROTECTED]> wrote:
>
> > On Mon, 04 Feb 2008 18:52:37 -0700
> > Jeff Genender <[EMAIL PROTECTED]> wrote:
> >
> > > great question..Im interested in this as well.
> > >
> > > Jeff
> > >
> > > Sangjin Lee wrote:
> > > > I had a quick question on the connect timeout...
> > > > The connect timeout supplied to connectors is in the unit of
> > > > seconds, and it appears the minimum value you can use is 1 second (
> > > > AbstractIoConnector.setConnectTimeout() in the case of the trunk).
> > > > Is this by design?  I can see cases where one needs to have a
> > > > shorter connect timeout, but it seems it is not possible today.
> > > > One solution might be to use ConnectFuture.join() with a timeout,
> > > > but that works only if you want to block until it times out...
> > > >
> > > > It also seems that this minimum timeout value is somewhat tied to
> > > > the timeout value used in the select() loop in the connector, which
> > > > is hard coded to be 1 second.  Would it be a good idea to support
> > > > connect timeout values in milliseconds, and make it shorter than 1
> > > > second?
> > > >
> > > > Thanks,
> > > > Sangjin
> > > >
> >
> > Hi,
> >
> > Apparently it's doable, the timeout value is multiplicated by 1000
> > before being placed in the ConnectionRequest deadline.
> > As far I understand it, it's not a big deal but an API change.
>
>
> +1 for sub-second timeout values
> And I think it's best to change the API now, before cutting 2.0-M1
> How about adding a java.util.concurrent.TimeUnit parameter to
> setConnectTimeout() ?
>
> Maarten
>
>
> >
> > Julien
> >
>

Re: connect timeout

[Maarten Bosteels]

On Feb 5, 2008 9:17 AM, Julien Vermillard <[EMAIL PROTECTED]> wrote:

> On Mon, 04 Feb 2008 18:52:37 -0700
> Jeff Genender <[EMAIL PROTECTED]> wrote:
>
> > great question..Im interested in this as well.
> >
> > Jeff
> >
> > Sangjin Lee wrote:
> > > I had a quick question on the connect timeout...
> > > The connect timeout supplied to connectors is in the unit of
> > > seconds, and it appears the minimum value you can use is 1 second (
> > > AbstractIoConnector.setConnectTimeout() in the case of the trunk).
> > > Is this by design?  I can see cases where one needs to have a
> > > shorter connect timeout, but it seems it is not possible today.
> > > One solution might be to use ConnectFuture.join() with a timeout,
> > > but that works only if you want to block until it times out...
> > >
> > > It also seems that this minimum timeout value is somewhat tied to
> > > the timeout value used in the select() loop in the connector, which
> > > is hard coded to be 1 second.  Would it be a good idea to support
> > > connect timeout values in milliseconds, and make it shorter than 1
> > > second?
> > >
> > > Thanks,
> > > Sangjin
> > >
>
> Hi,
>
> Apparently it's doable, the timeout value is multiplicated by 1000
> before being placed in the ConnectionRequest deadline.
> As far I understand it, it's not a big deal but an API change.


+1 for sub-second timeout values
And I think it's best to change the API now, before cutting 2.0-M1
How about adding a java.util.concurrent.TimeUnit parameter to
setConnectTimeout() ?

Maarten


>
> Julien
>

NioProcessor select(..) question

[Julien Vermillard]

In NioProcessor .java you got the following select implementation :

@Override
protected boolean select(int timeout) throws Exception {
   return selector.select(1000) > 0;
}

The hard-coded 1 sec value smell fishy, it's normal ? if so I think
I'll place a comment for indicate it's not a mistake.

Julien

Re: connect timeout

[Julien Vermillard]

On Mon, 04 Feb 2008 18:52:37 -0700
Jeff Genender <[EMAIL PROTECTED]> wrote:

> great question..Im interested in this as well.
> 
> Jeff
> 
> Sangjin Lee wrote:
> > I had a quick question on the connect timeout...
> > The connect timeout supplied to connectors is in the unit of
> > seconds, and it appears the minimum value you can use is 1 second (
> > AbstractIoConnector.setConnectTimeout() in the case of the trunk).
> > Is this by design?  I can see cases where one needs to have a
> > shorter connect timeout, but it seems it is not possible today.
> > One solution might be to use ConnectFuture.join() with a timeout,
> > but that works only if you want to block until it times out...
> > 
> > It also seems that this minimum timeout value is somewhat tied to
> > the timeout value used in the select() loop in the connector, which
> > is hard coded to be 1 second.  Would it be a good idea to support
> > connect timeout values in milliseconds, and make it shorter than 1
> > second?
> > 
> > Thanks,
> > Sangjin
> > 

Hi,

Apparently it's doable, the timeout value is multiplicated by 1000
before being placed in the ConnectionRequest deadline.
As far I understand it, it's not a big deal but an API change.

Julien

Re: [AsyncHttpClient] On bringing the code bases and communities together

[Julien Vermillard]

On Mon, 04 Feb 2008 22:02:19 -0700
Jeff Genender <[EMAIL PROTECTED]> 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 rightno 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