Jules Gosnell wrote:
James Strachan wrote:
On 7/12/06, Jules Gosnell
Greg Wilkins wrote:
However, in another sense, Jetty need not delegate this task, since
the
object returned in these cases is managed by WADI, but created by a
Factory that is injected at startup time. This factory might be
generating instances of a class that has very Jetty-specific knowledge
or is even a part of the Jetty distro...
Thats certainly one approach. Another is for the container to just ask
the policy API what to do (i.e. is the request going to be serviced
locally or not) so that the container can take care of the rest.
This leaks clustering concerns into the container's space.
If the container is going to do the redirecting/proxying (either
directly or as a call back), then it has to be concerned with clustering.
I understand that WADI has an implementation of this, but I want to
be able to use clustering mechanisms other than WADI. I think it is
raising the bar for clustering implementations if they must support
this.
I understand the cleanliness from the session API implementor's
perspective of using a factory and calling back the container when you
see fit - however I also understand the container developers
requirement to understand at all times what each thread is doing, to
tune things aggressively with full knowledge of threading models and
to generally be master of its own domain, so I can understand why a
container developer might prefer a non-callback related solution
(which could introduce all kinds of nasty thread related bugs into the
container).
Any clustering solution will use threads underneath its API. If this is
a concern you should simply make explicit where they may be used.
I don't see why both options can't be offered.
Exactly - why can we not have the simple policy API that we call to
understand what to do.
Jetty can have a session interceptor to call this API and do it's
proxying or redirection and then Jetty can use lots of different
clustering implementations.
But the Jetty developers may be lazy, and instead of implementing their
own interceptor they may choose to use the WADI implementation of it
that wraps up the whole invocation. Tomcat or openEJB may not be so
lazy or have other concerns - thus they might not use the WADI
interceptor but code directly to the policy API.
Agreed. Just some way to ask the Session API if a request can be
processed locally might do the trick, then if not Jetty can do its
proxy/redirect thing. The trickier thing is what to pass into the
strategy to help it decide...
by having Jetty make the decision:
- you leak clustering concerns into the web tier
- you have to duplicate similar code in every clustered tier
Jetty is not making the decision, it is calling an API
to make the decision. Jetty simply implements the execution of the
decision.
The code to do this has to be written for every clustering tier.
Now it is great that WADI wants to write it for every clustering tier
- but that is a big work load and I am not sure that WADI developers
will be able to keep every tier happy and deal with
all of their concerns.
Also, it kind of implies that G will only use WADI. Now I know
that wadi is itself extensible/pluggable/etc. so this might not
be a bad idea. But wadi either has be the G cluster API (and allow
other technologies to be plugged into it), or it has to give up
some of the space (eg implementation of interceptors) to the tier
implementations.
That is a tough call to make at this stage because people just do not
have enough exposure to WADI.
If it was at all possible to have an approach of a low level
API which can either be directly used or used via the WADI
interceptors, then that would give us a chance to evaluate
WADI. If the wadi interceptors are indeed the best, then
great - WADI because the cluster API for G.
So the question is - is the session API good enough to form the
interface between WADI interceptors and WADI
clustering implementations. Originally the answer was no, but
there have been some improvements proposed to the API.
Is that still the case? Eg. with the getExecutionLocation style API,
their is no need for the inefficiencies of getSessionLocation calls.
Alternately (if wadi understandably does not want to be cleft in two
by the G session API), if somebody writes a clustering
impl behind the G session API (eg the distributed map currently
being worked on), could that be plugged into Wadi as a pluggable
store implementation?
If so, Jetty could just use Wadi and we would get G integration
for free!
cheers
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
