Hi,
On Fri, 2017-05-05 at 07:18 -0600, Matt Ryan wrote:
> I was wondering about this also WRT federated data store. If the
> intent
> and effect of both are the same ("both" meaning what is currently
> called
> the "multiplexing node store" and the proposed (and in-progress)
> "federated
> data s
I put together a very crude initial POC which can be seen at [0]. This
simply allows a FileDataStore to be used as a delegate data store and the
FederatedDataStore to be used in Oak as the primary data store.
The approach is simply that the FederatedDataStore has information about
the delegates (
On Fri, Apr 21, 2017 at 7:20 AM, Davide Giannella wrote:
> On 20/04/2017 19:30, Matt Ryan wrote:
> > I misremembered above when I was describing a possible implementation. I
> > was thinking we'd add a method to the delegate, but that would be added
> to
> > the DataStore interface, obviously (n
Hi,
I'm not sure what the latest is here, but isn't this regarded as bad
practice?
Maintenance branches have always been subsets of the subsequent branch: 1.0
< 1.2 < 1.4 < 1.6 and so on? Any 1.6 release should contain *all* of 1.4
(give or take a week or two until the next stable release).
Has th
Hi,
This might be a side effect of the many maintenance branches we have. Based
on the current process, releasing any of them would mark the issue as
'closed', but I think it should be fine as long as the people doing the
releases don't lose track of these issues.
For example branch 1.2 might have
Hi,
When a client connects only temporarily to a SharedS3DataStore (for
example) and then goes away, the META/repository-* marker created by
SegmentNodeStoreService is not removed.
This causes MarkSweepGarbageCollector to abort with a "not all
repositories have marked references available" messag
I was wondering about this also WRT federated data store. If the intent
and effect of both are the same ("both" meaning what is currently called
the "multiplexing node store" and the proposed (and in-progress) "federated
data store"), it seems they should use a similar naming convention at least.
The Apache Jenkins build system has built Jackrabbit Oak (build #259)
Status: Failure
Check console output at https://builds.apache.org/job/Jackrabbit%20Oak/259/ to
view the results.
Changes:
[chetanm] OAK-6176 - Service to provide access to async indexer state
[chetanm] OAK-6176 - Service to
Hi Tomek
In all related discussions the term "mount" appears a lot. So why not
Mounting NodeStore? The module could be "oak-store-mount".
Regards
Julian
On Fri, May 5, 2017 at 1:39 PM, Tomek Rekawek wrote:
> Hello oak-dev,
>
> the multiplexing node store has been recently extracted from the oa
Hello oak-dev,
the multiplexing node store has been recently extracted from the oak-core into
a separate module and I’ve used it as an opportunity to rename the thing. The
name I suggested is Federated Node Store. Robert doesn’t agree it’s the right
name, mostly because the “partial” node store
Hi there,
we currently close bugs when a release is made which fixes the bug.
This can lead to somewhat strange effects, if a stable release is made
before a release from trunk happened.
For instance, OAK-5641 was marked closed when 1.4.14 was released, but
we it's not actually fixed in any
...change was already applied to 1.4, so we really ought to have it in
1.6 as well.
https://issues.apache.org/jira/browse/OAK-5667
(dead code)
Hi,
On 04/05/17 16:56, "Justin Edelson" wrote:
>>Hmm, depending on the Oak version, this may also be caused by OAK-5528.
>> The current fix versions are 1.4.15 and 1.6.0.
>>
>
>Would this show up in thread dumps? Based on the description, it seems
>like
>it should.
Not necessarily. In OAK-5528
14 matches
Mail list logo
