Re: import and export JCR data
If it's not composum, then it's file-vault or JCR related, which is even more concerning. I'm pretty confident this isn't user error. I've given consulting demonstrations, teaching others the ins and outs of file-vault XML-to-node translation, the various complex rules one can combine, and also written code that dynamically assembles valid file vault packages to be POSTed to CRX package manager, which I believe also uses file vault under the hood... I'm really quite aware, in general, of how this thing should work. Of course I could be missing something, but if this is user error, then it's something esoteric and imperceptible, something very different than the CRX and file vault I'm used to. Here's what I'm doing: 1) click "+" to create new package 2) click filter tab and "+" to create new filter 3) give root path "/content" and save with default Replace Import Mode and empty filter set 4) Click Build Result: empty content directory in the package. Nothing in the log file. I suppose as a next step I can split all com.composum logs to a separate log and set that to DEBUG level and watch for things... Maybe do the same with org.apache.jackrabbit.vault. One plausible possibility seems that my /content data might be in some invalid state such that file vault can't/won't read it?? I'm really grasping at possibilities at this point. -- View this message in context: http://apache-sling.73963.n3.nabble.com/import-and-export-JCR-data-tp4069390p4070161.html Sent from the Sling - Users mailing list archive at Nabble.com.
Re: How to export Sling data?
Sorry, double post. See http://apache-sling.73963.n3.nabble.com/import-and-export-JCR-data-td4069390.html -- View this message in context: http://apache-sling.73963.n3.nabble.com/How-to-export-Sling-data-tp4070157p4070158.html Sent from the Sling - Users mailing list archive at Nabble.com.
How to export Sling data?
Hi All, Does anybody have some terminal commands or procedure they follow for exporting data without composum? I've downloaded this "jackrabbit-filevault" project, and I've tried some different terminal commands after reading the documentation. Not sure what I'm doing. Does anybody here export data from JCR without composum? What's the process? * For those curious, why not Composum? It is demonstrating a severe defect preventing me from building a jcr package [https://github.com/ist-dresden/composum/issues/60]. Even if that defect is solved, this instability is concerning enough that we need a separate reliable process for exporting data -- View this message in context: http://apache-sling.73963.n3.nabble.com/How-to-export-Sling-data-tp4070157.html Sent from the Sling - Users mailing list archive at Nabble.com.
Re: import and export JCR data
Hi All, Does anybody have some terminal commands or procedure they follow for exporting data without composum? I've downloaded this "jackrabbit-filevault" project, and I've tried some different terminal commands after reading the documentation. Not sure what I'm doing. * For those curious, why not Composum? It is demonstrating a severe defect preventing me from building a jcr package [https://github.com/ist-dresden/composum/issues/60]. Even if that defect is solved, this instability is concerning enough that we need a separate reliable process for exporting data. -- View this message in context: http://apache-sling.73963.n3.nabble.com/import-and-export-JCR-data-tp4069390p4070156.html Sent from the Sling - Users mailing list archive at Nabble.com.
Re: Components each process twice
This response is good enough for me. The fact that the community hasn't largely said "yea we see it all the time and it's normal" tells me I'm probably causing this myself somewhere, and I'll have to look into it. I just didn't want to lose a day figuring out the root cause if this was known normal sling behaviour, or that sometime it just needs to render a component twice to for its own reasons. Curious that I've observed this on other projects from other devs - we must be falling for the same pitfall. -- View this message in context: http://apache-sling.73963.n3.nabble.com/Components-each-process-twice-tp4070042p4070081.html Sent from the Sling - Users mailing list archive at Nabble.com.
Re: How to create Rest APIs for non-JCR data in Sling 8??
Aha! Solved Here's my solution for posterity.
While Jersey would have been a preferred, more feature-rich solution, I just
couldn't get the OSGI-Jersey stuff working.
The solution:
- ResourceProvider listens for all requests to a particular path, and
returns a false "Resource" object, which doesn't actually exist in the JCR,
but it does have a resourceType
- A Servlet registers to render that resourceType.
Between these two, you've essentially got a Servlet that listens to a all
requests that fall under a particular Path :)
Registering a Servlet for a resourceType is pretty elementary, but for
posterity looking to get this ResourceProvider working in Sling 8, here's
how I did it. I expect there are better ways, but this is demonstrative:
/**
* Created by lancedolan on 1/27/17.
*/
@Component
@Service(value=ResourceProvider.class)
@Properties({
@Property(name = ResourceProvider.ROOTS, value = "service/image"),
@Property(name = ResourceProvider.OWNS_ROOTS, value = "true")
})
public class ImageResourceProvider implements ResourceProvider {
//@Override
public Resource getResource(ResourceResolver resourceResolver, String
path) {
AbstractResource abstractResource;
abstractResource = new AbstractResource() {
@Override
public String getResourceType() {
return ImageTypeServlet.RESOURCE_TYPE;
}
@Override
public String getResourceSuperType() {
return null;
}
@Override
public String getPath() {
return path;
}
@Override
public ResourceResolver getResourceResolver() {
return resourceResolver;
}
@Override
public ResourceMetadata getResourceMetadata() {
return new ResourceMetadata();
}
};
return abstractResource;
}
//@Override
public Resource getResource(ResourceResolver resourceResolver,
HttpServletRequest httpServletRequest, String path) {
return getResource(resourceResolver , path);
}
//@Override
public Iterator listChildren(Resource resource) {
return null;
}
}
And then you just create your own servlet, analogous to my ImageTypeServlet
which contains a static final String RESOURCE_TYPE
--
View this message in context:
http://apache-sling.73963.n3.nabble.com/How-to-create-Rest-APIs-for-non-JCR-data-in-Sling-8-tp4069947p4070023.html
Sent from the Sling - Users mailing list archive at Nabble.com.
Re: How to create Rest APIs for non-JCR data in Sling 8??
Henry Saginor-2 wrote > Hi Lance, > > I think a better practice is to register your servlet with a resource type > instead of path. This requires creating a node per resource. Please see my prior post where I disqualify all solutions that involve creating nodes. My entire requirement is that I'm creating a service that serves data that isn't in the JCR. I truly do appreciate your taking the time out of your day to try to help me, though, so I hope you don't feel slighted! :) I have been lead AEM Architect on Sling applications that serve millions of users globally and am already familiar with the fundamentals of Sling resource and script resolution :) This is just my first time needing to serve up "virtual" resources of very large number like this, such that a dynamic-URL service is absolutely the only solution. Update: I've made progress with the ResourceProvider solution! It seems the 403 response I was getting was actually result of my ResourceProvider successfully returning SyntheticResource, which Sling then responded with a 403 for... It seems all I need to learn is how to properly instantiate a Resource object and return it :) It seems I need to learn about this ResourceWrapper class and how to create ResourceMetadata -- View this message in context: http://apache-sling.73963.n3.nabble.com/How-to-create-Rest-APIs-for-non-JCR-data-in-Sling-8-tp4069947p4070022.html Sent from the Sling - Users mailing list archive at Nabble.com.
Re: "java.lang.VerifyError"
That's the solution, thank you! My maven-scr-plugin version had fallen badly out of date by re-building from an archetype... bumped to latest version and I no longer need the -noverify argument. Thanks again :D -- View this message in context: http://apache-sling.73963.n3.nabble.com/java-lang-VerifyError-tp407p4070003.html Sent from the Sling - Users mailing list archive at Nabble.com.
Re: "java.lang.VerifyError"
Sort of solved: adding -noverify to the JVM arguments stops this error from occurring. However, I don't fully understand the cause and I'm also nervous about forward compatibility... I wonder how this could prevent us from moving to future Java versions. It just seems like a bad smell that stable behaviour depends on an esoteric JVM flag. -- View this message in context: http://apache-sling.73963.n3.nabble.com/java-lang-VerifyError-tp407p4070001.html Sent from the Sling - Users mailing list archive at Nabble.com.
"java.lang.VerifyError"
Has anybody run into this before? I'm tempted to thing it's a defect in Sling
8.
I write a @Service for OSGI, and it has a @Reference to another service,
such as a ResourceResolverFactory, and deploy it to Sling the same way I
have for several years, and it fails to get the Reference, with the
following:
Error during instantiation of the implementation object
(java.lang.VerifyError: Expecting a stackmap frame at branch target 13
Exception Details:
Location:
com/edliohelloworld/image_microservice/ImageServlet.unbindResolverFactory(Lorg/apache/sling/api/resource/ResourceResolverFactory;)V
@5: if_acmpne
Reason:
Expected stackmap frame at this location.
Bytecode:
0x000: 2ab4 002c 2ba6 0008 2a01 b500 2cb1
)
java.lang.VerifyError: Expecting a stackmap frame at branch target 13
Exception Details:
Location:
com/edliohelloworld/image_microservice/ImageServlet.unbindResolverFactory(Lorg/apache/sling/api/resource/ResourceResolverFactory;)V
@5: if_acmpne
Reason:
Expected stackmap frame at this location.
Bytecode:
0x000: 2ab4 002c 2ba6 0008 2a01 b500 2cb1
Steps to reproduce:
- Running on Java 8 HotSpot JVM
- Download latest Sling 8 from http://sling.apache.org/downloads.cgi. You
can use either standalone or "Web Application," I've confirmed on both.
- Start the Sling server
- Write and Compile a simple OSGI bundle using the maven-bundle-plugin
- Include the following Servlet
@SlingServlet(
paths = "/myservice/image",
methods = {"GET" , "POST"})
public class ImageServlet extends SlingSafeMethodsServlet{
@Reference
ResourceResolverFactory resolverFactory;
@Override
protected void doGet(SlingHttpServletRequest request,
SlingHttpServletResponse response) throws ServletException, IOException {
response.setContentType("text/html");
PrintWriter out = response.getWriter();
out.println("
" + "HELLO WITH A " + resolverFactory + " FROM SERVLET" + "
");
}
}
You'll get the error on deployment of the bundle, and the servlet will not
register, and you'll get a 404 when attempting to hit the servlet. If you
comment out the @Reference annotation, so that Sling doesn't try to inject
the ResourceResolverFactory, then the Servlet will register, but of course
the resolverFactory will be null.
I also tested by writing my own *very* simple hello world service, and that
gets the same java.lang.VerifyError on instantiation.
My best guess is that I need to use a different JVM version or some JVM
arguments so that it doesn't do this verification??
--
View this message in context:
http://apache-sling.73963.n3.nabble.com/java-lang-VerifyError-tp407.html
Sent from the Sling - Users mailing list archive at Nabble.com.
Re: How to create Rest APIs for non-JCR data in Sling 8??
I guess, even if we use SlingSafeMethodsServlet and request parameter, I still have this problem of securing the servlet... I've put a servlet at paths = "/myservice/image" , and created a node at /myservice with an ACL that denies jcr: all to everyone and anonymous, and yet anonymous can still GET /myservice/image. It seems authentication still succeeds, as my Servlet can see the user ID on the request, but the authorization via Effective Policies isn't happening. -- View this message in context: http://apache-sling.73963.n3.nabble.com/How-to-create-Rest-APIs-for-non-JCR-data-in-Sling-8-tp4069947p4069998.html Sent from the Sling - Users mailing list archive at Nabble.com.
Re: How to create Rest APIs for non-JCR data in Sling 8??
I'm surprised at all the tech opinions this raised :)
First, there's a couple popular suggestions happening which aren't going in
the right direction, so I'll get that out of the way quick:
1) Any solution that involves me creating a JCR node and binding by resource
type is infeasible. I'm not willing to create a JCR node for each Resource
on the proxied datasource. If I have a million images on S3, and I'm trying
to expose them via /service/image, I'm not willing to create a million nodes
underneath /services/image, nor am I willing to keep that in sync, nor am I
capable of predicting all of the possible images that could be requested in
order to create those nodes. That's a ridiculous amount of work when the
goal is just to make all requests at a dynamic path route to a single
method.
2) Some have also said not to use Sling for this... I appreciate the time
and thought, but that isn't helpful and I must do this in Sling. These
services need access to the JCR for other purposes, and I also want the same
authentication/authorization handlers handling these services as my other
requests to the JCR. There will be a /home principal which is allowed to
access this /service.
If we can't solve this, we'll just use SlingSafeMethodsServlet and use
request parameters instead (ie. /service/image?id=123123 ). This will make
us cringe but we'll bear it.
I'd *really* like to continue down the ResourceProvider path by providing a
path, as shown in my code above. If I can just get past this 403 error, I'm
good! The effective policies of my ResourceProvider at /things should just
inherit "/", which is everyone=jcr:all so it doesn't seem that creating a
node with an ACL on it will help.. I'll continue to play a bit.
As for the Spring suggestions: Thank you, I'll consider this! It seems like
a lot of library to bring in when we'd only use a tiny part of the
functionality And anyhow, doesn't Spring just use Jersey under the hood
to provide endpoints?
Bertrand Delacretaz wrote
> We might need to release Sling 9 soon
Yes please :)
Bertrand Delacretaz wrote
> Maybe we just need to flesh out examples like Henry's in actual samples.
> Lance, would that help you?
Isn't his suggestion one involving creating a JCR node for all possible
request paths? So, for /service/{id} which could service a million
unpredictable ids, then I'd need to create a million nodes with names that I
can't predict?
--
View this message in context:
http://apache-sling.73963.n3.nabble.com/How-to-create-Rest-APIs-for-non-JCR-data-in-Sling-8-tp4069947p4069997.html
Sent from the Sling - Users mailing list archive at Nabble.com.
Re: How to create Rest APIs for non-JCR data in Sling 8??
These APIs I'm looking to build are likely to use other OSGI services I've written, and perhaps even write to the JCR for other reasons. Imagine doing a GET /api/images/my-new-image.jpg and the image lives in Amazon S3, but you want to write some audit data into the JCR. I'm still thinking through the overall solution, and have considered you're suggestion, but I don't want to give up on building APIs inside of OSGI/Sling unless I really need to. -- View this message in context: http://apache-sling.73963.n3.nabble.com/How-to-create-Rest-APIs-for-non-JCR-data-in-Sling-8-tp4069947p4069949.html Sent from the Sling - Users mailing list archive at Nabble.com.
RE: Not-sticky sessions with Sling?
Jason Bailey wrote > Couldn't this be simplified to simply stating that the sticky session > cookie only lasts for x amount of seconds? WHOAAA!! Bertrand, probably hold the phone on everything else I suggested in my last post - this solution is insanely simple, embarrassingly obvious in hindsight, and us architects on our side can see no problem with this solution. We actually had no idea that there is a expiration by seconds setting in AWS elastic load balancer. We just checked the interface and found the setting. Obviously in the good old days of F5 we could do whatever we want, but we're married to AWS now and had no idea we could do this. Thank you Jason, you might have just saved me some unsavory development task, whilst helping me Keep It Simple, Stupid. -- View this message in context: http://apache-sling.73963.n3.nabble.com/Not-sticky-sessions-with-Sling-tp4069530p4069731.html Sent from the Sling - Users mailing list archive at Nabble.com.
Re: Not-sticky sessions with Sling?
Chetan is making things crystal clear for us. Our next steps are: 1) Learn what the MAXIMUM "inconsistency window" could be. Is it possible to delay past 5 seconds? 10 Seconds? 60? What determines this? Only server load? I'll ask on the JCR forum and also experiment. 2) Design and test a solution almost exactly as Bertrand described. Sling responds to POST/PUT/DELETE with a JCR revision. Sling will behave differently when the Request contains a JCR revision more recent than it's current. I have no idea what I'm getting into or how hard this will be. Bertrand, I'd feel selfish taking you up on your offer to build this for me. Yet I'd be a fool to not at least partner with you to get it done. Should we correspond outside this mail list? Perhaps you could point me to the files you would edit to get this done and I could try to do it myself? I imagine a solution where you can configure, through OSGI, whether Sling will do one of the following: A) Ignore JCR revision in Request, and function as it does today (Default setting) B) Block until it has caught up to JCR revision in Request C) Call some other custom handler? This way we can do custom things like send a redirect to enhance the user experience during a block. In a product like ours, 5 or 10 second blocks aren't acceptable without user feedback. I also don't know how to determine the current Sling instance's Revision, or how to compute whether one revision is "more recent" than another. - Responding to a couple other minor points: Felix Meschberger-3 wrote > I suggest you go with something else, which does *not* need the repository > for persistence. This means you might want to investigate your own > authentication handler ... Thank you Felix :) I've actually done this work recently and it's working great! We have "stateless" authentication now, but are now dealing with the unacceptable inconsistency that Chetan warned about. That's the question on the table: In a write-operation-heavy application, how do we provide a "read-your-writes" consistent experience on an eventually-consistent solution (Sling cluster), when traditional sticky-sessions are an invalid solution because your userbase is large enough to demand server-scaling several times throughout the day. chetan mehrotra wrote > I can understand issue around when existing Sling server is removed > from the pool. However adding a new instance should not cause existing > users to be reassigned When adding an instance, we purposely invalidate all sticky sessions and users will get re-assigned to a new Sling instance, so that the new server actually improves performance. Imagine a farm of 4 app servers that has been SLAMMED and isn't performing well. Adding 1 or 100 new servers to that farm won't improve performance if every user is "stuck" to the previous 4 servers. If we don't do this invalidation and re-assignment on scaling-up, it can takes hours potentially for a scale-up to positively impact an overloaded cluster. Bertrand Delacretaz wrote > But Lance could patch [1] to experiment with different values, right? > > [1] > http://svn.apache.org/repos/asf/jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/document/DocumentNodeStore.java Thank you for pointing me to the code Bertrand :) On new information from Chetan, I'm losing interest in changing that value. Perhaps setting aSyncDelay to 0 or some small number will cause it to perform slower but be more consistent... However, my tentative assessment is that the interval would just be "checked" more often, but it will also get skipped more often, due to "local cache invalidation, computing the external changes for observation" as Chetan put it. I would love to be wrong about this and I'll ask on the JCR forum. -- View this message in context: http://apache-sling.73963.n3.nabble.com/Not-sticky-sessions-with-Sling-tp4069530p4069730.html Sent from the Sling - Users mailing list archive at Nabble.com.
RE: Not-sticky sessions with Sling?
Thi is tempting, but I know in my dev-instinct that we won't have the time to solve all the unsolved in that effort. Thank you for suggesting though :) -- View this message in context: http://apache-sling.73963.n3.nabble.com/Not-sticky-sessions-with-Sling-tp4069530p4069712.html Sent from the Sling - Users mailing list archive at Nabble.com.
Re: Not-sticky sessions with Sling?
lancedolan wrote > I must know what determines the duration of this revision catch-up time > ... While I don't know where to look in src code to answer this, I did run a very revealing experiment. It pretty much always takes 1 second exactly for a Sling instance to get the latest revision, and thus the latest data. When not 1 second, it takes 2 seconds exactly. If you increase load on the server, the likelihood of taking 2 seconds increases, and you also begin to see it take exactly 3 seconds in some rare cases. Increasing load increases the number of seconds before a "sync," however it's always near-exactly a second interval. It seems impossible for this to be a natural coincidence - I smell a setting somewhere (or perhaps hardcode value) which is telling Sling to check the latest JCR revision on 1 second intervals. When that window can't be hit, it checks on the next second interval, and so on. Is there a Sling dev who can tell me whether this is configurable? I have a load of questions about this discovery: - Am I wrong? (I'll be shocked) - Perhaps we can speed it up? - What event is causing it to "miss the window" and wait until the next 1 second synch interval? - If we do decrease the interval, will that just increase the likelihood of taking more intervals anyhow? - Is there a maximum number of 1 second intervals before the things just gets the latest?? progress. -- View this message in context: http://apache-sling.73963.n3.nabble.com/Not-sticky-sessions-with-Sling-tp4069530p4069711.html Sent from the Sling - Users mailing list archive at Nabble.com.
Re: Not-sticky sessions with Sling?
Bertrand Delacretaz wrote
> That would be a pity, as I suppose you're starting to like Sling now ;-)
Ma you have no idea haha! I've got almost every dev in the office all
excited about this now haha. However, it seems our hands are tied.
I wrote local consistency test scripts which POST and immediately GET a
property, checking for consistency.
Results on a 2-member Sling cluster and localhost mongodb:
-0% consistency with 50ms delay between POST and GET
-35% to 50% consistency with 1 second delay between POST and GET
-90% consistency with 2 second delay
-98% to 100% consistency after 3 seconds delay.
So yes, you are all correct.
True, we could use sticky sessions to avoid inconsistency... but only until
we scale our server-farm up or down, which we do daily So sticky
sessions doesn't really solve anything for us.
If you already understand how scaling nullifies the benefit of sticky
sessions, you can skip past this paragraph and move onto the next:
Each time we scale, users will lose their "stickiness." We have thousands of
write users ("authors"). Hundreds concurrently. Compare that to typical AEM
projects have less than 10 authors, and rarely more than 1 concurrently
(I've got several global-scale AEM implementations under my belt). For us,
it's a requirement that we add or remove app servers multiple times per day,
optimizing between AWS costs and performance. Each time we remove an
instance, those users will go to a new Sling instance, and experience the
inconsistency. Each time we add an instance, we will invalidate all
stickiness and users will get re-assigned to a new Sling instance, and
experience the inconsistency. If we don't do this invalidation and
re-assignment on scaling-up, it can takes hours potentially for a scale-up
to positively impact an overloaded cluster where all users are permanently
stuck to their current app server instance.
As you can see, we need to deal with the inconsistency problem, regardless
of whether we use sticky sessions.
I have some ideas, but none are appealing, and would benefit greatly from
your guys' knowledge:
1) Race condition
If this delay to "catch up" to latest revision is mostly predictable, it
doesn't grow as the repo grows in size, or if it doesn't change due to other
variables, we can measure it and then account for it reliably with
user-feedback (loading screen or whatever). This *might* be a race condition
we can live with.
My results above show as much as 3 or 4 seconds to "catch up." I must know
what determines the duration of this revision catch-up time. Is it a
function of repo size? Does the delay grow as the repo size grows? Does the
delay grow as usage increases? Does the delay grow as the number of Sling
instances in the cluster grow? Does the delay grow as network latency grows
(I'm testing all on the same machine with practically no latency compared to
a distributed production deployment). Is there any Sling dev, who is
familiar with the algorithm that Sling uses to select a "newer" revision,
who could answer this for me? ... perhaps it's just polling on a predictable
time period! :)
2) Browser knows what revision it's on.
The browser could know what JCR Revision it's on, learning that revision
after every POST or PUT, perhaps in some response header. When its future
requests are sent to a Sling instance on an older revision, it could wait
until that instance "catches up." This sounds like a horrible example of
client code operating on knowledge of underlying implementation details, and
we're not at all excited about the chaos to implement it. That being said,
can we programmatically check the revision that the current Sling instance
is reading from?
3) "Pause" during scale-up or scale-down.
Each time we add or remove a sling instance, all users experience a "pause"
screen while their new Sling Instance "catches up." This is essentially the
same as the race condition in #1, except we'd constrain users to only
experience this when we scale up or down. However, we are *extremely*
unhappy to impact our users just because we're scaling up or down,
especially when we must do so frequently.
Anybody have any other ideas?
Other questions:
1) When a brand new Sling instance discovers an existing JCR (Mongo), does
it automatically and immediately go to the latest head revision? Or is there
some progression through the revisions, and it takes time for the Sling
instance to catch up to the latest?
2) Is there any reason, BESIDES JCR CONSISTENCY, why a Sling cluster must be
deployed with sticky-sessions? What other problems would we introduce by not
having sticky sessions?
I seem to have used this email to track my own thoughts more than anything,
my sincere thanks if you've taken the time to read the whole thing.
--
View this message in context:
http://apache-sling.73963.n3.nabble.com/Not-sticky-sessions-with-Sling-tp4069530p4069709.html
Sent from the Sling - Users mailing list archive at Nabble.com.
Re: Not-sticky sessions with Sling?
Ok First of all - I GENUINELY appreciate the heck out of your time, and patience!! ... and THIS is really interesting: If THIS is true: chetan mehrotra wrote > If you are running a cluster with Sling on Oak/Mongo then sticky > sessions would be required due to eventual consistent nature of > repository. and THIS is true: chetan mehrotra wrote > Cluster which involves multiple datastores (tar) > is also eventually consistent. Then why is adobe recommending it's multi-million-dollar projects to go stateless with the encapsulated token here, if those architectures are *also* eventually: https://docs.adobe.com/docs/en/aem/6-1/administer/security/encapsulated-token.html If "being eventual" is the reason we can't go stateless, then how is adobe getting away with it if we know their architecture is also eventual?? What am I missing? I understand that the documentation I linked is a distributed segment store architecture and mine is a share documentstore datastore, but what is the REASON for them allowing a stateless (not sticky) architecture, if the REASON is not eventual consistency ? Both architectures are eventual. Again, thanks for your patience and sticking with me on this one... whoa pun! -- View this message in context: http://apache-sling.73963.n3.nabble.com/Not-sticky-sessions-with-Sling-tp4069530p4069698.html Sent from the Sling - Users mailing list archive at Nabble.com.
Re: Not-sticky sessions with Sling?
This is really disappointing for us. Through this revisioning, Oak has turned a datastore that is consistent by default into a datastore that is not :p It's ironic that the cluster which involves multiple datastores (tar), and thus should have a harder time being consistent, is the one that can accomplish consistency... and the cluster that involves a single shared source of truth (mongo/rdbms), and should have the easiest time being consistent, is not. Hehe. Ahh this probably shoots down our entire Sling proof of concept project. Our next step is to measure the consequences of moving forward with Sling+Oak+Mongo and not-sticky sessions. I'm going to try to test this, and get an empirical answer, by deploying to some AWS instances. I'll develop a custom AuthenticationHandler so that authentication is stateless and then we'll try to see how bad the "delay" might be. However, I would love a theoretical answer as well, if you've got one :) chetan mehrotra wrote > sticky > ... sticky sessions would be required due to eventual consistent nature of > repository. Okay, but if we disable stick sessions ANYHOW (because in our environment we must), how much time delay are we talking, do you think, in realistic practice? We might be able to solve this by giving user-feedback that covers up for the sync delay. When a user clicks save, they might just go to a different screen, providing enough time for things to sync up. It might be a race condition, but that might be acceptable if we can choose that architecture on good information. I think that, in theory, the answer to "worst case scenario" for eventual consistency is always "forever," but really... How long could a Sling instance take to get to the latest revision? More importantly, is it a function of Repo size, or repo activity? If the repo grows in size (number of nodes) and grows in use (number of writes/sec) does this impact how frequently Sling Cluster instances grab the most recent revision? Less importantly... Myself and colleagues are really curious as to why jackrabbit is implemented this way. Is there a performance benefit to being eventually, when the shared datastore is actually consistent? What's the reasoning for not always hitting the latest data? Also... Is there any way to force all reads to read the most recent revision, perhaps through some configuration? A performance cost for this might be tolerable -- View this message in context: http://apache-sling.73963.n3.nabble.com/Not-sticky-sessions-with-Sling-tp4069530p4069661.html Sent from the Sling - Users mailing list archive at Nabble.com.
Re: Not-sticky sessions with Sling?
Alright, this is a deal breaker for our business (if sling absolutely requires sticky sessions). I hope you're not offended that I'm not 100% convinced yet. I understand you do development on the sling project and are well qualified on the topic. To be honest, however, I don't understand fully what you said in your last post and I also know that AEM 6.1 can do what I'd like, which is really just Sling+Oak. If they can do it, I don't understand why we can't. ref: https://docs.adobe.com/docs/en/aem/6-1/administer/security/encapsulated-token.html I'd hate to throw away all the awesome progress we've made with Sling so far when I know that AEM, which is just sling + jackrabbit, can accomplish app-server-agnostic authentication, and thus avoid sticky sessions. Although I don't understand this "head revision" that you've described, and that's inexperience on my part, I am confident that you're telling me that when there is only one Mongo instance in existence, and all Sling instances get data from it, that directly after "sling-instance-1" writes "myProperty=myValue" to the JCR, then "sling-instances-2" could get the value of "myProperty" from somewhere else - some old value. This only seems possible to me if one of the following is true: A) the Sling instances are caching values from Mongo (perhaps Sling or Oak is doing that?) B) There are separate versions of that property stored in Mongo (perhaps this is what you meant by the word revision) and it's possible for a sling-instance to be reading an old version of a property from Mongo. C) Mongo isn't consistent. We know from mongo documentation that C isn't true - Mongo is consistent when reading from the primary replica set. So it must be that A or B is going on? And if so, what is your guess about how AEM 6, which is Sling+Oak, avoids this pitfall when they very clearly support the stateless architecture (ie not-sticky) that I'm planning? -- View this message in context: http://apache-sling.73963.n3.nabble.com/Not-sticky-sessions-with-Sling-tp4069530p4069605.html Sent from the Sling - Users mailing list archive at Nabble.com.
RE: How to change run mode in Sling8
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?
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
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?
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
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: How to change run mode in Sling8
Ok that makes sense. It sounds like developing a new codebase *based on* the launchpad might be my next step. I guess the launchpad is really an example, and not intended to be deployed to production as provided from the war download link here: https://sling.apache.org/downloads.cgi. 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.
Not-sticky sessions with Sling?
The only example code I can find to authenticate to Sling will use the JEE servlet container's "j_security_check" which then stores the authenticated session in App Server memory. A load-balancer without sticky-sessions enabled will cause an unstable experience for users, in which they are suddenly unauthenticated. -Does Sling already offer a mechanism for authenticating without storing that JCR session in Servlet Container Session? -Do any of you avoid sticky sessions without writing custom code? I'm thinking that this problem *must* be solved already. Either there's an authenticationhandler in Sling that I haven't found yet, or there's an open-source example that somebody could share with me :) If I must write this myself, is this the best place to start? https://sling.apache.org/documentation/the-sling-engine/authentication/authentication-authenticationhandler.html https://sling.apache.org/apidocs/sling8/org/apache/sling/auth/core/spi/AuthenticationHandler.html ... as usual, thanks guys. I realize I'm really dominating the mail list lately. I've got a lot to solve :) -- View this message in context: http://apache-sling.73963.n3.nabble.com/Not-sticky-sessions-with-Sling-tp4069530.html Sent from the Sling - Users mailing list archive at Nabble.com.
Re: How to change run mode in Sling8
I can look into overriding init params through some servlet container features. Is that the way that Sling devs expect me to turn on Mongo functionality? -- View this message in context: http://apache-sling.73963.n3.nabble.com/How-to-change-run-mode-in-Sling8-tp4069494p4069529.html Sent from the Sling - Users mailing list archive at Nabble.com.
Re: How to change run mode in Sling8
Hmm, my genuine apologies, I'm not sure what custom application bits are. If you're saying that I can deploy code that I write to Sling, that's absolutely true, but my understanding is that I need to change the runmode BEFORE the Sling instance starts up for the very first time, and I can only deploy my code to Sling OSGI AFTER the sling instance starts up for the very first time. I don't understand how to tell Sling to use oak_mongo instead of oako_tar. Might only solution right now is to either unzip the war and change the properties file before deploying for the first time, or to branch off the Sling source code and rebuild with that property changed. Is this what the Sling developers expect of me? It feels hacky. Isn't there a more conventional way for me to control my runmodes? -- View this message in context: http://apache-sling.73963.n3.nabble.com/How-to-change-run-mode-in-Sling8-tp4069494p4069528.html Sent from the Sling - Users mailing list archive at Nabble.com.
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: JS Use API usability or limitations
Thank you for your time everybody! For posterity: First to clarify, my very specific question is how to iterate an iterable in the model-building logic (what us old timers might call a "backing bean"). I do already know that I can use HTL to iterate the children, and I do recognize that in this contrived example it's a better separation of view/model concerns to do so. However I'm going to need to do lots of iterating on resources in my "backing beans" as I build model data for increasingly complex objects. Imagine a component that searches various parts of the JCR and filters on specific properties to generate a heterogenous list of content links... To suggest HTL just skirts around my development need in model-building logic. Vlad's syntax solved my problem. I'd love to understand why. It seems the Iterable contains a Map or List objects with a key and resource... Is that due to Rhino? The Sling docs say getChildren returns Iterable. I didn't expect this. I'm already feeling the pain of debugging JS Use API, which Stefan has warned about, and so did the sling docs on. I'm concluding that the JS Use API probably isn't ready and requires too much esoteric/idiomatic knowledge to give the sort of development speed one would expect with JS. I'm going to keep it as an option for very simple components. -- View this message in context: http://apache-sling.73963.n3.nabble.com/JS-Use-API-usability-or-limitations-tp4069490p4069521.html Sent from the Sling - Users mailing list archive at Nabble.com.
How to change run mode in Sling8
I cannot change run mode using the process I have in the past, with Sling8. The only thing that has worked for me was to crack open the org.apache.sling.launchpad-8-webapp.war file, crack open the oak jar file within it, edit sling_install.properties (sling.run.mode.install.options=oak|oak_mongo), and then zip it all back up again. This feels _wrong_ haha. Things I tried, which failed: -The Apache Sling Settings Service in OSGI console. It even says "The settings service manages some basic settings of Sling like run modes." However, there is no run mode config there. -JVM arguments. I've tried -Dsling.run.mode.options=oak,oak_mongo and -Dsling.run.modes=oak,oak_mongo. No luck. -Searched for other configurations in the configMgr console. How do I just tell a Sling instance to stop running oak_tar and start running oak_mongo? -- View this message in context: http://apache-sling.73963.n3.nabble.com/How-to-change-run-mode-in-Sling8-tp4069494.html Sent from the Sling - Users mailing list archive at Nabble.com.
Re: Join new member to Sling Oak cluster?
- What kind of discovery mechanism do you use? I don't know - whichever is the default discovery mechanism when running org.apache.sling.launchpad-8-webapp.war on Tomcat 8 and I've modified the content of the war file so that it will start with run modes oak|oak_mongo, so that by default it's looking for mongo on localhost. - Are the Sling/Oak instances and MongoDB clocks in sync? I didn't realize this is important, but they must be as it's all in my local machine. I'm not even using vagrant or virtual machines - just a buncha stuff on local MacOS. - Do you have anything suspicious in the error logs when the instances shut themselves down? See my reply above. Nothing very indicative, just the instance declaring that the clusterview has changed and itself is no longer in it... - What happens if after the instances are shut down and a new leader is elected you restart one of the old instances? Then they boot out the other other guy. They just take turns booting each other out. To be specific, I had a sling instance on :8080 and another on :8081, and they were connected to mongo localhost. Everything worked great as I developed on them for a good 6 hours. Then I added and instance on :8082 and when it connected to mongo localhost, tomcat 8080 and 8081 both shut down, and the log file is just their mutual agreement that the new clusterview doesn't include them. I immediately started 8080 and 8081 back up again, and the same thing happened but in reverse, with 8082 shutting itself down. -- View this message in context: http://apache-sling.73963.n3.nabble.com/Join-new-member-to-Sling-Oak-cluster-tp4069454p4069493.html Sent from the Sling - Users mailing list archive at Nabble.com.
Re: Join new member to Sling Oak cluster?
Not sure if I've experienced an intermittent but severe defect, or if I did
something wrong when attempting this yesterday.
I followed the exact same steps today, and the new instance *did*
successfully join. Either I'm wrong, and I actually did something
differently yesterday, or this is an intermittent defect and a big bummer.
I'll keep trying to reproduce.
Here is the log output from one of the instances that was already in the
cluster when the new one joined:
**
09.01.2017 16:20:36.062 *INFO*
[DocumentDiscoveryLiteService-BackgroundWorker-[1]]
org.apache.jackrabbit.oak.plugins.document.DocumentDiscoveryLiteService
doCheckView: view has changed from: a ClusterView[valid=true, viewSeqNum=2,
clusterViewId=ae406105-3c77-4498-b8fc-1557b012d46d, activeIds=1,2,
recoveringIds=null, inactiveIds=null] to: a ClusterView[valid=true,
viewSeqNum=3, clusterViewId=ae406105-3c77-4498-b8fc-1557b012d46d,
activeIds=1, recoveringIds=null, inactiveIds=2] - sending event...
09.01.2017 16:20:36.063 *INFO*
[DocumentDiscoveryLiteService-BackgroundWorker-[1]]
org.apache.jackrabbit.oak.plugins.document.DocumentDiscoveryLiteService
checkView: view changed from: a
ClusterView[{"seq":2,"final":true,"id":"ae406105-3c77-4498-b8fc-1557b012d46d","me":1,"active":[1,2],"deactivating":[],"inactive":[]}],
to: a
ClusterView[{"seq":3,"final":false,"id":"ae406105-3c77-4498-b8fc-1557b012d46d","me":1,"active":[1],"deactivating":[2],"inactive":[]}],
hasInstancesWithBacklog: true
09.01.2017 16:20:37.168 *INFO* [Thread-31]
org.apache.sling.discovery.impl.DiscoveryServiceImpl enqueueForAll: sending
PROPERTIES_CHANGED to all listeners (oldView=TopologyViewImpl
[current=false, super.hashCode=1259039663, instances=[an
InstanceDescription[slindId=3d4f31d9-b3ba-4e32-aa10-36ef150a37f0,
isLeader=true, isOwn=true,
clusterViewId=20a0797b-e957-4b8e-845b-9b9e0b6a246d,
properties={org.apache.sling.instance.endpoints=,
org.apache.sling.event.jobs.consumer.topics=/,com/composum/sling/core/pckgmgr/PackageJobExecutor,com/composum/sling/core/script/GroovyJobExecutor,org/apache/sling/event/impl/jobs/tasks/HistoryCleanUpTask,sling/webconsole/test,
org.apache.sling.instance.name=Instance
3d4f31d9-b3ba-4e32-aa10-36ef150a37f0,
org.apache.sling.instance.description=Instance with id
3d4f31d9-b3ba-4e32-aa10-36ef150a37f0 and run modes [oak_mongo, oak]}], an
InstanceDescription[slindId=cc9e3513-8f6c-460d-b27e-dd3844aa629d,
isLeader=false, isOwn=false,
clusterViewId=20a0797b-e957-4b8e-845b-9b9e0b6a246d,
properties={org.apache.sling.instance.endpoints=,
org.apache.sling.event.jobs.consumer.topics=/,com/composum/sling/core/pckgmgr/PackageJobExecutor,com/composum/sling/core/script/GroovyJobExecutor,org/apache/sling/event/impl/jobs/tasks/HistoryCleanUpTask,sling/webconsole/test,
org.apache.sling.instance.name=Instance
cc9e3513-8f6c-460d-b27e-dd3844aa629d,
org.apache.sling.instance.description=Instance with id
cc9e3513-8f6c-460d-b27e-dd3844aa629d and run modes [oak_mongo, oak]}]]],
newView=TopologyViewImpl [current=true, super.hashCode=238080023,
instances=[an
InstanceDescription[slindId=3d4f31d9-b3ba-4e32-aa10-36ef150a37f0,
isLeader=true, isOwn=true,
clusterViewId=20a0797b-e957-4b8e-845b-9b9e0b6a246d,
properties={org.apache.sling.instance.endpoints=,
org.apache.sling.event.jobs.consumer.topics=/,com/composum/sling/core/pckgmgr/PackageJobExecutor,com/composum/sling/core/script/GroovyJobExecutor,org/apache/sling/event/impl/jobs/tasks/HistoryCleanUpTask,sling/webconsole/test,
org.apache.sling.instance.name=Instance
3d4f31d9-b3ba-4e32-aa10-36ef150a37f0,
org.apache.sling.instance.description=Instance with id
3d4f31d9-b3ba-4e32-aa10-36ef150a37f0 and run modes [oak_mongo, oak]}], an
InstanceDescription[slindId=cc9e3513-8f6c-460d-b27e-dd3844aa629d,
isLeader=false, isOwn=false,
clusterViewId=20a0797b-e957-4b8e-845b-9b9e0b6a246d,
properties={org.apache.sling.instance.endpoints=,
org.apache.sling.event.jobs.consumer.topics=/,org/apache/sling/event/impl/jobs/tasks/HistoryCleanUpTask,sling/webconsole/test,
org.apache.sling.instance.name=Instance
cc9e3513-8f6c-460d-b27e-dd3844aa629d,
org.apache.sling.instance.description=Instance with id
cc9e3513-8f6c-460d-b27e-dd3844aa629d and run modes [oak_mongo, oak]}]]]).
09.01.2017 16:20:37.171 *INFO*
[DocumentDiscoveryLiteService-BackgroundWorker-[1]]
org.apache.jackrabbit.oak.plugins.document.DocumentDiscoveryLiteService
checkView: view changed from: a
ClusterView[{"seq":3,"final":false,"id":"ae406105-3c77-4498-b8fc-1557b012d46d","me":1,"active":[1],"deactivating":[2],"inactive":[]}],
to: a
ClusterView[{"seq":3,"final":true,"id":"ae406105-3c77-4498-b8fc-1557b012d46d","me":1,"active":[1],"deactivating":[],"inactive":[2]}],
hasInstancesWithBacklog: false
***
From there onward, the log file is just the normal shut-down logs as OSGI
unregisters bundles and the servlet container shuts down.
--
View this message in context:
JS Use API usability or limitations
I've got years of experience writing backing beans for Sling (aem)
components, but can't seem to get a simple JS backing working using the new
Javascript Use API.
All I want to do is print out a resource's children resources.
My JS backing bean:
use([], function () {
var returnObj = {
content: ""
};
var parent = resource.parent;
var children = parent.getChildren();
for (res in Iterator(children)) {
returnObj.content += res.name;
}
return returnObj;
});
The contents of returnObj.content will be the word "undefined" repeated X
times, where X is the number of children nodes of parent. This tells me it
successfully iterates the Iterable once for each item in it, but it's
failing to give me a reference to a child. If I try res.getName() instead, I
get:
org.mozilla.javascript.EcmaError: TypeError: Cannot find default value for
object
In fact, every single variation I've tried for iterating that collection has
lead to that exact Exception.
It seems to me Rhino is getting in the way. Am I right? What is the
community consensus on use of the JS Use API? Is it production-ready and
stable? Is my problem a user-error? What limitations exist here? I was
planning on doing the same things in JS that I've always done in Java, which
is usually a lot of read/write operations on the JCR.
--
View this message in context:
http://apache-sling.73963.n3.nabble.com/JS-Use-API-usability-or-limitations-tp4069490.html
Sent from the Sling - Users mailing list archive at Nabble.com.
RE: Sling 8 Resource Versioning? Jira access?
Ahh, yes you're right. I was getting a 403 apparently because of an old bad Chrome Plugin that was injecting Basic Auth headers into my request... my fault. -- View this message in context: http://apache-sling.73963.n3.nabble.com/Sling-8-Resource-Versioning-Jira-access-tp4069484p4069486.html Sent from the Sling - Users mailing list archive at Nabble.com.
Sling 8 Resource Versioning? Jira access?
The announcement for sling 8 announces a feature we're excited to use: Versioning through the Resource API: https://sling.apache.org/news/sling-launchpad-8-released.html#versioning-support-in-the-resource-api However, the only info it provides is a JIRA link I can't access: https://issues.apache.org/jira/browse/SLING-848 My questions: 1) How can I get access to Jira to see this? 2) Can we get put this information somewhere outside of JIRA, such as sling.apache.org or https://cwiki.apache.org/confluence/display/SLING ? (My apologies if it actually is out there somewhere, I've searched with no luck) -- View this message in context: http://apache-sling.73963.n3.nabble.com/Sling-8-Resource-Versioning-Jira-access-tp4069484.html Sent from the Sling - Users mailing list archive at Nabble.com.
Join new member to Sling Oak cluster?
Hey guys, sorry for multiple recent question. I'm biting down hard on Sling right now and hitting tons of learning curve and growing pains. My problem: If I create a fresh instance of MongoDB, and connect multiple fresh instances of Sling to it (each running in a separate tomcat instance), they all plug-and-play happily. They just discover each other and my clusterview is very stable at /system/console/topology. However, if I used the cluster for a while (deploy some OSGI bundles, create some JCR content) and *then* connect a new sling instance, what happens is that all of the current instances shut down (they literally send a shut down signal to tomcat's shut down port) and then the single new instance votes itself as the new leader, and only member, of a new 1-instance cluster. Is this a known issue? Do I need to "prime" my new member with the current state of the cluster before connecting it to the cluster or something (perhaps by uploading all the bundles and content that has been uploaded to the cluster?) -- View this message in context: http://apache-sling.73963.n3.nabble.com/Join-new-member-to-Sling-Oak-cluster-tp4069454.html Sent from the Sling - Users mailing list archive at Nabble.com.
Re: Multiple Version of Commons Lang in OSGI...
Gah - solved myself almost immediately after posting. For posterity: version 3.5 of commons lang has a different Bundle-SymbolicName ( org.apache.commons.lang3) in the OSGI metadata of MINFEST.MF. Simply by bumping to lang 3.5 you'll solve this. -- View this message in context: http://apache-sling.73963.n3.nabble.com/Multiple-Version-of-Commons-Lang-in-OSGI-tp4069450p4069452.html Sent from the Sling - Users mailing list archive at Nabble.com.
Multiple Version of Commons Lang in OSGI...
I have packages (such as composum tools) that depend on apache commons lang 3. I have other packages (such as most of the sling itself) that depend on commons lang version 2. There are no Java Package namespacing collisions between these packages - they can both exist in the same JVM safely. Version 3 uses "org.apache.commons.lang3.*" package. I should be able to install both of these packages. However, possibly because they have the same artifact ID or something, installing version 3 overwrites version 2, meaning I can't have both, and thus can't run both the core sling packages and the composum tools. This is a deal breaker right now for my Sling P.O.C. project. To be clear, the actual commons lang jar version 2 jar file, which is stored at /sling/felix/bundle71/version0.0, is deleted and and the version 3 jar file is stored at /sling/felix/bundle71/version0.1. The only solution I can imagine is to modify the commons-lang bundle with a custom artifact ID so that Sling won't consider them the same artifact. That would be a hack and cause issues later on. I'm positive somebody else has solved this issue? Google search yields nothing. -- View this message in context: http://apache-sling.73963.n3.nabble.com/Multiple-Version-of-Commons-Lang-in-OSGI-tp4069450.html Sent from the Sling - Users mailing list archive at Nabble.com.
