Greg Wilkins wrote:
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.
No - the redirection/proxying is not concerned with clustering - we have
divided and conquered the idea down to a much smaller concern, that of
relocating a request to another container (endpoint provided by
clustering layer):
boolean isRelocatable();
void relocate(EndPoint endPoint); // endpoint is an ip:port
The implementation of this concern is tier-specific and should be
implemented by the tier owner.
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 would far rather WADI didn't have to implement this and that it was
implemented by Jetty as described. We are getting muddled between what
WADI currently provides and where I would like to see WADI and the
g-session-api go.
If the Jetty6 continuations fn-ality complicates the situation, then
this can be addressed in the API above.
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.
This means that it is aware that it is clustered.
The code to call this API and react accordingly will be duplicated in
every tier.
Jetty simply implements the execution of
the decision.
I agree that the tier-ower should provide an implementation of this
piece of fn-ality. This will not need access to any clustering detail.
Simply the ip:port of the peer to which you are relocating the
invocation/request.
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
No - I don't - I want the clustered session manager to call the policy,
and, based on the result of that call, call some tier-specific behaviour
- see above - very good reasons for this were given in my last mail.
I don't want the container calling the policy, because then you need to
know that you are clustered - see those reasons.
- 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.
N/A
Also, it kind of implies that G will only use WADI.
wrong.
We are talking about a common API here and I am drawing on WADI for
examples of how I believe it should be done. No specific implementation
is being suggested.
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.
wrong.
and I'm not sure whether you are talking about the session or clustering
api here.
Both session and clustering apis are completely in the domain of
Geronimo. If either or both apis are pitched flexibly enough for WADI to
use them, it will implement them. If implementing them involves
significant sacrifice of fn-ality, simplicity or performance, then it won't.
As for giving up space, I have no problem with it, provided that there
is no leakage of concerns as a result of transfer of ownership of said
space.
That is a tough call to make at this stage because people just
do not have enough exposure to WADI.
N/A - I'm not making that call - just giving the benefit of my
experience to a design discussion.
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.
I'm not asking you to evaluate WADI. I am explaining what I see as
mistakes in the existing session API, in the hope that change may be made.
Anyone who is interested in WADI is welcome to join our lists and ask
questions that I will do my best to answer.
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.
I still believe not.
My sticking points are as follows (OTTOMH):
1) no exposure of any clustering detail should be made to the client
container - the existing API will do this, even if it just requires you
to call a boolean method, test the result and relocate an invocation if
it it true - reasons given in last mail.
2) no detail of any colocation policy should be exposed to the client
container - the existing API does this, by exposing implementational
structure (a map of web session attributes mixed with sessions from
other tiers) - reasons given in last mail.
3) I would like to see the api provide a cross-tier abstraction with
which the invocation/request can be encapsulated and manipulated, and
encourage the provision of optimal, tier-specific implementations of
invocation relocation fn-ality encapsulated by this interface.
4) I haven't studied the current API closely enough to ascertain how
apportions responsibility for a number of important issues - session
lifecycle, notifications, eviction, destruction, ttl, etc... - and I
don't think that they have been discussed in depth yet - so there may be
issues here as well.
I concur that some further code (e.g. policy and session impl) will need
access to expertise from both container and clustering tiers. This
knowledge should be confined entirely to these code sections.
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?
Yes
If so, Jetty could just use Wadi and we would get G integration
for free!
Yes - if someone wrote a WADI/Geronimo adapter. I haven't given it any
thought, but I do't think that this would pose a problem.
Jules
cheers
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."
/**********************************
* Jules Gosnell
* Partner
* Core Developers Network (Europe)
*
* www.coredevelopers.net
*
* Open Source Training & Support.
**********************************/
