[ANNOUNCE] CFP open for ApacheCon North America 2016

[Rich Bowen]

Community growth starts by talking with those interested in your
project. ApacheCon North America is coming, are you?

We are delighted to announce that the Call For Presentations (CFP) is
now open for ApacheCon North America. You can submit your proposed
sessions at
http://events.linuxfoundation.org/events/apache-big-data-north-america/program/cfp
for big data talks and
http://events.linuxfoundation.org/events/apachecon-north-america/program/cfp
for all other topics.

ApacheCon North America will be held in Vancouver, Canada, May 9-13th
2016. ApacheCon has been running every year since 2000, and is the place
to build your project communities.

While we will consider individual talks we prefer to see related
sessions that are likely to draw users and community members. When
submitting your talk work with your project community and with related
communities to come up with a full program that will walk attendees
through the basics and on into mastery of your project in example use
cases. Content that introduces what's new in your latest release is also
of particular interest, especially when it builds upon existing well
know application models. The goal should be to showcase your project in
ways that will attract participants and encourage engagement in your
community, Please remember to involve your whole project community (user
and dev lists) when building content. This is your chance to create a
project specific event within the broader ApacheCon conference.

Content at ApacheCon North America will be cross-promoted as
mini-conferences, such as ApacheCon Big Data, and ApacheCon Mobile, so
be sure to indicate which larger category your proposed sessions fit into.

Finally, please plan to attend ApacheCon, even if you're not proposing a
talk. The biggest value of the event is community building, and we count
on you to make it a place where your project community is likely to
congregate, not just for the technical content in sessions, but for
hackathons, project summits, and good old fashioned face-to-face networking.

-- 
rbo...@apache.org
http://apache.org/

Re: [discuss] persisting cluster (view) id for discovery-lite-descriptor

[Chetan Mehrotra]

There is another option to avoid extra effort when running within
Sling. Have an optional implementation which makes use of
SlingSettingsService to get fetch SlingId. With little bit of OSGi
kung fu you can have an implementation which uses SlingId when running
in Sling otherwise maintains its own id using File based approach.

This would reduce operational complexity
Chetan Mehrotra


On Wed, Nov 25, 2015 at 6:23 PM, Stefan Egli  wrote:
> Right, I'm not sure it is indeed a requirement. But without automatic
> support it might get forgotten and thus the cluster id would change upon
> failover.
>
> Cheers,
> Stefan
>
> On 25/11/15 13:40, "Chetan Mehrotra"  wrote:
>
>>On Wed, Nov 25, 2015 at 6:00 PM, Stefan Egli 
>>wrote:
 * disadvantage: cold standby would require an explicit copying of this
file
 (during initial hand-shake?)
>>
>>Why is that a requirement? Cold standby is just a backup and currently
>>there is no automatic failover support.
>>
>>For such cases we can allow passing the id as a system/framework property
>>also
>>
>>Chetan Mehrotra
>
>

Re: [jira] [Updated] (OAK-3632) Incorrect Value Conversion upon Node.setProperty and Node.setValue

[Amit Jain]

I'll change the release process document to reflect this.

On Tue, Nov 24, 2015 at 3:37 PM, Amit Jain  wrote:

> Hi,
>
> On Tue, Nov 24, 2015 at 2:55 PM, Marcel Reutegger 
> wrote:
>
>> I assume you mean the version in JIRA would be set as released.
>> Yes, I think that makes it easier to pick the correct fix
>> version while a release is in progress.
>>
>> I quickly checked JIRA and it seems we can also 'unrelease'
>> a version if needed.
>>
>> What do others think? Should we changed the release process [0]
>> accordingly?
>>
>
> +1, Yes we can do that to avoid such issues.
>

[discuss] persisting cluster (view) id for discovery-lite-descriptor

[Stefan Egli]

Hi,

Noticed that for TarMK the discovery-lite-descriptor does currently not
persist the cluster-view-id [0]. It should do this however, as otherwise
this causes upper-level discovery.oak to break the discovery API, as it
demands a persisted cluster id. (Note that this id is not to be confused
with the 'cluster node id' that identifies an instance within a document
node store cluster)

I wanted to get some ideas from the list as to how this should be
implemented. Current options are:
1. storing a 'cluster.id.file' (or 'discovery.cluster.id.file') similar to
the 'sling.id.file' (via BundleContext.getDataFile).
> * cloning a repository would therefore require to delete both sling.id.file
> and this new file
> * disadvantage: cold standby would require an explicit copying of this file
> (during initial hand-shake?)
2. storing the id as a property somewhere in the repository.
> * disadvantage: cloning a repository would clone this id as well and there
> might not be an easy enough way for a user to reset it
Opinions? Alternatives?

Cheers,
Stefan
--
[0] https://issues.apache.org/jira/browse/OAK-3672

Re: [discuss] persisting cluster (view) id for discovery-lite-descriptor

[Chetan Mehrotra]

On Wed, Nov 25, 2015 at 6:00 PM, Stefan Egli  wrote:
>> * disadvantage: cold standby would require an explicit copying of this file
>> (during initial hand-shake?)

Why is that a requirement? Cold standby is just a backup and currently
there is no automatic failover support.

For such cases we can allow passing the id as a system/framework property also

Chetan Mehrotra

Re: [discuss] persisting cluster (view) id for discovery-lite-descriptor

[Stefan Egli]

Right, I'm not sure it is indeed a requirement. But without automatic
support it might get forgotten and thus the cluster id would change upon
failover.

Cheers,
Stefan

On 25/11/15 13:40, "Chetan Mehrotra"  wrote:

>On Wed, Nov 25, 2015 at 6:00 PM, Stefan Egli 
>wrote:
>>> * disadvantage: cold standby would require an explicit copying of this
>>>file
>>> (during initial hand-shake?)
>
>Why is that a requirement? Cold standby is just a backup and currently
>there is no automatic failover support.
>
>For such cases we can allow passing the id as a system/framework property
>also
>
>Chetan Mehrotra

jackrabbit-oak build #6938: Broken

[Travis CI]

Build Update for apache/jackrabbit-oak
-

Build: #6938
Status: Broken

Duration: 405 seconds
Commit: 39ad4d8e07e885e0c2897dfabe86a0dd28eb17ff (trunk)
Author: Chetan Mehrotra
Message: OAK-3654 - Integrate with Metrics for various stats collection

Add a Noop variant for RepositoryStatistics

git-svn-id: https://svn.apache.org/repos/asf/jackrabbit/oak/trunk@1716571 
13f79535-47bb-0310-9956-ffa450edef68

View the changeset: 
https://github.com/apache/jackrabbit-oak/compare/85ae9b96ae3b...39ad4d8e07e8

View the full build log and details: 
https://travis-ci.org/apache/jackrabbit-oak/builds/93310633

--
sent by Jukka's Travis notification gateway