Re: Not-sticky sessions with Sling?

[Chetan Mehrotra]

On Fri, Jan 13, 2017 at 12:20 AM, lancedolan  wrote:
> In an architecture with
> only one Mongo instance, the moment one instance writes to the JCR, another
> instance will read the same data and agree consistently. It seems to me that
> the JCR state is strongly consistent.

No. DocumentNodeStore in each Sling node which are part of cluster
would periodically poll the backend root node state revision. If there
is any change detected it would update its head revision to match with
last seen root node revision from Mongo and then it would generate an
external observation event. So any change done on cluster node N1
would be _visible sometime later_ on cluster node N2.

So if you create a node on N1 and immediately try to read it on N2
then that read would fail as that change might not be "visible" on
other cluster node. So any new session opened on N2 would have its
base revision set to current head revision of that cluster node and
which may be older than current head revision in Mongo.

However the writes would still be consistent. So if you modify same
property concurrently from different cluster nodes that one of the
write would succeed and other would fail with a conflict.

Some details are provided at [1]

Chetan Mehrotra
[1] https://jackrabbit.apache.org/oak/docs/architecture/transactional-model.html

RE: How to change run mode in Sling8

[lancedolan]

Update: Ok, I get it now. Thank you - this is really slick. 


For posterity:

The "source code" for the "Sling Source Release" artifact at [1] is really
not the project source code. It's just some text files that neatly describe
which OSGI bundles and configurations (including run modes) you'd like
present in a new .war file which is then built using *actual* sling
artifacts from completely different projects.  This is called Sling
Provisioning, but shouldn't be confused with actual provisioning tools like
vagrant or something. I had expected to see actual source code when I
clicked that link and that felt wrong. Now I understand. 

All you have to do is download the "source code," set your run mode in
boot.txt, modify the list of artifacts if you wish (in
groupid/artifactid/version format) and run maven clean install. And if you
come from an older Sling background like I do, where you can change run
modes willy-nilly with JVM arguments, I guess you just have to suck it up
and provision a new Sling instance. If you use a remote datastore (such as
oak_mongo) then you can do so without losing your JCR data as well. 

[1] http://sling.apache.org/downloads.cgi



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/How-to-change-run-mode-in-Sling8-tp4069494p4069554.html
Sent from the Sling - Users mailing list archive at Nabble.com.

Re: Join new member to Sling Oak cluster?

[lancedolan]

Robert Munteanu-2 wrote
> - Are the Sling/Oak instances and MongoDB clocks in sync? 

I've just realized the significance of this question. Our Sling and Mongo
instances will be in different data centers entirely, Mongo provided as a
service and Sling in our own AWS instances somewhere... I suppose in this
distributed environment we don't have any strong guarantees about the clocks
being in Sync. Is this a known requirement of clustering? 



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/Join-new-member-to-Sling-Oak-cluster-tp4069454p4069553.html
Sent from the Sling - Users mailing list archive at Nabble.com.

RE: How to change run mode in Sling8

[lancedolan]

This is fantastic information!

I'd love a nice clear how-to documentation for getting this done, but hey
it's open source stuff, hah. I'll go fumble through the
slingstart-maven-plugin and probably have a question or two along the way.

Thanks guys.



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/How-to-change-run-mode-in-Sling8-tp4069494p4069552.html
Sent from the Sling - Users mailing list archive at Nabble.com.

Re: Not-sticky sessions with Sling?

[lancedolan]

Chetan,

I'd like to confirm to what degree that is true for our proposed
architecture. It seems that only the OSGI configurations and bundles would
be "eventually consistent." It seems the only "state" that is stored in
Sling instances are OSGI configurations and OSGI bundles. Everything else is
in the JCR, which Mongo can provide as strongly consistent ( I believe ).
Consider this example and correct me where I'm wrong. I'd hate to shoot
myself in the foot with bad assumptions.

Imagine 3 Sling instances all talking to 1 Mongo instance. In this case, it
seems to me that all REPO state is captured in a single Mongo instance,
which is consistent by default and eventually consistency only happens if
you hit secondary members of a Mongo Replica Set. In an architecture with
only one Mongo instance, the moment one instance writes to the JCR, another
instance will read the same data and agree consistently. It seems to me that
the JCR state is strongly consistent. 

However, OSGI configurations seem to propagate to each other through the JCR
only eventually... Additionally, when we deploy a new OSGI bundle to the JCR
(in an install directory or whatever), then those seem to only eventually
propagate to all Sling instances. I'm not totally sure that these are
"eventually," but it seems like the only place that state will only be
"eventual" in this architecture.

So, as long as we're cool with OSGI configurations and bundle installations
being eventual, everything else, stored in the JCR, should be strongly
consistent right?

And then, I believe we can even scale the Mongo instances into a replica set
for better availability and we'll still be strongly consistent so long as
all Sling instances only read from the primary member of the replica set:
[1]. 

Thanks for your time and thoughts dude!

[1] https://www.mongodb.com/faq#consistency



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/Not-sticky-sessions-with-Sling-tp4069530p4069551.html
Sent from the Sling - Users mailing list archive at Nabble.com.

RE: JS Use API usability or limitations

[lancedolan]

Aha. Thanks, I was sure it was sure weird Rhino thing. 

It's hard to call it valid JavaScript either, though, as it's invalid in
every single popular browser. That mozilla doc says "Non-standard. The
Iterator function is a SpiderMonkey-specific feature, and will be removed at
some point. " As a career JS developer, I simply wasn't going to know to use
this non-standard and widely unsupported function. On the other hand, using
other modern means, [1] and [2], of iterating the Iterable isn't supported
by Rhino .

I guess my point is just that the same syntax patterns a skilled JavaScript
developer would expect to use aren't always valid, which creates esoteric
knowledge for this environment. Whereas, I felt that all of my existing JS
knowledge was usable when I went to other server-side JS solutions, like
Node.js for example.



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/JS-Use-API-usability-or-limitations-tp4069490p4069550.html
Sent from the Sling - Users mailing list archive at Nabble.com.

Re: JS Use API usability or limitations

[Jason Bailey]

I've experienced a variety of results between switching between a dynamic and 
static types languages I think a lot of it has to do with context.

IMHO there's a certain rhythm to developing on any specific platform. Where 
using a certain set of technologies make more sense than others. Since 
everything in Sling is built on Java and you'll be dealing with Java API's, 
from a business logic perspective, I think you'll get the best results from 
writing that part In Java. I highly recommend the Sling Models as the starting 
point for that.

>From the view perspective, which I'm using to identify that initial end point 
>service you're calling I don't think it matters as much, although I haven't 
>heard of a lot of people using ecma.  I prefer to stick with JSPs since that's 
>what everything boils down to underneath anyways, sticking an abstraction 
>layer over it has always struck me as kind of wasteful.



From: lancedolan 
Sent: Wednesday, January 11, 2017 4:41 PM
To: users@sling.apache.org
Subject: RE: JS Use API usability or limitations

No architectural reason - purely speed of development reasons. Our team has
switched from Java to Node.js on our other projects and are seeing real
gains in dev time. We believe we could see the same faster development with
lightweight JS files as opposed to traditional type-safe Java.

I think this is a popular opinion amongst developers, that JS is faster to
write in than Java? The question currently on the table is whether the
difficulty in debugging esoteric Rhino interactions will negate that speed,
in which case we might as well stick to Java and enjoy stability of type
safety.



--
View this message in context: 
http://apache-sling.73963.n3.nabble.com/JS-Use-API-usability-or-limitations-tp4069490p4069526.html
Sent from the Sling - Users mailing list archive at Nabble.com.

RE: How to change run mode in Sling8

[Stefan Seifert]

you should use the sling provisioning file format together with the slingstart 
maven plugin [1]. these are very powerful tools and allows you to quickly build 
your own set of sling bundles together with your own application bundles and 
all required OSGi configuration and sling run modes by describing it in a text 
file and building either a standalone jar or WAR file out of it. the launchpad 
itself is build exactly this way. unfortunately there is no overall 
documentation how to do this the best way besides the documentation of the 
individual parts like [1]. and if you start building your own Launchpad with 
only the bundles you need you of course need to know which bundles you need - 
which may be a difficult task for someone new to sling regarding the great 
number of OSGi bundles.

the sling Launchpad itself is a good starting point for this. if you want to 
use all bundles includes you can directly reference the provisioning feature 
file and add your bundles [2]. but in most cases you will use only a subset, 
and then you can start copying the definition file of the Launchpad [3] and 
remove everything you do not need. a good source for inspiration are also 
integration tests projects which often make use of the provisioning file format 
as well to setup a sling instance for testing, either based on the sling 
Launchpad as in [4], or by using a minimal set of bundles like [5].

stefan


[1] https://sling.apache.org/documentation/development/slingstart.html
[2] 
http://repo1.maven.org/maven2/org/apache/sling/org.apache.sling.launchpad/8/org.apache.sling.launchpad-8-slingfeature.txt
[3] 
https://github.com/apache/sling/tree/trunk/launchpad/builder/src/main/provisioning
[4] 
https://github.com/apache/sling/tree/trunk/bundles/extensions/caconfig/integration-tests
[5] 
https://github.com/wcm-io-caravan/caravan-tooling/tree/develop/integration-test/minimal-launchpad


>-Original Message-
>From: lancedolan [mailto:lance.do...@gmail.com]
>Sent: Thursday, January 12, 2017 4:18 AM
>To: users@sling.apache.org
>Subject: Re: How to change run mode in Sling8
>
>I guess downloading and copying the source for the software I want to
>use
>and just using that as the basis for my own custom version of that
>software
>just feels like a bad development practice. Like, how do I upgrade to
>future
>versions of Sling? By respecting the Sling war as a deployable artifact,
>I
>could just swap in future version in our provisioning scripts. I feel
>like
>there are other examples of how that's awkward as well, but it's late
>and
>I'm getting foggy hah.
>
>If the war file provided as a release isn't intended to be more than an
>example, copying and modifying the source is the way Sling is intended
>to be
>used by the developers, then fair enough.
>
>This sounds like valuable information for beginning developers that find
>https://sling.apache.org. It's easy to get lost.
>
>
>
>
>
>--
>View this message in context: http://apache-
>sling.73963.n3.nabble.com/How-to-change-run-mode-in-Sling8-
>tp4069494p4069533.html
>Sent from the Sling - Users mailing list archive at Nabble.com.