Geronimo integration...

[Jules Gosnell-4]

Gianny,

re: splitting WADI into per-app and per-server granularity components....

Thinking a bit more about the Contextualiser stack....

We are agreed that, in a per-Server deployment, there should only be one
PartitionManager ...

I think that each app needs its own unique session id namespace - I am
open to negotiation on this, but I think that we need to go in this
direction.

This means that a single Partition must be able to store the location of
two sessions in two different apps, that share the same session id ?

So, i think that we are coming full circle back to my idea of creating
session namespaces within a single Contextualiser stack by using an
app-id as a prefix...

Looking at the rest of the contextualiser stack, if you are prepared to
consider going this route, rather than having a stack which is in
app-space at the top and server-space at the bottom, I think it will
simplify things considerably...

cons:

- all apps share the same session maps - this could lead to contention
as discussed - but a well written concurrent map, should be able to
handle this ?
- it will be difficult to extract per-app session stats - since all
sessions will be held communally
- we will have to perform an allocation on each stateful request to
compose the session key from the app and session-ids... (we could cache
this)

pros

- simpler
- per-server session stats are automatically aggregated
- uses less resources - e.g. we only have one set of housekeeping to
deal with (i.e. one Memory Evicter)
- we need to refactor to move per-app accessors onto e.g. the Invocation
instead of the Contextualiser...


So lets call our models :

- share-none/per-app - a completely seperate WADI deployment in each app
- current deployment strategy
- share-some/hybrid - the solution that you suggested, that I am
thinking might be too complex for a first cut
- share-all/per-server - the solution that I suggested, that we agreed
had issues - but may be simpler

So, I am now thinking that share-all is probably the quickest way to get
something up and running within Geronimo... I can come up with a single
stack with a GBean-ised API at the top....

What do you think ?

I will have a look at the Manager as well - in case we can share some of
this and move the non-shared stuff onto another object - the Invocation ?

Jules






--
"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.
 **********************************/

[Filip Hanik - Dev Lists]

Jules Gosnell wrote:

> Gianny,
>
> re: splitting WADI into per-app and per-server granularity components....
>
> Thinking a bit more about the Contextualiser stack....
>
> We are agreed that, in a per-Server deployment, there should only be
> one PartitionManager ...
>
> I think that each app needs its own unique session id namespace - I am
> open to negotiation on this, but I think that we need to go in this
> direction.
>
> This means that a single Partition must be able to store the location
> of two sessions in two different apps, that share the same session id ?
>
> So, i think that we are coming full circle back to my idea of creating
> session namespaces within a single Contextualiser stack by using an
> app-id as a prefix...
>
> Looking at the rest of the contextualiser stack, if you are prepared
> to consider going this route, rather than having a stack which is in
> app-space at the top and server-space at the bottom, I think it will
> simplify things considerably...
>
> cons:
>
> - all apps share the same session maps - this could lead to contention
> as discussed - but a well written concurrent map, should be able to
> handle this ?
> - it will be difficult to extract per-app session stats - since all
> sessions will be held communally
> - we will have to perform an allocation on each stateful request to
> compose the session key from the app and session-ids... (we could
> cache this)
>
> pros
>
> - simpler
> - per-server session stats are automatically aggregated
> - uses less resources - e.g. we only have one set of housekeeping to
> deal with (i.e. one Memory Evicter)
> - we need to refactor to move per-app accessors onto e.g. the
> Invocation instead of the Contextualiser...
>
>
> So lets call our models :
>
> - share-none/per-app - a completely seperate WADI deployment in each
> app - current deployment strategy

I think this is a waste of resources (at the lower layers, ala tribes),
this is what JBoss/Jgroups does, and it is non efficient.
Tribes was built in mind that you only need one comm channel for N apps
sitting on top of it.
So if we have one WADI per app, it should still only use single
resources for session relocation, like 1 shared connection pool
to write to a DB, or one Tribes app to write to a different node etc.
> - share-some/hybrid - the solution that you suggested, that I am
> thinking might be too complex for a first cut
> - share-all/per-server - the solution that I suggested, that we agreed
> had issues - but may be simpler
simple, usually works better as it is easier to code around the issues,
KISS usually leads to better quality
>
> So, I am now thinking that share-all is probably the quickest way to
> get something up and running within Geronimo... I can come up with a
> single stack with a GBean-ised API at the top....
>
> What do you think ?
remember, that in Tomcat, you can configure a setting where the
JSESSIONID is global to the domain, not just the app, and is shared
between webapps. So we need to consider what effects this will have on WADI

Filip

>
> I will have a look at the Manager as well - in case we can share some
> of this and move the non-shared stuff onto another object - the
> Invocation ?
>
> Jules

>
>
>
>
>
>

[Jules Gosnell-4]

Filip Hanik - Dev Lists wrote:

> Jules Gosnell wrote:
>
>> Gianny,
>>
>> re: splitting WADI into per-app and per-server granularity
>> components....
>>
>> Thinking a bit more about the Contextualiser stack....
>>
>> We are agreed that, in a per-Server deployment, there should only be
>> one PartitionManager ...
>>
>> I think that each app needs its own unique session id namespace - I
>> am open to negotiation on this, but I think that we need to go in
>> this direction.
>>
>> This means that a single Partition must be able to store the location
>> of two sessions in two different apps, that share the same session id ?
>>
>> So, i think that we are coming full circle back to my idea of
>> creating session namespaces within a single Contextualiser stack by
>> using an app-id as a prefix...
>>
>> Looking at the rest of the contextualiser stack, if you are prepared
>> to consider going this route, rather than having a stack which is in
>> app-space at the top and server-space at the bottom, I think it will
>> simplify things considerably...
>>
>> cons:
>>
>> - all apps share the same session maps - this could lead to
>> contention as discussed - but a well written concurrent map, should
>> be able to handle this ?
>> - it will be difficult to extract per-app session stats - since all
>> sessions will be held communally
>> - we will have to perform an allocation on each stateful request to
>> compose the session key from the app and session-ids... (we could
>> cache this)
>>
>> pros
>>
>> - simpler
>> - per-server session stats are automatically aggregated
>> - uses less resources - e.g. we only have one set of housekeeping to
>> deal with (i.e. one Memory Evicter)
>> - we need to refactor to move per-app accessors onto e.g. the
>> Invocation instead of the Contextualiser...
>>
>>
>> So lets call our models :
>>
>> - share-none/per-app - a completely seperate WADI deployment in each
>> app - current deployment strategy
>
> I think this is a waste of resources (at the lower layers, ala
> tribes), this is what JBoss/Jgroups does, and it is non efficient.
> Tribes was built in mind that you only need one comm channel for N
> apps sitting on top of it.
> So if we have one WADI per app, it should still only use single
> resources for session relocation, like 1 shared connection pool
> to write to a DB, or one Tribes app to write to a different node etc.
>
>> - share-some/hybrid - the solution that you suggested, that I am
>> thinking might be too complex for a first cut
>> - share-all/per-server - the solution that I suggested, that we
>> agreed had issues - but may be simpler
>
> simple, usually works better as it is easier to code around the
> issues, KISS usually leads to better quality
>
>>
>> So, I am now thinking that share-all is probably the quickest way to
>> get something up and running within Geronimo... I can come up with a
>> single stack with a GBean-ised API at the top....
>>
>> What do you think ?
>
> remember, that in Tomcat, you can configure a setting where the
> JSESSIONID is global to the domain, not just the app, and is shared
> between webapps. So we need to consider what effects this will have on
> WADI

Yes - I had something in mind like this for cross-context portlet
sessions - which must be able to share a single session id, live in
separate app contexts, but have a single unified lifetime - i.e. when
one session is invalidated, all are...

I figure that we introduce a pluggable strategy to create an
internal-key (e.g. /wadi-ABCD) from the external-key (e.g. ABCD or
ABCD.red (with e.g. mod_jk)). Usually, this strategy will prepend the
app-id (context-path for a webapp), but in the case that you mention, we
would flatten the cross-context namespace by using the same prefix for
all portlets that we wish to fall into this space - or just omit it all
together...

sound OK ?

Jules

>
> Filip
>
>>
>> I will have a look at the Manager as well - in case we can share some
>> of this and move the non-shared stuff onto another object - the
>> Invocation ?
>>
>> Jules
>
>
>>
>>
>>
>>
>>
>>
>

--
"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.
 **********************************/

[Filip Hanik - Dev Lists]

Jules Gosnell wrote:

> Filip Hanik - Dev Lists wrote:
>
>>
>> remember, that in Tomcat, you can configure a setting where the
>> JSESSIONID is global to the domain, not just the app, and is shared
>> between webapps. So we need to consider what effects this will have
>> on WADI
>
> Yes - I had something in mind like this for cross-context portlet
> sessions - which must be able to share a single session id, live in
> separate app contexts, but have a single unified lifetime - i.e. when
> one session is invalidated, all are...

interesting, you can essentially create one global session, and flatten
the namespace so that app /examples session.getAttribute("myatt")
becomes session.getAttribute("/examples/myatt");
(note, in tomcat the prefix has to be "/host/context/attributename") as
tomcat supports virtual hosts.

this will work even if the session is only available in one app,
/examples, as the implementation works for 1..N apps.

you can have one global session manager, just remember that
stop/undeploy of an app, should kick off listeners, and clean up that
apps attributes.

also, you can introduce a custom WADI optional feature to share session
attributes between webapps, kind of a neat idea when you think about it.

>
> I figure that we introduce a pluggable strategy to create an
> internal-key (e.g. /wadi-ABCD) from the external-key (e.g. ABCD or
> ABCD.red (with e.g. mod_jk)). Usually, this strategy will prepend the
> app-id (context-path for a webapp), but in the case that you mention,
> we would flatten the cross-context namespace by using the same prefix
> for all portlets that we wish to fall into this space - or just omit
> it all together...
not sure what you mean by this, the jvmRoute on mod_jk today is a minor
disaster, and a pretty sad story for a sticky loadbalancing algo.
I don't think depending on an external product like mod_jk is a good idea.
Maybe I'm misunderstanding you.

Filip

>
> sound OK ?
>
> Jules
>
>>
>> Filip
>>
>>>
>>> I will have a look at the Manager as well - in case we can share
>>> some of this and move the non-shared stuff onto another object - the
>>> Invocation ?
>>>
>>> Jules
>>
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>

[Jules Gosnell-4]

Filip Hanik - Dev Lists wrote:

> Jules Gosnell wrote:
>
>> Filip Hanik - Dev Lists wrote:
>>
>>>
>>> remember, that in Tomcat, you can configure a setting where the
>>> JSESSIONID is global to the domain, not just the app, and is shared
>>> between webapps. So we need to consider what effects this will have
>>> on WADI
>>
>>
>> Yes - I had something in mind like this for cross-context portlet
>> sessions - which must be able to share a single session id, live in
>> separate app contexts, but have a single unified lifetime - i.e. when
>> one session is invalidated, all are...
>
> interesting, you can essentially create one global session, and
> flatten the namespace so that app /examples session.getAttribute("myatt")
> becomes session.getAttribute("/examples/myatt");

I must have explained this badly - this wasn't my intention. What I
meant to say was that by giving two different apps the same namespace
prefix, they would be able to see each others sessions, but no-one elses.

So, I am talking about having a map of  e.g. <context>.<session-id> :
<session> - where session is a map of <attribute-key> :
<attribute-value>, whereas, I think that you are imagining something
more like a single map of : <session-id>.<context>/<attribute-key> :
<attribute-value> - for the portlet scenario (more below), this might be
an option (but not the route that I had in mind).

> (note, in tomcat the prefix has to be "/host/context/attributename")
> as tomcat supports virtual hosts.

Good point - I will bear that in mind - thanks.

>
> this will work even if the session is only available in one app,
> /examples, as the implementation works for 1..N apps.
>
> you can have one global session manager, just remember that
> stop/undeploy of an app, should kick off listeners, and clean up that
> apps attributes.

Yes - this might complicate things - I will investigate.

>
> also, you can introduce a custom WADI optional feature to share
> session attributes between webapps, kind of a neat idea when you think
> about it.

hmmm... - is this the same as two webapps sharing the same session
namespace ?

>
>>
>> I figure that we introduce a pluggable strategy to create an
>> internal-key (e.g. /wadi-ABCD) from the external-key (e.g. ABCD or
>> ABCD.red (with e.g. mod_jk)). Usually, this strategy will prepend the
>> app-id (context-path for a webapp), but in the case that you mention,
>> we would flatten the cross-context namespace by using the same prefix
>> for all portlets that we wish to fall into this space - or just omit
>> it all together...
>
> not sure what you mean by this,

So, referring back to my <context>.<session-id> : <session> structure. I
am saying that we create an internal-key (<context>.<session-id>) from
the external key (the session id that we retrieved from the request,
which may include decoration that needs to be stripped (in the case of
e.g. mod_jk)). The internal-key is simply the undecorated session-id
with a namespace qualifier - probably now: <vhost>.<context>. This
internal key is used in the Contextualiser stack to ensure separation of
data belonging to different apps on different vhosts.

> the jvmRoute on mod_jk today is a minor disaster, and a pretty sad
> story for a sticky loadbalancing algo.

Well - I disagree slightly - it has good and bad points:

- the bad - it messes with the session cookie
- the good - it enables an explicit coordination between container and
load-balancer which may be exploited.

perhaps a better solution would be to use a second cookie to encode
routing info ?

> I don't think depending on an external product like mod_jk is a good
> idea.

No - WADI does not depend on JK, but it does support it and exploit the
jvmRoute feature - I was just using it as an example of how the external
key does not necessarily map directly to the internal key.... - feel
better ? :-)

> Maybe I'm misunderstanding you.

yes !


Jules

>
> Filip
>
>
>>
>> sound OK ?
>>
>> Jules
>>
>>>
>>> Filip
>>>
>>>>
>>>> I will have a look at the Manager as well - in case we can share
>>>> some of this and move the non-shared stuff onto another object -
>>>> the Invocation ?
>>>>
>>>> Jules
>>>
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>
>>
>

--
"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.
 **********************************/

[Gianny Damour-2]

Jules,

I think that it makes sense to start with this share-all approach and
the namespacing of the session ID will give us that rather quickly :-)

Regarding the lifecycle of Web-app raised by Filip, this is how I
implemented it for the replication stuff:

* when a replication manager starts, it sends to the cluster a
ReplicaStorageMonitorEvent JOIN event (BasicReplicaStorageMonitor.start);
* replication storages monitor such an event and send to the joining
replication manager their location
(BasicReplicaStorageExporter.onMonitorEvent);
* when a replication storage starts or stops, it sends to the cluster a
ReplicaStorageEvent JOIN or LEAVE event
(BasicReplicaStorageAdvertiser.start and stop);
* replication managers monitor these events
(BasicReplicaStorageMonitor.onReplicaStorageEvent); and
* replication managers monitor leaving or failing peer events
(BasicReplicaStorageMonitor).

This way, a replication manager always know the current replication
storages and their locations..

Thanks,
Gianny

Jules Gosnell wrote:

> Filip Hanik - Dev Lists wrote:
>
>> Jules Gosnell wrote:
>>
>>> Filip Hanik - Dev Lists wrote:
>>>
>>>>
>>>> remember, that in Tomcat, you can configure a setting where the
>>>> JSESSIONID is global to the domain, not just the app, and is shared
>>>> between webapps. So we need to consider what effects this will have
>>>> on WADI
>>>
>>>
>>>
>>> Yes - I had something in mind like this for cross-context portlet
>>> sessions - which must be able to share a single session id, live in
>>> separate app contexts, but have a single unified lifetime - i.e.
>>> when one session is invalidated, all are...
>>
>>
>> interesting, you can essentially create one global session, and
>> flatten the namespace so that app /examples
>> session.getAttribute("myatt")
>> becomes session.getAttribute("/examples/myatt");
>
>
> I must have explained this badly - this wasn't my intention. What I
> meant to say was that by giving two different apps the same namespace
> prefix, they would be able to see each others sessions, but no-one elses.
>
> So, I am talking about having a map of  e.g. <context>.<session-id> :
> <session> - where session is a map of <attribute-key> :
> <attribute-value>, whereas, I think that you are imagining something
> more like a single map of : <session-id>.<context>/<attribute-key> :
> <attribute-value> - for the portlet scenario (more below), this might
> be an option (but not the route that I had in mind).
>
>> (note, in tomcat the prefix has to be "/host/context/attributename")
>> as tomcat supports virtual hosts.
>
>
> Good point - I will bear that in mind - thanks.
>
>>
>> this will work even if the session is only available in one app,
>> /examples, as the implementation works for 1..N apps.
>>
>> you can have one global session manager, just remember that
>> stop/undeploy of an app, should kick off listeners, and clean up that
>> apps attributes.
>
>
> Yes - this might complicate things - I will investigate.
>
>>
>> also, you can introduce a custom WADI optional feature to share
>> session attributes between webapps, kind of a neat idea when you
>> think about it.
>
>
> hmmm... - is this the same as two webapps sharing the same session
> namespace ?
>
>>
>>>
>>> I figure that we introduce a pluggable strategy to create an
>>> internal-key (e.g. /wadi-ABCD) from the external-key (e.g. ABCD or
>>> ABCD.red (with e.g. mod_jk)). Usually, this strategy will prepend
>>> the app-id (context-path for a webapp), but in the case that you
>>> mention, we would flatten the cross-context namespace by using the
>>> same prefix for all portlets that we wish to fall into this space -
>>> or just omit it all together...
>>
>>
>> not sure what you mean by this,
>
>
> So, referring back to my <context>.<session-id> : <session> structure.
> I am saying that we create an internal-key (<context>.<session-id>)
> from the external key (the session id that we retrieved from the
> request, which may include decoration that needs to be stripped (in
> the case of e.g. mod_jk)). The internal-key is simply the undecorated
> session-id with a namespace qualifier - probably now:
> <vhost>.<context>. This internal key is used in the Contextualiser
> stack to ensure separation of data belonging to different apps on
> different vhosts.
>
>> the jvmRoute on mod_jk today is a minor disaster, and a pretty sad
>> story for a sticky loadbalancing algo.
>
>
> Well - I disagree slightly - it has good and bad points:
>
> - the bad - it messes with the session cookie
> - the good - it enables an explicit coordination between container and
> load-balancer which may be exploited.
>
> perhaps a better solution would be to use a second cookie to encode
> routing info ?
>
>> I don't think depending on an external product like mod_jk is a good
>> idea.
>
>
> No - WADI does not depend on JK, but it does support it and exploit
> the jvmRoute feature - I was just using it as an example of how the
> external key does not necessarily map directly to the internal key....
> - feel better ? :-)
>
>> Maybe I'm misunderstanding you.
>
>
> yes !
>
>
> Jules
>
>>
>> Filip
>>
>>
>>>
>>> sound OK ?
>>>
>>> Jules
>>>
>>>>
>>>> Filip
>>>>
>>>>>
>>>>> I will have a look at the Manager as well - in case we can share
>>>>> some of this and move the non-shared stuff onto another object -
>>>>> the Invocation ?
>>>>>
>>>>> Jules
>>>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>

[Jules Gosnell-4]

Gianny Damour wrote:

> Jules,
>
> I think that it makes sense to start with this share-all approach and
> the namespacing of the session ID will give us that rather quickly :-)

good :-)

>
> Regarding the lifecycle of Web-app raised by Filip, this is how I
> implemented it for the replication stuff:
>
> * when a replication manager starts, it sends to the cluster a
> ReplicaStorageMonitorEvent JOIN event (BasicReplicaStorageMonitor.start);
> * replication storages monitor such an event and send to the joining
> replication manager their location
> (BasicReplicaStorageExporter.onMonitorEvent);
> * when a replication storage starts or stops, it sends to the cluster
> a ReplicaStorageEvent JOIN or LEAVE event
> (BasicReplicaStorageAdvertiser.start and stop);
> * replication managers monitor these events
> (BasicReplicaStorageMonitor.onReplicaStorageEvent); and
> * replication managers monitor leaving or failing peer events
> (BasicReplicaStorageMonitor).
>
> This way, a replication manager always know the current replication
> storages and their locations..

loosk good - I'll bear it all in mind...

The only real issue that I have thought of with the share-all approach
so far is this -

If you undeploy an application, you want all of its classes and
instances thereof removed from the local JVM - so that on redeploying
it, you don't come across any versioning problems.

This implies that this app's sessions must be removed from the JVM and
that they must be managed by vms on which the app is deployed - as when
they time-out, their destruction may involve their deserialisation or a
requirement for their parent app to be present...

If there are other instances of the app running, we can evacuate the
sessions to them. If there are not, we will either have to drop the
sessions, or move them into persistant storage until such time as an
instance of their app is available again....

So, we have a new requirement to unload a single apps sessions and a new
requirement to know which apps are where...

arggghhhh! it's beginning to get complicated :-( - more thought required...

I'm beginning to think that the only thing that we can really share
(without quite a bit of extra work) is the Dispatcher and connection to
the Cluster...



Jules

>
> Thanks,
> Gianny
>
> Jules Gosnell wrote:
>
>> Filip Hanik - Dev Lists wrote:
>>
>>> Jules Gosnell wrote:
>>>
>>>> Filip Hanik - Dev Lists wrote:
>>>>
>>>>>
>>>>> remember, that in Tomcat, you can configure a setting where the
>>>>> JSESSIONID is global to the domain, not just the app, and is
>>>>> shared between webapps. So we need to consider what effects this
>>>>> will have on WADI
>>>>
>>>>
>>>>
>>>>
>>>> Yes - I had something in mind like this for cross-context portlet
>>>> sessions - which must be able to share a single session id, live in
>>>> separate app contexts, but have a single unified lifetime - i.e.
>>>> when one session is invalidated, all are...
>>>
>>>
>>>
>>> interesting, you can essentially create one global session, and
>>> flatten the namespace so that app /examples
>>> session.getAttribute("myatt")
>>> becomes session.getAttribute("/examples/myatt");
>>
>>
>>
>> I must have explained this badly - this wasn't my intention. What I
>> meant to say was that by giving two different apps the same namespace
>> prefix, they would be able to see each others sessions, but no-one
>> elses.
>>
>> So, I am talking about having a map of  e.g. <context>.<session-id> :
>> <session> - where session is a map of <attribute-key> :
>> <attribute-value>, whereas, I think that you are imagining something
>> more like a single map of : <session-id>.<context>/<attribute-key> :
>> <attribute-value> - for the portlet scenario (more below), this might
>> be an option (but not the route that I had in mind).
>>
>>> (note, in tomcat the prefix has to be "/host/context/attributename")
>>> as tomcat supports virtual hosts.
>>
>>
>>
>> Good point - I will bear that in mind - thanks.
>>
>>>
>>> this will work even if the session is only available in one app,
>>> /examples, as the implementation works for 1..N apps.
>>>
>>> you can have one global session manager, just remember that
>>> stop/undeploy of an app, should kick off listeners, and clean up
>>> that apps attributes.
>>
>>
>>
>> Yes - this might complicate things - I will investigate.
>>
>>>
>>> also, you can introduce a custom WADI optional feature to share
>>> session attributes between webapps, kind of a neat idea when you
>>> think about it.
>>
>>
>>
>> hmmm... - is this the same as two webapps sharing the same session
>> namespace ?
>>
>>>
>>>>
>>>> I figure that we introduce a pluggable strategy to create an
>>>> internal-key (e.g. /wadi-ABCD) from the external-key (e.g. ABCD or
>>>> ABCD.red (with e.g. mod_jk)). Usually, this strategy will prepend
>>>> the app-id (context-path for a webapp), but in the case that you
>>>> mention, we would flatten the cross-context namespace by using the
>>>> same prefix for all portlets that we wish to fall into this space -
>>>> or just omit it all together...
>>>
>>>
>>>
>>> not sure what you mean by this,
>>
>>
>>
>> So, referring back to my <context>.<session-id> : <session>
>> structure. I am saying that we create an internal-key
>> (<context>.<session-id>) from the external key (the session id that
>> we retrieved from the request, which may include decoration that
>> needs to be stripped (in the case of e.g. mod_jk)). The internal-key
>> is simply the undecorated session-id with a namespace qualifier -
>> probably now: <vhost>.<context>. This internal key is used in the
>> Contextualiser stack to ensure separation of data belonging to
>> different apps on different vhosts.
>>
>>> the jvmRoute on mod_jk today is a minor disaster, and a pretty sad
>>> story for a sticky loadbalancing algo.
>>
>>
>>
>> Well - I disagree slightly - it has good and bad points:
>>
>> - the bad - it messes with the session cookie
>> - the good - it enables an explicit coordination between container
>> and load-balancer which may be exploited.
>>
>> perhaps a better solution would be to use a second cookie to encode
>> routing info ?
>>
>>> I don't think depending on an external product like mod_jk is a good
>>> idea.
>>
>>
>>
>> No - WADI does not depend on JK, but it does support it and exploit
>> the jvmRoute feature - I was just using it as an example of how the
>> external key does not necessarily map directly to the internal
>> key.... - feel better ? :-)
>>
>>> Maybe I'm misunderstanding you.
>>
>>
>>
>> yes !
>>
>>
>> Jules
>>
>>>
>>> Filip
>>>
>>>
>>>>
>>>> sound OK ?
>>>>
>>>> Jules
>>>>
>>>>>
>>>>> Filip
>>>>>
>>>>>>
>>>>>> I will have a look at the Manager as well - in case we can share
>>>>>> some of this and move the non-shared stuff onto another object -
>>>>>> the Invocation ?
>>>>>>
>>>>>> Jules
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>
>

--
"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.
 **********************************/

[Jules Gosnell-4]

Jules Gosnell wrote:

> Gianny Damour wrote:
>
>> Jules,
>>
>> I think that it makes sense to start with this share-all approach and
>> the namespacing of the session ID will give us that rather quickly :-)
>
>
> good :-)
>
>>
>> Regarding the lifecycle of Web-app raised by Filip, this is how I
>> implemented it for the replication stuff:
>>
>> * when a replication manager starts, it sends to the cluster a
>> ReplicaStorageMonitorEvent JOIN event
>> (BasicReplicaStorageMonitor.start);
>> * replication storages monitor such an event and send to the joining
>> replication manager their location
>> (BasicReplicaStorageExporter.onMonitorEvent);
>> * when a replication storage starts or stops, it sends to the cluster
>> a ReplicaStorageEvent JOIN or LEAVE event
>> (BasicReplicaStorageAdvertiser.start and stop);
>> * replication managers monitor these events
>> (BasicReplicaStorageMonitor.onReplicaStorageEvent); and
>> * replication managers monitor leaving or failing peer events
>> (BasicReplicaStorageMonitor).
>>
>> This way, a replication manager always know the current replication
>> storages and their locations..
>
>
> loosk good - I'll bear it all in mind...
>
> The only real issue that I have thought of with the share-all approach
> so far is this -
>
> If you undeploy an application, you want all of its classes and
> instances thereof removed from the local JVM - so that on redeploying
> it, you don't come across any versioning problems.
>
> This implies that this app's sessions must be removed from the JVM and
> that they must be managed by vms on which the app is deployed - as
> when they time-out, their destruction may involve their
> deserialisation or a requirement for their parent app to be present...
>
> If there are other instances of the app running, we can evacuate the
> sessions to them. If there are not, we will either have to drop the
> sessions, or move them into persistant storage until such time as an
> instance of their app is available again....
>
> So, we have a new requirement to unload a single apps sessions and a
> new requirement to know which apps are where...
>
> arggghhhh! it's beginning to get complicated :-( - more thought
> required...
>
> I'm beginning to think that the only thing that we can really share
> (without quite a bit of extra work) is the Dispatcher and connection
> to the Cluster...
>

Thinking more deeply about this, I have come across another issue which
looks quite nasty...

Consider a bunch of portlets which do cross-context dispatch to each
other but are deployed within different apps. My understanding is as
follows :

The same session id may be mapped to a different session within the
context of each portlet, but the lifecycles of all sessions must be
unified so that if one is invalidated, all are invalidated.  I was
planning to implement this behaviour by storing all sessions mapped to
the same id within a larger 'super-session'. The sub-session lifecycles
would all be mapped to the super-session lifecycle. The super-session
would be object given to WADI's clustering layer and this would ensure
the colocation of all of the sub-sessions - i.e. if one moved to another
peer - they would all move - apparently cross-context dispatch is always
done locally...

The problem arises in that these sub-sessions will belong to different
deployment units. What happens if I undeploy one of the portlets on a
server, but not the others ? The sessions associated with Portlet1 may
need to be migrated to another instance of the same Portlet in order for
their availability to be maintained and in order for refs to the
undeployed classes to be removed from the local jvm - but clients may
still be stuck to e.g. Portlet2 on the same server, which was doing
cross-context dispatch onto Portlet2... - I guess this highlights a
Portlet dependency issue - which is that if you undeploy a Portlet, you
must undeploy all the upstream (in terms of cross-context dispatch)
portlets first.... (does anyone know if portlet containers do this sort
of thing?)  - trouble is, if this is not done atomically, how will WADI
cope with the fragmentation of a super-session ? If we allow
super-session fragmentation and then re-aggregation, things could get
very complex... - super-sessions obviously need a lot more thought than
I or the proposed Geronimo session API have yet given them....

Anyone have any thoughts about this - I am disappearing into my own navel !

Jules

>
>
> Jules
>
>>
>> Thanks,
>> Gianny
>>
>> Jules Gosnell wrote:
>>
>>> Filip Hanik - Dev Lists wrote:
>>>
>>>> Jules Gosnell wrote:
>>>>
>>>>> Filip Hanik - Dev Lists wrote:
>>>>>
>>>>>>
>>>>>> remember, that in Tomcat, you can configure a setting where the
>>>>>> JSESSIONID is global to the domain, not just the app, and is
>>>>>> shared between webapps. So we need to consider what effects this
>>>>>> will have on WADI
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Yes - I had something in mind like this for cross-context portlet
>>>>> sessions - which must be able to share a single session id, live
>>>>> in separate app contexts, but have a single unified lifetime -
>>>>> i.e. when one session is invalidated, all are...
>>>>
>>>>
>>>>
>>>>
>>>> interesting, you can essentially create one global session, and
>>>> flatten the namespace so that app /examples
>>>> session.getAttribute("myatt")
>>>> becomes session.getAttribute("/examples/myatt");
>>>
>>>
>>>
>>>
>>> I must have explained this badly - this wasn't my intention. What I
>>> meant to say was that by giving two different apps the same
>>> namespace prefix, they would be able to see each others sessions,
>>> but no-one elses.
>>>
>>> So, I am talking about having a map of  e.g. <context>.<session-id>
>>> : <session> - where session is a map of <attribute-key> :
>>> <attribute-value>, whereas, I think that you are imagining something
>>> more like a single map of : <session-id>.<context>/<attribute-key> :
>>> <attribute-value> - for the portlet scenario (more below), this
>>> might be an option (but not the route that I had in mind).
>>>
>>>> (note, in tomcat the prefix has to be
>>>> "/host/context/attributename") as tomcat supports virtual hosts.
>>>
>>>
>>>
>>>
>>> Good point - I will bear that in mind - thanks.
>>>
>>>>
>>>> this will work even if the session is only available in one app,
>>>> /examples, as the implementation works for 1..N apps.
>>>>
>>>> you can have one global session manager, just remember that
>>>> stop/undeploy of an app, should kick off listeners, and clean up
>>>> that apps attributes.
>>>
>>>
>>>
>>>
>>> Yes - this might complicate things - I will investigate.
>>>
>>>>
>>>> also, you can introduce a custom WADI optional feature to share
>>>> session attributes between webapps, kind of a neat idea when you
>>>> think about it.
>>>
>>>
>>>
>>>
>>> hmmm... - is this the same as two webapps sharing the same session
>>> namespace ?
>>>
>>>>
>>>>>
>>>>> I figure that we introduce a pluggable strategy to create an
>>>>> internal-key (e.g. /wadi-ABCD) from the external-key (e.g. ABCD or
>>>>> ABCD.red (with e.g. mod_jk)). Usually, this strategy will prepend
>>>>> the app-id (context-path for a webapp), but in the case that you
>>>>> mention, we would flatten the cross-context namespace by using the
>>>>> same prefix for all portlets that we wish to fall into this space
>>>>> - or just omit it all together...
>>>>
>>>>
>>>>
>>>>
>>>> not sure what you mean by this,
>>>
>>>
>>>
>>>
>>> So, referring back to my <context>.<session-id> : <session>
>>> structure. I am saying that we create an internal-key
>>> (<context>.<session-id>) from the external key (the session id that
>>> we retrieved from the request, which may include decoration that
>>> needs to be stripped (in the case of e.g. mod_jk)). The internal-key
>>> is simply the undecorated session-id with a namespace qualifier -
>>> probably now: <vhost>.<context>. This internal key is used in the
>>> Contextualiser stack to ensure separation of data belonging to
>>> different apps on different vhosts.
>>>
>>>> the jvmRoute on mod_jk today is a minor disaster, and a pretty sad
>>>> story for a sticky loadbalancing algo.
>>>
>>>
>>>
>>>
>>> Well - I disagree slightly - it has good and bad points:
>>>
>>> - the bad - it messes with the session cookie
>>> - the good - it enables an explicit coordination between container
>>> and load-balancer which may be exploited.
>>>
>>> perhaps a better solution would be to use a second cookie to encode
>>> routing info ?
>>>
>>>> I don't think depending on an external product like mod_jk is a
>>>> good idea.
>>>
>>>
>>>
>>>
>>> No - WADI does not depend on JK, but it does support it and exploit
>>> the jvmRoute feature - I was just using it as an example of how the
>>> external key does not necessarily map directly to the internal
>>> key.... - feel better ? :-)
>>>
>>>> Maybe I'm misunderstanding you.
>>>
>>>
>>>
>>>
>>> yes !
>>>
>>>
>>> Jules
>>>
>>>>
>>>> Filip
>>>>
>>>>
>>>>>
>>>>> sound OK ?
>>>>>
>>>>> Jules
>>>>>
>>>>>>
>>>>>> Filip
>>>>>>
>>>>>>>
>>>>>>> I will have a look at the Manager as well - in case we can share
>>>>>>> some of this and move the non-shared stuff onto another object -
>>>>>>> the Invocation ?
>>>>>>>
>>>>>>> Jules
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>

--
"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.
 **********************************/

[Jules Gosnell-4]

Jules Gosnell wrote:

> Gianny Damour wrote:
>
>> Jules,
>>
>> I think that it makes sense to start with this share-all approach and
>> the namespacing of the session ID will give us that rather quickly :-)
>
>
> good :-)
>
>>
>> Regarding the lifecycle of Web-app raised by Filip, this is how I
>> implemented it for the replication stuff:
>>
>> * when a replication manager starts, it sends to the cluster a
>> ReplicaStorageMonitorEvent JOIN event
>> (BasicReplicaStorageMonitor.start);
>> * replication storages monitor such an event and send to the joining
>> replication manager their location
>> (BasicReplicaStorageExporter.onMonitorEvent);
>> * when a replication storage starts or stops, it sends to the cluster
>> a ReplicaStorageEvent JOIN or LEAVE event
>> (BasicReplicaStorageAdvertiser.start and stop);
>> * replication managers monitor these events
>> (BasicReplicaStorageMonitor.onReplicaStorageEvent); and
>> * replication managers monitor leaving or failing peer events
>> (BasicReplicaStorageMonitor).
>>
>> This way, a replication manager always know the current replication
>> storages and their locations..
>
>
> loosk good - I'll bear it all in mind...
>
> The only real issue that I have thought of with the share-all approach
> so far is this -
>
> If you undeploy an application, you want all of its classes and
> instances thereof removed from the local JVM - so that on redeploying
> it, you don't come across any versioning problems.
>
> This implies that this app's sessions must be removed from the JVM and
> that they must be managed by vms on which the app is deployed - as
> when they time-out, their destruction may involve their
> deserialisation or a requirement for their parent app to be present...
>
> If there are other instances of the app running, we can evacuate the
> sessions to them. If there are not, we will either have to drop the
> sessions, or move them into persistant storage until such time as an
> instance of their app is available again....
>
> So, we have a new requirement to unload a single apps sessions and a
> new requirement to know which apps are where...
>
> arggghhhh! it's beginning to get complicated :-( - more thought
> required...
>
> I'm beginning to think that the only thing that we can really share
> (without quite a bit of extra work) is the Dispatcher and connection
> to the Cluster...
>
>

leaving Portlets and coming back to the immediate problem - sharing a
Contextualiser stack between a number of apps and what happens if an app
is stopped/undeployed....

what we may really be talking about here is a heterogeneous deployment -
i.e. a cluster where not all nodes are running the same apps. It may
only be heterogeneous for a short while, whilst an app instance is
upgraded on a single node - but this is still heterogeneity and the
availability of this app's sessions must be maintained...

the current shared-none approach resolves this by ensuring the
homogeneity of the cluster by unifying cluster-membership with
containing-the-app-in-question - i.e. the problem of heterogeneity never
raises its head because as soon as you cease to run the app in question
you also cease to be a cluster member...

aarrrrgggghhhh ! heterogeneous deployments were an issue that I have
tried very hard not to avoid !

To deal with this problem cleanly, i think that we may need to support
the abstraction of subclusters - i.e. groups within groups. There is a
universal set/group (E), which represents everyone connected to the
cluster. E contains a number of possibly intersecting subsets - each one
of which represents the set of nodes running a particular application.
The superset, E, is heterogeneous, but the subsets are all homogeneous
(for a given app).

This is beginning to look a little like the way that Gianny has modeled
his replication service - as a separate 'group' with its own membership
and join/leave protocol - is that correct, Gianny ?

Perhaps we should be looking at extending our group api to support
subsetting so that we can implement heterogeneity and other subsetting
(replication sets and possibly even partner groupings (the peers to
which you replicate  a given session)) as subsets of E...

The more that I think about this, the cooler that I think it is :-)

Thoughts... ?


Jules

>
> Jules
>
>>
>> Thanks,
>> Gianny
>>
>> Jules Gosnell wrote:
>>
>>> Filip Hanik - Dev Lists wrote:
>>>
>>>> Jules Gosnell wrote:
>>>>
>>>>> Filip Hanik - Dev Lists wrote:
>>>>>
>>>>>>
>>>>>> remember, that in Tomcat, you can configure a setting where the
>>>>>> JSESSIONID is global to the domain, not just the app, and is
>>>>>> shared between webapps. So we need to consider what effects this
>>>>>> will have on WADI
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Yes - I had something in mind like this for cross-context portlet
>>>>> sessions - which must be able to share a single session id, live
>>>>> in separate app contexts, but have a single unified lifetime -
>>>>> i.e. when one session is invalidated, all are...
>>>>
>>>>
>>>>
>>>>
>>>> interesting, you can essentially create one global session, and
>>>> flatten the namespace so that app /examples
>>>> session.getAttribute("myatt")
>>>> becomes session.getAttribute("/examples/myatt");
>>>
>>>
>>>
>>>
>>> I must have explained this badly - this wasn't my intention. What I
>>> meant to say was that by giving two different apps the same
>>> namespace prefix, they would be able to see each others sessions,
>>> but no-one elses.
>>>
>>> So, I am talking about having a map of  e.g. <context>.<session-id>
>>> : <session> - where session is a map of <attribute-key> :
>>> <attribute-value>, whereas, I think that you are imagining something
>>> more like a single map of : <session-id>.<context>/<attribute-key> :
>>> <attribute-value> - for the portlet scenario (more below), this
>>> might be an option (but not the route that I had in mind).
>>>
>>>> (note, in tomcat the prefix has to be
>>>> "/host/context/attributename") as tomcat supports virtual hosts.
>>>
>>>
>>>
>>>
>>> Good point - I will bear that in mind - thanks.
>>>
>>>>
>>>> this will work even if the session is only available in one app,
>>>> /examples, as the implementation works for 1..N apps.
>>>>
>>>> you can have one global session manager, just remember that
>>>> stop/undeploy of an app, should kick off listeners, and clean up
>>>> that apps attributes.
>>>
>>>
>>>
>>>
>>> Yes - this might complicate things - I will investigate.
>>>
>>>>
>>>> also, you can introduce a custom WADI optional feature to share
>>>> session attributes between webapps, kind of a neat idea when you
>>>> think about it.
>>>
>>>
>>>
>>>
>>> hmmm... - is this the same as two webapps sharing the same session
>>> namespace ?
>>>
>>>>
>>>>>
>>>>> I figure that we introduce a pluggable strategy to create an
>>>>> internal-key (e.g. /wadi-ABCD) from the external-key (e.g. ABCD or
>>>>> ABCD.red (with e.g. mod_jk)). Usually, this strategy will prepend
>>>>> the app-id (context-path for a webapp), but in the case that you
>>>>> mention, we would flatten the cross-context namespace by using the
>>>>> same prefix for all portlets that we wish to fall into this space
>>>>> - or just omit it all together...
>>>>
>>>>
>>>>
>>>>
>>>> not sure what you mean by this,
>>>
>>>
>>>
>>>
>>> So, referring back to my <context>.<session-id> : <session>
>>> structure. I am saying that we create an internal-key
>>> (<context>.<session-id>) from the external key (the session id that
>>> we retrieved from the request, which may include decoration that
>>> needs to be stripped (in the case of e.g. mod_jk)). The internal-key
>>> is simply the undecorated session-id with a namespace qualifier -
>>> probably now: <vhost>.<context>. This internal key is used in the
>>> Contextualiser stack to ensure separation of data belonging to
>>> different apps on different vhosts.
>>>
>>>> the jvmRoute on mod_jk today is a minor disaster, and a pretty sad
>>>> story for a sticky loadbalancing algo.
>>>
>>>
>>>
>>>
>>> Well - I disagree slightly - it has good and bad points:
>>>
>>> - the bad - it messes with the session cookie
>>> - the good - it enables an explicit coordination between container
>>> and load-balancer which may be exploited.
>>>
>>> perhaps a better solution would be to use a second cookie to encode
>>> routing info ?
>>>
>>>> I don't think depending on an external product like mod_jk is a
>>>> good idea.
>>>
>>>
>>>
>>>
>>> No - WADI does not depend on JK, but it does support it and exploit
>>> the jvmRoute feature - I was just using it as an example of how the
>>> external key does not necessarily map directly to the internal
>>> key.... - feel better ? :-)
>>>
>>>> Maybe I'm misunderstanding you.
>>>
>>>
>>>
>>>
>>> yes !
>>>
>>>
>>> Jules
>>>
>>>>
>>>> Filip
>>>>
>>>>
>>>>>
>>>>> sound OK ?
>>>>>
>>>>> Jules
>>>>>
>>>>>>
>>>>>> Filip
>>>>>>
>>>>>>>
>>>>>>> I will have a look at the Manager as well - in case we can share
>>>>>>> some of this and move the non-shared stuff onto another object -
>>>>>>> the Invocation ?
>>>>>>>
>>>>>>> Jules
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
>

--
"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.
 **********************************/

[Jules Gosnell-4]

Jules Gosnell wrote:

> Jules Gosnell wrote:
>
>> Gianny Damour wrote:
>>
>>> Jules,
>>>
>>> I think that it makes sense to start with this share-all approach
>>> and the namespacing of the session ID will give us that rather
>>> quickly :-)
>>
>>
>>
>> good :-)
>>
>>>
>>> Regarding the lifecycle of Web-app raised by Filip, this is how I
>>> implemented it for the replication stuff:
>>>
>>> * when a replication manager starts, it sends to the cluster a
>>> ReplicaStorageMonitorEvent JOIN event
>>> (BasicReplicaStorageMonitor.start);
>>> * replication storages monitor such an event and send to the joining
>>> replication manager their location
>>> (BasicReplicaStorageExporter.onMonitorEvent);
>>> * when a replication storage starts or stops, it sends to the
>>> cluster a ReplicaStorageEvent JOIN or LEAVE event
>>> (BasicReplicaStorageAdvertiser.start and stop);
>>> * replication managers monitor these events
>>> (BasicReplicaStorageMonitor.onReplicaStorageEvent); and
>>> * replication managers monitor leaving or failing peer events
>>> (BasicReplicaStorageMonitor).
>>>
>>> This way, a replication manager always know the current replication
>>> storages and their locations..
>>
>>
>>
>> loosk good - I'll bear it all in mind...
>>
>> The only real issue that I have thought of with the share-all
>> approach so far is this -
>>
>> If you undeploy an application, you want all of its classes and
>> instances thereof removed from the local JVM - so that on redeploying
>> it, you don't come across any versioning problems.
>>
>> This implies that this app's sessions must be removed from the JVM
>> and that they must be managed by vms on which the app is deployed -
>> as when they time-out, their destruction may involve their
>> deserialisation or a requirement for their parent app to be present...
>>
>> If there are other instances of the app running, we can evacuate the
>> sessions to them. If there are not, we will either have to drop the
>> sessions, or move them into persistant storage until such time as an
>> instance of their app is available again....
>>
>> So, we have a new requirement to unload a single apps sessions and a
>> new requirement to know which apps are where...
>>
>> arggghhhh! it's beginning to get complicated :-( - more thought
>> required...
>>
>> I'm beginning to think that the only thing that we can really share
>> (without quite a bit of extra work) is the Dispatcher and connection
>> to the Cluster...
>>
>>
> leaving Portlets and coming back to the immediate problem - sharing a
> Contextualiser stack between a number of apps and what happens if an
> app is stopped/undeployed....
>
> what we may really be talking about here is a heterogeneous deployment
> - i.e. a cluster where not all nodes are running the same apps. It may
> only be heterogeneous for a short while, whilst an app instance is
> upgraded on a single node - but this is still heterogeneity and the
> availability of this app's sessions must be maintained...
>
> the current shared-none approach resolves this by ensuring the
> homogeneity of the cluster by unifying cluster-membership with
> containing-the-app-in-question - i.e. the problem of heterogeneity
> never raises its head because as soon as you cease to run the app in
> question you also cease to be a cluster member...
>
> aarrrrgggghhhh ! heterogeneous deployments were an issue that I have
> tried very hard not to avoid !
>
> To deal with this problem cleanly, i think that we may need to support
> the abstraction of subclusters - i.e. groups within groups. There is a
> universal set/group (E), which represents everyone connected to the
> cluster. E contains a number of possibly intersecting subsets - each
> one of which represents the set of nodes running a particular
> application. The superset, E, is heterogeneous, but the subsets are
> all homogeneous (for a given app).
>
> This is beginning to look a little like the way that Gianny has
> modeled his replication service - as a separate 'group' with its own
> membership and join/leave protocol - is that correct, Gianny ?
>
> Perhaps we should be looking at extending our group api to support
> subsetting so that we can implement heterogeneity and other subsetting
> (replication sets and possibly even partner groupings (the peers to
> which you replicate  a given session)) as subsets of E...
>
> The more that I think about this, the cooler that I think it is :-)
>

One last thought - before I take the dog for a walk and give this some
really serious consideration :-)

if we can make the api to a subset identical to the api to E, then we
can write code that does not need to know whether it is running in a
standalone situation or a subsetted situation - all each app needs to do
is register membership with a 'set' and monitor membership of this set.
Whether it is E or a subset of E, becomes irrelevant. You could even
have subsets of subsets, if you could find a reasonable usecase :-)

Jules

> Thoughts... ?
>
>
> Jules
>
>>
>> Jules
>>
>>>
>>> Thanks,
>>> Gianny
>>>
>>> Jules Gosnell wrote:
>>>
>>>> Filip Hanik - Dev Lists wrote:
>>>>
>>>>> Jules Gosnell wrote:
>>>>>
>>>>>> Filip Hanik - Dev Lists wrote:
>>>>>>
>>>>>>>
>>>>>>> remember, that in Tomcat, you can configure a setting where the
>>>>>>> JSESSIONID is global to the domain, not just the app, and is
>>>>>>> shared between webapps. So we need to consider what effects this
>>>>>>> will have on WADI
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yes - I had something in mind like this for cross-context portlet
>>>>>> sessions - which must be able to share a single session id, live
>>>>>> in separate app contexts, but have a single unified lifetime -
>>>>>> i.e. when one session is invalidated, all are...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> interesting, you can essentially create one global session, and
>>>>> flatten the namespace so that app /examples
>>>>> session.getAttribute("myatt")
>>>>> becomes session.getAttribute("/examples/myatt");
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> I must have explained this badly - this wasn't my intention. What I
>>>> meant to say was that by giving two different apps the same
>>>> namespace prefix, they would be able to see each others sessions,
>>>> but no-one elses.
>>>>
>>>> So, I am talking about having a map of  e.g. <context>.<session-id>
>>>> : <session> - where session is a map of <attribute-key> :
>>>> <attribute-value>, whereas, I think that you are imagining
>>>> something more like a single map of :
>>>> <session-id>.<context>/<attribute-key> : <attribute-value> - for
>>>> the portlet scenario (more below), this might be an option (but not
>>>> the route that I had in mind).
>>>>
>>>>> (note, in tomcat the prefix has to be
>>>>> "/host/context/attributename") as tomcat supports virtual hosts.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Good point - I will bear that in mind - thanks.
>>>>
>>>>>
>>>>> this will work even if the session is only available in one app,
>>>>> /examples, as the implementation works for 1..N apps.
>>>>>
>>>>> you can have one global session manager, just remember that
>>>>> stop/undeploy of an app, should kick off listeners, and clean up
>>>>> that apps attributes.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Yes - this might complicate things - I will investigate.
>>>>
>>>>>
>>>>> also, you can introduce a custom WADI optional feature to share
>>>>> session attributes between webapps, kind of a neat idea when you
>>>>> think about it.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> hmmm... - is this the same as two webapps sharing the same session
>>>> namespace ?
>>>>
>>>>>
>>>>>>
>>>>>> I figure that we introduce a pluggable strategy to create an
>>>>>> internal-key (e.g. /wadi-ABCD) from the external-key (e.g. ABCD
>>>>>> or ABCD.red (with e.g. mod_jk)). Usually, this strategy will
>>>>>> prepend the app-id (context-path for a webapp), but in the case
>>>>>> that you mention, we would flatten the cross-context namespace by
>>>>>> using the same prefix for all portlets that we wish to fall into
>>>>>> this space - or just omit it all together...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> not sure what you mean by this,
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> So, referring back to my <context>.<session-id> : <session>
>>>> structure. I am saying that we create an internal-key
>>>> (<context>.<session-id>) from the external key (the session id that
>>>> we retrieved from the request, which may include decoration that
>>>> needs to be stripped (in the case of e.g. mod_jk)). The
>>>> internal-key is simply the undecorated session-id with a namespace
>>>> qualifier - probably now: <vhost>.<context>. This internal key is
>>>> used in the Contextualiser stack to ensure separation of data
>>>> belonging to different apps on different vhosts.
>>>>
>>>>> the jvmRoute on mod_jk today is a minor disaster, and a pretty sad
>>>>> story for a sticky loadbalancing algo.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Well - I disagree slightly - it has good and bad points:
>>>>
>>>> - the bad - it messes with the session cookie
>>>> - the good - it enables an explicit coordination between container
>>>> and load-balancer which may be exploited.
>>>>
>>>> perhaps a better solution would be to use a second cookie to encode
>>>> routing info ?
>>>>
>>>>> I don't think depending on an external product like mod_jk is a
>>>>> good idea.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> No - WADI does not depend on JK, but it does support it and exploit
>>>> the jvmRoute feature - I was just using it as an example of how the
>>>> external key does not necessarily map directly to the internal
>>>> key.... - feel better ? :-)
>>>>
>>>>> Maybe I'm misunderstanding you.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> yes !
>>>>
>>>>
>>>> Jules
>>>>
>>>>>
>>>>> Filip
>>>>>
>>>>>
>>>>>>
>>>>>> sound OK ?
>>>>>>
>>>>>> Jules
>>>>>>
>>>>>>>
>>>>>>> Filip
>>>>>>>
>>>>>>>>
>>>>>>>> I will have a look at the Manager as well - in case we can
>>>>>>>> share some of this and move the non-shared stuff onto another
>>>>>>>> object - the Invocation ?
>>>>>>>>
>>>>>>>> Jules
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

--
"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.
 **********************************/

[Jules Gosnell-4]

Jules Gosnell wrote:

> Jules Gosnell wrote:
>
>> Jules Gosnell wrote:
>>
>>> Gianny Damour wrote:
>>>
>>>> Jules,
>>>>
>>>> I think that it makes sense to start with this share-all approach
>>>> and the namespacing of the session ID will give us that rather
>>>> quickly :-)
>>>
>>>
>>>
>>>
>>> good :-)
>>>
>>>>
>>>> Regarding the lifecycle of Web-app raised by Filip, this is how I
>>>> implemented it for the replication stuff:
>>>>
>>>> * when a replication manager starts, it sends to the cluster a
>>>> ReplicaStorageMonitorEvent JOIN event
>>>> (BasicReplicaStorageMonitor.start);
>>>> * replication storages monitor such an event and send to the
>>>> joining replication manager their location
>>>> (BasicReplicaStorageExporter.onMonitorEvent);
>>>> * when a replication storage starts or stops, it sends to the
>>>> cluster a ReplicaStorageEvent JOIN or LEAVE event
>>>> (BasicReplicaStorageAdvertiser.start and stop);
>>>> * replication managers monitor these events
>>>> (BasicReplicaStorageMonitor.onReplicaStorageEvent); and
>>>> * replication managers monitor leaving or failing peer events
>>>> (BasicReplicaStorageMonitor).
>>>>
>>>> This way, a replication manager always know the current replication
>>>> storages and their locations..
>>>
>>>
>>>
>>>
>>> loosk good - I'll bear it all in mind...
>>>
>>> The only real issue that I have thought of with the share-all
>>> approach so far is this -
>>>
>>> If you undeploy an application, you want all of its classes and
>>> instances thereof removed from the local JVM - so that on
>>> redeploying it, you don't come across any versioning problems.
>>>
>>> This implies that this app's sessions must be removed from the JVM
>>> and that they must be managed by vms on which the app is deployed -
>>> as when they time-out, their destruction may involve their
>>> deserialisation or a requirement for their parent app to be present...
>>>
>>> If there are other instances of the app running, we can evacuate the
>>> sessions to them. If there are not, we will either have to drop the
>>> sessions, or move them into persistant storage until such time as an
>>> instance of their app is available again....
>>>
>>> So, we have a new requirement to unload a single apps sessions and a
>>> new requirement to know which apps are where...
>>>
>>> arggghhhh! it's beginning to get complicated :-( - more thought
>>> required...
>>>
>>> I'm beginning to think that the only thing that we can really share
>>> (without quite a bit of extra work) is the Dispatcher and connection
>>> to the Cluster...
>>>
>>>
>> leaving Portlets and coming back to the immediate problem - sharing a
>> Contextualiser stack between a number of apps and what happens if an
>> app is stopped/undeployed....
>>
>> what we may really be talking about here is a heterogeneous
>> deployment - i.e. a cluster where not all nodes are running the same
>> apps. It may only be heterogeneous for a short while, whilst an app
>> instance is upgraded on a single node - but this is still
>> heterogeneity and the availability of this app's sessions must be
>> maintained...
>>
>> the current shared-none approach resolves this by ensuring the
>> homogeneity of the cluster by unifying cluster-membership with
>> containing-the-app-in-question - i.e. the problem of heterogeneity
>> never raises its head because as soon as you cease to run the app in
>> question you also cease to be a cluster member...
>>
>> aarrrrgggghhhh ! heterogeneous deployments were an issue that I have
>> tried very hard not to avoid !
>>
>> To deal with this problem cleanly, i think that we may need to
>> support the abstraction of subclusters - i.e. groups within groups.
>> There is a universal set/group (E), which represents everyone
>> connected to the cluster. E contains a number of possibly
>> intersecting subsets - each one of which represents the set of nodes
>> running a particular application. The superset, E, is heterogeneous,
>> but the subsets are all homogeneous (for a given app).
>>
>> This is beginning to look a little like the way that Gianny has
>> modeled his replication service - as a separate 'group' with its own
>> membership and join/leave protocol - is that correct, Gianny ?
>>
>> Perhaps we should be looking at extending our group api to support
>> subsetting so that we can implement heterogeneity and other
>> subsetting (replication sets and possibly even partner groupings (the
>> peers to which you replicate  a given session)) as subsets of E...
>>
>> The more that I think about this, the cooler that I think it is :-)
>>
> One last thought - before I take the dog for a walk and give this some
> really serious consideration :-)
>
> if we can make the api to a subset identical to the api to E, then we
> can write code that does not need to know whether it is running in a
> standalone situation or a subsetted situation - all each app needs to
> do is register membership with a 'set' and monitor membership of this
> set. Whether it is E or a subset of E, becomes irrelevant. You could
> even have subsets of subsets, if you could find a reasonable usecase :-)
>

further thoughts...

- this approach would involve little if any change to the higher level
parts of WADI - everything would be looked after at the dispatcher/group
level.
- we would need to extend the Group/Cluster API to include e.g. set
creation and destruction notifications.
- some clients - i.e. a replication service, might choose to listen to
multiple sets and service all of them with one set of resources
- some clients will just assume that they are a member of the only set
and carry on obliviously
- we will need to extend the dispatcher/group module with subset
lifecycle and membership protocols - Tribes might implement these
natively using preexisting protocols ?
- there are all sorts of things in Geronimo that we could do with a
clean model that supports heterogeneity :-)
- etc...

Jules

> Jules
>
>> Thoughts... ?
>>
>>
>> Jules
>>
>>>
>>> Jules
>>>
>>>>
>>>> Thanks,
>>>> Gianny
>>>>
>>>> Jules Gosnell wrote:
>>>>
>>>>> Filip Hanik - Dev Lists wrote:
>>>>>
>>>>>> Jules Gosnell wrote:
>>>>>>
>>>>>>> Filip Hanik - Dev Lists wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> remember, that in Tomcat, you can configure a setting where the
>>>>>>>> JSESSIONID is global to the domain, not just the app, and is
>>>>>>>> shared between webapps. So we need to consider what effects
>>>>>>>> this will have on WADI
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Yes - I had something in mind like this for cross-context
>>>>>>> portlet sessions - which must be able to share a single session
>>>>>>> id, live in separate app contexts, but have a single unified
>>>>>>> lifetime - i.e. when one session is invalidated, all are...
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> interesting, you can essentially create one global session, and
>>>>>> flatten the namespace so that app /examples
>>>>>> session.getAttribute("myatt")
>>>>>> becomes session.getAttribute("/examples/myatt");
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I must have explained this badly - this wasn't my intention. What
>>>>> I meant to say was that by giving two different apps the same
>>>>> namespace prefix, they would be able to see each others sessions,
>>>>> but no-one elses.
>>>>>
>>>>> So, I am talking about having a map of  e.g.
>>>>> <context>.<session-id> : <session> - where session is a map of
>>>>> <attribute-key> : <attribute-value>, whereas, I think that you are
>>>>> imagining something more like a single map of :
>>>>> <session-id>.<context>/<attribute-key> : <attribute-value> - for
>>>>> the portlet scenario (more below), this might be an option (but
>>>>> not the route that I had in mind).
>>>>>
>>>>>> (note, in tomcat the prefix has to be
>>>>>> "/host/context/attributename") as tomcat supports virtual hosts.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Good point - I will bear that in mind - thanks.
>>>>>
>>>>>>
>>>>>> this will work even if the session is only available in one app,
>>>>>> /examples, as the implementation works for 1..N apps.
>>>>>>
>>>>>> you can have one global session manager, just remember that
>>>>>> stop/undeploy of an app, should kick off listeners, and clean up
>>>>>> that apps attributes.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Yes - this might complicate things - I will investigate.
>>>>>
>>>>>>
>>>>>> also, you can introduce a custom WADI optional feature to share
>>>>>> session attributes between webapps, kind of a neat idea when you
>>>>>> think about it.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> hmmm... - is this the same as two webapps sharing the same session
>>>>> namespace ?
>>>>>
>>>>>>
>>>>>>>
>>>>>>> I figure that we introduce a pluggable strategy to create an
>>>>>>> internal-key (e.g. /wadi-ABCD) from the external-key (e.g. ABCD
>>>>>>> or ABCD.red (with e.g. mod_jk)). Usually, this strategy will
>>>>>>> prepend the app-id (context-path for a webapp), but in the case
>>>>>>> that you mention, we would flatten the cross-context namespace
>>>>>>> by using the same prefix for all portlets that we wish to fall
>>>>>>> into this space - or just omit it all together...
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> not sure what you mean by this,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> So, referring back to my <context>.<session-id> : <session>
>>>>> structure. I am saying that we create an internal-key
>>>>> (<context>.<session-id>) from the external key (the session id
>>>>> that we retrieved from the request, which may include decoration
>>>>> that needs to be stripped (in the case of e.g. mod_jk)). The
>>>>> internal-key is simply the undecorated session-id with a namespace
>>>>> qualifier - probably now: <vhost>.<context>. This internal key is
>>>>> used in the Contextualiser stack to ensure separation of data
>>>>> belonging to different apps on different vhosts.
>>>>>
>>>>>> the jvmRoute on mod_jk today is a minor disaster, and a pretty
>>>>>> sad story for a sticky loadbalancing algo.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Well - I disagree slightly - it has good and bad points:
>>>>>
>>>>> - the bad - it messes with the session cookie
>>>>> - the good - it enables an explicit coordination between container
>>>>> and load-balancer which may be exploited.
>>>>>
>>>>> perhaps a better solution would be to use a second cookie to
>>>>> encode routing info ?
>>>>>
>>>>>> I don't think depending on an external product like mod_jk is a
>>>>>> good idea.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> No - WADI does not depend on JK, but it does support it and
>>>>> exploit the jvmRoute feature - I was just using it as an example
>>>>> of how the external key does not necessarily map directly to the
>>>>> internal key.... - feel better ? :-)
>>>>>
>>>>>> Maybe I'm misunderstanding you.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> yes !
>>>>>
>>>>>
>>>>> Jules
>>>>>
>>>>>>
>>>>>> Filip
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> sound OK ?
>>>>>>>
>>>>>>> Jules
>>>>>>>
>>>>>>>>
>>>>>>>> Filip
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I will have a look at the Manager as well - in case we can
>>>>>>>>> share some of this and move the non-shared stuff onto another
>>>>>>>>> object - the Invocation ?
>>>>>>>>>
>>>>>>>>> Jules
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>

--
"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.
 **********************************/

[djencks]

On May 9, 2006, at 6:10 AM, Jules Gosnell wrote:

> Jules Gosnell wrote:
>
>> Gianny Damour wrote:
>>
>>> Jules,
>>>
>>> I think that it makes sense to start with this share-all approach  
>>> and the namespacing of the session ID will give us that rather  
>>> quickly :-)
>>
>>
>> good :-)
>>
>>>
>>> Regarding the lifecycle of Web-app raised by Filip, this is how I  
>>> implemented it for the replication stuff:
>>>
>>> * when a replication manager starts, it sends to the cluster a  
>>> ReplicaStorageMonitorEvent JOIN event  
>>> (BasicReplicaStorageMonitor.start);
>>> * replication storages monitor such an event and send to the  
>>> joining replication manager their location  
>>> (BasicReplicaStorageExporter.onMonitorEvent);
>>> * when a replication storage starts or stops, it sends to the  
>>> cluster a ReplicaStorageEvent JOIN or LEAVE event  
>>> (BasicReplicaStorageAdvertiser.start and stop);
>>> * replication managers monitor these events  
>>> (BasicReplicaStorageMonitor.onReplicaStorageEvent); and
>>> * replication managers monitor leaving or failing peer events  
>>> (BasicReplicaStorageMonitor).
>>>
>>> This way, a replication manager always know the current  
>>> replication storages and their locations..
>>
>>
>> loosk good - I'll bear it all in mind...
>>
>> The only real issue that I have thought of with the share-all  
>> approach so far is this -
>>
>> If you undeploy an application, you want all of its classes and  
>> instances thereof removed from the local JVM - so that on  
>> redeploying it, you don't come across any versioning problems.
>>
>> This implies that this app's sessions must be removed from the JVM  
>> and that they must be managed by vms on which the app is deployed  
>> - as when they time-out, their destruction may involve their  
>> deserialisation or a requirement for their parent app to be  
>> present...
>>
>> If there are other instances of the app running, we can evacuate  
>> the sessions to them. If there are not, we will either have to  
>> drop the sessions, or move them into persistant storage until such  
>> time as an instance of their app is available again....
>>
>> So, we have a new requirement to unload a single apps sessions and  
>> a new requirement to know which apps are where...
>>
>> arggghhhh! it's beginning to get complicated :-( - more thought  
>> required...
>>
>> I'm beginning to think that the only thing that we can really  
>> share (without quite a bit of extra work) is the Dispatcher and  
>> connection to the Cluster...
>>
> Thinking more deeply about this, I have come across another issue  
> which looks quite nasty...
>
> Consider a bunch of portlets which do cross-context dispatch to  
> each other but are deployed within different apps. My understanding  
> is as follows :
>
> The same session id may be mapped to a different session within the  
> context of each portlet, but the lifecycles of all sessions must be  
> unified so that if one is invalidated, all are invalidated.  I was  
> planning to implement this behaviour by storing all sessions mapped  
> to the same id within a larger 'super-session'. The sub-session  
> lifecycles would all be mapped to the super-session lifecycle. The  
> super-session would be object given to WADI's clustering layer and  
> this would ensure the colocation of all of the sub-sessions - i.e.  
> if one moved to another peer - they would all move - apparently  
> cross-context dispatch is always done locally...
>
> The problem arises in that these sub-sessions will belong to  
> different deployment units. What happens if I undeploy one of the  
> portlets on a server, but not the others ? The sessions associated  
> with Portlet1 may need to be migrated to another instance of the  
> same Portlet in order for their availability to be maintained and  
> in order for refs to the undeployed classes to be removed from the  
> local jvm - but clients may still be stuck to e.g. Portlet2 on the  
> same server, which was doing cross-context dispatch onto  
> Portlet2... - I guess this highlights a Portlet dependency issue -  
> which is that if you undeploy a Portlet, you must undeploy all the  
> upstream (in terms of cross-context dispatch) portlets first....  
> (does anyone know if portlet containers do this sort of thing?)  -  
> trouble is, if this is not done atomically, how will WADI cope with  
> the fragmentation of a super-session ? If we allow super-session  
> fragmentation and then re-aggregation, things could get very  
> complex... - super-sessions obviously need a lot more thought than  
> I or the proposed Geronimo session API have yet given them....
>
> Anyone have any thoughts about this - I am disappearing into my own  
> navel !

It seems to me that if you undeploy a portlet app that is part of a  
portal on only one server  that could be interpreted as removing that  
node from the cluster -- the portal will no longer work correctly on  
that node, or it will be a different application than on the other  
nodes.  Does this attitude make the problem tractable?

thanks
david jencks

>
> Jules
>
>>
>>
>> Jules
>>
>>>
>>> Thanks,
>>> Gianny
>>>
>>> Jules Gosnell wrote:
>>>
>>>> Filip Hanik - Dev Lists wrote:
>>>>
>>>>> Jules Gosnell wrote:
>>>>>
>>>>>> Filip Hanik - Dev Lists wrote:
>>>>>>
>>>>>>>
>>>>>>> remember, that in Tomcat, you can configure a setting where  
>>>>>>> the JSESSIONID is global to the domain, not just the app, and  
>>>>>>> is shared between webapps. So we need to consider what  
>>>>>>> effects this will have on WADI
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Yes - I had something in mind like this for cross-context  
>>>>>> portlet sessions - which must be able to share a single  
>>>>>> session id, live in separate app contexts, but have a single  
>>>>>> unified lifetime - i.e. when one session is invalidated, all  
>>>>>> are...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> interesting, you can essentially create one global session, and  
>>>>> flatten the namespace so that app /examples session.getAttribute
>>>>> ("myatt")
>>>>> becomes session.getAttribute("/examples/myatt");
>>>>
>>>>
>>>>
>>>>
>>>> I must have explained this badly - this wasn't my intention.  
>>>> What I meant to say was that by giving two different apps the  
>>>> same namespace prefix, they would be able to see each others  
>>>> sessions, but no-one elses.
>>>>
>>>> So, I am talking about having a map of  e.g. <context>.<session-
>>>> id> : <session> - where session is a map of <attribute-key> :  
>>>> <attribute-value>, whereas, I think that you are imagining  
>>>> something more like a single map of : <session-id>.<context>/
>>>> <attribute-key> : <attribute-value> - for the portlet scenario  
>>>> (more below), this might be an option (but not the route that I  
>>>> had in mind).
>>>>
>>>>> (note, in tomcat the prefix has to be "/host/context/
>>>>> attributename") as tomcat supports virtual hosts.
>>>>
>>>>
>>>>
>>>>
>>>> Good point - I will bear that in mind - thanks.
>>>>
>>>>>
>>>>> this will work even if the session is only available in one  
>>>>> app, /examples, as the implementation works for 1..N apps.
>>>>>
>>>>> you can have one global session manager, just remember that  
>>>>> stop/undeploy of an app, should kick off listeners, and clean  
>>>>> up that apps attributes.
>>>>
>>>>
>>>>
>>>>
>>>> Yes - this might complicate things - I will investigate.
>>>>
>>>>>
>>>>> also, you can introduce a custom WADI optional feature to share  
>>>>> session attributes between webapps, kind of a neat idea when  
>>>>> you think about it.
>>>>
>>>>
>>>>
>>>>
>>>> hmmm... - is this the same as two webapps sharing the same  
>>>> session namespace ?
>>>>
>>>>>
>>>>>>
>>>>>> I figure that we introduce a pluggable strategy to create an  
>>>>>> internal-key (e.g. /wadi-ABCD) from the external-key (e.g.  
>>>>>> ABCD or ABCD.red (with e.g. mod_jk)). Usually, this strategy  
>>>>>> will prepend the app-id (context-path for a webapp), but in  
>>>>>> the case that you mention, we would flatten the cross-context  
>>>>>> namespace by using the same prefix for all portlets that we  
>>>>>> wish to fall into this space - or just omit it all together...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> not sure what you mean by this,
>>>>
>>>>
>>>>
>>>>
>>>> So, referring back to my <context>.<session-id> : <session>  
>>>> structure. I am saying that we create an internal-key  
>>>> (<context>.<session-id>) from the external key (the session id  
>>>> that we retrieved from the request, which may include decoration  
>>>> that needs to be stripped (in the case of e.g. mod_jk)). The  
>>>> internal-key is simply the undecorated session-id with a  
>>>> namespace qualifier - probably now: <vhost>.<context>. This  
>>>> internal key is used in the Contextualiser stack to ensure  
>>>> separation of data belonging to different apps on different vhosts.
>>>>
>>>>> the jvmRoute on mod_jk today is a minor disaster, and a pretty  
>>>>> sad story for a sticky loadbalancing algo.
>>>>
>>>>
>>>>
>>>>
>>>> Well - I disagree slightly - it has good and bad points:
>>>>
>>>> - the bad - it messes with the session cookie
>>>> - the good - it enables an explicit coordination between  
>>>> container and load-balancer which may be exploited.
>>>>
>>>> perhaps a better solution would be to use a second cookie to  
>>>> encode routing info ?
>>>>
>>>>> I don't think depending on an external product like mod_jk is a  
>>>>> good idea.
>>>>
>>>>
>>>>
>>>>
>>>> No - WADI does not depend on JK, but it does support it and  
>>>> exploit the jvmRoute feature - I was just using it as an example  
>>>> of how the external key does not necessarily map directly to the  
>>>> internal key.... - feel better ? :-)
>>>>
>>>>> Maybe I'm misunderstanding you.
>>>>
>>>>
>>>>
>>>>
>>>> yes !
>>>>
>>>>
>>>> Jules
>>>>
>>>>>
>>>>> Filip
>>>>>
>>>>>
>>>>>>
>>>>>> sound OK ?
>>>>>>
>>>>>> Jules
>>>>>>
>>>>>>>
>>>>>>> Filip
>>>>>>>
>>>>>>>>
>>>>>>>> I will have a look at the Manager as well - in case we can  
>>>>>>>> share some of this and move the non-shared stuff onto  
>>>>>>>> another object - the Invocation ?
>>>>>>>>
>>>>>>>> Jules
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
> --
> "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.
> **********************************/
>

[Jules Gosnell-4]

David Jencks wrote:

>
> On May 9, 2006, at 6:10 AM, Jules Gosnell wrote:
>
>> Jules Gosnell wrote:
>>
>>> Gianny Damour wrote:
>>>
>>>> Jules,
>>>>
>>>> I think that it makes sense to start with this share-all approach  
>>>> and the namespacing of the session ID will give us that rather  
>>>> quickly :-)
>>>
>>>
>>>
>>> good :-)
>>>
>>>>
>>>> Regarding the lifecycle of Web-app raised by Filip, this is how I  
>>>> implemented it for the replication stuff:
>>>>
>>>> * when a replication manager starts, it sends to the cluster a  
>>>> ReplicaStorageMonitorEvent JOIN event  
>>>> (BasicReplicaStorageMonitor.start);
>>>> * replication storages monitor such an event and send to the  
>>>> joining replication manager their location  
>>>> (BasicReplicaStorageExporter.onMonitorEvent);
>>>> * when a replication storage starts or stops, it sends to the  
>>>> cluster a ReplicaStorageEvent JOIN or LEAVE event  
>>>> (BasicReplicaStorageAdvertiser.start and stop);
>>>> * replication managers monitor these events  
>>>> (BasicReplicaStorageMonitor.onReplicaStorageEvent); and
>>>> * replication managers monitor leaving or failing peer events  
>>>> (BasicReplicaStorageMonitor).
>>>>
>>>> This way, a replication manager always know the current  
>>>> replication storages and their locations..
>>>
>>>
>>>
>>> loosk good - I'll bear it all in mind...
>>>
>>> The only real issue that I have thought of with the share-all  
>>> approach so far is this -
>>>
>>> If you undeploy an application, you want all of its classes and  
>>> instances thereof removed from the local JVM - so that on  
>>> redeploying it, you don't come across any versioning problems.
>>>
>>> This implies that this app's sessions must be removed from the JVM  
>>> and that they must be managed by vms on which the app is deployed  -
>>> as when they time-out, their destruction may involve their  
>>> deserialisation or a requirement for their parent app to be  present...
>>>
>>> If there are other instances of the app running, we can evacuate  
>>> the sessions to them. If there are not, we will either have to  drop
>>> the sessions, or move them into persistant storage until such  time
>>> as an instance of their app is available again....
>>>
>>> So, we have a new requirement to unload a single apps sessions and  
>>> a new requirement to know which apps are where...
>>>
>>> arggghhhh! it's beginning to get complicated :-( - more thought  
>>> required...
>>>
>>> I'm beginning to think that the only thing that we can really  share
>>> (without quite a bit of extra work) is the Dispatcher and  
>>> connection to the Cluster...
>>>
>> Thinking more deeply about this, I have come across another issue  
>> which looks quite nasty...
>>
>> Consider a bunch of portlets which do cross-context dispatch to  each
>> other but are deployed within different apps. My understanding  is as
>> follows :
>>
>> The same session id may be mapped to a different session within the  
>> context of each portlet, but the lifecycles of all sessions must be  
>> unified so that if one is invalidated, all are invalidated.  I was  
>> planning to implement this behaviour by storing all sessions mapped  
>> to the same id within a larger 'super-session'. The sub-session  
>> lifecycles would all be mapped to the super-session lifecycle. The  
>> super-session would be object given to WADI's clustering layer and  
>> this would ensure the colocation of all of the sub-sessions - i.e.  
>> if one moved to another peer - they would all move - apparently  
>> cross-context dispatch is always done locally...
>>
>> The problem arises in that these sub-sessions will belong to  
>> different deployment units. What happens if I undeploy one of the  
>> portlets on a server, but not the others ? The sessions associated  
>> with Portlet1 may need to be migrated to another instance of the  
>> same Portlet in order for their availability to be maintained and  in
>> order for refs to the undeployed classes to be removed from the  
>> local jvm - but clients may still be stuck to e.g. Portlet2 on the  
>> same server, which was doing cross-context dispatch onto  Portlet2...
>> - I guess this highlights a Portlet dependency issue -  which is that
>> if you undeploy a Portlet, you must undeploy all the  upstream (in
>> terms of cross-context dispatch) portlets first....  (does anyone
>> know if portlet containers do this sort of thing?)  -  trouble is, if
>> this is not done atomically, how will WADI cope with  the
>> fragmentation of a super-session ? If we allow super-session  
>> fragmentation and then re-aggregation, things could get very  
>> complex... - super-sessions obviously need a lot more thought than  I
>> or the proposed Geronimo session API have yet given them....
>>
>> Anyone have any thoughts about this - I am disappearing into my own  
>> navel !
>
>
> It seems to me that if you undeploy a portlet app that is part of a  
> portal on only one server  that could be interpreted as removing that  
> node from the cluster -- the portal will no longer work correctly on  
> that node, or it will be a different application than on the other  
> nodes.

agreed - but how do the Portal clients know ? and if the Portlets are
all deployables in their own right, how do you undeploy them all
atomically ? If you undeploy them individually, you end up with the
problem described below...

> Does this attitude make the problem tractable?

It pinpoints the problem - but doesn't resolve it - we still have to
decide what to do with the portlet's state...

the problem is that if we colocate all the portlet sessions for a given
portal in the same object, and undeploy just one portlet, we have to
decide what to do with its sessions...

options -

(1) leave them where they are :
 - this will cause the retention of their classes within the JVM. If the
portlet is redeployed with altered classes, class version collisions may
occur
 - if one of these session simes out whilst its portlet instance is
undeployed, this may cause problems as listeners will fail to be called
and inconsistant states may arise

(2) shift them to another node, where an instance of the same portlet is
running :
 - it means we need to know what is running where - hence one reason,
amongst many others, for the subsetting proposal
 - break up the Portal super-sessions, sending only relevant Portlet
sub-sessions, or send all super-sessions, hoping that no client will
return to the Portal on this node ?

(3) give up on these subsessions and just bin them !
 - may be the easiest option until we find a better way - my portlet
knowledge is not really up to this - maybe David's is ?

maybe we have to rethink the colocation stuff and couple related
sessions more loosely - but this will make migrating them all together
more complex :-(

Thanks for joining the thread, David, your input is greatly appreciated,


Jules

>
> thanks
> david jencks
>
>>
>> Jules
>>
>>>
>>>
>>> Jules
>>>
>>>>
>>>> Thanks,
>>>> Gianny
>>>>
>>>> Jules Gosnell wrote:
>>>>
>>>>> Filip Hanik - Dev Lists wrote:
>>>>>
>>>>>> Jules Gosnell wrote:
>>>>>>
>>>>>>> Filip Hanik - Dev Lists wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> remember, that in Tomcat, you can configure a setting where  
>>>>>>>> the JSESSIONID is global to the domain, not just the app, and  
>>>>>>>> is shared between webapps. So we need to consider what  effects
>>>>>>>> this will have on WADI
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Yes - I had something in mind like this for cross-context  
>>>>>>> portlet sessions - which must be able to share a single  session
>>>>>>> id, live in separate app contexts, but have a single  unified
>>>>>>> lifetime - i.e. when one session is invalidated, all  are...
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> interesting, you can essentially create one global session, and  
>>>>>> flatten the namespace so that app /examples session.getAttribute
>>>>>> ("myatt")
>>>>>> becomes session.getAttribute("/examples/myatt");
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> I must have explained this badly - this wasn't my intention.  What
>>>>> I meant to say was that by giving two different apps the  same
>>>>> namespace prefix, they would be able to see each others  sessions,
>>>>> but no-one elses.
>>>>>
>>>>> So, I am talking about having a map of  e.g. <context>.<session-
>>>>> id> : <session> - where session is a map of <attribute-key> :  
>>>>> <attribute-value>, whereas, I think that you are imagining  
>>>>> something more like a single map of : <session-id>.<context>/
>>>>> <attribute-key> : <attribute-value> - for the portlet scenario  
>>>>> (more below), this might be an option (but not the route that I  
>>>>> had in mind).
>>>>>
>>>>>> (note, in tomcat the prefix has to be "/host/context/
>>>>>> attributename") as tomcat supports virtual hosts.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Good point - I will bear that in mind - thanks.
>>>>>
>>>>>>
>>>>>> this will work even if the session is only available in one  app,
>>>>>> /examples, as the implementation works for 1..N apps.
>>>>>>
>>>>>> you can have one global session manager, just remember that  
>>>>>> stop/undeploy of an app, should kick off listeners, and clean  up
>>>>>> that apps attributes.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Yes - this might complicate things - I will investigate.
>>>>>
>>>>>>
>>>>>> also, you can introduce a custom WADI optional feature to share  
>>>>>> session attributes between webapps, kind of a neat idea when  you
>>>>>> think about it.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> hmmm... - is this the same as two webapps sharing the same  
>>>>> session namespace ?
>>>>>
>>>>>>
>>>>>>>
>>>>>>> I figure that we introduce a pluggable strategy to create an  
>>>>>>> internal-key (e.g. /wadi-ABCD) from the external-key (e.g.  ABCD
>>>>>>> or ABCD.red (with e.g. mod_jk)). Usually, this strategy  will
>>>>>>> prepend the app-id (context-path for a webapp), but in  the case
>>>>>>> that you mention, we would flatten the cross-context  namespace
>>>>>>> by using the same prefix for all portlets that we  wish to fall
>>>>>>> into this space - or just omit it all together...
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> not sure what you mean by this,
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> So, referring back to my <context>.<session-id> : <session>  
>>>>> structure. I am saying that we create an internal-key  
>>>>> (<context>.<session-id>) from the external key (the session id  
>>>>> that we retrieved from the request, which may include decoration  
>>>>> that needs to be stripped (in the case of e.g. mod_jk)). The  
>>>>> internal-key is simply the undecorated session-id with a  
>>>>> namespace qualifier - probably now: <vhost>.<context>. This  
>>>>> internal key is used in the Contextualiser stack to ensure  
>>>>> separation of data belonging to different apps on different vhosts.
>>>>>
>>>>>> the jvmRoute on mod_jk today is a minor disaster, and a pretty  
>>>>>> sad story for a sticky loadbalancing algo.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Well - I disagree slightly - it has good and bad points:
>>>>>
>>>>> - the bad - it messes with the session cookie
>>>>> - the good - it enables an explicit coordination between  
>>>>> container and load-balancer which may be exploited.
>>>>>
>>>>> perhaps a better solution would be to use a second cookie to  
>>>>> encode routing info ?
>>>>>
>>>>>> I don't think depending on an external product like mod_jk is a  
>>>>>> good idea.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> No - WADI does not depend on JK, but it does support it and  
>>>>> exploit the jvmRoute feature - I was just using it as an example  
>>>>> of how the external key does not necessarily map directly to the  
>>>>> internal key.... - feel better ? :-)
>>>>>
>>>>>> Maybe I'm misunderstanding you.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> yes !
>>>>>
>>>>>
>>>>> Jules
>>>>>
>>>>>>
>>>>>> Filip
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> sound OK ?
>>>>>>>
>>>>>>> Jules
>>>>>>>
>>>>>>>>
>>>>>>>> Filip
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I will have a look at the Manager as well - in case we can  
>>>>>>>>> share some of this and move the non-shared stuff onto  another
>>>>>>>>> object - the Invocation ?
>>>>>>>>>
>>>>>>>>> Jules
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> --
>> "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.
>> **********************************/
>>
>

--
"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.
 **********************************/