Re: svn commit: r1583285 - /jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/value/ValueImpl.java
Hi, On Tue, Apr 1, 2014 at 9:29 AM, Michael Dürig mdue...@apache.org wrote: 3rd try: http://svn.apache.org/r1583661 Looks good, thanks! On Mon, Mar 31, 2014 at 11:56 PM, Chetan Mehrotra chetan.mehro...@gmail.com wrote: +1. I also missed getting a clean way to get blobId from Blob. So adding this method would be useful in other cases also The getContentIdentity() method has a specific contract and the return value should generally not be interpreted as a referenceable identifier. If you need a method that exposes the blobId, it would be best to add a separate method for that. But note that not all Blob implementations have a blobId like in BlobStoreBlob. BR, Jukka Zitting
Re: svn commit: r1577449 - in /jackrabbit/oak/trunk/oak-core/src: main/java/org/apache/jackrabbit/oak/plugins/segment/ main/java/org/apache/jackrabbit/oak/plugins/segment/file/ main/java/org/apache/ja
On Wed, Apr 2, 2014 at 11:36 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: I consider this an unfortunate recent development. Not sure. There are some deployment scenarios where a shared FileDataStore is a must requirement and thus we need to support cases where blobs can be stored separately from node data. Yes it adds to the complexity of backup but then such a feature is required then that cost has to be paid. Default setups currently do not use FileDataStore or BlobStore with SegmentNodeStore. So as per defaults original design is still honored. Chetan Mehrotra
Re: svn commit: r1583285 - /jackrabbit/oak/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/value/ValueImpl.java
On Wed, Apr 2, 2014 at 12:18 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: The getContentIdentity() method has a specific contract and the return value should generally not be interpreted as a referenceable identifier. Ack. If you need a method that exposes the blobId, it would be best to add a separate method for that. But note that not all Blob implementations have a blobId like in BlobStoreBlob. For now there is no strong requirement for that. If need arises would follow up this way Chetan Mehrotra
jackrabbit-oak build #3984: Broken
Build Update for apache/jackrabbit-oak - Build: #3984 Status: Broken Duration: 225 seconds Commit: 80a80e69175ce237ac586a7acd51177694879c08 (trunk) Author: Chetan Mehrotra Message: OAK-1295 - Recovery for missing _lastRev updates (WIP) Added specific method for acquiring recovery lock and releasing recovery lock. For Mongo the acquire logic use a conditional update git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1583890 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/bb72c07081bb...80a80e69175c View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/22079781 -- sent by Jukka's Travis notification gateway
Re: svn commit: r1577449 - in /jackrabbit/oak/trunk/oak-core/src: main/java/org/apache/jackrabbit/oak/plugins/segment/ main/java/org/apache/jackrabbit/oak/plugins/segment/file/ main/java/org/apache/ja
On 2.4.14 8:06 , Jukka Zitting wrote: Hi, On Mon, Mar 31, 2014 at 11:59 PM, Chetan Mehrotra chetan.mehro...@gmail.com wrote: Why the . extra subdirectory? The repository home folder is used by various components in Oak. I consider this an unfortunate recent development. Most parts in Oak have explicitly been designed to store all content and configuration within the NodeStore/MicroKernel, which is why we're able to localize all clustering, backup and other such concerns within those backend implementations. That design gets broken if components start storing data separately in the repository folder. I double that. Everything is content was and IMO should still be a key driver for the design. Michael BR, Jukka Zitting
jackrabbit-oak build #3985: Broken
Build Update for apache/jackrabbit-oak - Build: #3985 Status: Broken Duration: 286 seconds Commit: 10c89f108d2c1e9cbd440860f1f2e590b2ee3760 (trunk) Author: Chetan Mehrotra Message: OAK-1295 - Recovery for missing _lastRev updates (WIP) Fix the not query for acquiring lock git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1583891 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/80a80e69175c...10c89f108d2c View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/22079793 -- sent by Jukka's Travis notification gateway
jackrabbit-oak build #3986: Broken
Build Update for apache/jackrabbit-oak - Build: #3986 Status: Broken Duration: 273 seconds Commit: f02dd6b4943b85ec2365c6dc950ee414ada1b394 (trunk) Author: Chetan Mehrotra Message: OAK-1295 - Recovery for missing _lastRev updates (WIP) Refactor -- to use enum for string constant -- clock handling moved to single method -- Strongly type getters for property git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1583892 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/10c89f108d2c...f02dd6b4943b View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/22079797 -- sent by Jukka's Travis notification gateway
jackrabbit-oak build #3984: Broken
Build Update for apache/jackrabbit-oak - Build: #3984 Status: Broken Duration: 1657 seconds Commit: bb72c07081bb79a746dc01571e19948ba3f060c4 (trunk) Author: Chetan Mehrotra Message: OAK-1295 - Recovery for missing _lastRev updates (WIP) Moving common methods to Utils -- Moving timestampToString to Utils -- Adding closeIfCloseable to close objects of types closeable. -- Remove unused methods git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1583889 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/4b1db7cc7ea8...bb72c07081bb View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/22079782 -- sent by Jukka's Travis notification gateway
Re: svn commit: r1577449 - in /jackrabbit/oak/trunk/oak-core/src: main/java/org/apache/jackrabbit/oak/plugins/segment/ main/java/org/apache/jackrabbit/oak/plugins/segment/file/ main/java/org/apache/ja
On 02/04/2014 07:48, Chetan Mehrotra wrote: On Wed, Apr 2, 2014 at 11:36 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: I consider this an unfortunate recent development. Not sure. There are some deployment scenarios where a shared FileDataStore is a must requirement and thus we need to support cases where blobs can be stored separately from node data. Yes it adds to the complexity of backup but then such a feature is required then that cost has to be paid. I back this. Sharing immutable blobs between instances is a must have for big repositories. I know that with mongo you can shard etc, but still you're duplicating the space (other that there are functionalities that address this in mongo). Backup will have to be arranged separately with something like rsync or netapp snapshots, etc. D.
jackrabbit-oak build #3987: Errored
Build Update for apache/jackrabbit-oak - Build: #3987 Status: Errored Duration: 3002 seconds Commit: 67c04d7ecc5181ea0096e33b5bbddbe2f94236ee (trunk) Author: Chetan Mehrotra Message: OAK-1295 - Recovery for missing _lastRev updates (WIP) Refactored to use new methods git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1583893 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/f02dd6b4943b...67c04d7ecc51 View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/22079810 -- sent by Jukka's Travis notification gateway
Re: svn commit: r1577449 - in /jackrabbit/oak/trunk/oak-core/src: main/java/org/apache/jackrabbit/oak/plugins/segment/ main/java/org/apache/jackrabbit/oak/plugins/segment/file/ main/java/org/apache/ja
On 02 Apr 2014, at 08:06, Jukka Zitting jukka.zitt...@gmail.commailto:jukka.zitt...@gmail.com wrote: That design gets broken if components start storing data separately in the repository folder. Agree with that design principle, but the (shared) file system DS is a valid exception IMO (same for the S3 DS). Later we would probably store the config files when using Oak outside of std OSGi env like with PojoSR @Chetan: why would the configs not be stored in the repo? I do not see how this relates to non-OSGi environments
Question regarding missing _lastRev recovery - OAK-1295
Hi, How do we expose _lastRev recovery operation? This would need to check all the cluster nodes info and run recovery for those nodes which need recovery. 1. We either have a scheduled job which checks all the nodes and run the recovery. What should be the interval to trigger the job? 2. Or if we want it run only when triggered manually, then expose an appropriate MBean. Thanks Amit
RE: Question regarding missing _lastRev recovery - OAK-1295
Hi, I think the recovery should be triggered automatically by the system when: 1) a cluster node starts up and sees it didn't shut down properly. I'm not sure this information is available, but remember we discussed this once. 2) a cluster node sees a lease timeout of another cluster node and initiates the recovery for the failed cluster node. this check could be done in the background operations thread on a regular basis. probably depending on the lease interval. In addition it would probably also be useful to have the recovery operation available as a command in oak-run. that way you can manually trigger it from the command line. WDYT? Regards Marcel How do we expose _lastRev recovery operation? This would need to check all the cluster nodes info and run recovery for those nodes which need recovery. 1. We either have a scheduled job which checks all the nodes and run the recovery. What should be the interval to trigger the job? 2. Or if we want it run only when triggered manually, then expose an appropriate MBean. Thanks Amit
jackrabbit-oak build #3990: Passed
Build Update for apache/jackrabbit-oak - Build: #3990 Status: Passed Duration: 2483 seconds Commit: 28bd58f599ccc5a5ecaf28dec700fd80373b59e3 (trunk) Author: Marcel Reutegger Message: OAK-1663: Long running RevisionTest Reset lastTimestamp to current time millis when clock is unset git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1583944 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/faba951c0ffc...28bd58f599cc View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/22089286 -- sent by Jukka's Travis notification gateway
Re: Question regarding missing _lastRev recovery - OAK-1295
Hi, 1) a cluster node starts up and sees it didn't shut down properly. I'm not sure this information is available, but remember we discussed this once. Yes, this case has been taken care of in the startup. this check could be done in the background operations thread on a regular basis. probably depending on the lease interval. The lease time is set to 1 minute. Would it be ok to check this every minute, from every node? Thanks Amit On Wed, Apr 2, 2014 at 4:14 PM, Marcel Reutegger mreut...@adobe.com wrote: Hi, I think the recovery should be triggered automatically by the system when: 1) a cluster node starts up and sees it didn't shut down properly. I'm not sure this information is available, but remember we discussed this once. 2) a cluster node sees a lease timeout of another cluster node and initiates the recovery for the failed cluster node. this check could be done in the background operations thread on a regular basis. probably depending on the lease interval. In addition it would probably also be useful to have the recovery operation available as a command in oak-run. that way you can manually trigger it from the command line. WDYT? Regards Marcel How do we expose _lastRev recovery operation? This would need to check all the cluster nodes info and run recovery for those nodes which need recovery. 1. We either have a scheduled job which checks all the nodes and run the recovery. What should be the interval to trigger the job? 2. Or if we want it run only when triggered manually, then expose an appropriate MBean. Thanks Amit
Re: Question regarding missing _lastRev recovery - OAK-1295
The lease time is set to 1 minute. Would it be ok to check this every minute, from every node? Adding to that the default time intervals are - asyncDelay = 1 sec - The background operation are performed every 1 sec per cluster node. If nothing changes we would fire 1query/sec/cluster node to check the head revision - cluster lease time = 1 min - This is the time after a cluster lease would be renewed. So we need to decide the time interval for Job for detecting recovery condition Chetan Mehrotra On Wed, Apr 2, 2014 at 4:31 PM, Amit Jain am...@ieee.org wrote: Hi, 1) a cluster node starts up and sees it didn't shut down properly. I'm not sure this information is available, but remember we discussed this once. Yes, this case has been taken care of in the startup. this check could be done in the background operations thread on a regular basis. probably depending on the lease interval. The lease time is set to 1 minute. Would it be ok to check this every minute, from every node? Thanks Amit On Wed, Apr 2, 2014 at 4:14 PM, Marcel Reutegger mreut...@adobe.com wrote: Hi, I think the recovery should be triggered automatically by the system when: 1) a cluster node starts up and sees it didn't shut down properly. I'm not sure this information is available, but remember we discussed this once. 2) a cluster node sees a lease timeout of another cluster node and initiates the recovery for the failed cluster node. this check could be done in the background operations thread on a regular basis. probably depending on the lease interval. In addition it would probably also be useful to have the recovery operation available as a command in oak-run. that way you can manually trigger it from the command line. WDYT? Regards Marcel How do we expose _lastRev recovery operation? This would need to check all the cluster nodes info and run recovery for those nodes which need recovery. 1. We either have a scheduled job which checks all the nodes and run the recovery. What should be the interval to trigger the job? 2. Or if we want it run only when triggered manually, then expose an appropriate MBean. Thanks Amit
Re: svn commit: r1577449 - in /jackrabbit/oak/trunk/oak-core/src: main/java/org/apache/jackrabbit/oak/plugins/segment/ main/java/org/apache/jackrabbit/oak/plugins/segment/file/ main/java/org/apache/ja
@Chetan: why would the configs not be stored in the repo? I do not see how this relates to non-OSGi environments Well thats the basic config required to configure DocumentNodeStore/SegmentNodeStore. These config cannot be stored as content. Other settings like security related config currently is not read from NodeStore and in OSGi env is being provided by OSGi ConfigAdmin. And more other settings like Index are currently stored as content Chetan Mehrotra On Wed, Apr 2, 2014 at 3:49 PM, Michael Marth mma...@adobe.com wrote: On 02 Apr 2014, at 08:06, Jukka Zitting jukka.zitt...@gmail.commailto:jukka.zitt...@gmail.com wrote: That design gets broken if components start storing data separately in the repository folder. Agree with that design principle, but the (shared) file system DS is a valid exception IMO (same for the S3 DS). Later we would probably store the config files when using Oak outside of std OSGi env like with PojoSR @Chetan: why would the configs not be stored in the repo? I do not see how this relates to non-OSGi environments
jackrabbit-oak build #3991: Passed
Build Update for apache/jackrabbit-oak - Build: #3991 Status: Passed Duration: 2596 seconds Commit: 3b8b4c7ff1b6a97b1867c96a9250488fec2351dc (trunk) Author: Alexandru Parvulescu Message: OAK-1664 org.apache.jackrabbit.oak.namepath package missing package-info file git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1583947 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/28bd58f599cc...3b8b4c7ff1b6 View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/22090087 -- sent by Jukka's Travis notification gateway
jackrabbit-oak build #3992: Passed
Build Update for apache/jackrabbit-oak - Build: #3992 Status: Passed Duration: 2609 seconds Commit: 3efb5cbfa81d2f770445ba2027ccc8e954f15c95 (trunk) Author: Marcel Reutegger Message: OAK-1662: Node not accessible after document split git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1583951 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/3b8b4c7ff1b6...3efb5cbfa81d View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/22091348 -- sent by Jukka's Travis notification gateway
jackrabbit-oak build #3994: Broken
Build Update for apache/jackrabbit-oak - Build: #3994 Status: Broken Duration: 2194 seconds Commit: 0e0a47ec387626e494a65dd143e3a25a3d004abe (trunk) Author: Julian Reschke Message: OAK-1533 - remove JDBC URL specific constructors from -core git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1583981 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/1402e7db17c0...0e0a47ec3876 View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/22096647 -- sent by Jukka's Travis notification gateway
Re: jackrabbit-oak build #3994: Broken
Test case failure on oak-solr Failed tests: testOffsetAndLimit(org.apache.jackrabbit.core.query.LimitAndOffsetTest): expected:1 but was:0 testOffsetAndLimitWithGetSize(org.apache.jackrabbit.core.query.LimitAndOffsetTest): expected:2 but was:0 Chetan Mehrotra On Wed, Apr 2, 2014 at 6:04 PM, Travis CI ju...@apache.org wrote: Build Update for apache/jackrabbit-oak - Build: #3994 Status: Broken Duration: 2194 seconds Commit: 0e0a47ec387626e494a65dd143e3a25a3d004abe (trunk) Author: Julian Reschke Message: OAK-1533 - remove JDBC URL specific constructors from -core git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1583981 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/1402e7db17c0...0e0a47ec3876 View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/22096647 -- sent by Jukka's Travis notification gateway
Re: jackrabbit-oak build #3994: Broken
ignored the test for now (r1584015) Tommaso 2014-04-02 14:48 GMT+02:00 Chetan Mehrotra chetan.mehro...@gmail.com: Test case failure on oak-solr Failed tests: testOffsetAndLimit(org.apache.jackrabbit.core.query.LimitAndOffsetTest): expected:1 but was:0 testOffsetAndLimitWithGetSize(org.apache.jackrabbit.core.query.LimitAndOffsetTest): expected:2 but was:0 Chetan Mehrotra On Wed, Apr 2, 2014 at 6:04 PM, Travis CI ju...@apache.org wrote: Build Update for apache/jackrabbit-oak - Build: #3994 Status: Broken Duration: 2194 seconds Commit: 0e0a47ec387626e494a65dd143e3a25a3d004abe (trunk) Author: Julian Reschke Message: OAK-1533 - remove JDBC URL specific constructors from -core git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@158398113f79535-47bb- 0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/1402e7db17c0...0e0a47ec3876 View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/22096647 -- sent by Jukka's Travis notification gateway
Re: svn commit: r1583994 - in /jackrabbit/oak/trunk/oak-core/src: main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/OakFileDataStore.java test/java/org/apache/jackrabbit/oak/plugins/blob/data
Hi, On Wed, Apr 2, 2014 at 8:25 AM, chet...@apache.org wrote: +//TODO FIXME Temporary workaround for OAK-1666. Override the default +//synchronized map with a Noop. This should be removed when fix +//for JCR-3764 is part of release. +inUse = new NoOpMapDataIdentifier, WeakReferenceDataIdentifier(); This breaks the following client: Binary binary = session.getValueFactory().createBinary(...); // wait over a garbage collection cycle session.getRootNode().setProperty(foo, binary); session.save(); Note that the wait in between could be anything, in the worst case just bad timing or more likely some other long-running statements like waiting for user input or creating other large binaries. The inUse map is in FileDataStore for a reason. If it's causing performance issues, the right solution is *not* to just disable it but rather to figure out how the same functionality could be achieved more efficiently. BR, Jukka Zitting
Re: svn commit: r1583994 - in /jackrabbit/oak/trunk/oak-core/src: main/java/org/apache/jackrabbit/oak/plugins/blob/datastore/OakFileDataStore.java test/java/org/apache/jackrabbit/oak/plugins/blob/data
On Wed, Apr 2, 2014 at 6:30 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: The inUse map is in FileDataStore for a reason. Ack. From what I have understood from Blob GC logic in Oak is that it relies on blob last modified value to distinguish between active used blobs. So for performing GC only those blob would be considered whose lastModified value is say 1 day. Only these blobs would be candidate for deletion. This ensures that any blob created in transient space are not considered for GC. So current logic does make an assumption that 1 day is sufficient time and hence not foolproof. However the current impl of inUse would probably only work for a single node system and would fail for shared DataStore scenario as its an in memory state and its hard to determine inUse state for whole cluster. For supporting such case we would have to rely on lastModified time interval to distinguish between active used blobs regards Chetan Chetan Mehrotra
Oak 1.0 (and 0.20) release plan
Hi, We've done a lot of stuff over the past two years and many parts of Oak are already good enough for production use, so I think we should start preparing for our 1.0 release. Our original plan was to target for Jackrabbit 3.0 [1] but given the problems we encountered [2] I think it would make more sense to do separate Jackrabbit 2.8 and Oak 1.0 releases now, and revisit the idea of a unified Jackrabbit 3.0 release once the dust settles. With that background, here's my suggestion for a Oak 1.0 release plan: * Cut Oak 0.20 from trunk already this week to get a clear branch point * Create a 1.0 branch from that point, with version number to 1.0-SNAPSHOT - this will be our release branch, with focus on stability - all changes should go first to trunk, and merged to 1.0 only after extra review - if needed, we can cut a few more 0.2x releases from the branch - when everything looks good, we cut Oak 1.0.0 from the branch - afterwards the branch will be used for 1.0.x maintenance releases * Update trunk version to 1.1-SNAPSHOT - normal development may continue in the trunk - any changes should remain backwards compatibile with 1.0 [1] http://markmail.org/message/u7dsue7ezb4cd4ox [2] http://markmail.org/message/lgvbvw742zryhlmp BR, Jukka Zitting
Re: roadmap update
Hi, On Fri, Mar 28, 2014 at 5:59 AM, Lukas Kahwe Smith sm...@pooteeweet.org wrote: would be nice to get an update on the roadmap of Oak. Good point, and thanks for the reminder! See [1] for suggested plan to Oak 1.0, and [2] for the bigger Jackrabbit picture. [1] http://markmail.org/message/6kkkdmyf6ni5pgte [2] http://markmail.org/message/yydr4ry7m3tmjinf BR, Jukka Zitting
jackrabbit-oak build #4000: Passed
Build Update for apache/jackrabbit-oak - Build: #4000 Status: Passed Duration: 2742 seconds Commit: c692326301c4bc0f0cfe0db77eeeca5a90349255 (trunk) Author: Michael Duerig Message: OAK-1618: Implement noInternal from JackrabbitEventFilter Add issue reference git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1584058 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/a30cf9068750...c692326301c4 View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/22109296 -- sent by Jukka's Travis notification gateway
jackrabbit-oak build #4001: Errored
Build Update for apache/jackrabbit-oak - Build: #4001 Status: Errored Duration: 1940 seconds Commit: 173ccf992e95c7151495fc3b6273f9af767cd73f (trunk) Author: Jukka Zitting Message: OAK-631: SegmentMK: Implement garbage collection Use memory mapping to access already written entries in TarWriter Improve the cache handling in SegmentTracker git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1584067 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/c692326301c4...173ccf992e95 View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/22111941 -- sent by Jukka's Travis notification gateway
Oak and Jackrabbit-related conference: AEM Hub next week
Hi, There's an Oak and Jackrabbit-related developer event taking place next Wednesday and Thursday in London. AEMHub takes place on 9-10 April, and has a number of talks hopefully of interest to the community, including: - AEM's new architecture built upon Oak - JCR nodes and polling importers - Performance benchmarking DAMs built on Jackrabbit There's also Apache Sling talks, including YAMF - the Lightweight Mapping Solution (Sling Models), the latest iteration of the Sling Health Check Tools, a talk on integrating with Apache Solr, and a talk on Apache Cordova. There'll be a few Apache folk attending, so it would be great to see you there. See http://aemhub.cognifide.com/ for more information. Thanks, Andrew. -- asav...@apache.org / cont...@andrewsavory.com http://www.andrewsavory.com/
jackrabbit-oak build #4007: Fixed
Build Update for apache/jackrabbit-oak - Build: #4007 Status: Fixed Duration: 2472 seconds Commit: 0ca8f0019394a74047e843a545d56f3985097bd2 (trunk) Author: Jukka Zitting Message: OAK-631: SegmentMK: Implement garbage collection Remember to follow also the reference graph of segments within the TarWriter Allow old checkpoints to expire git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1584257 13f79535-47bb-0310-9956-ffa450edef68 View the changeset: https://github.com/apache/jackrabbit-oak/compare/f2aa3052c98d...0ca8f0019394 View the full build log and details: https://travis-ci.org/apache/jackrabbit-oak/builds/22158306 -- sent by Jukka's Travis notification gateway
Oak Training: MikroKernels/NodeStores
Hi all, after the last review feedback, I have revised the section on MicroKernels and NodeStores. I would appreciate any feedback if this new version is both technically correct and also using the right terms. The revised section is available here (User : review/Pwd: oak4502): http://oak.inside-apps.com/Review_Microkernels_NodeStores.docx Thanks in advance for any comments! Regards, Ben Zahler Inside Solutions AG | Felsenstrasse 11 | 4450 Sissach | Schweiz Telefon: +41 61 551 00 40 | Direkt: +41 61 551 00 43 http://www.inside-solutions.chhttp://www.inside-solutions.ch/
