the failure as far as i can see is:
Running org.apache.jackrabbit.oak.jcr.AsyncConflictsIT
No output has been received in the last 10 minutes, this potentially
indicates a stalled build or something wrong with the build itself.
The build has been terminated
i don't think this is related to
Build Update for apache/jackrabbit-oak
-
Build: #7043
Status: Errored
Duration: 2173 seconds
Commit: 88dccebec307c629e01980181745a67fe8b69813 (trunk)
Author: Angela Schreiber
Message: OAK-3759 : UserManager.onCreate is not omitted for system users in
case of X
On 9.12.15 12:02 , Michael Dürig wrote:
Do you have any suggestions?
Something must be way wrong as the build either takes ~30 minutes or it
times out after 90 minutes. There is quite a difference here. Maybe we
need to go through the log files and compare test execution times of
individua
On Tue, Dec 1, 2015 at 6:21 PM, Timothée Maret wrote:
> The API would
>
> - Cover encrypting/decrypting data using an instance global master key
> - Make no assumption regarding how to get the master key
This looks useful!. I think having just the decryption part should be
sufficient as part of A
ah, good one! did not know about this, I'll replace the code
On Wed, Dec 9, 2015 at 2:20 PM, Chetan Mehrotra
wrote:
> On Wed, Dec 9, 2015 at 6:36 PM, wrote:
> > +private static String multiplier(String in, int times) {
> > +StringBuilder sb = new StringBuilder();
> > +for (
On Wed, Dec 9, 2015 at 6:36 PM, wrote:
> +private static String multiplier(String in, int times) {
> +StringBuilder sb = new StringBuilder();
> +for (int i = 0; i < times; i++) {
> +sb.append(in);
> +}
> +return sb.toString();
> +}
> +
May be u
On 9.12.15 12:41 , Julian Reschke wrote:
Something must be way wrong as the build either takes ~30 minutes or it
times out after 90 minutes. There is quite a difference here. Maybe we
need to go through the log files and compare test execution times of
individual tests between timed out and su
On 2015-12-09 12:02, Michael Dürig wrote:
On 9.12.15 11:58 , Julian Reschke wrote:
On 2015-12-09 09:42, Michael Dürig wrote:
Hi,
In the last 5 build on our Jenkins instance [1] we always had one of the
DocumentRDB jobs timing out [2]. This means the job didn't complete
within 90 minutes. Th
On 9.12.15 11:58 , Julian Reschke wrote:
On 2015-12-09 09:42, Michael Dürig wrote:
Hi,
In the last 5 build on our Jenkins instance [1] we always had one of the
DocumentRDB jobs timing out [2]. This means the job didn't complete
within 90 minutes. This is not because we are close to the limit
On 2015-12-09 09:42, Michael Dürig wrote:
Hi,
In the last 5 build on our Jenkins instance [1] we always had one of the
DocumentRDB jobs timing out [2]. This means the job didn't complete
within 90 minutes. This is not because we are close to the limit as
regular builds take roughly 30 minutes.
On 2015-12-09 10:33, Davide Giannella wrote:
On 08/12/2015 16:06, Julian Reschke wrote:
So what's the correct JIRA state for something that has been fixed in
1.3.x, which is intended to be backported to 1.2, but hasn't been
backported yet? Can I still set that to "resolved"?
If the backport i
On Tue, Dec 8, 2015 at 9:36 PM, Julian Reschke wrote:
> So what's the correct JIRA state for something that has been fixed in 1.3.x,
> which is intended to be backported to 1.2, but hasn't been backported yet?
> Can I still set that to "resolved"?
So far the practice some of us follow is to add l
The Apache Jenkins build system has built Apache Jackrabbit Oak matrix (build
#600)
Status: Failure
Check console output at
https://builds.apache.org/job/Apache%20Jackrabbit%20Oak%20matrix/600/ to view
the results.
Changes:
[reschke] OAK-3729: RDBDocumentStore: implement RDB-specific VersionG
[X] +1, shut down oakcomm...@jackrabbit.apache.org
Davide
On 08/12/2015 16:06, Julian Reschke wrote:
>
> So what's the correct JIRA state for something that has been fixed in
> 1.3.x, which is intended to be backported to 1.2, but hasn't been
> backported yet? Can I still set that to "resolved"?
If the backport is part of the issue no you can't. If the b
Hello team,
we normally keep, as much as possible, a regular release cycle for the
various Oak versions.
Just wanted to let all the community know that as we're approaching
Christmas and most of us won't be in front of a screen we're skipping
one release cycle.
Please refer to jira for the updat
Hi,
In the last 5 build on our Jenkins instance [1] we always had one of the
DocumentRDB jobs timing out [2]. This means the job didn't complete
within 90 minutes. This is not because we are close to the limit as
regular builds take roughly 30 minutes.
Is there anything we could do in the s
17 matches
Mail list logo
