Re: [AsyncWeb] Client redesign
On Feb 8, 2008, at 11:27 PM, Alan D. Cabrera wrote: On Jan 29, 2008, at 5:46 PM, Tuure Laurinolli wrote: David M. Lloyd wrote: So basically there's been a number of suggestions as to what to name these things. Here are the two options: Name from pastebin Option 1 Option 2 - -- AsyncHttpClientHttpClientFactory HttpClient HttpRequestor HttpClientHttpConnector HttpFuture HttpFutureHttpFuture Going with Option 1, I took a look at what the current MINA AHC would look like with this API - the result is at http://www.laurinolli.fi/~tazle/http-client-trivial-implementation.patch It isn't exactly like current AHC (it's not possible to close connections at the moment), but pretty close. The AHC tests run, for example. This implementation gets rid of the resource leaks caused by constantly creating and not disposing NioSocketConnectors, but does not even try to address pipelining or large requests. Of course nothing is decided until everyone has had a chance to weigh in. Indeed - I don't particularly like the code I wrote, but I think it needed to be written in order to see what hoops there were to jump through. I think the HttpHandler and HttpFuture interfaces are bad, especially the way IoHandler events are converted into HttpFuture/ HttpHandler events. HttpClient on the other hand seems like an interface we should have. It seems ideal for hiding the complexity of possible pipelining or request pooling. I like how this thread is going. But I can't help but think that we're driving the API from the implementors' standpoint and not the users. IMO, we need to start with a metaphor. The one that I envision is not too far from what's being discussed but points out some, what I feel to be, deficiencies in what you propose Tuure. I like the metaphor of a browser. The HttpClientFactory is nice as the holder of the shared resources. The HttpClient can be thought of as a browser. It holds cookies, etc. With that said, the URL belongs in the request not the HttpClient constructor. Bah. Catching up on other threads... Regards, Alan
Re: connect timeout
On Feb 4, 2008, at 5:29 PM, 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? It doesn't matter to me but I'm just curious. Why would one want a timeout less than a second? Regards, Alan
[AsyncWeb] Need an async client now
What should I use? I prefer the API from Geronimo but I see that it doesn't get built in in Mina. I would also prefer to use Mina 1.x and wait until Mina 2.x shakes itself out. So, I'm going to toss out the idea of releasing the new API as 1.0 and we can release the new Mina 2.x based API as 2.0. Thoughts? Regards, Alan
[AsyncWeb] data collection instrumentation
What we have looks pretty neat. Here is some information that I would love to get my hands on: - first byte - not really REQUEST_STARTED - SSL negotiation completed - last byte - most likely REQUEST_COMPLETED Regards, Alan
Re: [AsyncWeb] SSL server and client certs
Look in the Trust Factory..that is exactly where you need to look. Currently the SSL impl is based on communication and anonymous only (I was working on the SSL client cert but got side tracked with my new job). You probably should allow for a setter that allow you to set a certificate object and, to make things easy on the user, a way to pull one from a file and keystore (Im just thing about how to make this API as simple as possible). The Trust Factory is exactly the area I would recommend adding the enhancement. Alan...this is awesome stuff...thanks for taking such an interest! Jeff Alan D. Cabrera wrote: I need this. What will it take for me to add it? It looks like it I need to flesh out that trust factory. Regards, Alan
Re: [AsyncWeb] Need an async client now
I agree...I think 2.0 is the way to go...the enhancements really make it nicer. Jeff Alex Karasulu wrote: On Feb 9, 2008 12:39 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: On Feb 9, 2008, at 6:09 AM, Alex Karasulu wrote: On Feb 9, 2008 3:56 AM, Alan D. Cabrera [EMAIL PROTECTED] wrote: What should I use? I prefer the API from Geronimo but I see that it doesn't get built in in Mina. I would also prefer to use Mina 1.x and wait until Mina 2.x shakes itself out. So, I'm going to toss out the idea of releasing the new API as 1.0 and we can release the new Mina 2.x based API as 2.0. Thoughts? IMO I think looking ahead towards the use of MINA 2.0 is the best route here and it seems that people have already taken care of the merge. Perhaps there's some emails that you may have missed on the commits@ list and here. Mike already merged the two I think unless I'm mistaken which may be the case since I have been catching up as well. Well, it is in SVN. At the moment there are two clients in there. The newer one does not get added to the Jar artifact per its POM configuration. I really prefer the newer one from Geronimo. Oh and 1.0 whichever MINA it's based on makes sense to me but jumping to 2.0 to denote the use of MINA 2.0 sounds good too. I just think we should stick to MINA 2.0 through and through because of the gains made therein. Only the Pope and my mother-in-law are infallible. I think that MINA 2.x rocks and will be a resounding success but I think it will take a little bit for things to shake out. IIUC, there's still discussion to fiddle with bits of 2.0. I just want to start w/ MINA 1.x for now. Its characteristics are known and it's been around the block a few times. I am happy to do the scut work for a 1.0 release. Loved the comment about the Pope and your MIL :). You can always work on a 1.0 based version but we're still far from a release as well since the PMC is just mobilizing around these new projects. Also note that a MINA 2.0release is imminent. Furthermore there's been considerable effort put into keeping all the people interested in Asyncweb working together towards a common goal. Sticking to MINA 2.0 overall will be in the best interest of the community. We're seeing great synergy where core MINA folks are working closely with the AHC developers. It's really great to see ramping up and took a bit of effort. If there are any hick-ups along the way with MINA 2.0 you have my word and I'm sure the word of others' here to resolve them immediately. Fragmenting this community into those that work on 1.0 and 2.0 based version of AHC just when the collaboration is ramping up would not be good. Please don't presume the time frame is going to be longer when based on MINA 2.0. Whatever the issue may be for you we'll try our best to accommodate whatever it may be. Is there some other problem that you have not mentioned which requires a 1.0 release besides just doing it rapidly? Thanks, Alex
Re: [mina] Sending datagrams without connection
David M. Lloyd wrote: Wilson Yeung wrote: It would be quite nice to be able to do something equivalent to sendto() with a DatagramAcceptor or a DatagramConnector. I've written a UDP application based on Mina that sends precisely 1 packet to 1 million end points, and waits for 1 packet from 1 million end points. Each 2 packet exchange is 1 Mina IoSession, and I continuously reuse the same 1000 - 5000 prebound IoSession objects, that is, I keep 1000 - 5000 of these exchanges in flight at a time. My opinion is that there should simply be one IoSession for all datagram sockets. Let me clarify - I mean one IoSession for *each* datagram socket. - DML
Re: [mina] Sending datagrams without connection
Wilson Yeung wrote: It would be quite nice to be able to do something equivalent to sendto() with a DatagramAcceptor or a DatagramConnector. I've written a UDP application based on Mina that sends precisely 1 packet to 1 million end points, and waits for 1 packet from 1 million end points. Each 2 packet exchange is 1 Mina IoSession, and I continuously reuse the same 1000 - 5000 prebound IoSession objects, that is, I keep 1000 - 5000 of these exchanges in flight at a time. My opinion is that there should simply be one IoSession for all datagram sockets. MINA cannot have a valid notion of a session because the underlying protocol might not have such a notion. Creating IoSessions for every packet or pair of packets is supremely wasteful. - DML
Re: [AsyncWeb] Need an async client now
Alex Karasulu wrote: snip IMO I think looking ahead towards the use of MINA 2.0 is the best route here and it seems that people have already taken care of the merge. Perhaps there's some emails that you may have missed on the commits@ list and here. Mike already merged the two I think unless I'm mistaken which may be the case since I have been catching up as well. I'm still working on the merge. It's a lot of work. There are a lot of very big differences between the AHC codec and the AsyncWeb codec. The AsyncWeb codec is designed to be independent of the client/server that uses it while the AHC codec is tightly coupled to the AHC client. Refactoring AHC to use the AsyncWeb codec has been challenging. It will be a while before the merge is complete. Oh and 1.0 whichever MINA it's based on makes sense to me but jumping to 2.0to denote the use of MINA 2.0 sounds good too. I just think we should stick to MINA 2.0 through and through because of the gains made therein. I'm of the opinion that we should use MINA 2.0. I think AsyncWeb will draw a lot of attention to MINA which will help us work out any kinks in MINA 2.0. MINA 2.0 also has a lot of new features that can be utilized to minimize the number of threads needed for MINA apps. -Mike
Re: [AsyncWeb] Client redesign
David M. Lloyd wrote: 3) Session things like cookie management should be maintained at a higher level - maybe even a separate HttpSession object that can be provided to each request, on a read-only or read-write basis I hope higher level here means that people who actually use HTTP in stateless fashion won't be bothered by it :) 5) The (optional) ability to specify an IoConnector to the client Hmm, IoConnector probably can only be shared by different HTTP clients, and not some other protocols that add their own filters to it. It think it's a good idea anyway, at least indirectly through some HttpClientFactory or whatnot.
Re: [AsyncWeb] Client redesign
On Feb 9, 2008, at 7:42 AM, David M. Lloyd wrote: Alan D. Cabrera wrote: I like the metaphor of a browser. The HttpClientFactory is nice as the holder of the shared resources. The HttpClient can be thought of as a browser. It holds cookies, etc. With that said, the URL belongs in the request not the HttpClient constructor. That's a good thought. The reason that the URL was originally put in the HttpClient constructor (as well as the request) was to allow the management of connections to be separated from the URL request. Realistically, a URL could be dropped in favor of discrete scheme/hostname/port parameters on an connection object. Though it's not always desirable to do this, so specifying and maintaining a physical connection should be an optional kind of thing to do. Not sure why one needs to specify the URL so far in advance. I'm not picky as far as API goes, but I'd like to see the following (many of these items have been stated by others, but here's a roundup): 1) The ability to control connections independently of requests 2) Pipelining keepalive (which should be a direct consequence of [1]) Good stuff. I'm glad these important features will most likely not drive the API. 3) Session things like cookie management should be maintained at a higher level - maybe even a separate HttpSession object that can be provided to each request, on a read-only or read-write basis 3a) HttpSession should be a interface of some type, so the user can intercept cookie reads and writes and act on them directly Could this not be in the HttpClient? If we follow the metaphor of a browser, it makes sense to store the session there. 4) Future objects for any blocking operation I was thinking that we could have a Future object that implements an AHC callback interface. This would keep the client simple. Those needing synchronous mechanisms could drop in an instance of this Future object. Just trying to prevent something like: ah.doThisWay().addListener(bar); foo = ahc.doAnotherWay(); foo.await(); 5) The (optional) ability to specify an IoConnector to the client This could maybe be specified in the factory to use when allocating clients. Regards, Alan
Re: [AsyncWeb] Need an async client now
Sticking to MINA 2.0 overall will be in the best interest of the community I couldn't agree more. I really see no reason to stick with 1.x In fact, I think we should 'release' MINA-2.0-M1 asap. Maarten On Feb 9, 2008 7:49 PM, Alex Karasulu [EMAIL PROTECTED] wrote: On Feb 9, 2008 12:39 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: On Feb 9, 2008, at 6:09 AM, Alex Karasulu wrote: On Feb 9, 2008 3:56 AM, Alan D. Cabrera [EMAIL PROTECTED] wrote: What should I use? I prefer the API from Geronimo but I see that it doesn't get built in in Mina. I would also prefer to use Mina 1.x and wait until Mina 2.x shakes itself out. So, I'm going to toss out the idea of releasing the new API as 1.0 and we can release the new Mina 2.x based API as 2.0. Thoughts? IMO I think looking ahead towards the use of MINA 2.0 is the best route here and it seems that people have already taken care of the merge. Perhaps there's some emails that you may have missed on the commits@ list and here. Mike already merged the two I think unless I'm mistaken which may be the case since I have been catching up as well. Well, it is in SVN. At the moment there are two clients in there. The newer one does not get added to the Jar artifact per its POM configuration. I really prefer the newer one from Geronimo. Oh and 1.0 whichever MINA it's based on makes sense to me but jumping to 2.0 to denote the use of MINA 2.0 sounds good too. I just think we should stick to MINA 2.0 through and through because of the gains made therein. Only the Pope and my mother-in-law are infallible. I think that MINA 2.x rocks and will be a resounding success but I think it will take a little bit for things to shake out. IIUC, there's still discussion to fiddle with bits of 2.0. I just want to start w/ MINA 1.x for now. Its characteristics are known and it's been around the block a few times. I am happy to do the scut work for a 1.0 release. Loved the comment about the Pope and your MIL :). You can always work on a 1.0 based version but we're still far from a release as well since the PMC is just mobilizing around these new projects. Also note that a MINA 2.0release is imminent. Furthermore there's been considerable effort put into keeping all the people interested in Asyncweb working together towards a common goal. Sticking to MINA 2.0 overall will be in the best interest of the community. We're seeing great synergy where core MINA folks are working closely with the AHC developers. It's really great to see ramping up and took a bit of effort. If there are any hick-ups along the way with MINA 2.0 you have my word and I'm sure the word of others' here to resolve them immediately. Fragmenting this community into those that work on 1.0 and 2.0 based version of AHC just when the collaboration is ramping up would not be good. Please don't presume the time frame is going to be longer when based on MINA 2.0. Whatever the issue may be for you we'll try our best to accommodate whatever it may be. Is there some other problem that you have not mentioned which requires a 1.0 release besides just doing it rapidly? Thanks, Alex
Re: [AsyncWeb] Client redesign
Alan D. Cabrera wrote: snip That's a good thought. The reason that the URL was originally put in the HttpClient constructor (as well as the request) was to allow the management of connections to be separated from the URL request. Realistically, a URL could be dropped in favor of discrete scheme/hostname/port parameters on an connection object. Though it's not always desirable to do this, so specifying and maintaining a physical connection should be an optional kind of thing to do. Not sure why one needs to specify the URL so far in advance. I like the idea of specifying a base URI for the HttpClient. So you use a base URI of something like http://somedomain.foo; and subsequent requests could then do something like get(/bar) which would do a GET on http://somedomain.foo/bar;. This would require further abstraction than what AHC has to offer currently. -Mike snip
Re: [AsyncWeb] AHC Wiki Space Created
Awesome...thanks Alan. Alan D. Cabrera wrote: I've made this space for us: http://cwiki.apache.org/confluence/display/AHC/Index Regards, Alan
Re: [AsyncWeb] Client redesign
On Feb 9, 2008, at 12:13 PM, Mike Heath wrote: David M. Lloyd wrote: Alan D. Cabrera wrote: I like the metaphor of a browser. The HttpClientFactory is nice as the holder of the shared resources. The HttpClient can be thought of as a browser. It holds cookies, etc. With that said, the URL belongs in the request not the HttpClient constructor. That's a good thought. The reason that the URL was originally put in the HttpClient constructor (as well as the request) was to allow the management of connections to be separated from the URL request. Realistically, a URL could be dropped in favor of discrete scheme/hostname/port parameters on an connection object. Though it's not always desirable to do this, so specifying and maintaining a physical connection should be an optional kind of thing to do. I'm not picky as far as API goes, but I'd like to see the following (many of these items have been stated by others, but here's a roundup): 1) The ability to control connections independently of requests 2) Pipelining keepalive (which should be a direct consequence of [1]) 3) Session things like cookie management should be maintained at a higher level - maybe even a separate HttpSession object that can be provided to each request, on a read-only or read-write basis 3a) HttpSession should be a interface of some type, so the user can intercept cookie reads and writes and act on them directly 4) Future objects for any blocking operation 5) The (optional) ability to specify an IoConnector to the client Hope I'm making sense. There are a lot of different use cases that need to be addressed in the AsyncWeb client API. I've got a small laundry list of use cases rattling around in my head that I would like support in AsyncWeb. Do we have a wiki available for AsyncWeb where we can start posting some of our ideas We can drop our ideas down in this http://cwiki.apache.org/confluence/display/AHC/Index Regards, Alan
[AsyncWeb] AHC Wiki Space Created
I've made this space for us: http://cwiki.apache.org/confluence/display/AHC/Index Regards, Alan
Re: [AsyncWeb] Client redesign
Mike Heath wrote: I like the idea of specifying a base URI for the HttpClient. So you use a base URI of something like http://somedomain.foo; and subsequent requests could then do something like get(/bar) which would do a GET on http://somedomain.foo/bar;. This would require further abstraction than what AHC has to offer currently. Also, think about virtual hosts. You may have 10 different hostnames that all connect to the same physical host. In this case you still need to specify the full URL per request. Also, proxies and load-balancers have this same requirement - furthermore, in a load-balancing situation, you may even need to make requests with (for example) a scheme of https to a non-SSL host. So this should be designed with the maximum flexibility possible. - DML
Re: [AsyncWeb] Client redesign
On Feb 9, 2008, at 3:56 PM, Mike Heath wrote: Alan D. Cabrera wrote: snip That's a good thought. The reason that the URL was originally put in the HttpClient constructor (as well as the request) was to allow the management of connections to be separated from the URL request. Realistically, a URL could be dropped in favor of discrete scheme/hostname/port parameters on an connection object. Though it's not always desirable to do this, so specifying and maintaining a physical connection should be an optional kind of thing to do. Not sure why one needs to specify the URL so far in advance. I like the idea of specifying a base URI for the HttpClient. So you use a base URI of something like http://somedomain.foo; and subsequent requests could then do something like get(/bar) which would do a GET on http://somedomain.foo/bar;. This would require further abstraction than what AHC has to offer currently. I think that this bit can be, and is, handled with URLs. I don't see the advantage of adding complexity to the metaphor and, hence, the API. Regards, Alan
Re: [AsyncWeb] Client redesign
On Feb 9, 2008, at 4:29 PM, David M. Lloyd wrote: Mike Heath wrote: I like the idea of specifying a base URI for the HttpClient. So you use a base URI of something like http://somedomain.foo; and subsequent requests could then do something like get(/bar) which would do a GET on http://somedomain.foo/bar;. This would require further abstraction than what AHC has to offer currently. Also, think about virtual hosts. You may have 10 different hostnames that all connect to the same physical host. In this case you still need to specify the full URL per request. Also, proxies and load-balancers have this same requirement - furthermore, in a load-balancing situation, you may even need to make requests with (for example) a scheme of https to a non-SSL host. So this should be designed with the maximum flexibility possible. Not sure if you're arguing for putting a URL in the constructor as well as the request. All the above scenarios are cleanly handled w/ URLs. Regards, Alan
Re: [AsyncWeb] AHC Wiki Space Created
Alan could you delete this space and make one for Asyncweb instead of just for the client? Thanks, Alex On Feb 9, 2008 6:31 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: I've made this space for us: http://cwiki.apache.org/confluence/display/AHC/Index Regards, Alan
Re: [AsyncWeb] AHC Wiki Space Created
+1. Didn't we decide to provide both ahc and asyncweb server under the asyncweb subproject? Trustin 2008-02-09 (토), 20:27 -0500, Alex Karasulu 쓰시길: Alan could you delete this space and make one for Asyncweb instead of just for the client? Thanks, Alex On Feb 9, 2008 6:31 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: I've made this space for us: http://cwiki.apache.org/confluence/display/AHC/Index Regards, Alan -- what we call human nature is actually human habit -- http://gleamynode.net/ signature.asc Description: This is a digitally signed message part
Re: [AsyncWeb] AHC Wiki Space Created
On Feb 9, 2008 8:32 PM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote: +1. Didn't we decide to provide both ahc and asyncweb server under the asyncweb subproject? Yeah I think Alan just forgot. No worries we've now got a confluence administrator to help out :). Alex 2008-02-09 (토), 20:27 -0500, Alex Karasulu 쓰시길: Alan could you delete this space and make one for Asyncweb instead of just for the client? Thanks, Alex On Feb 9, 2008 6:31 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: I've made this space for us: http://cwiki.apache.org/confluence/display/AHC/Index Regards, Alan -- what we call human nature is actually human habit -- http://gleamynode.net/
Re: [AsyncWeb] AHC Wiki Space Created
Here you go: http://cwiki.apache.org/confluence/display/AWEB/Index Regards, Alan On Feb 9, 2008, at 5:45 PM, Alex Karasulu wrote: On Feb 9, 2008 8:32 PM, 이희승 (Trustin Lee) [EMAIL PROTECTED] wrote: +1. Didn't we decide to provide both ahc and asyncweb server under the asyncweb subproject? Yeah I think Alan just forgot. No worries we've now got a confluence administrator to help out :). Alex 2008-02-09 (토), 20:27 -0500, Alex Karasulu 쓰시길: Alan could you delete this space and make one for Asyncweb instead of just for the client? Thanks, Alex On Feb 9, 2008 6:31 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: I've made this space for us: http://cwiki.apache.org/confluence/display/AHC/Index Regards, Alan -- what we call human nature is actually human habit -- http://gleamynode.net/
