<div dir="ltr"><div>There are two problems with client generated ID's, and the main one is that you can't guarantee that the cancellation message will go to the same server as the original invocation. With my current design the initial request will send back a JSESSIONID that allows the cancel request to be targeted at the correct server (of course if we already have affinity then this is not a problem, but we can't guarantee that).<br></div><div><br>The other problem is that there is no easy way to guarantee there will not be conflicts, although I guess you could send back a 409 and force the client to retry with a new cancellation id if a conflict happens. You can't really tie this to IP because it may be behind a load balancer, and something like a GUID may be expensive to generate for every invocation.<br><br></div><div>With the 1xx approach I am worried that not all load balancers/proxies will properly support it. As this is not really used outside of 'Expect: 100-continue' I would be surprised if this works correctly without problems, even though it is valid according to the spec.<br></div><div><br></div><div>Another potentially yucky way to do this would be to have the client use chunked encoding and keep the request open, allowing it to send some kind of cancellation token at any time. This feels really hacky though.<br></div><div><br></div><div>Basically all the options suck, the one I put in the doc was that one that I thought sucked the least when dealing with load balancers.<br></div><div><br></div>Stuart<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 5, 2016 at 12:11 AM, David M. Lloyd <span dir="ltr"><<a href="mailto:david.lloyd@redhat.com" target="_blank">david.lloyd@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 05/04/2016 12:50 AM, Stuart Douglas wrote:<br>
</span><span class="">> Hi everyone,<br>
><br>
> I have started looking into support for service invocation over HTTP.<br>
> Unlike our existing HTTP upgrade support this will map EJB<br>
> requests/responses directly to HTTP requests and responses, which should<br>
> allow it to be used behind existing load balancers.<br>
><br>
> I have started an initial description of the protocol at:<br>
> <a href="https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc" rel="noreferrer" target="_blank">https://github.com/stuartwdouglas/wildfly-http-client/blob/master/docs/wire-spec-v1.asciidoc</a><br>
><br>
> The intention is to follow HTTP semantics as closely as possible.<br>
> Clustering will be provided in a similar manner to web clustering (i.e.<br>
> it will require a load balancer, and work in a similar manner to web<br>
> clustering).<br>
><br>
> There is still plenty work that needs to be done (especially around<br>
> security), so if anyone has any feedback let me know.<br>
<br>
</span>One thing I noticed is that you went a different way with async<br>
invocations and cancellation support.<br>
<br>
The way I originally proposed was that the request/response works as per<br>
normal, but a 1xx header is used to send the client a cancellation token<br>
which can be POSTed back to the server to cancel the invocation. I<br>
understand that this approach requires 1xx support which some clients<br>
might not have.<br>
<br>
In your proposal, the async EJB request always returns immediately and<br>
uses an invocation ID which can later be retrieved. I rejected this<br>
approach because it requires the server to maintain state outside of the<br>
request - something that is sure to fail. Also the client doesn't<br>
really have any notion as to when it can GET the response: it would have<br>
to do it more or less immediately to avoid a late response (or when<br>
Future.get() is called), meaning you need two round trips in the common<br>
case, which is not so good.<br>
<br>
I think that the best compromise solution is to treat async invocations<br>
identically to regular invocations, and instead let the *client* give a<br>
cancellation ID to the server, which it can later POST to the server as<br>
I described in my original document. If the server receives the<br>
client's ID (maybe also matching the client's IP address) then the<br>
request can be canceled if it is still running.<br>
<br>
Failing this I still prefer the 1xx approach where the server gives a<br>
cancellation ID at the beginning of the request, as this avoids problems<br>
where the server has to maintain large object state for indefinite<br>
amounts of time. Either of these two options means only one server<br>
round trip for async invocation, and no server-side caching of responses.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
- DML<br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</div></div></blockquote></div><br></div>