Multiple oak repositories using an OSGI whiteboard
Hi, I'd like to setup two distinct Oak repositories in the same VM, each containing an OSGI whiteboard. Looking at the components inside oak-core that announce their availability using this whiteboard and the way the registration is implemented in the OSGI whiteboard, I was wondering whether above setup is possible without causing a clash in the OSGI service registry. If so, what would be the easiest way to create separate "namespaces" where every component is automatically associated with its designated whiteboard? Kind regards Dominique
RE: Multiple oak repositories using an OSGI whiteboard
Hi, Thanks everybody for their responses. Yes, there is some special code looking up the second repository, and I thought about registering the second repository with a separate interface, so it can still be bound. My concern, however, is what happens with all the "inner" components, that are not directly coupled to the repository but rather registered in a whiteboard, and still contribute to the correct functioning. To be more precise, let's say I'd like to create 1 oak repository of type Tar (T) and 1 of type Mongo (M): I give T an OSGI whiteboard, while M gets a default implementation that doesn't register its services in OSGI. Let's further say that the construction code of T @References an oak OSGI component (e.g. SecurityProvider), while M constructs one programmatically (e.g. an instance of type SecurityProviderImpl). Would this cause an interference, e.g. could the one explicitly built for M also be implicitly used for T? Thanks Dominique From: Carsten Ziegeler Sent: Wednesday, July 16, 2014 3:50 PM To: oak-dev@jackrabbit.apache.org Subject: Re: Multiple oak repositories using an OSGI whiteboard As David points out subsystems might help our writing your own service registry hooks. If you're not using one of those, you have a flat/shared service registry and usually services using a repository service just pick up one from the service registry and that's the one with the highest ranking at the point of asking the registry. Therefore repository services which are registered after this point in time are not even considered and there is no rebinding (unless e.g. DS is used with a greedy reference). As you don't want to rewrite all the code using a repository service, namespacing is the only option. However, the question is, what do you do with this second repository service? Is there special code just looking up the second repository? Maybe in that case, the simpler option could be to register the repository with a different service interface - something like a marker interface SecondaryRepository etc. (maybe with a better name) Regards Carsten 2014-07-16 3:08 GMT-07:00 David Bosschaert : > Hi Dominique, > > You could look into OSGi Application Subsystems (OSGi Enterprise Spec > 5 chapter 134). Application subsystems provide separate namespaces and > by default don't share out services. Other subsystem types include > Feature subsystems (where everything is shared) and Composite > subsystems where you define explicitly what is shared and what is not. > > I wrote a blog a while ago on how to get Apache Aries subsystems > running on Apache Felix, which might be useful: > > http://coderthoughts.blogspot.com/2014/01/osgi-subsytems-on-apache-felix.html > > Alternatively you can create your own service namespaces by using OSGi > Service Registry hooks, but these are a bit more low-level than > subsystems... > > Best regards, > > David > > On 15 July 2014 21:23, Dominique Pfister wrote: > > Hi, > > > > > > I'd like to setup two distinct Oak repositories in the same VM, each > containing an OSGI whiteboard. > > > > > > Looking at the components inside oak-core that announce their > availability using this whiteboard and the way the registration is > implemented in the OSGI whiteboard, I was wondering whether above setup is > possible without causing a clash in the OSGI service registry. If so, what > would be the easiest way to create separate "namespaces" where every > component is automatically associated with its designated whiteboard? > > > > > > Kind regards > > > > Dominique > -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
svn commit r1300904
Sorry for committing this without a comment (pressed Enter with the wrong focus, argh!). Commit message should read: Author: dpfister Date: Thu Mar 15 10:48:34 2012 New Revision: 1300904 URL: http://svn.apache.org/viewvc?rev=1300904&view=rev Log: Simplify RevisionStore interface, add javadoc to describe contract regarding lock/unlockHead
Re: svn commit r1300904
Sensational, thanks a lot! On Mar 15, 2012, at 12:04 PM, Felix Meschberger wrote: > Hi, > > You can do: > > $ svn ps svn:log --revprop -r 1300904 "Log: Simplify RevisionStore > interface, add javadoc to describe contract regarding lock/unlockHead" > > This updates/fixes the log message in subversion. > > Regards > Felix > > Am 15.03.2012 um 11:57 schrieb Dominique Pfister: > >> Sorry for committing this without a comment (pressed Enter with the wrong >> focus, argh!). Commit message should read: >> >> Author: dpfister >> Date: Thu Mar 15 10:48:34 2012 >> New Revision: 1300904 >> >> URL: http://svn.apache.org/viewvc?rev=1300904&view=rev >> Log: Simplify RevisionStore interface, add javadoc to describe contract >> regarding lock/unlockHead >
Re: On setting component boundaries in Oak
Hi, On Mar 15, 2012, at 1:57 PM, Jukka Zitting wrote: > Hi, > > On Thu, Mar 15, 2012 at 10:19 AM, Stefan Guggisberg > wrote: >> On Thu, Mar 15, 2012 at 9:07 AM, Angela Schreiber wrote: The API and protocol bindings on the top are just some examples. >>> >>> ok... because i am not so sure about a plain WebDAV binding. >>> imo that one would rather belong on top of the JCR binding. >>> so, i would rather not have listed here as long as we don't >>> really plan to build that as it might cause confusion. > > OK, let's drop the WebDAV bit for now from the diagram. As I said, > it's just an example of what we could do. > >>> well... but this means that the mk implementations that are >>> currently located in the oak-core module should be moved out >>> to some different component. >> >> agreed, and that's IMO good. we should allow for alternative >> mk impls (like we did with the jr pm's) but we also should >> also designate a default impl (sort of a mk api reference impl). > > Yep. I'd like to see that default MK be as simple as possible, ideally > just an in-memory implementation designed mostly for testing and as a > reference point for other implementations. Of course, it's a good idea to have an in-memory implementation for quick testing, but IMO a default implementation should at least store data in a way that it survives a restart. Kind regards Dominique
Re: Lifetime of revision identifiers
Hi, On Apr 2, 2012, at 7:28 PM, Jukka Zitting wrote: > Hi, > > On Mon, Apr 2, 2012 at 6:34 PM, Stefan Guggisberg > wrote: >> i don't think that we should allow clients to explicitly extend the life span >> of a specific revision. this would IMO unnecessarily complicate the GC >> logic and it would allow misbehaved clients to compromise the stability >> of the mk. > > This would notably complicate things in oak-core and higher up. Any > large batch operations would have to worry about the underlying > revisions becoming unavailable unless they are continuously updated to > the latest head revision. > > I don't think allowing lease extensions would complicate garbage > collection too much. All I'm asking is that the collector should look > at the "last access time" instead of the "create time" of a revision > to determine whether it's still referenceable or not. Sounds reasonable, as long as you explicitely access the revision first, and then the nodes it contains. Things get more complicated if you'd "hang on" to some node in some revision and then expect that this revision stays alive. Regards Dominique > > BR, > > Jukka Zitting
Re: Lifetime of revision identifiers
Hi, I made a second thought, and I'm no longer sure I would allow a revision to be reachable by some client interaction. In the current design, the GC will copy the head revision to the "to store" plus all the revisions that are either newly created (by some commit call coming in later) or still manipulated (by a commit that started earlier but where the internal commit builder is still not finished). I'd extend this design by copying all revisions that were created in some fixed interval (e.g. 10 minutes) before the head revision was created, and see whether this will suffice. Regards Dominique On Apr 3, 2012, at 11:05 AM, Dominique Pfister wrote: > Hi, > > On Apr 2, 2012, at 7:28 PM, Jukka Zitting wrote: > >> Hi, >> >> On Mon, Apr 2, 2012 at 6:34 PM, Stefan Guggisberg >> wrote: >>> i don't think that we should allow clients to explicitly extend the life >>> span >>> of a specific revision. this would IMO unnecessarily complicate the GC >>> logic and it would allow misbehaved clients to compromise the stability >>> of the mk. >> >> This would notably complicate things in oak-core and higher up. Any >> large batch operations would have to worry about the underlying >> revisions becoming unavailable unless they are continuously updated to >> the latest head revision. >> >> I don't think allowing lease extensions would complicate garbage >> collection too much. All I'm asking is that the collector should look >> at the "last access time" instead of the "create time" of a revision >> to determine whether it's still referenceable or not. > > Sounds reasonable, as long as you explicitely access the revision first, and > then the nodes it contains. Things get more complicated if you'd "hang on" to > some node in some revision and then expect that this revision stays alive. > > Regards > Dominique > >> >> BR, >> >> Jukka Zitting >
Re: Lifetime of revision identifiers
Hi, On Apr 3, 2012, at 11:51 AM, Jukka Zitting wrote: > Hi, > > On Tue, Apr 3, 2012 at 11:47 AM, Dominique Pfister wrote: >> I made a second thought, and I'm no longer sure I would allow >> a revision to be reachable by some client interaction. > > You'd drop revision identifiers from the MicroKernel interface? That's > a pretty big design change... No, I probably did not make myself clear: I would not keep a revision (and all its nodes) reachable in terms of garbage collection, simply because it was accessed by a client some time ago. Dominique > > BR, > > Jukka Zitting
Re: Lifetime of revision identifiers
Hi,
On Apr 3, 2012, at 12:50 PM, Jukka Zitting wrote:
> Hi,
>
> On Tue, Apr 3, 2012 at 11:56 AM, Dominique Pfister wrote:
>> On Apr 3, 2012, at 11:51 AM, Jukka Zitting wrote:
>>> You'd drop revision identifiers from the MicroKernel interface? That's
>>> a pretty big design change...
>>
>> No, I probably did not make myself clear: I would not keep a revision
>> (and all its nodes) reachable in terms of garbage collection, simply
>> because it was accessed by a client some time ago.
>
> If that's the case, I'm worried about what could happen to code like this:
>
>String revision = mk.getHeadRevision();
>String root = getNodes("/", revision);
>
> Suppose someone else makes a commit in between the two calls and the
> garbage collector gets triggered. The result then would be that the
> getNodes() call will fail because the given revision identifier is no
> longer available.
If we have a delay of 10 minutes for revisions getting garbage collected, this
would imply that 10 minutes passed between the first call and the second call,
right? This seems rather unlikely.
>
> And if you consider that an unlikely enough scenario, consider a case
> where I want to then page through a potentially large list of the
> child nodes:
>
>int page_size = 10;
>long count = getChildNodeCount(root);
>for (long offset = 0; offset < count; offset += page_size) {
>String children = mk.getNodes("/", revision, 1, offset,
> page_size, null);
>}
>
> That could take a potentially long time, during which the revision
> might well get garbage-collected. How should a client prepare for such
> a situation?
If simply iterating over this large list takes longer than the 10 minutes
mentioned above, you'd have REALLY have a lot of child nodes. And if the client
does some work in between (or waits for some other user interaction to continue
paging), I guess it must be able to handle this situation gracefully.
I'm just worried about the other extreme: if you have a lot of such clients
requesting large child node lists on different head revisions, the garbage
collector will never be able to actually collect a revision and space will run
out soon.
Dominique
>
> BR,
>
> Jukka Zitting
Re: Lifetime of revision identifiers
On 3.4.12 13:36, Michael Dürig wrote: > 10 minutes (like any value) seems quite arbitrary to me. I wouldn't want to > fix deployments by fiddling around with this. Rather should clients be > empowered to specify how long they need a certain revision (e.g. by a lease > model as Jukka proposed). > If a deployment runs out of space because the client application holds on to > too many revisions for too long, this can be fixed by optimising the client > and adjusting the store size to the actual client's requirements. I don't like the idea in general, that a server compontent relies on clients to behave "well" or things will break. As you said, we don't have any conclusive figures yet, how fast things will grow in the revision store. It is just my gut feeling, that keeping revisions around as long as they're accessed, will generate other problems if we don't have a hard limit on a revision's overall lifetime. Dominique
Re: Lifetime of revision identifiers
On Apr 3, 2012, at 2:39 PM, Jukka Zitting wrote: > Hi, > > On Tue, Apr 3, 2012 at 2:31 PM, Dominique Pfister wrote: >> As you said, we don't have any conclusive figures yet, how fast >> things will grow in the revision store. > > How about we revisit this issue in a few weeks once we have initial > benchmarks in place? +1 :-) Cheers Dominique > > BR, > > Jukka Zitting
Re: MicroKernel.getInstance
On Apr 10, 2012, at 6:32 PM, Jukka Zitting wrote: > Hi, > > On Tue, Apr 10, 2012 at 5:23 PM, Julian Reschke wrote: >> Proposal: rename to "locator". > > Alternative proposal: Get rid of MicroKernelFactory entirely. > > Components that need to instantiate a MK implementation should > directly use the appropriate constructor or other > implementation-specific instantiation mechanism. That way whoever > starts the repository or the MK instance is clearly in charge of also > shutting it down when appropriate. The current approach with the MKF > and MK.dispose() doesn't properly address that issue. > > URL-based access or other lookups should IMHO only be used for cases > where the repository has already been initialized and only a reference > to it is needed. For such cases we should use JNDI, OSGi service > references, or other existing mechanisms instead of a custom MKF > interface. > > As an example of using such a solution, see the new > AbstractMicroKernelIT class in oak-it-mk and the standard Java service > provider mechanism it leverages. Sounds fine to me, +1 Cheers Dominique > > BR, > > Jukka Zitting
Re: Intermittent test failures with -PintegrationTesting
Hi Michi, Seen this, too, very rarely though. Anyway, I created an issue for this: https://issues.apache.org/jira/browse/OAK-107 Cheers Dominique On May 21, 2012, at 11:41 PM, Michael Dürig wrote: > > Hi, > > About every third build fails for me: > > --- > Test set: org.apache.jackrabbit.mk.store.DefaultRevisionStoreTest > --- > Tests run: 4, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.723 > sec <<< FAILURE! > testConcurrentMergeGC(org.apache.jackrabbit.mk.store.DefaultRevisionStoreTest) > > Time elapsed: 0.737 sec <<< ERROR! > org.apache.jackrabbit.mk.api.MicroKernelException: > java.lang.RuntimeException: Unexpected error > at > org.apache.jackrabbit.mk.core.MicroKernelImpl.merge(MicroKernelImpl.java:504) > at > org.apache.jackrabbit.mk.store.DefaultRevisionStoreTest.testConcurrentMergeGC(DefaultRevisionStoreTest.java:184) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at > org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) > at > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) > at > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) > at > org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) > at > org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:172) > at > org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:104) > at > org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:70) > Caused by: java.lang.RuntimeException: Unexpected error > at > org.apache.jackrabbit.mk.store.StoredNodeAsState$3.getNode(StoredNodeAsState.java:176) > at > org.apache.jackrabbit.mk.store.StoredNodeAsState.getChildNode(StoredNodeAsState.java:120) > at > org.apache.jackrabbit.mk.store.DefaultRevisionStore$3.childNodeChanged(DefaultRevisionStore.java:476) > at > org.apache.jackrabbit.mk.model.AbstractNode.diff(AbstractNode.java:126) > at > org.apache.jackrabbit.mk.store.DefaultRevisionStore.compare(DefaultRevisionStore.java:443) > at org.apache.jackrabbit.mk.model.NodeDelta.(NodeDelta.java:68) > at > org.apache.jackrabbit.mk.model.CommitBuilder.mergeNode(CommitBuilder.java:371) > at > org.apache.jackrabbit.mk.model.CommitBuilder.mergeTree(CommitBuilder.java:363) > at > org.apache.jackrabbit.mk.model.CommitBuilder.doMerge(CommitBuilder.java:216) > at > org.apache.jackrabbit.mk.core.MicroKernelImpl.merge(MicroKernelImpl.java:502) > ... 32 more > Caused by: org.apache.jackrabbit.mk.store.NotFoundException: > 0a9706e6ec0320c779cd6f775910826e79c97f58 > at > org.apache.jackrabbit.mk.persistence.InMemPersistence.readNode(InMemPersistence.
Re: The revenge of OAK-53 part II: IT failure
Hi Michi, On May 23, 2012, at 1:38 PM, Michael Dürig wrote: > Didn't see it again up to now. I'll keep an eye on it. Is there any log > data that would be helpful if this occurs again? Unfortunately not (yet), if it reappears, I'll add a logger to the mk subproject and log messages in the server. Cheers Dominique > > Michael > >> >> cheers >> stefan >> >>> >>> Michael >>> >>> cheers stefan >at > > org.apache.jackrabbit.mk.client.Client.toMicroKernelException(Client.java:372) >at org.apache.jackrabbit.mk.client.Client.write(Client.java:353) >at > > org.apache.jackrabbit.mk.test.MicroKernelIT.testBlobs(MicroKernelIT.java:855) >at > > org.apache.jackrabbit.mk.test.MicroKernelIT.testBlobs(MicroKernelIT.java:843) >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >at > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >at > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >at java.lang.reflect.Method.invoke(Method.java:597) >at > > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) >at > > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) >at > > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) >at > > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) >at > > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) >at > > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) >at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) >at > > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) >at > > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) >at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) >at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) >at > org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) >at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) >at > org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) >at org.junit.runners.ParentRunner.run(ParentRunner.java:300) >at org.junit.runners.Suite.runChild(Suite.java:128) >at org.junit.runners.Suite.runChild(Suite.java:24) >at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) >at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) >at > org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) >at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) >at > org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) >at org.junit.runners.ParentRunner.run(ParentRunner.java:300) >at org.junit.runners.Suite.runChild(Suite.java:128) >at org.junit.runners.Suite.runChild(Suite.java:24) >at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) >at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) >at > org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) >at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) >at > org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) >at org.junit.runners.ParentRunner.run(ParentRunner.java:300) >at org.junit.runners.Suite.runChild(Suite.java:128) >at org.junit.runners.Suite.runChild(Suite.java:24) >at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) >at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) >at > org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) >at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) >at > org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) >at org.junit.runners.ParentRunner.run(ParentRunner.java:300) >at > > org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236) >at > > org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134) >at > > org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113) >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >at > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
Re: The revenge of OAK-53 part II: IT failure
Hi Michi, And you're sure you built and installed the latest oak-mk package, and are not accidentally refering to an old one that doesn't contain the fix made in OAK-12, namely to BoundaryInputStream? Cheers Dominique On May 24, 2012, at 11:43 AM, Michael Dürig wrote: > > Hi Dominique, > > On 23.5.12 13:45, Dominique Pfister wrote: >> Hi Michi, >> >> On May 23, 2012, at 1:38 PM, Michael Dürig wrote: >> >>> Didn't see it again up to now. I'll keep an eye on it. Is there any log >>> data that would be helpful if this occurs again? >> >> Unfortunately not (yet), if it reappears, I'll add a logger to the mk >> subproject and log messages in the server. > > This just happens again. The output form the Maven build is > > --- > T E S T S > --- > Running org.apache.jackrabbit.mk.test.EverythingIT > java.io.IOException: Bad HTTP request line: 9?)c??:O?+?w > > ?c9???'td???>a"Y??#0??ˀ??+??4¨?:?0?1 > > #`# > at org.apache.jackrabbit.mk.server.Request.parse(Request.java:72) > at > org.apache.jackrabbit.mk.server.HttpProcessor.process(HttpProcessor.java:100) > at > org.apache.jackrabbit.mk.server.HttpProcessor.process(HttpProcessor.java:75) > at org.apache.jackrabbit.mk.server.Server.process(Server.java:169) > at org.apache.jackrabbit.mk.server.Server$2.run(Server.java:131) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:680) > Tests run: 72, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 15.639 > sec <<< FAILURE! > > Results : > > Tests in error: > testBlobs[1](org.apache.jackrabbit.mk.test.MicroKernelIT): > java.net.SocketException: Broken pipe > > Tests run: 72, Failures: 0, Errors: 1, Skipped: 0 > > > Stack trace from the logs: > > --- > Test set: org.apache.jackrabbit.mk.test.EverythingIT > --- > Tests run: 72, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 15.64 > sec <<< FAILURE! > testBlobs[1](org.apache.jackrabbit.mk.test.MicroKernelIT) Time elapsed: > 4.259 sec <<< ERROR! > org.apache.jackrabbit.mk.api.MicroKernelException: > java.net.SocketException: Broken pipe > at > org.apache.jackrabbit.mk.client.Client.toMicroKernelException(Client.java:372) > at org.apache.jackrabbit.mk.client.Client.write(Client.java:353) > at > org.apache.jackrabbit.mk.test.MicroKernelIT.testBlobs(MicroKernelIT.java:855) > at > org.apache.jackrabbit.mk.test.MicroKernelIT.testBlobs(MicroKernelIT.java:843) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) > at > org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) > at org.junit.runners.ParentRunner.run(ParentRunner.java:300) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:24) > at org.junit.runners.ParentRunner$
Re: The revenge of OAK-53 part II: IT failure
Hm, I just ran this test another couple of times, but am still unable to reproduce it. I noticed that your EverythingIT test run takes almost twice as much time than mine, which might hint at some timing-related problem. Berofe adding some logging output to the server to find out what causes this problem, may I ask you to try the following: comment line 72 in oak-mk's HttpProcessor.java: 72: socket.setSoTimeout(INITIAL_SO_TIMEOUT); and re-run the test? This is just a wild guess, but perhaps the initial socket timeout of 1 second is too aggressive for the transfer of 32MB-sized blob. Dominique On May 24, 2012, at 12:14 PM, Michael Dürig wrote: > > > On 24.5.12 10:59, Dominique Pfister wrote: >> Hi Michi, >> >> And you're sure you built and installed the latest oak-mk package, and are >> not accidentally refering to an old one that doesn't contain the fix made in >> OAK-12, namely to BoundaryInputStream? > > I think so. I did svn up and mvn clean install -PintegrationTesting just > a couple of hours ago. > > Michael > >> >> Cheers >> Dominique >> >> On May 24, 2012, at 11:43 AM, Michael Dürig wrote: >> >>> >>> Hi Dominique, >>> >>> On 23.5.12 13:45, Dominique Pfister wrote: >>>> Hi Michi, >>>> >>>> On May 23, 2012, at 1:38 PM, Michael Dürig wrote: >>>> >>>>> Didn't see it again up to now. I'll keep an eye on it. Is there any log >>>>> data that would be helpful if this occurs again? >>>> >>>> Unfortunately not (yet), if it reappears, I'll add a logger to the mk >>>> subproject and log messages in the server. >>> >>> This just happens again. The output form the Maven build is >>> >>> --- >>> T E S T S >>> --- >>> Running org.apache.jackrabbit.mk.test.EverythingIT >>> java.io.IOException: Bad HTTP request line: 9?)c??:O?+?w >>> >>> ?c9???'td???>a"Y??#0??ˀ??+??4¨?:?0?1 >>> >>> #`# >>> at org.apache.jackrabbit.mk.server.Request.parse(Request.java:72) >>> at >>> org.apache.jackrabbit.mk.server.HttpProcessor.process(HttpProcessor.java:100) >>> at >>> org.apache.jackrabbit.mk.server.HttpProcessor.process(HttpProcessor.java:75) >>> at org.apache.jackrabbit.mk.server.Server.process(Server.java:169) >>> at org.apache.jackrabbit.mk.server.Server$2.run(Server.java:131) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) >>> at >>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) >>> at java.lang.Thread.run(Thread.java:680) >>> Tests run: 72, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 15.639 >>> sec<<< FAILURE! >>> >>> Results : >>> >>> Tests in error: >>> testBlobs[1](org.apache.jackrabbit.mk.test.MicroKernelIT): >>> java.net.SocketException: Broken pipe >>> >>> Tests run: 72, Failures: 0, Errors: 1, Skipped: 0 >>> >>> >>> Stack trace from the logs: >>> >>> --- >>> Test set: org.apache.jackrabbit.mk.test.EverythingIT >>> --- >>> Tests run: 72, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 15.64 >>> sec<<< FAILURE! >>> testBlobs[1](org.apache.jackrabbit.mk.test.MicroKernelIT) Time elapsed: >>> 4.259 sec<<< ERROR! >>> org.apache.jackrabbit.mk.api.MicroKernelException: >>> java.net.SocketException: Broken pipe >>> at >>> org.apache.jackrabbit.mk.client.Client.toMicroKernelException(Client.java:372) >>> at org.apache.jackrabbit.mk.client.Client.write(Client.java:353) >>> at >>> org.apache.jackrabbit.mk.test.MicroKernelIT.testBlobs(MicroKernelIT.java:855) >>> at >>> org.apache.jackrabbit.mk.test.MicroKernelIT.testBlobs(MicroKernelIT.java:843) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) >>> at java.lang.reflect.Method.invoke(Method.
Re: ConcurrentModificationException during gc run
Hi Michi, Yes, Tom experienced the same issue yesterday. I'm gonna have a look. Thanks Dominique On Jul 4, 2012, at 11:23 AM, Michael Dürig wrote: > > Hi, > > I got a ConcurrentModificationException while checking the 0.3 release. > This didn't cause any test case to fail but was printed to the console. > > Michael > > Running org.apache.jackrabbit.oak.jcr.JcrTckTest > java.util.ConcurrentModificationException > at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1100) > at java.util.TreeMap$EntryIterator.next(TreeMap.java:1136) > at java.util.TreeMap$EntryIterator.next(TreeMap.java:1131) > at > org.apache.jackrabbit.mk.store.DefaultRevisionStore.markBranches(DefaultRevisionStore.java:561) > at > org.apache.jackrabbit.mk.store.DefaultRevisionStore.gc(DefaultRevisionStore.java:497) > at > org.apache.jackrabbit.mk.store.DefaultRevisionStore$2.run(DefaultRevisionStore.java:159) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) > at > java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:680)
Re: Test failure: testSelector(org.apache.jackrabbit.test.api.query.qom.SelectorTest
Hi, On Jul 25, 2012, at 11:01 AM, Jukka Zitting wrote: > Hi, > > On Wed, Jul 25, 2012 at 10:48 AM, Michael Dürig wrote: >> While running the integration tests locally I got the following failure. >> Seems to be a transient issue since it went away on the 2nd try. > > I've noticed something similar every now and then. I suspect it's a > consequence of the garbage collector being too aggressive in > reclaiming old revisions that are still being referenced by the test > cases. The garbage collector currently keeps commits that were created within 60 minutes of the current head commit's creation time: do the integration tests run for such a long time? Dominique > > BR, > > Jukka Zitting
Re: [VOTE] Accept MongoMK contribution (Was: [jira] [Created] (OAK-293) MongoDB-based MicroKernel)
And here's my: +1 Kind regards Dominique On Sep 13, 2012, at 5:09 PM, Jukka Zitting wrote: > Hi, > > On Thu, Sep 6, 2012 at 9:37 PM, Philipp Marx (JIRA) wrote: >> Summary: MongoDB-based MicroKernel > > This is a pretty major new feature so I'd like us to vote on whether > we want to take over the maintenance and further development of this > code. If we agree, I'd also suggest that we invite Philipp Marx as the > original author of this code to join us as a Jackrabbit committer and > PMC member. > > So, please vote on accepting this "MongoMK" contribution and granting > committer and PMC member status Philipp Marx. This vote is open for > the next 72 hours. > >[ ] +1 Accept the MongoMK contribution and grant committer and PMC > member status to Philipp Marx >[ ] -1 Don't accept the codebase and/or grant committership, because... > > My vote is +1. > > BR, > > Jukka Zitting
EditorProvider after Oak construction
Hi, I’m working on an application packaged as an OSGI bundle that would perform some validation and store some auxiliary data in a node whenever a stream is saved in one of its properties, so I’m thinking on creating some CommitHook (or an EditorProvider) that would be able to compute the auxiliary property. Now comes the problem: in my setup, the Oak repository is created with some Hooks/Providers on startup, and AFAICS only Observer’s can be added/removed after that, is this correct? Thanks Dominique
Re: EditorProvider after Oak construction
Hi Jukka, On Jan 9, 2014, at 4:39 PM, Jukka Zitting wrote: > Hi, > > On Thu, Jan 9, 2014 at 10:29 AM, Dominique Pfister wrote: >> I’m working on an application packaged as an OSGI bundle that would perform >> some validation and >> store some auxiliary data in a node whenever a stream is saved in one of its >> properties, so I’m >> thinking on creating some CommitHook (or an EditorProvider) that would be >> able to compute >> the auxiliary property. > > An EditorProvider is probably better for this case, as it adds less > overhead than a full CommitHook. > >> Now comes the problem: in my setup, the Oak repository is created with some >> Hooks/Providers >> on startup, and AFAICS only Observer’s can be added/removed after that, is >> this correct? > > If you expose your EditorProvider as an OSGi service, Oak should > automatically pick it up and apply it to any new commits. At least > that's the intention; I'm not sure if the OSGi binding yet does that. Great news, that’s exactly what I hoped for! Cheers Dominique > > BR, > > Jukka Zitting
Re: EditorProvider after Oak construction
Hi again, My enthusiasm might have been a bit premature: there is actually a WhiteboardEditorProvider in Oak that will invoke all registered OSGI services of type EditorProvider, but it is unused (in contrast to e.g. WhiteboardAuthorizableActionProvider). Would a simple registration of this “special” EditorProvider in Oak.with(…) fix it? Thanks Dominique On Jan 9, 2014, at 4:54 PM, Dominique Pfister mailto:dpfis...@adobe.com>> wrote: Hi Jukka, On Jan 9, 2014, at 4:39 PM, Jukka Zitting mailto:jukka.zitt...@gmail.com>> wrote: Hi, On Thu, Jan 9, 2014 at 10:29 AM, Dominique Pfister mailto:dpfis...@adobe.com>> wrote: I’m working on an application packaged as an OSGI bundle that would perform some validation and store some auxiliary data in a node whenever a stream is saved in one of its properties, so I’m thinking on creating some CommitHook (or an EditorProvider) that would be able to compute the auxiliary property. An EditorProvider is probably better for this case, as it adds less overhead than a full CommitHook. Now comes the problem: in my setup, the Oak repository is created with some Hooks/Providers on startup, and AFAICS only Observer’s can be added/removed after that, is this correct? If you expose your EditorProvider as an OSGi service, Oak should automatically pick it up and apply it to any new commits. At least that's the intention; I'm not sure if the OSGi binding yet does that. Great news, that’s exactly what I hoped for! Cheers Dominique BR, Jukka Zitting
[jira] [Commented] (OAK-78) waitForCommit() test failure for MK remoting
[ https://issues.apache.org/jira/browse/OAK-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13264745#comment-13264745 ] Dominique Pfister commented on OAK-78: -- OK, but I'd expect that a change in a class's behavior will also update the associated javadoc. Removed obsolete description in revision 1332128. > waitForCommit() test failure for MK remoting > > > Key: OAK-78 > URL: https://issues.apache.org/jira/browse/OAK-78 > Project: Jackrabbit Oak > Issue Type: Bug > Components: mk >Reporter: Jukka Zitting >Assignee: Jukka Zitting >Priority: Minor > Fix For: 0.2 > > > The .mk.client.Client class is synchronized, which makes it fail the new > waitForCommit() integration test. > There doesn't seem to be any need for synchronization in Client (the server > should in any case be thread-safe), so I think we should just unsynchronize > the Client method. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-82) Running MicroKernelIT test with the InMem persistence creates a lot of GC threads
Dominique Pfister created OAK-82: Summary: Running MicroKernelIT test with the InMem persistence creates a lot of GC threads Key: OAK-82 URL: https://issues.apache.org/jira/browse/OAK-82 Project: Jackrabbit Oak Issue Type: Bug Affects Versions: 0.1 Reporter: Dominique Pfister Priority: Minor Fix For: 0.2 This is caused by MicroKernelImplFixture not disposing the MK instances it created -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-82) Running MicroKernelIT test with the InMem persistence creates a lot of GC threads
[ https://issues.apache.org/jira/browse/OAK-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Pfister resolved OAK-82. -- Resolution: Fixed Fixed in revision 139. > Running MicroKernelIT test with the InMem persistence creates a lot of GC > threads > - > > Key: OAK-82 > URL: https://issues.apache.org/jira/browse/OAK-82 > Project: Jackrabbit Oak > Issue Type: Bug >Affects Versions: 0.1 > Reporter: Dominique Pfister >Priority: Minor > Fix For: 0.2 > > > This is caused by MicroKernelImplFixture not disposing the MK instances it > created -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-56) File system abstraction
[ https://issues.apache.org/jira/browse/OAK-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267331#comment-13267331 ] Dominique Pfister commented on OAK-56: -- > On a related note, what's the status of the related o.a.j.mk.fs code in > oak-core? Unless we need more of the > functionality than we currently do > (one-liners in MicroKernelFactory and NodeMapInDb), I'd rather replace it > > with Commons IO or even just plain Java IO. I'd replace it with Commons IO and its FileUtils features: this is already in use in other projects (such as Jackrabbit itself) and much better tested. > If, as it sounds like, the code will mostly be needed for the MicroKernel > implementation, we should at least > move the o.a.j.mk.fs package from > oak-core to oak-mk. I don't see a need for this in the MicroKernel implementation: instead of moving it back into this project, I'd rather move it to oak-commons and rename the package to o.a.j.commons.fs, if Tom insists on keeping it. > File system abstraction > --- > > Key: OAK-56 > URL: https://issues.apache.org/jira/browse/OAK-56 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, mk >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Minor > > A file system abstraction allows to add new features (cross cutting concerns) > in a modular way, for example: > - detection and special behavior of out-of-disk space situation > - profiling and statistics over JMX > - re-try on file system problems > - encryption > - file system monitoring > - replication / real-time backup on the file system level (for clustering) > - caching (improved performance for CRX) > - allows to easily switch to faster file system APIs (FileChannel, memory > mapped files) > - debugging (for example, logging all file system operations) > - allows to implement s3 / hadoop / mongodb / ... file systems - not only by > us but from 3th party, possibly the end user > - zip file system (for example to support read-only, compressed repositories) > - testing: simulating out of disk space and out of memory (ensure the > repository doesn't corrupt in this case) > - testing: simulate very large files (using an in-memory file system) > - splitting very large files in 2 gb blocks (FAT and other file systems that > don't support large files) > - data compression (if needed) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-56) File system abstraction
[ https://issues.apache.org/jira/browse/OAK-56?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13267334#comment-13267334 ] Dominique Pfister commented on OAK-56: -- > commons and rename the package to o.a.j.commons.fs Sorry, should be o.a.j.oak.commons.fs, of course. > File system abstraction > --- > > Key: OAK-56 > URL: https://issues.apache.org/jira/browse/OAK-56 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, mk >Reporter: Thomas Mueller >Assignee: Thomas Mueller >Priority: Minor > > A file system abstraction allows to add new features (cross cutting concerns) > in a modular way, for example: > - detection and special behavior of out-of-disk space situation > - profiling and statistics over JMX > - re-try on file system problems > - encryption > - file system monitoring > - replication / real-time backup on the file system level (for clustering) > - caching (improved performance for CRX) > - allows to easily switch to faster file system APIs (FileChannel, memory > mapped files) > - debugging (for example, logging all file system operations) > - allows to implement s3 / hadoop / mongodb / ... file systems - not only by > us but from 3th party, possibly the end user > - zip file system (for example to support read-only, compressed repositories) > - testing: simulating out of disk space and out of memory (ensure the > repository doesn't corrupt in this case) > - testing: simulate very large files (using an in-memory file system) > - splitting very large files in 2 gb blocks (FAT and other file systems that > don't support large files) > - data compression (if needed) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-82) Running MicroKernelIT test with the InMem persistence creates a lot of GC threads
[ https://issues.apache.org/jira/browse/OAK-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13269615#comment-13269615 ] Dominique Pfister commented on OAK-82: -- Oops, that rationale slipped my attention even though it was explicitly documented: thanks for fixing that! > Running MicroKernelIT test with the InMem persistence creates a lot of GC > threads > - > > Key: OAK-82 > URL: https://issues.apache.org/jira/browse/OAK-82 > Project: Jackrabbit Oak > Issue Type: Bug >Affects Versions: 0.1 > Reporter: Dominique Pfister >Priority: Minor > Fix For: 0.2.1 > > > This is caused by MicroKernelImplFixture not disposing the MK instances it > created -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-107) testConcurrentMergeGC fails intermittently
[ https://issues.apache.org/jira/browse/OAK-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Pfister updated OAK-107: -- Attachment: stacktrace > testConcurrentMergeGC fails intermittently > -- > > Key: OAK-107 > URL: https://issues.apache.org/jira/browse/OAK-107 > Project: Jackrabbit Oak > Issue Type: Bug >Affects Versions: 0.2.1 > Reporter: Dominique Pfister > Attachments: stacktrace > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-107) testConcurrentMergeGC fails intermittently
Dominique Pfister created OAK-107: - Summary: testConcurrentMergeGC fails intermittently Key: OAK-107 URL: https://issues.apache.org/jira/browse/OAK-107 Project: Jackrabbit Oak Issue Type: Bug Affects Versions: 0.2.1 Reporter: Dominique Pfister Attachments: stacktrace -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-107) testConcurrentMergeGC fails intermittently
[ https://issues.apache.org/jira/browse/OAK-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Pfister updated OAK-107: -- Attachment: (was: stacktrace) > testConcurrentMergeGC fails intermittently > -- > > Key: OAK-107 > URL: https://issues.apache.org/jira/browse/OAK-107 > Project: Jackrabbit Oak > Issue Type: Bug >Affects Versions: 0.2.1 > Reporter: Dominique Pfister > Attachments: stacktrace.txt > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-107) testConcurrentMergeGC fails intermittently
[ https://issues.apache.org/jira/browse/OAK-107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Pfister updated OAK-107: -- Attachment: stacktrace.txt > testConcurrentMergeGC fails intermittently > -- > > Key: OAK-107 > URL: https://issues.apache.org/jira/browse/OAK-107 > Project: Jackrabbit Oak > Issue Type: Bug >Affects Versions: 0.2.1 > Reporter: Dominique Pfister > Attachments: stacktrace.txt > > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-138) Move client/server package in oak-mk to separate project
[ https://issues.apache.org/jira/browse/OAK-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Pfister updated OAK-138: -- Description: As a further cleanup step in OAK-13, I'd like to move the packages o.a.j.mk.client and o.a.j.mk.server and referenced classes in oak-mk to a separate project, e.g. oak-mk-remote. This new project will then be added as a dependency to: oak-core oak-run oak-it-mk was: As a further cleanup step in OAK-13, I'd like to move the packages o.a.j.oak.mk.client and o.a.j.oak.mk.server and referenced classes in oak-mk to a separate project, e.g. oak-mk-remote. This new project will then be added as a dependency to: oak-core oak-run oak-it-mk > Move client/server package in oak-mk to separate project > > > Key: OAK-138 > URL: https://issues.apache.org/jira/browse/OAK-138 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, it, mk, run >Affects Versions: 0.3 >Reporter: Dominique Pfister >Assignee: Dominique Pfister > > As a further cleanup step in OAK-13, I'd like to move the packages > o.a.j.mk.client and o.a.j.mk.server and referenced classes in oak-mk to a > separate project, e.g. oak-mk-remote. > This new project will then be added as a dependency to: > oak-core > oak-run > oak-it-mk -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-138) Move client/server package in oak-mk to separate project
Dominique Pfister created OAK-138: - Summary: Move client/server package in oak-mk to separate project Key: OAK-138 URL: https://issues.apache.org/jira/browse/OAK-138 Project: Jackrabbit Oak Issue Type: Improvement Components: core, it, mk, run Affects Versions: 0.3 Reporter: Dominique Pfister Assignee: Dominique Pfister As a further cleanup step in OAK-13, I'd like to move the packages o.a.j.oak.mk.client and o.a.j.oak.mk.server and referenced classes in oak-mk to a separate project, e.g. oak-mk-remote. This new project will then be added as a dependency to: oak-core oak-run oak-it-mk -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-138) Move client/server package in oak-mk to separate project
[ https://issues.apache.org/jira/browse/OAK-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13293559#comment-13293559 ] Dominique Pfister commented on OAK-138: --- -1 to merging as well: I prefer having an oak-mk-remote project with a concise name and a precise focus. > The log wrapper is a somewhat similar implementation. Hm, is there some other similarity besides that log wrapper and o.a.j.mk.client.Client both implement the MicroKernel interface? > Move client/server package in oak-mk to separate project > > > Key: OAK-138 > URL: https://issues.apache.org/jira/browse/OAK-138 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, it, mk, run >Affects Versions: 0.3 > Reporter: Dominique Pfister >Assignee: Dominique Pfister > > As a further cleanup step in OAK-13, I'd like to move the packages > o.a.j.mk.client and o.a.j.mk.server and referenced classes in oak-mk to a > separate project, e.g. oak-mk-remote. > This new project will then be added as a dependency to: > oak-core > oak-run > oak-it-mk -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-138) Move client/server package in oak-mk to separate project
[ https://issues.apache.org/jira/browse/OAK-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13294366#comment-13294366 ] Dominique Pfister commented on OAK-138: --- @Thomas: I agree that other MK implementations may benefit from such a refactoring into at least one project (e.g. oak-mk-commons or oak-mk-base). Nevertheless, this issue is about moving the remote classes into a separate project, as oak-mk does not depend on them (opposed to data store, jsop or cache), so IMHO this is a topic for another issue. I think Jukka's right about the requirement for a separate MK API project, therefore: +1 for oak-mk-remote +1 for oak-mk-api > Move client/server package in oak-mk to separate project > > > Key: OAK-138 > URL: https://issues.apache.org/jira/browse/OAK-138 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, it, mk, run >Affects Versions: 0.3 >Reporter: Dominique Pfister >Assignee: Dominique Pfister > > As a further cleanup step in OAK-13, I'd like to move the packages > o.a.j.mk.client and o.a.j.mk.server and referenced classes in oak-mk to a > separate project, e.g. oak-mk-remote. > This new project will then be added as a dependency to: > oak-core > oak-run > oak-it-mk -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-138) Move client/server package in oak-mk to separate project
[ https://issues.apache.org/jira/browse/OAK-138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Pfister resolved OAK-138. --- Resolution: Fixed Added a separate oak-mk-api component, and refactored client/server to oak-mk-remote, as discussed. > Move client/server package in oak-mk to separate project > > > Key: OAK-138 > URL: https://issues.apache.org/jira/browse/OAK-138 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, it, mk, run >Affects Versions: 0.3 > Reporter: Dominique Pfister > Assignee: Dominique Pfister > > As a further cleanup step in OAK-13, I'd like to move the packages > o.a.j.mk.client and o.a.j.mk.server and referenced classes in oak-mk to a > separate project, e.g. oak-mk-remote. > This new project will then be added as a dependency to: > oak-core > oak-run > oak-it-mk -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-114) MicroKernel API: specify retention policy for old revisions
[ https://issues.apache.org/jira/browse/OAK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406910#comment-13406910 ] Dominique Pfister commented on OAK-114: --- The javadoc is possibly not clear enough: a revision returned by getHeadRevision remains accessible for _at least_ 10 minutes or _even longer_ if it is still the head revision, regardless of the time it was committed. So in Jukka's snippet above, the getNodes call wouldn't fail, because only 10 minutes passed. Anyway, I think we really need some performance figures first, before we can decide whether this policy is too aggressive. OTOH, the current GC logic is quite small and straightforward, so it shouldn't be difficult to change it at a later time if need arises. > MicroKernel API: specify retention policy for old revisions > --- > > Key: OAK-114 > URL: https://issues.apache.org/jira/browse/OAK-114 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mk >Reporter: Stefan Guggisberg >Assignee: Stefan Guggisberg > Attachments: OAK-114.patch > > > the MicroKernel API javadoc should specify the minimal guaranteed retention > period for old revisions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (OAK-114) MicroKernel API: specify retention policy for old revisions
[ https://issues.apache.org/jira/browse/OAK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13406910#comment-13406910 ] Dominique Pfister edited comment on OAK-114 at 7/5/12 8:30 AM: --- The javadoc is possibly not clear enough: a revision returned by getHeadRevision remains accessible for _at least_ 10 minutes or _even longer_ if it is still the head revision, regardless of the time it was committed. So in Jukka's snippet above, the getNodes call wouldn't fail, because only 5 minutes passed. Anyway, I think we really need some performance figures first, before we can decide whether this policy is too aggressive. OTOH, the current GC logic is quite small and straightforward, so it shouldn't be difficult to change it at a later time if need arises. was (Author: dpfister): The javadoc is possibly not clear enough: a revision returned by getHeadRevision remains accessible for _at least_ 10 minutes or _even longer_ if it is still the head revision, regardless of the time it was committed. So in Jukka's snippet above, the getNodes call wouldn't fail, because only 10 minutes passed. Anyway, I think we really need some performance figures first, before we can decide whether this policy is too aggressive. OTOH, the current GC logic is quite small and straightforward, so it shouldn't be difficult to change it at a later time if need arises. > MicroKernel API: specify retention policy for old revisions > --- > > Key: OAK-114 > URL: https://issues.apache.org/jira/browse/OAK-114 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mk >Reporter: Stefan Guggisberg >Assignee: Stefan Guggisberg > Attachments: OAK-114.patch > > > the MicroKernel API javadoc should specify the minimal guaranteed retention > period for old revisions. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-114) MicroKernel API: specify retention policy for old revisions
[
https://issues.apache.org/jira/browse/OAK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13407201#comment-13407201
]
Dominique Pfister commented on OAK-114:
---
bq.{quote} If we are keeping track of when a particular revision was last
returned by getHeadRevision, wouldn't it be simple to use the same mechanism to
also keep track of when revisions are returned from or passed to other
MicroKernel methods? I don't see how that would imply any more "complex state
management" than what's already needed.{quote}
If we just remember the earliest revision returned by getHeadRevision, we need
just one field and the next GC cycle can skip all revisions committed later. If
we remember all revisions accessed, we'll end up with some possibly sparse list
of revisions, and the GC cycle would need to re-link these revisions - modify
parent commit, re-calculate diff - to get a consistent view.
bq.{quote} The benefit of switching from "last returned as head revision" to
"last accessed/seen" for figuring out when a revision is still needed is that
we can allow unused revisions expire much faster. With the "last accessed/seen"
pattern there'll be no problem with an expiry time of just a few seconds, which
would in most cases allow the garbage collector to be much more aggressive than
with the 10 minute time proposed here.{quote}
I can see the advantage, but this would leave the door open for some bogus
polling client that keeps some very old revision alive, which I'd like to avoid.
> MicroKernel API: specify retention policy for old revisions
> ---
>
> Key: OAK-114
> URL: https://issues.apache.org/jira/browse/OAK-114
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mk
>Reporter: Stefan Guggisberg
>Assignee: Stefan Guggisberg
> Attachments: OAK-114.patch
>
>
> the MicroKernel API javadoc should specify the minimal guaranteed retention
> period for old revisions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (OAK-114) MicroKernel API: specify retention policy for old revisions
[
https://issues.apache.org/jira/browse/OAK-114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13407201#comment-13407201
]
Dominique Pfister edited comment on OAK-114 at 7/5/12 3:24 PM:
---
bq. If we are keeping track of when a particular revision was last returned by
getHeadRevision, wouldn't it be simple to use the same mechanism to also keep
track of when revisions are returned from or passed to other MicroKernel
methods? I don't see how that would imply any more "complex state management"
than what's already needed.
If we just remember the earliest revision returned by getHeadRevision, we need
just one field and the next GC cycle can skip all revisions committed later. If
we remember all revisions accessed, we'll end up with some possibly sparse list
of revisions, and the GC cycle would need to re-link these revisions - modify
parent commit, re-calculate diff - to get a consistent view.
bq. The benefit of switching from "last returned as head revision" to "last
accessed/seen" for figuring out when a revision is still needed is that we can
allow unused revisions expire much faster. With the "last accessed/seen"
pattern there'll be no problem with an expiry time of just a few seconds, which
would in most cases allow the garbage collector to be much more aggressive than
with the 10 minute time proposed here.
I can see the advantage, but this would leave the door open for some bogus
polling client that keeps some very old revision alive, which I'd like to avoid.
was (Author: dpfister):
bq.{quote} If we are keeping track of when a particular revision was last
returned by getHeadRevision, wouldn't it be simple to use the same mechanism to
also keep track of when revisions are returned from or passed to other
MicroKernel methods? I don't see how that would imply any more "complex state
management" than what's already needed.{quote}
If we just remember the earliest revision returned by getHeadRevision, we need
just one field and the next GC cycle can skip all revisions committed later. If
we remember all revisions accessed, we'll end up with some possibly sparse list
of revisions, and the GC cycle would need to re-link these revisions - modify
parent commit, re-calculate diff - to get a consistent view.
bq.{quote} The benefit of switching from "last returned as head revision" to
"last accessed/seen" for figuring out when a revision is still needed is that
we can allow unused revisions expire much faster. With the "last accessed/seen"
pattern there'll be no problem with an expiry time of just a few seconds, which
would in most cases allow the garbage collector to be much more aggressive than
with the 10 minute time proposed here.{quote}
I can see the advantage, but this would leave the door open for some bogus
polling client that keeps some very old revision alive, which I'd like to avoid.
> MicroKernel API: specify retention policy for old revisions
> ---
>
> Key: OAK-114
> URL: https://issues.apache.org/jira/browse/OAK-114
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mk
>Reporter: Stefan Guggisberg
>Assignee: Stefan Guggisberg
> Attachments: OAK-114.patch
>
>
> the MicroKernel API javadoc should specify the minimal guaranteed retention
> period for old revisions.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-187) ConcurrentModificationException during gc run
[
https://issues.apache.org/jira/browse/OAK-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominique Pfister resolved OAK-187.
---
Resolution: Fixed
Assignee: Dominique Pfister
Fixed in revision 1365621.
> ConcurrentModificationException during gc run
> -
>
> Key: OAK-187
> URL: https://issues.apache.org/jira/browse/OAK-187
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mk
>Reporter: Michael Dürig
> Assignee: Dominique Pfister
>
> I sporadically encounter a {{ConcurrentModificationException}} when building
> with {{-PintegrationTesting}}. This happens while the {{JcrTckTest}} suite
> runs and is only printed to the console. No tests fail.
> {code}
> Running org.apache.jackrabbit.oak.jcr.JcrTckIT
> java.util.ConcurrentModificationException
> at java.util.TreeMap$PrivateEntryIterator.nextEntry(TreeMap.java:1100)
> at java.util.TreeMap$EntryIterator.next(TreeMap.java:1136)
> at java.util.TreeMap$EntryIterator.next(TreeMap.java:1131)
> at
> org.apache.jackrabbit.mk.store.DefaultRevisionStore.markBranches(DefaultRevisionStore.java:562)
> at
> org.apache.jackrabbit.mk.store.DefaultRevisionStore.gc(DefaultRevisionStore.java:498)
> at
> org.apache.jackrabbit.mk.store.DefaultRevisionStore$2.run(DefaultRevisionStore.java:160)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
> at
> java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:680)
> Tests run: 1906, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 65.443 sec
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (OAK-231) Support for large child node lists.
Dominique Pfister created OAK-231: - Summary: Support for large child node lists. Key: OAK-231 URL: https://issues.apache.org/jira/browse/OAK-231 Project: Jackrabbit Oak Issue Type: Improvement Components: mk Reporter: Dominique Pfister Assignee: Dominique Pfister -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OAK-231) Support for large child node lists
[ https://issues.apache.org/jira/browse/OAK-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Pfister updated OAK-231: -- Summary: Support for large child node lists (was: Support for large child node lists.) > Support for large child node lists > -- > > Key: OAK-231 > URL: https://issues.apache.org/jira/browse/OAK-231 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mk > Reporter: Dominique Pfister > Assignee: Dominique Pfister > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OAK-216) Occasional org.apache.jackrabbit.mk.store.NotFoundExceptions
[
https://issues.apache.org/jira/browse/OAK-216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominique Pfister resolved OAK-216.
---
Resolution: Fixed
Assignee: Dominique Pfister
Issue was caused by a wrong assumption in the GC, that all branches are
uniquely identifiable by their branch root id, which is wrong, as one can
create two branches of the same commit.
> Occasional org.apache.jackrabbit.mk.store.NotFoundExceptions
>
>
> Key: OAK-216
> URL: https://issues.apache.org/jira/browse/OAK-216
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mk
>Reporter: Jukka Zitting
> Assignee: Dominique Pfister
>
> Every now and then our builds fail with one or another of the JCR TCK tests
> failing due to a {{org.apache.jackrabbit.mk.store.NotFoundException}} being
> thrown on some revision in the MicroKernel.
> Since the garbage collector is currently only instructed to remove revisions
> that are over 60 minutes old, such lost revisions should never occur in
> normal builds.
> The following change to line 163 of {{DefaultRevisionStore.java}} makes the
> problem easy to reproduce reliably, which strongly suggests that this problem
> indeed is caused or at least triggered by the garbage collector:
> {code}
> -}, 60, 60, TimeUnit.SECONDS);
> +}, 1, 1, TimeUnit.SECONDS);
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-5) JCR bindings for Oak
[
https://issues.apache.org/jira/browse/OAK-5?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13227428#comment-13227428
]
Dominique Pfister commented on OAK-5:
-
What about this, Tom: I use Eclipse, too, and if I "mvn eclipse:eclipse" the
parent project and open it, it will automatically open all submodules (with the
correct build inter-dependencies) and allow me to move classes from one module
to the other. Would that work for you?
> JCR bindings for Oak
>
>
> Key: OAK-5
> URL: https://issues.apache.org/jira/browse/OAK-5
> Project: Jackrabbit Oak
> Issue Type: New Feature
>Reporter: Jukka Zitting
> Labels: jcr
> Fix For: 0.1
>
>
> One of the proposed goals for the 0.1 release is at least a basic JCR binding
> for Oak. Most of that already exists in /jackrabbit/sandbox, we just need to
> decide where and how to place it in Oak. I think we should either put it all
> under o.a.j.oak.jcr in oak-core, or create a separate oak-jcr component for
> the JCR binding.
> As for functionality, it would be nice if the JCR binding was able to do at
> least the following:
> {code}
> Repository repository = JcrUtils.getRepository(...);
> Session session = repository.login(...);
> try {
> // Create
> session.getRootNode().addNode("hello")
> .setProperty("world", "hello world");
> session.save();
> // Read
> assertEquals(
> "hello world",
> session.getProperty("/hello/world").getString());
> // Update
> session.getNode("/hello").setProperty("world", "Hello, World!");
> session.save();
> assertEquals(
> "Hello, World!",
> session.getProperty("/hello/world").getString());
> // Delete
> session.getNode("/hello").delete();
> session.save();
> assertTrue(!session.propertyExists("/hello/world"));
> } finally {
> create.logout();
> }
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-13) Cleanup org.apache.jackrabbit.mk
[ https://issues.apache.org/jira/browse/OAK-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13229144#comment-13229144 ] Dominique Pfister commented on OAK-13: -- I can comment on the packages/classes I created: o.a.j.mk.cluster: there's not much going on here and I can delete that o.a.j.mk.client/server: these contain code for exposing/accessing an MK implementation over HTTP, along with some static resources that provide a very simple browser interface, where every method of the MicroKernel interface is mapped to some HTML page with a form that can be submitted to actually invoke the method on the running MK, which I originally created to get acquainted with the MK API. Not sure whether we want to keep this. > Cleanup org.apache.jackrabbit.mk > > > Key: OAK-13 > URL: https://issues.apache.org/jira/browse/OAK-13 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: angela > > imo we should clean up the org.apache.jackrabbit.mk.* packages that are > currently > located in the oak-core module. > for me it is really hard to destinguish between code that is really part of > the > productive code base for the oak project and code that is purely experimental > chunk and leftover. > in order to become familiar with the code that would be helpful for me and > anybody else that will contribute to the project. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OAK-53) exclude longer running tests in the default maven profile
[ https://issues.apache.org/jira/browse/OAK-53?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250629#comment-13250629 ] Dominique Pfister commented on OAK-53: -- +1 IMO, long running tests are a PITA, and drives me to make local changes to ignore them or even skip the whole test suite. I definitely prefer to exclude such tests in the default profile. > exclude longer running tests in the default maven profile > - > > Key: OAK-53 > URL: https://issues.apache.org/jira/browse/OAK-53 > Project: Jackrabbit Oak > Issue Type: Test >Reporter: Stefan Guggisberg > > the current maven build using the default profile takes ~3min on my machine > which is IMO way too long. > 'mvn clean install' should IMO allow quick turn around cycles during > development and finish within a couple of seconds. > requiring the developers to use a custom maven profile dring development (as > suggested in OAK-52) is IMO not acceptable. custom profiles are hard to > remember when working on different projects. > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
