On Wed, 29 Oct 2003, Geetha Manjunath wrote:
While I do strongly agree about the possibility of different values of
the same expression at different points in a P program (due to
adaptation and so on), this example of yours confused me...
Assume, for example, that name is a response body-dependent
expression and code A above executes a callout service on the
response headers. By the time the service call completes, the
processor may read a few more chunks of that response body and the
value of the named expression can change.
How can the processor read a few more chunks while performing the
rule processing ?
The P interpreter instance serving this particular transaction will
block, but the proxy executing that interpreter instance does not have
to block. All production proxies I know do not block on external
operations such as a callout service call. They continue to work on
other items. These "other items" usually include network I/O for
pending transactions, possibly including the ones for which the rules
are being interpreted.
Thus, depending on the design, a proxy may continue to read response
body while the service is doing its thing and the interpreter instance
is waiting.
In fact, in most cases, a complete body will _not_ be available at any
single time -- it is just too big to cache (the service can cache the
body if it needs to, but the proxy may not).
If this is so, then I suppose, we would end up in a non
deterministic behaviour!
Depends on what you mean by "non-determinism" in this case, I guess.
You agree above that adaptations can cause the same expression to have
different values. "Reading a few more chunks" is just another
adaptation, if you will. There is no difference from P point of view.
We can (and probably should) demand that interpreters do not block
except for a few known points like service executions. While writing
ruleset with adaptation rules is close to programming with threads, we
want to avoid parallel processing surprises as much as possible. P
"threads" can (and probably should) have well-documented preemption
points.
In other words, my question is probably about the vectoring point..
what are options for vectoring point for a non-HTTP protocol, for
example?
I do not think the above is related to vectoring points. The problem
exists even if there is a single vectoring point. Multiple vectoring
points just introduce more opportunities for something to be changed
while the rules are interpreted.
Did my response clarified the problem enough?
Thanks,
Alex.