Yes, creating an separate request object for each request fixed the problem. Now it seems to work OK. I have yet to test timeouts. I suppose either the failed() or cancelled() method is called in a case of connection timeout.
On Fri, Nov 22, 2013 at 3:37 PM, Oleg Kalnichevski <[email protected]> wrote: > On Fri, 2013-11-22 at 15:10 +0200, Petteri Hentilä wrote: > > Thanks again. > > > > I made my own implementation of the FutureCallback interface: > > > > private static class FutureCallbackImpl implements > > FutureCallback<HttpResponse> { > > > > private HttpCoreContext coreContext; > > public FutureCallbackImpl(HttpCoreContext coreContext) { > > this.coreContext = coreContext; > > } > > > > @Override > > public void cancelled() { > > > > } > > > > @Override > > public void completed(HttpResponse response) { > > System.out.println("completed" + "->" + > > response.getStatusLine(); > > > > } > > > > @Override > > public void failed(Exception cause) { > > System.out.println("failed" + "->" + cause); > > } > > } > > > > And here is how I use it. > > > > HttpAsyncRequester requester = new HttpAsyncRequester(httpproc); > > > > final HttpHost target = new HttpHost("www.google.fi", 80, > "http"); > > BasicHttpRequest request = new BasicHttpRequest("GET", "/"); > > > > for(int i=0; i<50; i++) { > > HttpCoreContext coreContext = HttpCoreContext.create(); > > coreContext.setAttribute("index", i); > > FutureCallbackImpl callBack = new > > FutureCallbackImpl(coreContext); > > > > requester.execute( > > new BasicAsyncRequestProducer(target, request), > > new BasicAsyncResponseConsumer(), > > pool, > > coreContext, > > // Handle HTTP response from a callback > > callBack > > ); > > > > } > > > > What I do here is to send 50 requests inside one loop. > > > > However, each time I run the program the failed() callback method is > called > > a several times with the exception being > > java.util.ConcurrentModificationException. > > > > There seems to be a concurrency problem somewhere? > > > > Oh, where could only that be? Let me look at the stack trace. Hmm. No > stack trace. Let me try mind reading. > > What do you think should happen when you attempt to execute the _same_ > request object 50 times using multiple CPU cores? > > Oleg > > > > > > > On Fri, Nov 22, 2013 at 2:37 PM, Oleg Kalnichevski <[email protected]> > wrote: > > > > > On Fri, 2013-11-22 at 14:27 +0200, Petteri Hentilä wrote: > > > > A couple of comments. > > > > > > > > 1. I cannot pass the HttpContext to FutureCallback as a construction > > > > parameter, because that class has only one parameterless > constructor. I > > > > also cannot put the HttpContext as the generic type for > FutureCallback > > > > because it gives me a compile error. > > > > > > > > > > FutureCallback is an _interface_. One can have any constructor > > > parameters for a class that implements this interface. > > > > > > > 2. I derived my own class from BasicAsyncResponseConsumer to have > more > > > > control over the response processing, but that class does not have > the > > > > correct methods that I would need. It has a method > > > > responseReceived(HttpResponse) but it does not get HttpContext as a > > > > parameter. It also has a method failed(Exception) but it does not get > > > > HttpContext as a parameter either. > > > > > > > > > > Same deal as with FutureCallback. You can pass any additional > contextual > > > parameters at the construction time. > > > > > > Oleg > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
