| The HTTP/S implementation of the ClientILService object. One of these
exists for each Connection object. Normally, this would be where you
would boot up a client-side listener for the server to invoke. However
in this case, we poll the server instead. In short, the ClientIL that we
provide, once serialized and shipped to the server, simply places requests
the server makes to it in a server-side storage mechanism. Then, when we
send an HTTP request to the server, the servlet looks for queued requests
waiting for us, batches them up and returns them in the response. Since
we place ALL requests delivered to ANY instance of the ClientIL in a
central storage queue, we have to have a way to get only the requests placed
in storage by OUR ClientIL. Originally, I attempted to use the ConnectionId
for this purpose, but it proooved to be less than ideal due to the fact that
it created many cases where requests were being fielded to an instance of a
ClientIL which was sent over the wire prior to the server returning our
ConnectionId. This resulted in lost requests. Furthermore, since this had
no control over exactly when the ConnectionId was set, we were forced to
loop until it was not null. The current implementation doesn�t' suffer from
these issues, as we can take full control over the process of setting our
identifier and therefore, set the identifier on our ClientIL at creation time.
author:
Nathan Phelps (nathan@jboss.org)
version:
$Revision: 57198 $ |
