Re: [AsyncWeb] Need an async client now
Is it ready? You're only at M1. What are the next milestones planned before you hit beta? Regards, Alan On Feb 9, 2008, at 3:56 PM, Maarten Bosteels wrote: 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
On Feb 9, 2008, at 3:22 PM, Alan D. Cabrera wrote: On Feb 9, 2008, at 7:42 AM, David M. Lloyd wrote: 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(); So, I was thinking that you would send requests like so: ahc.send(url, listener); I realize that URL could be in a request object but I've left that bit, which might need further discussion, out for the sake of this discussion. I'm also starting w/ the Geronimo AHC because I am most familiar with it. To use a FutureResponseV object which implements AsyncHttpClientCallback one would: FutureResponseApplicationResponse futureResonse = new FutureResponseApplicationResponse(builderListener); ahc.send(url, builderListener); Here the send call would see that it's being passed an instance of FutureResponse and inject the information that the FutureResponse needs to be able to cancel the request. The listener builderListener is quite different from the former listener. It actually builds the ApplicationResponse from HTTP response and calls setValue(V value). This releases a latch for any call to V get() to proceed. Calls that return nothing could always use Void. The cool thing about this is that the API stays clean while obtaining much more power. Regards, Alan
Re: [AsyncWeb] Client redesign
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. This isn't a metaphor, it's an API. Using a metaphor to help conceptualize what you're trying to accomplish can be helpful, but there's no point in carrying it any farther than that. Once you start rejecting an idea because it doesn't fit you metaphor, you've stepped over that line. To properly design a useful API, the only thing that matters are the functional requirements (i.e., what usecases must the API support?). In any case, yes, allowing the user to specify a URI to both a connection and a request would be sufficient to solve this problem. The key difference that I want to point out is, the request URI should not be required to be relative to the connection URI; consequently, the connection URI should not have a path, query, or fragment part (since the URI is used only for the purposes of extracting the scheme, host, and port). In addition, the user- info part should be part of the request URI (since it can change on a per-request basis), not the connection URI. The limitation on what would be allowed on a connection URI is the reason that I suggested earlier that the API could accept discrete scheme, hostname, and port parts - since the rest of the URI is not useful anyway. But since either method satisfies the requirements (it's just a question of aesthetics at this point), I'm satisfied either way. - DML
Re: [AsyncWeb] Client redesign
Alan D. Cabrera wrote: On Feb 9, 2008, at 3:22 PM, Alan D. Cabrera wrote: On Feb 9, 2008, at 7:42 AM, David M. Lloyd wrote: 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(); So, I was thinking that you would send requests like so: ahc.send(url, listener); This is a departure from the rest of MINA though, in which the idiom is more like this: ahc.send(request).setListener(listener); // does not block or: ahc.send(request).get(); // blocks using IoFuture and similar objects. I think it would be wise to remain consistent with the MINA idiom in this case. This method has the advantage of using java.util.concurrent-style future objects as well as listeners as proposed above. - DML
Re: [AsyncWeb] Client redesign
David M. Lloyd wrote: The limitation on what would be allowed on a connection URI is the reason that I suggested earlier that the API could accept discrete scheme, hostname, and port parts - since the rest of the URI is not useful anyway. But since either method satisfies the requirements (it's just a question of aesthetics at this point), I'm satisfied either way. More arguments both ways: Requiring hostname and port instead of an URI for the connection makes the user of the connection do URI parsing, which is somewhat ugly, and quite repetitive. For the casual user, passing in the URI and letting the library handle the ugly bits would be easier. However, parsing the URI into hostname and port in the connection adds failure modes to the connection, and requires the library to decide what to do in ambiguous cases (is it actually specified somewhere that port for an HTTP URI is 80 if not specified in the URI, for example?). Of course, the casual user probably doesn't care about connection pooling, and possibly not even about pipelining and keep-alive, he just wants a component that takes an HttpRequest, does some magic and gets an HttpResponse back to the callback he gave to the component.
Re: [AsyncWeb] Client redesign
Tuure Laurinolli wrote: Of course, the casual user probably doesn't care about connection pooling, and possibly not even about pipelining and keep-alive, he just wants a component that takes an HttpRequest, does some magic and gets an HttpResponse back to the callback he gave to the component. Yes, this is my thinking as well - the casual user wants a simplified API, while the advanced user wants a more detailed interface. - DML
Re: [AsyncWeb] Client redesign
David M. Lloyd wrote: Yes, this is my thinking as well - the casual user wants a simplified API, while the advanced user wants a more detailed interface. Certainly no reason not to offer both capabilities ;-) Jeff - DML
Re: [AsyncWeb] Client redesign
Alan D. Cabrera wrote: I see and take your point. It is six of one and half a dozen of another. What I'm confused about is why we need to initially specify anything outside of the actual request. What problem are we trying to solve? Maybe I'm misunderstanding what you are espousing so let me put it in my own words and you tell me if it's accurate. Please ignore the argument of using URIs or discrete parameters for me moment because I think that they are obscuring my real concern. HttpClient client = HttpClientFactory.create(baseURI); client.send(/foo?pet=cat) If this is accurate, I don't understand the need for the baseURI. Maybe this is a MINA convention? OK, I see where the disconnect is. We agree that the high-level API should work as you describe. What was discussed earlier was a second, lower layer to the API - one in which the user can take direct control over the actual physical connection and impose their own policy. Use cases for the lower- level API would include load-balancing, proxies, and that sort of thing: a lower-level API for lower-level HTTP functions. This low-level API would, through some mechanism, allow connections to be established and maintained independently of the request mechanism - but in order to do so, there must be a means to specify the actual connection information: protocol (scheme), hostname, and port. How this is done is unimportant, as long as the functionality is present. This way you get a balance of power and ease-of-use. Hopefully this clarifies what I was trying to say. There was a bit of prior context to the discussion, which I guess I was relying on a bit too much. :-) - DML
Re: [AsyncWeb] Client redesign
On Feb 10, 2008, at 10:35 AM, David M. Lloyd wrote: Alan D. Cabrera wrote: On Feb 9, 2008, at 3:22 PM, Alan D. Cabrera wrote: On Feb 9, 2008, at 7:42 AM, David M. Lloyd wrote: 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(); So, I was thinking that you would send requests like so: ahc.send(url, listener); This is a departure from the rest of MINA though, in which the idiom is more like this: ahc.send(request).setListener(listener); // does not block or: ahc.send(request).get(); // blocks using IoFuture and similar objects. I think it would be wise to remain consistent with the MINA idiom in this case. This method has the advantage of using java.util.concurrent-style future objects as well as listeners as proposed above. Ok, makes sense to me and there's great value at carrying on that convention in AHC. Regards, Alan
Re: [AsyncWeb] Need an async client now
Hello, On Feb 10, 2008 5:28 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: Is it ready? You're only at M1. What are the next milestones planned before you hit beta? The version numbering scheme is described at the bottom of http://mina.apache.org/downloads.html [1] IMO we should have created 2.0-M0 a few months ago. But for some reason we have been postponing it as long as there were open JIRA issues that could require an API change. According to [1] we are allowed to make API changes between M1 and M2 but of course it's nicer for the user if we can avoid it. I just had a look at JIRA at there were more open issues than I thought (6) but no show-stoppers AFAICS. Maybe we should have a vote about cutting 2.0-M0 ? Maarten Regards, Alan On Feb 9, 2008, at 3:56 PM, Maarten Bosteels wrote: 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] Need an async client now
On Feb 10, 2008, at 11:35 AM, Maarten Bosteels wrote: Hello, On Feb 10, 2008 5:28 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: Is it ready? You're only at M1. What are the next milestones planned before you hit beta? The version numbering scheme is described at the bottom of http://mina.apache.org/downloads.html [1] IMO we should have created 2.0-M0 a few months ago. But for some reason we have been postponing it as long as there were open JIRA issues that could require an API change. According to [1] we are allowed to make API changes between M1 and M2 but of course it's nicer for the user if we can avoid it. I just had a look at JIRA at there were more open issues than I thought (6) but no show-stoppers AFAICS. Maybe we should have a vote about cutting 2.0-M0 ? Maybe I'm being dense. You mean 2.0-RC1? When do you guys cut a branch to stabilize your beta? Does it depend on the situation? Regards, Alan
Re: [AsyncWeb] Client redesign
On Feb 10, 2008, at 10:05 AM, David M. Lloyd wrote: 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. This isn't a metaphor, it's an API. Using a metaphor to help conceptualize what you're trying to accomplish can be helpful, but there's no point in carrying it any farther than that. Once you start rejecting an idea because it doesn't fit you metaphor, you've stepped over that line. To properly design a useful API, the only thing that matters are the functional requirements (i.e., what usecases must the API support?). We shall agreed to disagree here. I fully understand the need for compelling use cases to drive the API. A clean metaphor means a clean API. A great metaphor helps users quickly and accurately assimilate an API. Slavishly extending an API in an ad hoc manner, and I'm not claiming that this is what you are doing, to support use cases more often than not leads to a Byzantine API that is hard to use. A good metaphor is very important. In any case, yes, allowing the user to specify a URI to both a connection and a request would be sufficient to solve this problem. The key difference that I want to point out is, the request URI should not be required to be relative to the connection URI; consequently, the connection URI should not have a path, query, or fragment part (since the URI is used only for the purposes of extracting the scheme, host, and port). In addition, the user- info part should be part of the request URI (since it can change on a per-request basis), not the connection URI. The limitation on what would be allowed on a connection URI is the reason that I suggested earlier that the API could accept discrete scheme, hostname, and port parts - since the rest of the URI is not useful anyway. But since either method satisfies the requirements (it's just a question of aesthetics at this point), I'm satisfied either way. I see and take your point. It is six of one and half a dozen of another. What I'm confused about is why we need to initially specify anything outside of the actual request. What problem are we trying to solve? Maybe I'm misunderstanding what you are espousing so let me put it in my own words and you tell me if it's accurate. Please ignore the argument of using URIs or discrete parameters for me moment because I think that they are obscuring my real concern. HttpClient client = HttpClientFactory.create(baseURI); client.send(/foo?pet=cat) If this is accurate, I don't understand the need for the baseURI. Maybe this is a MINA convention? Regards, Alan
Re: [AsyncWeb] SSL server and client certs
The way it stands now, AHC takes a javax.net.ssl.SSLContext object as a way to configure/handle SSL. While this provides a maximum flexibility (one can create any type of configuration and trust/key management as he/she sees fit), perhaps one could use easier steps of providing more standard options in trust/key management in creating SSLContext. Thanks, Sangjin On Feb 9, 2008 9:58 AM, Jeff Genender [EMAIL PROTECTED] wrote: 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] data collection instrumentation
That is a great idea. It should not be hard to add these events... Regards, Sangjin On Feb 9, 2008 1:49 AM, Alan D. Cabrera [EMAIL PROTECTED] wrote: 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] Client redesign
Going back on some of the points here... On Jan 29, 2008 2:25 PM, Mike Heath [EMAIL PROTECTED] wrote: Connecting - Connecting is done as a blocking operation. In Jeff Geneder's AHC branch in the Geronimo sandbox, thread pools are being used for asynchronous connecting. This is unfortunate since MINA already has this functionality and does it in a much lighter weight manner than using a thread pool. I'm a little confused as to what you mean when you say connecting is done as a blocking operation. You are not saying AHC's connect is done as a blocking operation, right? :) As for the thread pool, I thought Mina's socket connector involves a thread pool (Executor) one way or the other, no? Is there a way to use connectors without involving a thread pool (whether the caller supplies one or the socket connector constructors creates one)? Completion Notification - With the existing AHC, there's a single callback for the Client. I REALLY like the observable future pattern that MINA uses. With each asynchronous operation, a future object is returned. This future object can be used to block until the operation completes. The future is also observable so you can also register one or more completion listeners with the future. This makes it real easy to do a fork/join like operation like: future1 = doAsynch1(); future2 = doAsynch2(); future3 = doAsynch3(); future1.await() future2.await() future3.await() or use an event driven approach like: doAsynch1().addListener(...); doAsynch2().addListener(...); doAsynch3().addListener(...); This provides maximum flexibility. This should be incorporated into AsyncWeb client. If you look at the current AHC code, it actually *does* use both future (ResponseFuture) and a callback (AsyncHttpClientCallback). Both correspond to the future and the future listener, so it ended up being something very similar to what mina's future does. It would take a trivial refactoring to reshape it to look like Mina's future. Another thing it supports is a completion queue. One can fire multiple non-blocking send() calls to multiple URLs, and sit on the completion queue to handle the results as they arrive. Although callers can write their own code to do things like this, supporting it at the API level would be a nice thing to keep. This comes in pretty handy in a scatter-and-gather situation... My 2 cents... Thanks, Sangjin
Re: connect timeout
I can see cases where one might need a very short connect timeout. If your use case requires a very low fault tolerance and if you would rather fail calls than waiting for any longer than is necessary, then 1 second might not be an adequate minimum value. The characteristic would be a high-load situation where low latency (i.e. high bandwidth) is normally expected and required. For example, if one set of services is making calls to another set of services within a single network (i.e. intranet) in high volumes, then the expectation on the latency is usually very low. Normally calls should succeed within a very short amount of time. Suppose the remote services start having problems and suddenly connects and reads are taking longer. Having a short connect timeout and a short read timeout is a good way to *contain* that risk. If connect timeout can only be 1 second or longer, then there would be many situations where the problems from that remote service will quickly spread over to any calling services and have a cascading effect... Thanks, Sangjin On Feb 9, 2008 12:39 AM, Alan D. Cabrera [EMAIL PROTECTED] wrote: 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
Re: [AsyncWeb] Need an async client now
Until 2.0 GA we should leave the trunk as is. When we go to GA after some number of milestones then we can create the 2.0 branch which will only include bug fixes. Right now the bleeding edge is the trunk. This is where all new features and API changes occur. I think we can do milestone releases while there are JIRA issues associated with new features and API changes. Then we can announce a feature/API freeze. We can release some GA candidates that stabilize the trunk in preparation for the GA release: not that we're not stable but this option exists. Then when we all have agreed that a GA should be cut we can branch, tag and release. The trunk becomes 2.1 or whatever we like to call it. Only bug fixes occur on the 2.0 branch. New features and API changes go into 2.1 in the trunk. Does this sound reasonable? BTW we should have cut a M1 or M0 (the first milestone release) from the trunk a while back. I had asked when this would happen. There is no limit to the number of milestone releases we can have. So let's pump one out. If something pops up that presents some urgency we can release again. Let's follow the release early, release often mantra. Alex On Feb 10, 2008 4:05 PM, Maarten Bosteels [EMAIL PROTECTED] wrote: On Feb 10, 2008 9:05 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: On Feb 10, 2008, at 11:35 AM, Maarten Bosteels wrote: Hello, On Feb 10, 2008 5:28 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: Is it ready? You're only at M1. What are the next milestones planned before you hit beta? The version numbering scheme is described at the bottom of http://mina.apache.org/downloads.html [1] IMO we should have created 2.0-M0 a few months ago. But for some reason we have been postponing it as long as there were open JIRA issues that could require an API change. According to [1] we are allowed to make API changes between M1 and M2 but of course it's nicer for the user if we can avoid it. I just had a look at JIRA at there were more open issues than I thought (6) but no show-stoppers AFAICS. Maybe we should have a vote about cutting 2.0-M0 ? Maybe I'm being dense. You mean 2.0-RC1? When do you guys cut a branch to stabilize your beta? Does it depend on the situation? Good question. In my very humble opinion cutting 2-0-M1 means : (a) creating a 2.0 branch and (b) creating a 2.0-M1 tag All further development for 2.0 would then happen on the 2.0 branch instead of on the trunk. Isn't that the usual way to proceed ? Maarten Regards, Alan
Re: connect timeout
+1 This was well put Sangjin. After reading this I realized that may deployments of AHC will have similar needs: sub-second timeouts are critical. Alex On Feb 10, 2008 7:10 PM, Sangjin Lee [EMAIL PROTECTED] wrote: I can see cases where one might need a very short connect timeout. If your use case requires a very low fault tolerance and if you would rather fail calls than waiting for any longer than is necessary, then 1 second might not be an adequate minimum value. The characteristic would be a high-load situation where low latency (i.e. high bandwidth) is normally expected and required. For example, if one set of services is making calls to another set of services within a single network (i.e. intranet) in high volumes, then the expectation on the latency is usually very low. Normally calls should succeed within a very short amount of time. Suppose the remote services start having problems and suddenly connects and reads are taking longer. Having a short connect timeout and a short read timeout is a good way to *contain* that risk. If connect timeout can only be 1 second or longer, then there would be many situations where the problems from that remote service will quickly spread over to any calling services and have a cascading effect... Thanks, Sangjin On Feb 9, 2008 12:39 AM, Alan D. Cabrera [EMAIL PROTECTED] wrote: 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
Re: [AsyncWeb] Need an async client now
2008-02-10 (일), 00:56 +0100, Maarten Bosteels 쓰시길: 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. Yeah, go MINA! :) Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ signature.asc Description: This is a digitally signed message part
Re: [AsyncWeb] Client redesign
First off, I agree with what's under consensus so far in this thread. Great to see more people get involved! :) 2008-02-09 (토), 17:01 -0800, Alan D. Cabrera 쓰시길: 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. You mean the java.net.URL class? Trustin -- 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
Great. Thanks, Alan! Cheers, Trustin 2008-02-09 (토), 17:58 -0800, Alan D. Cabrera 쓰시길: 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/ -- what we call human nature is actually human habit -- http://gleamynode.net/ signature.asc Description: This is a digitally signed message part
Re: [AsyncWeb] Client redesign
On Feb 11, 2008 1:28 AM, Mike Heath [EMAIL PROTECTED] wrote: Jeff Genender wrote: David M. Lloyd wrote: Yes, this is my thinking as well - the casual user wants a simplified API, while the advanced user wants a more detailed interface. Certainly no reason not to offer both capabilities ;-) I totally agree. I think we should offer a very simple straight forward API for the simple cases where the developer only wants asynchronism and doesn't want to worry about the details. At the same time, there are some very complex use cases that we have to account for that would require a more complex API. I keep imaging providing a very flexible API that can accommodate large uploads/downloads, deal with chunked encoding and COMET technique, handle pipelining, etc. We could then wrap this flexible API with a simpler API for dealing with simple requests. I like this layered approach. I also like the list of features/usage senarios especially AJAX/COMET centric features. At some point I think we need to have a similar discussion about this and the server. Alex
Re: connect timeout
I would have to give Sangjin's arguments a +0. I think he makes some good points but I don't think I would say that support sub-second timeouts is _critical_ until people start asking for it. Load balancing is a case where connect timeouts would be important and all of the load balancers I've configured (both hardware and software loadbalancers) default to a connect timeout of 1 second. -Mike Alex Karasulu wrote: +1 This was well put Sangjin. After reading this I realized that may deployments of AHC will have similar needs: sub-second timeouts are critical. Alex On Feb 10, 2008 7:10 PM, Sangjin Lee [EMAIL PROTECTED] wrote: I can see cases where one might need a very short connect timeout. If your use case requires a very low fault tolerance and if you would rather fail calls than waiting for any longer than is necessary, then 1 second might not be an adequate minimum value. The characteristic would be a high-load situation where low latency (i.e. high bandwidth) is normally expected and required. For example, if one set of services is making calls to another set of services within a single network (i.e. intranet) in high volumes, then the expectation on the latency is usually very low. Normally calls should succeed within a very short amount of time. Suppose the remote services start having problems and suddenly connects and reads are taking longer. Having a short connect timeout and a short read timeout is a good way to *contain* that risk. If connect timeout can only be 1 second or longer, then there would be many situations where the problems from that remote service will quickly spread over to any calling services and have a cascading effect... Thanks, Sangjin On Feb 9, 2008 12:39 AM, Alan D. Cabrera [EMAIL PROTECTED] wrote: 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
Re: [AsyncWeb] Need an async client now
The new logging features in SLF4J and removing IoSessionLogger were what was holding up an M1 release. Where do we stand on the logging front right now? -Mike Maarten Bosteels wrote: On Feb 10, 2008 9:05 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: On Feb 10, 2008, at 11:35 AM, Maarten Bosteels wrote: Hello, On Feb 10, 2008 5:28 PM, Alan D. Cabrera [EMAIL PROTECTED] wrote: Is it ready? You're only at M1. What are the next milestones planned before you hit beta? The version numbering scheme is described at the bottom of http://mina.apache.org/downloads.html [1] IMO we should have created 2.0-M0 a few months ago. But for some reason we have been postponing it as long as there were open JIRA issues that could require an API change. According to [1] we are allowed to make API changes between M1 and M2 but of course it's nicer for the user if we can avoid it. I just had a look at JIRA at there were more open issues than I thought (6) but no show-stoppers AFAICS. Maybe we should have a vote about cutting 2.0-M0 ? Maybe I'm being dense. You mean 2.0-RC1? When do you guys cut a branch to stabilize your beta? Does it depend on the situation? Good question. In my very humble opinion cutting 2-0-M1 means : (a) creating a 2.0 branch and (b) creating a 2.0-M1 tag All further development for 2.0 would then happen on the 2.0 branch instead of on the trunk. Isn't that the usual way to proceed ? Maarten Regards, Alan
Re: [AsyncWeb] Client redesign
Jeff Genender wrote: David M. Lloyd wrote: Yes, this is my thinking as well - the casual user wants a simplified API, while the advanced user wants a more detailed interface. Certainly no reason not to offer both capabilities ;-) I totally agree. I think we should offer a very simple straight forward API for the simple cases where the developer only wants asynchronism and doesn't want to worry about the details. At the same time, there are some very complex use cases that we have to account for that would require a more complex API. I keep imaging providing a very flexible API that can accommodate large uploads/downloads, deal with chunked encoding and COMET technique, handle pipelining, etc. We could then wrap this flexible API with a simpler API for dealing with simple requests. For example, if all I want to do is a couple of simple GET requests, I should haven't to build an HttpRequest object. I should be able to provide a URL and do a simple GET. -Mike
Re: [AsyncWeb] Client redesign
Most of the statements I made were referring to the AsyncWeb client code and not the latest AHC code that came over from Geronimo. There is a huge difference here and I think that's what led to a lot of the confusion over the statements I made. -Mike Sangjin Lee wrote: Going back on some of the points here... On Jan 29, 2008 2:25 PM, Mike Heath [EMAIL PROTECTED] wrote: Connecting - Connecting is done as a blocking operation. In Jeff Geneder's AHC branch in the Geronimo sandbox, thread pools are being used for asynchronous connecting. This is unfortunate since MINA already has this functionality and does it in a much lighter weight manner than using a thread pool. I'm a little confused as to what you mean when you say connecting is done as a blocking operation. You are not saying AHC's connect is done as a blocking operation, right? :) As for the thread pool, I thought Mina's socket connector involves a thread pool (Executor) one way or the other, no? Is there a way to use connectors without involving a thread pool (whether the caller supplies one or the socket connector constructors creates one)? Completion Notification - With the existing AHC, there's a single callback for the Client. I REALLY like the observable future pattern that MINA uses. With each asynchronous operation, a future object is returned. This future object can be used to block until the operation completes. The future is also observable so you can also register one or more completion listeners with the future. This makes it real easy to do a fork/join like operation like: future1 = doAsynch1(); future2 = doAsynch2(); future3 = doAsynch3(); future1.await() future2.await() future3.await() or use an event driven approach like: doAsynch1().addListener(...); doAsynch2().addListener(...); doAsynch3().addListener(...); This provides maximum flexibility. This should be incorporated into AsyncWeb client. If you look at the current AHC code, it actually *does* use both future (ResponseFuture) and a callback (AsyncHttpClientCallback). Both correspond to the future and the future listener, so it ended up being something very similar to what mina's future does. It would take a trivial refactoring to reshape it to look like Mina's future. Another thing it supports is a completion queue. One can fire multiple non-blocking send() calls to multiple URLs, and sit on the completion queue to handle the results as they arrive. Although callers can write their own code to do things like this, supporting it at the API level would be a nice thing to keep. This comes in pretty handy in a scatter-and-gather situation... My 2 cents... Thanks, Sangjin
Re: [AsyncWeb] Client redesign
David M. Lloyd wrote: Alan D. Cabrera wrote: snip So, I was thinking that you would send requests like so: ahc.send(url, listener); This is a departure from the rest of MINA though, in which the idiom is more like this: ahc.send(request).setListener(listener); // does not block To clarify, we should support send(...).addListener(listener) so that we can have multiple completion listeners. One of my big pet peeves with AHC as it stands now is that it only accepts one completion listener and you have to specify that completion listener when the request is initiated. One of the really powerful features of MINA is that you can add a completion listener to a future at any time as well as add as many listeners you want. -Mike snip
