Clustering the Application Scope

[Gert Franz]

Hello all,

 

I just wanted to have everyone’s opinion on the idea I will describe below. As many of you may know it is possible to cluster the session scope and store it in a sessionstore which can be either a database, a cache or the file system. Now often people have applications in a cluster that need to stay in “synch”. So for instance if you reinit an application on one server, you should initialize all others in the cluster too. So Micha and I discussed already a while ago what options (back then for Railo) are available.

 

I just wanted to throw out the following ideas:

-          Cluster the complete application scope just in the same way the session scope is clustered
in the Application.cfc one would write:

this.applicationstorage = “cache|datasource|file|memory”;

this.applicationcluster = true|false;

o   Pros

§  Easy to implement as a user

§  A pointer from the session scope to the application scope would be possible again

o   Cons

§  Singletons are serialized as well so they have to be deserialized for every request (if applicationcluster is set to false)

§  Values are not immediately available if a request sets a value, but only if the request has finished and the value has been rewritten to the storage

§  Serialization and deserialization can be time consuming, since people tend to store a lot in the application scope

 

-          Cluster a subKey of the application scope. This means that the application.cfc could look like this;

this.applicationstorage = “cache|datasource|file|memory”;

this.applicationstorageKey = ‘cluster’; // means that the application.cluster key and all values below are stored in the applicationstorage

this.applicationcluster = true|false;

o   Pros

§  The higher performance would be useable for the non-clustered part of the application scope

§  No serialization necessary

§  Since only a subset is clustered, the performance can be enhanced by not overloading the clustered key with data.

§  The complete application scope would still be clusterable if the key is set to “”.

o   Cons

§  None that I can see

 

A general con is, that variables set on one server in a clustered application scope are not immediately available to any other server, until the next request on any other server might read the application scope from the storage.

 

Obviously the keys in the clustered parts of the application scope are only allowing serializable values.

 

This idea is lingering with us for a while already and we could have used it in many occasions. I am very intrigued by it and I would appreciate your thoughts.

 

Sincerely
Gert Franz

 

RASIA GmbH

Spittelgasse 7

5103 Moeriken-Wildegg

Email: ge...@rasia.ch
Skype: gert.franz

Phone Switzerland: +41 76 5680 231

 

[Igal @ Lucee.org]

+1 for clustering a subkey.

Igal Sapir
Lucee Core Developer
Lucee.org

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/015a01d052ae%2446d166e0%24d47434a0%24%40rasia.ch.
For more options, visit https://groups.google.com/d/optout.

[Michael van Leest]

+1 subkey, but would prefer a separated cluster scope. I've seen something about cluster scope in the past.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/54F0A3DC.6080409%40lucee.org.

For more options, visit https://groups.google.com/d/optout.

--
Sent from Gmail Mobile

[Alex Skinner]

Pretty sure I made a feature request for this back in the railo days.  definitely sub keys rather than whole scopes.

Also id be interested in whether a sync of data similar to how elastic search does it should be used rather than external cache store.  I'd be worried about Latency for app scope. Also I think its fair to say that typically for most people app scope it's read many write far less where as session is far more down to the app.

Cheers

A

Sent from my phone

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAMaJE6sfk_j2YT9-R94s-XETfPcycifvM67D0-_YvN_N1dKJ2w%40mail.gmail.com.

[Alex Skinner]

I wonder whether a mysql style binary log could be the approach or actually just making events that could be listened for by individual nodes to know that certainly  keys in the scope are dirty and need to be reinited rather than worrying about how to deal with complex objects.  To me events would go along way with this

A

Sent from my phone

[Igal @ Lucee.org]

+1 for events that can be intercepted in Java and thus allow for easy integration with other systems and develop new tools as needed.

Igal Sapir
Lucee Core Developer
Lucee.org

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/CAFrbJ5Vmqk8VJrwrD-YgEV5vf%3D7nApGyAwRn9G10F5diy1%3D2DA%40mail.gmail.com.

[denstar]

On 2/27/15 12:54 PM, Igal @ Lucee.org wrote:
> +1 for events that can be intercepted in Java and thus allow for easy
> integration with other systems and develop new tools as needed.

I wrote a wrapper for Infinispan ages ago-- that bad boy would fit this
bill, and a few of the other "that would be neat to have" neat to haves
mentioned in this thread.

Big fan of stuff like JMS, over say adding a scope that we can't set up
for push, pull, poll, whatnot types of scenarios.

I love to leverage tools like that which already exist, and are used in
heavy-duty contexts (mission critical type stuff), vs. rolling new
implementations, that then need to get battle tested. Not that you
don't need to battle-test how things are glued together, too, but when
the core is some beastly solid thing... :)

-Den

[Owen Knapp]

yes! subkey!

[Rory Laitila]

What happened with the paid cluster scope extension? I thought we already had this functionality, although I have never used it.

I like keeping the consistency of different scopes when dealing with different lifetimes. To me, a separate cluster scope is clear when compared with application, request, session, server, lifetimes.

I could see the usefulness of clustering the application scope, then one can think of the cluster as the application lifetime. Maybe you can have both options, cluster the application scope and accept the drawbacks, or use a cluster scope. I don't however see the clarity in having application.cluster.

I also like the idea do being able to call the cluster cache directly, cacheput() cacheget() etc. I think the scopes are syntactic sugar and useful, but we don't need to necessarily hide the implementation for those that want that.

[Chris Blackwell]

-1

a special key in the application scope that does something magical, but also behaves differently from the rest of the scope as it won't accept an unserializable value.. that's a horrible idea.

What happened to the idea of keeping the core trim and lean and providing extra functionality as extensions?

This would be much better implemented as an extension that provides a cluster scope, with pluggable transports. 

--
You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/bbf21c87-3c20-48f3-8a66-d94545013546%40googlegroups.com.

[Luis Majano]

I am not sure if I would be a big fan of clustering the application scope.  I think the concern of having a local JVM memory space is useful and separate from a clustered environment.  For having a clustered storage, well, that's why you have clustered caches that you can easily connect already to Lucee like Couchbase, Infinispan, etc.  I would not want my cfc's or anything I put on application scope to be serialized across the wire even though you could set serializable = false on them. 

I think the attractiveness is to have the applications communicate with each other instead of trying to do communications via the application scope.  Message queues, websockets and AMQP standard messaging protocols might be a more suited avenue that could be abstracted into Lucee in such a way where an application can have inter-cluster communications.  Where you can issue one event in one instance and it can propagate in the cluster.  RabbitMQ is fantastic at it and very easy to integrate.

So I am more in favor of inter-cluster communication, than application storage distribution. My 2 cents.

On Friday, February 27, 2015 at 8:56:13 AM UTC-8, Gert Franz wrote:

[Andrew Dixon]

Think I'm with Luis on this one, inter-cluster communication seems far more useful to me than the application cluster described. Not sure I see the usefulness of the application clustering when most things you would want to share between servers in a cluster is data. Lucee has the cache for this and you can already cluster the Ehcache that ships with Lucee very easily anyway.

Kind regards,

Andrew

about.me
mso - Lucee - Member

--

You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/399e50a9-712e-4ffa-af55-354e5397274e%40googlegroups.com.

[Adam Cameron]

On Sunday, 1 March 2015 05:18:58 UTC+13, Chris Blackwell wrote:

-1

a special key in the application scope that does something magical, but also behaves differently from the rest of the scope as it won't accept an unserializable value.. that's a horrible idea.

I'm glad you said it, because it saves me from doing so, and now I can just be all agreeable: "Chris I agree".

This would be much better implemented as an extension that provides a cluster scope, with pluggable transports.  

The pain point clustering data is trying to solve is that it's available across CFML instances. This is - as I say in today's blog article (http://blog.adamcameron.me/2015/03/cfml-data-connection-objects-instead-of.html) - well trod ground already, and Lucee doesn't need to mess around implementing its own version of it. And clustering the application scope is conflating two concepts, so not the right place to even start looking at the solution for this.

What I think might be something to do is to implement  CacheService concept, and perhaps Lucee has a baked in MemCached (or Ehcache, or whatever it is: it doesn't matter). Publish its interface and some sort of implementation documentation (like an RFC) so then other implementation can be swapped in / out / around.

With stuff like this, don't bake the solution into Lucee. Just expose relevant hooks and implement some reference implementation.

Make Lucee as extensible as possible to the Lucee devs can do the bare minimum of work to facilitate other people doing the actual work.

-- 

Adam

[Dominic Watson]

Agreed with those sceptical of the idea, especially the special subkey concept - feels like it would muddy the language rather than cleanse it.

Arbitrary scopes though, that are implemented with some standard interface and that can be written as extensions sounds like a potentially good abstraction for this sort of thing though (presumably the cluster scope is written in this way??)

--

You received this message because you are subscribed to the Google Groups "Lucee" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lucee+un...@googlegroups.com.
To post to this group, send email to lu...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/lucee/09e38341-5fe0-4e23-a109-71ba48f15f8a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Pixl8 Interactive, 3 Tun Yard, Peardon Street, London SW8 3HT, United Kingdom T: +44 [0] 845 260 0726• W: www.pixl8.co.uk• E: in...@pixl8.co.uk

Follow us on: Facebook Twitter LinkedIn

CONFIDENTIAL AND PRIVILEGED - This e-mail and any attachment is intended solely for the addressee, is strictly confidential and may also be subject to legal, professional or other privilege or may be protected by work product immunity or other legal rules. If you are not the addressee please do not read, print, re-transmit, store or act in reliance on it or any attachments. Instead, please email it back to the sender and then immediately permanently delete it. Pixl8 Interactive Ltd Registered in England. Registered number: 04336501. Registered office: 8 Spur Road, Cosham, Portsmouth, Hampshire, PO6 3EB

[Adam Cameron]

On 1 March 2015 at 21:25, Dominic Watson <dominic...@pixl8.co.uk> wrote:

Arbitrary scopes though, that are implemented with some standard interface and that can be written as extensions sounds like a potentially good abstraction for this sort of thing though (presumably the cluster scope is written in this way??)

Yes, this'd be quite cool. I'd opt again for just the mechanism to create a scope and "hook it in" to a codebase ought to be the approach, rather than the Lucee Team actually implement any. Or perhaps re-implement / cross-implement existing scopes using the same mechanism would be something to do.

The first step being to define what it is to be a "scope"? This might be a different forum thread though, perhaps.

-- 

Adam