adaptTo() 2016 - Agenda published

[Stefan Seifert]

We're proud to present this year's agenda http://adapt.to/schedule

Luckily, there are still tickets available http://adapt.to/tickets

#adaptTo

Kind regards on behalf of the adaptTo() team

stefan

Re: Requirement to support multiple NodeStore instance in same setup (OAK-4490)

[Julian Sedding]

Hi Chetan

I agree that we should not rely on the service.ranking for this. A
type property makes sense IMO.

On the other hand, do we really need to expose both NodeStores in the
service registry? The secondary (cache) NodeStore could also be
treated as an implementation detail of the DocumentNodeStore and
switched on/off via configuration. Of course the devil is in the
detail then - how to configure different BlobStores, cache sizes etc
of the secondary NodeStore?

Not exposing the secondary NodeStore in the service registry would be
backwards compatible. Introducing the "type" property potentially
breaks existing consumers, i.e. is not backwards compatible.

Regards
Julian


On Tue, Jun 21, 2016 at 9:03 AM, Chetan Mehrotra
 wrote:
> Hi Team,
>
> As part of OAK-4180 feature around using another NodeStore as a local
> cache for a remote Document store I would need to register another
> NodeStore instance (for now a SegmentNodeStore - OAK-4490) with the
> OSGi service registry.
>
> This instance would then be used by SecondaryStoreCacheService to save
> NodeState under certain paths locally and use it later for reads.
>
> With this change we would have a situation where there would be
> multiple NodeStore instance in same service registry. This can confuse
> some component which have a dependency on NodeStore as a reference and
> we need to ensure they bind to correct NodeStore instance.
>
> Proposal A - Use a 'type' service property to distinguish
> ==
>
> Register the NodeStore with a 'type' property. For now the value can
> be 'primary' or 'secondary'. When any component registers the
> NodeStore it also provides the type property.
>
> On user side the reference needs to provide which type of NodeStore it
> needs to bound
>
> This would ensure that user of NodeStore get bound to correct type.
>
> if we use service.ranking then it can cause a race condition where the
> secondary instance may get bound untill primary comes up
>
> Looking for feedback on what approach to take
>
> Chetan Mehrotra

Re: Oak 1.5.4 release plan

[Davide Giannella]

On 20/06/2016 10:47, Davide Giannella wrote:
> On 16/06/2016 10:02, Davide Giannella wrote:
>> Hello team,
>>
>> I'm planning to cut Oak 1.5.4 next Monday the 20th July in the morning
>> British time.
>>
> Release is currently blocked as of
> https://issues.apache.org/jira/browse/OAK-4486.
>

thanks for the quick fix Marcel. We're currently blocked on a new issue

https://issues.apache.org/jira/browse/OAK-4491

Davide