[jira] Resolved: (ASYNCWEB-5) asyncweb build is broken
[ https://issues.apache.org/jira/browse/ASYNCWEB-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rick McGuire resolved ASYNCWEB-5. - Resolution: Fixed Committed revision 633433. Thanks Sangjin. asyncweb build is broken Key: ASYNCWEB-5 URL: https://issues.apache.org/jira/browse/ASYNCWEB-5 Project: Asyncweb Issue Type: Bug Reporter: Sangjin Lee Priority: Blocker Attachments: ASYNCWEB-5.patch The asyncweb build is broken at AsyncHttpClientTest. Also, there is a broken unit test once you get past the build breakage. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [AsyncWeb] build broken w/ last checkin
I agree with Alan...I understood that the G version was going away now that we built community over here on this. Comments? Jeff Alan Cabrera wrote: On Mar 1, 2008, at 8:12 PM, Alan D. Cabrera wrote: AsyncHttpClient was changed w/ the last checkin on 2/26 and now the build is broken. I looked at the actual changes. I'm just trying to grok the changes because I realize that I am new here. It seems that the old AsyncHttpClient is still evolving? How does this fit in with the plans for the old AsyncHttpClient, the new Geronimo AsyncHttpClient, and the new API that's currently in discussion? I had thought, maybe naively, that we were going to roll the old two into the new one. Regards, Alan
Re: [AsyncWeb] build broken w/ last checkin
I am in agreement as well. I would like to see this merge happen quickly so the users see progress and there's no longer any need to keep the G branch alive. Someone said to me you need to get cookin in the kitchen when the guests arrive :). Then we can just start releasing some milestones that people can use and we can track/patch etc. It's nice now that MINA 2.0-m1 is out. This means we can release an Asyncweb milestone as a whole. Also another thing I want people to think about is that this project is one unit rather than just a client. There's a server in there too and we can release it together. The community around this is coming together fast and that's just great which means there's a good potential for graduating this project eventually. These are my hopes for Asyncweb. Alex On Tue, Mar 4, 2008 at 9:33 AM, Jeff Genender [EMAIL PROTECTED] wrote: I agree with Alan...I understood that the G version was going away now that we built community over here on this. Comments? Jeff Alan Cabrera wrote: On Mar 1, 2008, at 8:12 PM, Alan D. Cabrera wrote: AsyncHttpClient was changed w/ the last checkin on 2/26 and now the build is broken. I looked at the actual changes. I'm just trying to grok the changes because I realize that I am new here. It seems that the old AsyncHttpClient is still evolving? How does this fit in with the plans for the old AsyncHttpClient, the new Geronimo AsyncHttpClient, and the new API that's currently in discussion? I had thought, maybe naively, that we were going to roll the old two into the new one. Regards, Alan
Re: [AsyncWeb] Ideas for client
On Mar 3, 2008, at 12:22 PM, Sangjin Lee wrote: I haven't had a chance to add my use case: the scatter-and-gather situation where one uses a completion queue to handle the result. Hopefully I'll do that some time this week... I also would like to discuss how to get back to the request while processing the response. It is often desirable and sometimes even necessary to find out the request from the response. How should we address this? One could obviously have a direct reference to the Request from the Response, but there are drawbacks. It basically means that the requests will stick around until the response goes out of scope. This may have some negative consequences especially if requests are large objects and/or mutable. Another approach might be to refer only to certain parts of the request from the response; e.g. the request URL. However, it's not clear if it's only the request URL callers would be interested in, and then the list of these attributes may grow pretty quickly. What do others think? I like the idea of being able to attach a user object, or handle if you will, to the request. This handle will be passed back in the response. Regards, Alan
MINA NioDatagramAcceptor reading one UDP packet at a time
If I want to have a program that received UDP packets. Do I need to write a protocol filter in order to make sure my IoHandler.messageReceived() method only gets one packet at a time? Thanks
Re: [Asyncweb] server API for commiting HTTPReponse in chunk
First off, sorry for the LATE response tot his thread. My comments are
below inline.
이희승 (Trustin Lee) wrote:
Adding commit(Partial)?Response method causes HttpResponse to keep a
response to IoSession, which doesn't sound good to me. What do you
think about providing another setContent method with QueueIoBuffer?
We could provide a special implementation of Queue that allows a user to
stream a list of IoBuffers on demand. The encoder will try to access
the queue by calling poll() to get the newest chunk.
Actually this proposal causes some changes in ProtocolCodecDecoder and
MINA itself so it can understand QueueIoBuffer. However, the encoder
won't need to be changed at all.
Another trickier part is decoding. I prefer to have HttpRequest (or
HttpResponse) to have a QueueIoBuffer as a content so the decoder can
offer the newly received chunk there.
On the other hand, Use of the Queue interface might be inadequate and we
might need to introduce more specialized interface like the following:
public interface IoBufferStream {
void offer(IoBuffer buf);
// Returns null on the end of the content.
// Returns an empty buffer if no chunk is ready yet.
IoBuffer poll();
// and some listener registration...
IoBufferStream addListener(IoBufferStreamListener listener);
IoBufferStream removeListener(IoBufferStreamListener listener);
}
By having MINA core providing a standardized interface for streaming a
large list of buffer chunks will make more broad range of users happier
rather than implementing such a feature in a certain protocol provider.
WDYT?
Don't we already have the equivalent of an IoBufferStream with just
IoSession.write() and IoHandler.messageReceived()? It seams like this
would add a lot of complication just to solve the problem of partial
HTTP responses from AsyncWeb server. Also, wouldn't use a Queue require
the decode to block waiting for messages to send?
That being said, I don't like the HttpResponse object holding the
IoSession either. You also have to think about the HTTP client. On the
client side it doesn't make any sense to have an addContent on an HTTP
response.
I'm more inclined toward something like:
public interface PartialResponse {
void write(Object message);
void done();
addListener(PartialWriteListener listener);
removeListener(PartialWriteListener listener);
}
public interface PartialWriteListener {
void onWriteCompletion(PartialResponse partialResponse, Object
writtenMessage);
}
You would then do something like:
PartialResponse partial = response.commitPartialResponse(httpResponse);
partial.write(startofData);
partial.addListener(new PartialWriteListener() {
void onWriteCompletiion(PartialResponse partialResponse, Object
writtenMessage) {
if (noMoreData) {
partialResponse.done();
} else {
partialResponse.write(moreData);
}
}
});
Thoughts?
Of course, we still have to incorporate exception handling if an
exception is thrown from the listener as Tuure pointed out and this
doesn't address the notion of setting a chunk size as David pointed out.
-Mike
2008-02-14 (목), 12:20 +0100, Julien Vermillard 쓰시길:
Hi,
I would like to have your comments about the Asyncweb server API
Actually you create your HttpResponse like that :
MutableHttpResponse response = new DefaultHttpResponse();
response.setContent(myIoBuffer);
response.setHeader(Content-Type, text/html);
response.setStatus(HttpResponseStatus.OK);
context.commitResponse(response);
I like this API, it's very simple to use. I would like to keep it
because it's *very* easy for anybody to make a simple HttpService for
serving few data, like RPC call or anything you want.
As Dave commented here http://jira.safehaus.org/browse/ASYNCWEB-21 it's
totally inefficient for serving large data and streaming is impossible.
I would like to propose a variation of Dave API idea :
We keep response.setContent(myIoBuffer); because it will fit 70% of
the use cases :)
We add to MutableHttpResponse a Queue of IoBuffer you can fill like you
want for example :
MutableHttpResponse response = new DefaultHttpResponse();
response.setStatus(HttpResponseStatus.OK);
response.addContent(buffer1);
response.addContent(buffer2);
response.addContent(buffer3);
response.commitResponse(response);
So you can add content in chunks in place of 1 big buffer, that won't
resolve the streaming problem, but it's convenient.
Now streaming :
MutableHttpResponse response = new DefaultHttpResponse();
response.setStatus(HttpResponseStatus.OK);
// add a first chunk (optional)
response.addContent(buffer1);
PartialResponseListener listener = new PartialResponseListener() {
public void queueEmpty(HTTPResponse response) {
if(moreDataToSend) {
...
// add more data
response.addContent(buffer);
} else {
Re: [Asyncweb client] a number of changes to migrate from the Geronimo sandbox
Alan D. Cabrera wrote: On Mar 3, 2008, at 12:26 PM, Sangjin Lee wrote: We have been making a number of changes on the Geronimo sandbox side for the AsyncHttpClient. We've been meaning to move them over, but the pent-up changes have grown to quite a few. I haven't had time to sit down and analyze whether certain bug fixes are applicable for the asyncweb codec. I hope I'll be able to do that some time this week or next week at the latest. Just a heads up for you... Has the merge for Geronimo AHC been completed on the Mina side yet? IIRC, someone was still integrating the AsyncWeb codec. No it's still in limbo. I haven't had as much time as I anticipated to work on this. On top of the fact that is taking much more time than I originally estimated that it would (doesn't it always though?) The biggest problem is that AHC uses the HttpRequest object to store the state of the request, the future, the callback, etc. This doesn't work at all with the AsyncWeb Commons code. Unfortunately, this also affects almost everything in AHC so it's not something that can be easily changed in small steps. In my local working copy, I've moved everything over to use the AsyncWeb commons HttpRequest and I've moved all the state information into the AHC ResponseFuture object. This has, of course, required API changes. Everything compiles, but nothing works and it will take a lot more effort to make it work. I'm not sure how best to proceed. We need to port support for HTTP proxy and HTTP auth to AsyncWeb Commons. There are also a lot of AHC tests that I think would be valuable to have in AsyncWeb Commons. After that, honestly, I think that we should focus our efforts on the new client API's that are being discussed. It doesn't make sense to port AHC over to use AsyncWeb Commons if were only going to go and revamp the API anyway. We can still capitalize on a lot of the AHC work in AsyncWeb Commons and this can be done incrementally. Thoughts? -Mike
[jira] Created: (ASYNCWEB-6) HttpMethod should not be an enum
HttpMethod should not be an enum Key: ASYNCWEB-6 URL: https://issues.apache.org/jira/browse/ASYNCWEB-6 Project: Asyncweb Issue Type: Bug Reporter: Mike Heath Currently o.a.a.common.HttpMethod is an enum. This prevents us from supporting non-standard HTTP methods (the extension-method portion of RFC 2616 5.1.1). We should either just use a String or provide some way of supporting arbitrary HTTP methods. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [AsyncWeb] build broken w/ last checkin
I would also like to see asyncweb make progress as quickly as possible, and I'd like to contribute to that effect as well. As Mike pointed out in a different thread, however, there are some challenges to this. It's looking more likely that this is not going to be a simple merge of code but substantial rework. I think part of it stems from the fact that the old AHC relies on its own codec (based on mina 1.1.x) and the asyncweb already has a good codec that's completely different from AHC's. We do have an immediate need to use AHC *now*, and critical bug fixes need to happen, as we're using it right now. But we're making a conscious effort to limit the changes to mostly bug fixes, and we're trying to propagate the changes to asyncweb whenever it is applicable. Those are the things we're doing (or trying to do) to make sure things don't diverge or get out of hand. Regards, Sangjin On Tue, Mar 4, 2008 at 6:49 AM, Alex Karasulu [EMAIL PROTECTED] wrote: I am in agreement as well. I would like to see this merge happen quickly so the users see progress and there's no longer any need to keep the G branch alive. Someone said to me you need to get cookin in the kitchen when the guests arrive :). Then we can just start releasing some milestones that people can use and we can track/patch etc. It's nice now that MINA 2.0-m1 is out. This means we can release an Asyncweb milestone as a whole. Also another thing I want people to think about is that this project is one unit rather than just a client. There's a server in there too and we can release it together. The community around this is coming together fast and that's just great which means there's a good potential for graduating this project eventually. These are my hopes for Asyncweb. Alex On Tue, Mar 4, 2008 at 9:33 AM, Jeff Genender [EMAIL PROTECTED] wrote: I agree with Alan...I understood that the G version was going away now that we built community over here on this. Comments? Jeff Alan Cabrera wrote: On Mar 1, 2008, at 8:12 PM, Alan D. Cabrera wrote: AsyncHttpClient was changed w/ the last checkin on 2/26 and now the build is broken. I looked at the actual changes. I'm just trying to grok the changes because I realize that I am new here. It seems that the old AsyncHttpClient is still evolving? How does this fit in with the plans for the old AsyncHttpClient, the new Geronimo AsyncHttpClient, and the new API that's currently in discussion? I had thought, maybe naively, that we were going to roll the old two into the new one. Regards, Alan
Re: [AsyncWeb] build broken w/ last checkin
Sangjin Lee wrote: I would also like to see asyncweb make progress as quickly as possible, and I'd like to contribute to that effect as well. As Mike pointed out in a different thread, however, there are some challenges to this. It's looking more likely that this is not going to be a simple merge of code but substantial rework. I think part of it stems from the fact that the old AHC relies on its own codec (based on mina 1.1.x) and the asyncweb already has a good codec that's completely different from AHC's. We do have an immediate need to use AHC *now*, and critical bug fixes need to happen, as we're using it right now. But we're making a conscious effort to limit the changes to mostly bug fixes, and we're trying to propagate the changes to asyncweb whenever it is applicable. Those are the things we're doing (or trying to do) to make sure things don't diverge or get out of hand. Why don't we put AHC in a branch in the AsyncWeb Subversion repository? This way AHC can continue using its own codec and we can support and maintain it without going through a lot of work. Once it gets stabilized we could even cut a release. In the mean time, we can continue working toward a revised 2.0 client that uses the AsyncWeb codec. WDYT? -Mike On Tue, Mar 4, 2008 at 6:49 AM, Alex Karasulu [EMAIL PROTECTED] wrote: I am in agreement as well. I would like to see this merge happen quickly so the users see progress and there's no longer any need to keep the G branch alive. Someone said to me you need to get cookin in the kitchen when the guests arrive :). Then we can just start releasing some milestones that people can use and we can track/patch etc. It's nice now that MINA 2.0-m1 is out. This means we can release an Asyncweb milestone as a whole. Also another thing I want people to think about is that this project is one unit rather than just a client. There's a server in there too and we can release it together. The community around this is coming together fast and that's just great which means there's a good potential for graduating this project eventually. These are my hopes for Asyncweb. Alex On Tue, Mar 4, 2008 at 9:33 AM, Jeff Genender [EMAIL PROTECTED] wrote: I agree with Alan...I understood that the G version was going away now that we built community over here on this. Comments? Jeff Alan Cabrera wrote: On Mar 1, 2008, at 8:12 PM, Alan D. Cabrera wrote: AsyncHttpClient was changed w/ the last checkin on 2/26 and now the build is broken. I looked at the actual changes. I'm just trying to grok the changes because I realize that I am new here. It seems that the old AsyncHttpClient is still evolving? How does this fit in with the plans for the old AsyncHttpClient, the new Geronimo AsyncHttpClient, and the new API that's currently in discussion? I had thought, maybe naively, that we were going to roll the old two into the new one. Regards, Alan
