Re: Increase language level to Java 7

[Julian Sedding]

We could enforce java6 signatures for the branches using the
animal-sniffer-maven-plugin. This should help detect bogus backports
quickly.

Regards
Julian

On Thu, Apr 7, 2016 at 10:57 AM, Francesco Mari
 wrote:
> Language features would be available for new, backport-free developments.
> Existing code doesn't have to use those features if they would be an issue
> during backports.
>
> 2016-04-07 10:25 GMT+02:00 Davide Giannella :
>
>> On 06/04/2016 15:25, Francesco Mari wrote:
>> > I was talking about trunk, of course. Developers working in areas where
>> > backports are the norm have to carefully consider if and when using Java
>> 7
>> > language features would be appropriate. New portions of the codebase
>> could
>> > use of the new features freely.
>> >
>>
>> We were discussing this on chat. Generally I'd say +1 for trunk but we
>> risk to introduce problems for backports.
>>
>> Davide
>>
>>
>>

Re: Jackrabbit 2.10 vs Oak 1.2.7

[Michael Marth]

Hi Domenic,

My POV:
You are essentially testing how fast Oak or JR can put nodes into 
MySQL/Postgres/Mongo. IMO Oak’s design does not suggest that there should be 
fundamental differences between JR and Oak for this isolated case. (*)

However, where Oak is expected to outperform JR is when
1) the test case reflects realistic usage patterns and
2) horizontal scalability becomes a topic.

To explain:
Re 1: in reality you would usually have many reading threads for each writing 
thread. Oak’s MVCC design caters for performance for such test cases.
Re 2: If you have many cluster nodes the MVCC becomes even more pronounced (not 
only different threads but different processes). Also, if you have observation 
listeners and many cluster nodes then I expect to see substantial differences 
between Oak and JR.

Cheers
Michael

(*) with the notable exception of TarMK which I expect to outperform anything 
on any test case ;)



On 06/04/16 16:20, "Domenic DiTano"  wrote:

>Hi Marcel,
>
>I uploaded all the source to github along with a summary spreadsheet.  I
>would appreciate any time you have to review.
>
>https://github.com/Domenic-Ansys/Jackrabbit2-Oak-Tests
>
>As you stated the move is a non goal, but in comparison to Jackrabbit 2 I
>am also finding in my tests that create, update, and copy are all faster
>in Jackrabbit 2 (10k nodes).  Any input would be appreciated...
>
>Also, will MySql will not be listed as "Experimental" at some point?
>
>Thanks,
>Domenic
>
>
>-Original Message-
>From: Marcel Reutegger [mailto:mreut...@adobe.com]
>Sent: Thursday, March 31, 2016 6:14 AM
>To: oak-dev@jackrabbit.apache.org
>Subject: Re: Jackrabbit 2.10 vs Oak 1.2.7
>
>Hi Domenic,
>
>On 30/03/16 14:34, "Domenic DiTano" wrote:
>>"In contrast to Jackrabbit 2, a move of a large subtree is an expensive
>>operation in Oak"
>>So should I avoid doing a move of a large number of items using Oak?
>>If we are using Oak then should we avoid operations with a large number
>>of items in general?
>
>In general it is fine to have a large change set with Oak. With Oak you
>can even have change sets that do not fit into the heap.
>
>>  As a FYI - there are other benefits for us to move to Oak, but our
>>application uses executes JCR operations with a large number of items
>>quite often.  I am worried about the performance.
>>
>>The move method is pretty simple - should I be doing it differently?
>>
>>public static long moveNodes(Session session, Node node, String
>>newNodeName)
>>throws Exception{
>>  long start = System.currentTimeMillis();
>>  session.move(node.getPath(), "/"+newNodeName);
>> session.save();
>>  long end = System.currentTimeMillis();
>>  return end-start;
>>}
>
>No, this is fine. As mentioned earlier, with Oak a move operation is not
>cheap and is basically implemented as copy to new location and delete at
>the old location.
>
>A cheap move operation was considered a non-goal when Oak was designed:
>https://wiki.apache.org/jackrabbit/Goals%20and%20non%20goals%20for%20Jackr
>a
>bbit%203
>
>
>Regards
> Marcel

Re: Failing SegmentToJdbcTest.validateMigration

[Angela Schreiber]

Hi Tomek

I create https://issues.apache.org/jira/browse/OAK-4174
in order not to mix my modifications with the upgrade
code as i consider the @ignore mark just a temp workaround
in order to keep everyone and jenkins happy :-)

kind regards
angela

On 07/04/16 14:01, "Tomek Rekawek"  wrote:

>Hello Angela,
>
>> On 07 Apr 2016, at 13:37, Angela Schreiber  wrote:
>> 
>> I will take the liberty to mark the test with an @Ignore tag when
>> committing my changes. What's your preferred way to investigate
>> this? Shall I clone the OAK-4119? Or do you want to take a closer
>> look once I am done such that you can actually experience the
>> failure?
>
>Feel free to commit your changes with the @Ignore annotation and ping me
>once the OAK-4119 is done - I'll look into the failing test then.
>
>Best regards,
>Tomek
>
>-- 
>Tomek Rękawek | Adobe Research | www.adobe.com
>reka...@adobe.com

Re: Failing SegmentToJdbcTest.validateMigration

[Angela Schreiber]

Hi Tomek

While I see that OAK-4128 has been resolved fixed, I still experience
a failing SegmentToJdbcTest.validateMigration test, with my pending
changes for OAK-4119.

I will take the liberty to mark the test with an @Ignore tag when
committing my changes. What's your preferred way to investigate
this? Shall I clone the OAK-4119? Or do you want to take a closer
look once I am done such that you can actually experience the
failure?

Kind regards
Angela

On 16/03/16 14:26, "Angela Schreiber"  wrote:

>Hi Tomek
>
>Thanks a lot for the confirmation and the issue!
>
>Just as a side node: our Adobe internal repositories
>_always_ have a policy node at the root. If the sidegrade
>is likely to be used in real, productive environments
>this should IMO be considered a critical bug.
>
>Thanks and kind regards
>Angela
>
>
>On 16/03/16 14:00, "Tomek Rekawek"  wrote:
>
>>Hello Angela,
>>
>>> On 16 Mar 2016, at 12:39, Angela Schreiber  wrote:
>>> 
>>> stepping into the AbstractOak2OakTest and finally
>>> RepositorySidegrade.copyState i actually see that the target
>>>NodeBuilder
>>> that results from copyWorkspace doesn't have the jcr:mixinTypes
>>> property copied from the src to the target, which consequently
>>
>>Indeed, it seems there's a bug, which causes the RepositorySidegrade to
>>skip the root node properties. I think the reason lies in the
>>calculateEffectiveIncludePaths() method, which produces an effective list
>>of paths to migrate. If we have a '/' in the input list, the method will
>>replace it with a list of '/' children and the root itself is removed
>>from the list.
>>
>>Similar issue is present in the RepositoryUpgrade, but it isn't so
>>dangerous there, as we create the root node anyway using an initializer.
>>
>>Created OAK-4128 to track this.
>>
>>However, the OAK-4128 is reproducible and present not only on the JDBC
>>destination, so I guess the random failures (including the ones on
>>Jenkins) are related to something else.
>>
>>Best regards,
>>Tomek
>>
>>-- 
>>Tomek Rękawek | Adobe Research | www.adobe.com
>>reka...@adobe.com
>>
>

Oak 1.5.1 release plan

[Davide Giannella]

Hello team,

I'm planning to cut Oak 1.5.1 on Monday 11th April in the morning CEST.

If there are any objections please let me know. Otherwise I will
re-schedule any non-resolved issue for the next iteration.

Thanks
Davide

Re: Increase language level to Java 7

[Francesco Mari]

Language features would be available for new, backport-free developments.
Existing code doesn't have to use those features if they would be an issue
during backports.

2016-04-07 10:25 GMT+02:00 Davide Giannella :

> On 06/04/2016 15:25, Francesco Mari wrote:
> > I was talking about trunk, of course. Developers working in areas where
> > backports are the norm have to carefully consider if and when using Java
> 7
> > language features would be appropriate. New portions of the codebase
> could
> > use of the new features freely.
> >
>
> We were discussing this on chat. Generally I'd say +1 for trunk but we
> risk to introduce problems for backports.
>
> Davide
>
>
>