The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build
#370)
Status: Still Failing
Check console output at
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/370/ to view
the results.
Changes:
[alexparvulescu] OAK-3294 Read-only live FileStore implementati
Hi Vikas,
On Fri, 2015-08-28 at 20:28 +0530, Vikas Saurabh wrote:
> Hi Robert,
>
> AFAIK, each node pushes paths that are changed by that node between 2
> background updates.
> Other cluster nodes mainly use it to generate external observation
> events
> and cache invalidation due to changes by o
Hi Robert,
AFAIK, each node pushes paths that are changed by that node between 2
background updates.
Other cluster nodes mainly use it to generate external observation events
and cache invalidation due to changes by other nodes in the cluster.
So, yes it's useful only for cluster case.
I think M
Hi,
My current multiplexing prototype only handles multiplexing for the
NODES collection. However, upon a review it seems to me that the
JOURNAL collection is quite closely tied to the NODES collection.
By reading the code it looks to me like the only use it has is the
cache invalidation when cha
Build Update for apache/jackrabbit-oak
-
Build: #6269
Status: Fixed
Duration: 1952 seconds
Commit: 44edcca310d3b2956a4161da776efdb14326c631 (trunk)
Author: Alexandru Parvulescu
Message: OAK-3301 AbstractRepositoryUpgrade leaks Repository instances
- patch prov
Hi,
On Fri, 2015-08-21 at 14:07 +, Thomas Mueller wrote:
> Hi,
>
> The DocumentStore doesn't really know the path, it only knows the
> key, and
> if the key is hashed you can't calculate the path.
>
> There are some options:
>
> (a) Each document that has a hashed path as the key also has a
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build
#369)
Status: Still Failing
Check console output at
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/369/ to view
the results.
Changes:
Test results:
1 tests failed.
REGRESSION:
org.apache.jackr
Hi,
>AFAIK your tests re. restart have been done from within an OSGi
>container (AEM) restarting the repository bundle.
Actually I restarted the JVM. But I probably didn't use the very latest
version of Oak, checkpoints may also have played a role in my case (there
were 2 checkpoints; probably fr
On 28.8.15 2:41 , Thomas Mueller wrote:
Hi,
I'm not an expert on compaction, but the differences the current approach
I see are:
* No compaction maps. No memory problem. No persistent compaction map. As
far as I understand, currently you can have _multiple_ compaction map at
the same time. I
On 28.8.15 2:11 , Robert Munteanu wrote:
On Fri, 2015-08-28 at 12:26 +0200, Michael Dürig wrote:
java.lang.OutOfMemoryError: PermGen space [1]. I'm seeing these quite
often lately. This looks like Maven itself runs out of PermGen space.
Does anyone know how to configure this for Jenkins?
My
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build
#368)
Status: Failure
Check console output at
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/368/ to view
the results.
Changes:
Test results:
All tests passed
Hi,
I'm not an expert on compaction, but the differences the current approach
I see are:
* No compaction maps. No memory problem. No persistent compaction map. As
far as I understand, currently you can have _multiple_ compaction map at
the same time. I think that persisting the compaction map is
On Fri, 2015-08-28 at 12:26 +0200, Michael Dürig wrote:
>
> java.lang.OutOfMemoryError: PermGen space [1]. I'm seeing these quite
> often lately. This looks like Maven itself runs out of PermGen space.
> Does anyone know how to configure this for Jenkins?
My first gues would be the 'JVM Options'
Hi,
I'm looking at LastRevRecoveryAgentTest [1] which uses a shared
document store for two DocumentNodeStore instances. Disposing both node
store instances makes the tests fail, as the document store will be
closed by the first call to dispose() and the second call will fail.
The reason is the fo
Upon further consideration, here’s an alternative proposal.
To recap the problem:
Say version 1.0.x has an issue that leads to repo inconsistencies or even
(repairable) data loss
The issue is fixed in 1.0.y, but users running an inbetween version might have
experienced that data loss (maybe with
AFAIU this is pretty much what we are now doing under the hood. That is,
your proposal would make the compaction step more explicit and visible
above the node store API.
An advantage of your approach is preventing mix segments all together
(i.e. compacted segments still referring to uncompacte
On Fri, 2015-08-28 at 12:46 +0200, Michael Dürig wrote:
> Hi,
>
> I'm a bit reluctant about finalizers as it is all too easy to
> introduce
> subtle problems causing instance to be resurrected. IMO a better
> approach would be to use phantom references, avoiding such problems.
Fair enough. For
Hi,
Please welcome Julian as a new committer and PMC member of the Apache
Jackrabbit project. The Jackrabbit PMC recently decided to offer Julian
committership based on his contributions. I'm happy to announce that he
accepted the offer and that all the related administrative work has now
bee
Hi,
Please welcome Francesco as a new committer and PMC member of the Apache
Jackrabbit project. The Jackrabbit PMC recently decided to offer
Francesco committership based on his contributions. I'm happy to
announce that he accepted the offer and that all the related
administrative work has n
cba
Am 28. August 2015 02:36:27 GMT-04:00, schrieb Thomas Mueller
:
>Hi,
>
>I wonder what does the team think about using "final" for variables and
>parameters. In Oak, so far we didn't use it a lot. This question has
>come up with OAK-3148. The patch uses "final" for variables, but not
>for para
Hi Julian,
I did some testing and came to the conclusion for AEM 6.1 (with Oak 1.2.2)
to run properly ,with automated compaction enabled, it requires a minimum
of around 4.5 GB in heap.
On Fri, Aug 28, 2015 at 1:14 PM, Julian Sedding wrote:
> Hi Thomas
>
> The idea is most welcome. Just had an
Hi Thomas
The idea is most welcome. Just had an OOME with 4G heap on a local dev
instance yesterday due to compaction (running Oak 1.2.4).
Which API do you want to use for copying? The NodeStore API? Note that
for a complete copy you need to also consider copying checkpoints.
The idea is very si
Hi,
I'm a bit reluctant about finalizers as it is all too easy to introduce
subtle problems causing instance to be resurrected. IMO a better
approach would be to use phantom references, avoiding such problems.
Michael
On 27.8.15 2:48 , Robert Munteanu wrote:
Hi,
The oak test suite often
java.lang.OutOfMemoryError: PermGen space [1]. I'm seeing these quite
often lately. This looks like Maven itself runs out of PermGen space.
Does anyone know how to configure this for Jenkins?
Michael
[1] Exception in thread "main" java.lang.OutOfMemoryError: PermGen space
at java.lan
On 28.8.15 8:36 , Thomas Mueller wrote:
Personally, my favorite is (c), followed by (b). As for (a),
(a): -1
(b): +99
(c): +100
I think
(same as Alex Miller at StackOverflow) it clutters the code and
decreases readability. Too bad "final" is not the default in Java
+10^10
Michael
Hi Tomek,
On Fri, 2015-08-28 at 08:30 +, Tomek Rekawek wrote:
> Hello,
>
> I’m trying to avoid re-assigning local variables whenever it’s
> possible. For me it makes the code easier to reason about - I know
> that the variable “state" created at the beginning of the method is
> the same one I
Hi,
>- I know that the variable ³state" created at the beginning of the method
>is the same one I can access at the end.
For short methods, it's easy to see this, by reading the code. In my view
easier than using "final", which makes the code less readable.
For large methods,... well you should
Hello,
I’m trying to avoid re-assigning local variables whenever it’s possible. For me
it makes the code easier to reason about - I know that the variable “state"
created at the beginning of the method is the same one I can access at the end.
If I need the child state at some point I can create
Hi,
I thought about SegmentStore compaction and made a few slides:
http://www.slideshare.net/ThomasMueller12/multi-store-compaction
Feedback is welcome! The idea is at quite an early stage, so if you don't
understand or agree with some items, I'm to blame.
Regards,
Thomas
On 2015-08-28 08:36, Thomas Mueller wrote:
Hi,
I wonder what does the team think about using "final" for variables and parameters. In Oak, so far we didn't
use it a lot. This question has come up with OAK-3148. The patch uses "final" for variables, but not for
parameters. Lately, I have seens
30 matches
Mail list logo
