[jira] [Commented] (OAK-7) In-memory persistence
[ https://issues.apache.org/jira/browse/OAK-7?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13226125#comment-13226125 ] Stefan Guggisberg commented on OAK-7: - Currently that's not possible since the o.a.j.mk.Repository class always creates the homeDir, even if you switch the DefaultRevisionStore to use InMemPersistence. +1 for changing the current behavior and just creating the homeDir on demand, i.e. lazily when it's actually accessed. In-memory persistence - Key: OAK-7 URL: https://issues.apache.org/jira/browse/OAK-7 Project: Jackrabbit Oak Issue Type: New Feature Reporter: Jukka Zitting Fix For: 0.1 There should be a way to run an Oak repository that requires zero disk access. Currently that's not possible since the o.a.j.mk.Repository class always creates the homeDir, even if you switch the DefaultRevisionStore to use InMemPersistence. Having such a fully in-memory repository makes it easier (and faster) to run test cases for which the actual persistence mechanism is irrelevant. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: jsop and property / node with same name
On Wed, Mar 7, 2012 at 8:35 PM, David Buchmann david.buchm...@liip.ch wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
hi,
while implementing the jackalope php jsop client for the jackrabbit
backend, i stumbled over a problem with the json returned when a
property and a child node have the same name:
the repository is something like this:
test toast=bar
toast/
/test
to create it, i do
Session s = repository.login(credentials,workspace);
Node n = s.getRootNode().addNode(test);
n.setProperty(toast, bar);
n.addNode(toast);
s.save();
now the json returned for /test looks like this:
{toast:bar,:jcr:primaryType:Name,jcr:primaryType:nt:unstructured,toast:{}}
note: there is twice the key toast. as far as i understand json, this
is not valid. the php function json_decode just overwrites the property
toast = bar with the node array toast = array(). javascript json
parsers tend to do the same.
is jackrabbit using a custom json parser that can handle same-name keys?
are there any plans to make this valid json?
or would the jcr spec forbid it? found nothing about it. when looking at
the xml representation, it sounds totally normal. when outputting i.e.
the path of the property and the node it looks strange.
as of jcr 2.0 properties and child nodes may share the same namespace [0].
cheers
stefan
[0] http://www.day.com/specs/jcr/2.0/3_Repository_Model.html#3.4.2.2
Child Resolution
thanks for input,
david
- --
Liip AG // Agile Web Development // T +41 26 422 25 11
CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk9XuHIACgkQqBnXnqWBgIss8QCgvUFwzFLURDtdRSXHrdrboCuu
AwIAoMNJSL0VwGfjxfDJy6c87k/5gbj5
=fe9h
-END PGP SIGNATURE-
Re: Integration Tests with TCK
On Thu, Mar 8, 2012 at 3:57 PM, Angela Schreiber anch...@adobe.com wrote: hi in addition to the proposal by jukka to setup benchmarks i would like to suggest to soon setup integration testing that also test jr3 against the TCK. imo it's important that we identify implementation details that violate the JCR specification early in the process. this will not only allow us to take conscious decisions regarding compliance violations but will also be very important to spot possible issues that will arise with migration of JCR applications to jackrabbit3. (thinking of apps like sling or cq that relying on quite some jr2 implementation details that are also reflected in the TCK :-). what do you think? +1, agreed. cheers stefan angela
[jira] [Commented] (OAK-3) Internal tree model
[ https://issues.apache.org/jira/browse/OAK-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13224109#comment-13224109 ] Stefan Guggisberg commented on OAK-3: - +1 for the patch, i agree that .oak.model would be better. Internal tree model --- Key: OAK-3 URL: https://issues.apache.org/jira/browse/OAK-3 Project: Jackrabbit Oak Issue Type: New Feature Reporter: Jukka Zitting Assignee: Jukka Zitting Attachments: OAK-3.1.patch As [discussed|http://markmail.org/message/qdvl5zz5cpkoxz3j] recently on dev@, I'd like to introduce an internal tree model for abstracting read access to the underlying storage implementation. We seem to have reached a rough consensus on the interfaces, so it's time to move them to svn. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jr3] Tree model
On Tue, Mar 6, 2012 at 11:57 AM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
On Mon, Mar 5, 2012 at 3:06 PM, Stefan Guggisberg
stefan.guggisb...@gmail.com wrote:
Properties and child nodes are all addressed using an unordered
name-item mapping on the parent node.
what made me change my mind is that the JSON model
doesn't (naturally) support ordered child entries. i've forgot
about that and i guess that mandating order in a JSON-like
model spells trouble sooner or later.
Right. That's also my intuition.
for getChildNodeEntries() we can therefore drop the distinction
between user-defined and native order and just
state that the iteration order is stable.
Sounds good. The nice thing about this is that it's fairly easy to put
orderability back in at a later point as adding an extra API
constraint can't break existing code whereas removing one (like in
dropping the orderability requirement) can get a bit painful in case
we've already started relying on it in higher-level code.
agreed.
See below for an updated NodeState interface draft that drops the
orderability requirement (but still requires some stable ordering). I
also changed the size and offset types from int to long to resolve the
mini-debate on a potential built-in size limit, regardless of how
likely reaching a 2G limit would have been. Finally, for simplicity I
dropped the length argument from getChildNodeEntries(), as the added
value it gives is pretty small.
i'd rather keep the length argument since it maps to the corresponding
microkernel method and it might make the implementation easier.
OTOH, i don't feel strong about it.
I'm still keeping the numeric offset parameter since it's needed for
efficiently implementing the MicroKernel interface and there's no easy
alternative that would still keep the MicroKernel directly applicable
as a remote access interface.
+1 for this proposal,thanks!
cheers
stefan
BR,
Jukka Zitting
/**
* A content tree consists of nodes and properties, each of which
* evolves through different states during its lifecycle. This interface
* represents a specific, immutable state of a node in a content tree.
* Depending on context, a NodeState instance can be interpreted as
* representing the state of just that node, of the subtree starting at
* that node, or of an entire tree in case it's a root node.
* p
* The crucial difference between this interface and the similarly named
* class in Jackrabbit 2.x is that this interface represents a specific,
* immutable state of a node, whereas the Jackrabbit 2.x class represented
* the current state of a node.
*
* h2Properties and child nodes/h2
* p
* A node consists of an unordered set of name -gt; item mappings. Each
* property and child node is uniquely named and a single name can only
* refer to a property or a child node, not both at the same time.
*
* h2Immutability and thread-safety/h2
* p
* As mentioned above, all node and property states are always immutable.
* Thus repeating a method call is always guaranteed to produce the same
* result as before unless some internal error occurs (see below). Note
* however that this immutability only applies to a specific state instance.
* Different states of a node can obviously be different, and in some cases
* even different instances of the same state may behave slightly differently.
* For example due to performance optimization or other similar changes the
* iteration order of properties or child nodes may be different for two
* instances of the same state.
* p
* In addition to being immutable, a specific state instance guaranteed to
* be fully thread-safe. Possible caching or other internal changes need to
* be properly synchronized so that any number of concurrent clients can
* safely access a state instance.
*
* h2Persistence and error-handling/h2
* p
* A node state can be (and often is) backed by local files or network
* resources. All IO operations or related concerns like caching should be
* handled transparently below this interface. Potential IO problems and
* recovery attempts like retrying a timed-out network access need to be
* handled below this interface, and only hard errors should be thrown up
* as {@link RuntimeException unchecked exceptions} that higher level code
* is not expected to be able to recover from.
* p
* Since this interface exposes no higher level constructs like access
* controls, locking, node types or even path parsing, there's no way
* for content access to fail because of such concerns. Such functionality
* and related checked exceptions or other control flow constructs should
* be implemented on a higher level above this interface.
*
* h2Decoration and virtual content/h2
* p
* Not all content exposed by this interface needs to be backed by actual
* persisted data. An implementation may want to provide provide derived
* data like
Re: Setting up Oak (Was: [RESULT] [VOTE] Codename for the jr3 implementation effort)
On Tue, Mar 6, 2012 at 1:41 PM, Bart van der Schans b.vandersch...@onehippo.com wrote: Hi, On Tue, Mar 6, 2012 at 1:00 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Tue, Mar 6, 2012 at 9:17 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: Oak has the advantage and so we'll go with that. I'll set up the new mailing list, issue tracker and svn space in a moment. The issue tracker is now available at https://issues.apache.org/jira/browse/OAK and the svn space is at http://svn.apache.org/repos/asf/jackrabbit/oak/ (I'll set up a Git mirror later today). The oak-dev@ mailing list should follow up shortly, see INFRA-4514 [1]. I'm all in favor of having a nice and fancy working name, a separate jira and svn location, but are we sure we want to setup separate mailing lists as well? I'm afraid this might split up the jr community or in the best case everybody from the jr community subscribes to the new lists as well, which makes having the lists a bit superfluous. How do other people feel about this? personally i prefer separate mailing lists for oak. it does spare people interested in jackrabbit 2.x only from the chatter/buzz around oak. OTOH, if they're interested in oak they are free to subscribe to the dedicated oak lists. cheers stefan Regards, Bart
Re: Setting up Oak (Was: [RESULT] [VOTE] Codename for the jr3 implementation effort)
On Tue, Mar 6, 2012 at 1:00 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Tue, Mar 6, 2012 at 9:17 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: Oak has the advantage and so we'll go with that. I'll set up the new mailing list, issue tracker and svn space in a moment. The issue tracker is now available at https://issues.apache.org/jira/browse/OAK and the svn space is at http://svn.apache.org/repos/asf/jackrabbit/oak/ (I'll set up a Git mirror later today). The oak-dev@ mailing list should follow up shortly, see INFRA-4514 [1]. excellent, thanks! To get us started, I'll set up a basic multimodule build in oak/trunk along the lines of what we have in jackrabbit/trunk. As initial components I propose the following: * oak-core, for the main codebase (incl. unit tests) * oak-run, for a runnable jar packaging * oak-it, for integration tests * oak-bench, for performance tests We'll start building the Oak codebase under org.apache.jackrabbit.oak in oak-core. To avoid having to start from scratch, I propose that we copy the existing MK work from org.apache.jackrabbit.mk to under oak-core and gradually clean up and refactor relevant parts of the codebase to subpackages under o.a.j.oak. Other existing code from above the MK should probably treated similarly. agreed cheers stefan [1] https://issues.apache.org/jira/browse/INFRA-4514 BR, Jukka Zitting
Re: [jr3] Tree model
On Mon, Mar 5, 2012 at 2:10 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Mon, Mar 5, 2012 at 1:36 PM, Marcel Reutegger mreut...@adobe.com wrote: int getChildNodeCount(); this doesn't work well when you have concurrent child node operations. e.g. one session adds a child node while another session removes the child nodes. We're talking about an immutable state here, so the child node count never changes for a given NodeState instance. correct IMO it would be better if the number of child nodes is calculated by the caller. why do we have the method anyway? ;) The caller may well want to adapt it's functionality depending on whether a node has 10 or 10M child nodes. agreed cheers stefan IterableChildNodeEntry getChildNodeEntries(int offset, int length); doesn't this imply that the implementation will keep the child nodes in a list? Any implementation that supports orderable child nodes is necessarily some form of a list. The only extra bit here is that I'm expecting the implementation to be able to use a numeric index instead of some other pointer to indicate the starting point. That should be easily doable with most models of persistence. Also, the current MicroKernel interface assumes that the underlying storage model is able to use numeric indices. BR, Jukka Zitting
Re: [jr3] Tree model
On Mon, Mar 5, 2012 at 12:38 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
On Mon, Mar 5, 2012 at 11:25 AM, Thomas Mueller muel...@adobe.com wrote:
If we want to use distinct interfaces for read-only and writable nodes,
what about ImmutableNode and MutableNode extends ImmutableNode.
That's troublesome because then a client that's given an ImmutableNode
can't rely on the instance being immutable (because it could in fact
be a MutableNode instance).
Anyway, see https://gist.github.com/1977909 (and below) for my latest
draft of these interfaces. Note also the javadocs.
i am commenting from the mk POV, assuming that the proposed
interface is going to be used below the mk api.
i am generally in favor of your proposal. however, contrary to my earlier
statement, i strongly believe now that the order of child nodes is best
handled on an upper layer, like you originally suggested in this thread.
i.e.
Properties and child nodes are all addressed using an unordered
name-item mapping on the parent node.
what made me change my mind is that the JSON model
doesn't (naturally) support ordered child entries. i've forgot
about that and i guess that mandating order in a JSON-like
model spells trouble sooner or later.
i also realized that the overhead of handling order in an
upper layer (above the mk) is probably not too severe since
it's only required on child node iteration of 'orderable'
nodes. path resolutions e.g. wouldn't be affected.
for getChildNodeEntries() we can therefore drop the distinction
between user-defined and native order and just
state that the iteration order is stable.
cheers
stefan
ps: i am currently off work and can't follow the discussion
in real-time...
This draft is fairly close to the model already present in
o.a.j.mk.model, with the most crucial difference being that a
ChildNodeEntry returns a NodeState reference instead of just a content
id. In other words, the underlying addressing mechanism is hidden
below this interface.
Note that since we considered it best to decouple the methods for
accessing properties and child nodes, i.e. have getProperty(String)
and getNode(String) instead of just a getItem(String), it actually
makes sense to have a getName() method on the PropertyState instance.
Otherwise a separate PropertyEntry interface would be needed in order
to avoid unnecessary extra string lookups when iterating over all
properties. The desire to avoid extra lookups is also why I'd rather
use a separate interface for properties instead of adding extra
methods to NodeState.
BR,
Jukka Zitting
/**
* A content tree consists of nodes and properties, each of which
* evolves through different states during its lifecycle. This interface
* represents a specific, immutable state of a node in a content tree.
* Depending on context, a NodeState instance can be interpreted as
* representing the state of just that node, of the subtree starting at
* that node, or of an entire tree in case it's a root node.
* p
* The crucial difference between this interface and the similarly named
* class in Jackrabbit 2.x is that this interface represents a specific,
* immutable state of a node, whereas the Jackrabbit 2.x class represented
* the current state of a node.
*
* h2Properties and child nodes/h2
* p
* A node consists of an unordered set of properties, and an ordered set
* of child nodes. Each property and child node is uniquely named and a
* single name can only refer to a property or a child node, not both at
* the same time.
*
* h2Immutability and thread-safety/h2
* p
* As mentioned above, all node and property states are always immutable.
* Thus repeating a method call is always guaranteed to produce the same
* result as before unless some internal error occurs (see below). Note
* however that this immutability only applies to a specific state instance.
* Different states of a node can obviously be different, and in some cases
* even different instances of the same state may behave slightly differently.
* For example due to performance optimization or other similar changes the
* iteration order of properties may be different for two instances of the
* same node state. However, all such changes must file
* p
* In addition to being immutable, a specific state instance guaranteed to
* be fully thread-safe. Possible caching or other internal changes need to
* be properly synchronized so that any number of concurrent clients can
* safely access a state instance.
*
* h2Persistence and error-handling/h2
* p
* A node state can be (and often is) backed by local files or network
* resources. All IO operations or related concerns like caching should be
* handled transparently below this interface. Potential IO problems and
* recovery attempts like retrying a timed-out network access need to be
* handled below this interface, and only hard errors should be thrown up
* as {@link
Re: [jr3] Tree model
On Thu, Mar 1, 2012 at 8:13 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, It looks my initial attempt at this didn't work too well, as my intention wasn't clear enough and the interface draft I included seemed to raise mostly concerns about technicalities (too many methods, etc.) instead of the fundamental design tradeoffs I was trying to highlight. So let's try this again. What I'm looking for is a clear, shared idea of what a jr3 content tree looks like at a low level (i.e. before stuff like node types, etc.) since the current MK interface leaves many of those details unspecified. Here's what the MK interface currently says about this: * The MicroKernel bData Model/b: * ul * lisimple JSON-inspired data model: just nodes and properties/li * lia node is represented as an object, consisting of an unordered collection * of properties and an array of (child) node objects/li * liproperties are represented as name/value pairs/li * liMVPs are represented as name/array-of-values pairs/li * lisupported property types: string, number/li * liother property types (weak/hard reference, date, etc) would need to be * encoded/mangled in name or value/li * lino support for JCR/XML-like namespaces, foo:bar is just an ordinary name/li * liproperties and child nodes share the same namespace, i.e. a property and * a child node, sharing the same parent node, cannot have the same name/li * /ul please note that the above is somehow outdated, e.g. MVPs are IMO just regular properties where the values are encoded in a single string (transparent to the mk). There are a few complications and missing details with this model (as documented) that I tried to address in my original proposal. The most notable are: thanks for bringing this up! comments follow inline... * The data model specifies that a node contains an an array of (child) node objects and seems to imply that child nodes are always orderable. This is a major design constraint for the underlying storage model that doesn't seem necessary (a higher-level component could store ordering information explicitly) or desirable (see past discussions on this). To avoid this I think child nodes should be treated as an unordered set of name/node mappings. i don't think that it is a major design constraint in general. since in a jcr repository a lot of content is expected to be ordered (- nt:unstructured) we should IMO support this in the mk and don't delegate this to the upper layer. i agree that very 'flat' nodes are a special case. how about stating something along the line of: child nodes are an orderable (implying 'ordered' of course) set of name/node mappings. however, if the size of the set exceeds a certain (discoverable?) trheshold, it might just ordered, but not orderable. * Another unspecified bit is whether same-name-siblings need to be supported on the storage level. The MK implies that SNSs are not supported (i.e. a higher level component needs to use things like name mangling to implement SNSs on top of the MK), but the note about an *array* of (child) node objects kind of leaves the door open for two child nodes to (perhaps accidentally) have the same name. For also this reason I think child nodes should be treated as a map from names to corresponding nodes. agreed, good point. * The data model doesn't specify whether the name of a node is an integral part of the node itself. The implementation(s) clarify (IMHO correctly) that the name of each child node is more logically a part of the parent node. Thus, unlike in JCR, there should be no getName() method on a low-level interface for nodes. correct. * Somewhat contrary to the above, the data model specifies properties as name/value pairs. The MK interface doesn't allow individual properties to be accessed separately, so this detail doesn't show up too much in practice. However, in terms of an internal API it would be useful to keep properties mostly analogous to child nodes. Thus there should be no getName() method on a low-level interface for properties (or, perhaps more accurately, values). * The data model says that properties and child nodes share the same namespace but treats properties and child nodes differently in other aspects (properties as an unordered collection, child nodes as an array). This seems like an unnecessary complication that's likely to cause trouble down the line (e.g. where and how will we enforce this constraint?). From an API point of view it would be cleanest either to treat both properties and child nodes equally (like having all as parts of a single unordered set of name/item mappings) or to allow and use a completely separate spaces for property and child node names. properties and child nodes sharing the same namespace is IMO an important requirement since we want to be close to the json model. for the tree abstraction (representing an immutable hierarchy) i am fine with
Re: [VOTE] Codename for the jr3 implementation effort (Was: [jr3] Codename)
Thus, please vote on which of these two codenames we should use for the jr3 implementation effort: [x] Oak cheers stefan
Re: [jr3] implicit assumptions in MK design?
On Thu, Mar 1, 2012 at 2:53 PM, Michael Marth mma...@adobe.com wrote: Hi Dom, Are you suggesting, that cluster sync will be provided purely by the underlying NoSQL database? Yes, that's what I meant. well that's one possible approach. cheers stefan Michael -- Michael Marth | Engineering Manager +41 61 226 55 22 | mma...@adobe.com Barfüsserplatz 6, CH-4001 Basel, Switzerland On Mar 1, 2012, at 2:25 PM, Dominique Pfister wrote: Hi Michael, Are you suggesting, that cluster sync will be provided purely by the underlying NoSQL database? Until now, I always assumed that all cluster nodes expose an MK interface, and that changes are transmitted to other nodes via calls on this MK interface. So in your example, cluster node 2 would see a delete /a/b and the question of a broken tree never arises. Regards Dominique On Mar 1, 2012, at 1:53 PM, Michael Marth wrote: Hi, I have thought a bit about how one could go about implementing a micro kernel based on a NoSQL database (think Cassandra or Mongo) where a JCR node would probably be stored as an individual document and the MK implementation would provide the tree on top of that. Consider that you have two or more cluster nodes of such an NoSQL db (each receiving writes from a different SPI) and that these two cluster nodes would be eventually consistent. It is easy to imagine cases where the tree structure of one node will be temporarily broken (at least for specific implementations, see example below). I am not particularly worried about that, but I wonder if the MK interface design implicitly assumes that the MK always exposes a non-broken tree to the SPI. The second question I have if we assume that a particular version of the tree the MK exposes to the SPI is stable over time (or: can it be the case that the SPI refreshes the current version it might see a different tree. Again, example below)? I think we should be explicit about these assumptions or non-assumtptions because either the MK implementer has to take care of them or the higher levels (SPI, client) have to deal with them. Michael (*) example from above: consider node structure /a/b/c. On on cluster node 1 JCR node b is deleted. In order to implement that in a document db the MK on cluster node 1 would need to separately delete b and c. The second cluster node could receive the deletion of b first. So for some time there would be a JCR node c on cluster node 2 that has no parent. example regarding tree version stability: suppose in the example above that tree version 1 is /a/b/c and tree version 2 is /a. Because deleting b and c will arrive on cluster node 2 as separate events there must either be some additional communication between the cluster nodes so that cluster node 2 knows when tree version 2 is fully replicated. Or cluster node 2 will expose a tree version 2 that first looks like /a/b and later as /a (i.e. the same version number's tree will change over time)
Re: [jr3] Tree model
On Wed, Feb 29, 2012 at 12:01 AM, Jukka Zitting jukka.zitt...@gmail.com wrote:
Hi,
On Tue, Feb 28, 2012 at 6:21 PM, Jukka Zitting jukka.zitt...@gmail.com
wrote:
I guess you'd agree that the MicroKernel API covers a lot more
functionality than the Tree/Leaf interfaces I drafted. Someone
implementing the MicroKernel needs abstractions like Tree/Leaf and a
lot more besides.
To make this clearer, see https://gist.github.com/1935626 (or the end
of this message) for a draft of how a MicroKernel implementation could
use the proposed Tree API to implement the MK read operations.
The draft relies on three extra methods: getTree(),
splitPathToElements() and serializeToJson(), all of which can be
implemented (and optimized) separately. Most notably all handing of
possible caching layers, virtual content trees, etc. can be localized
inside the getTree() method with no need to involve and change any of
the code in the other methods. That's the kind of separation of
concerns I'm looking for.
Compare that to the existing sandbox/microkernel codebase, and you
notice how the equivalent code is split across the MicroKernelImpl,
Repository and RevisionProvider/DefaultRevisionStore classes. Along
that path a lot of assumptions about the underlying storage model get
made (for example that all nodes are accessible by a string id), and a
more or less hardcoded caching mechanism gets introduced. My hope with
the proposed Tree interface is to provide a simple way to address such
issues and thus, through a shared API, make it easier to divide and
coordinate work on them.
i agree. the sandbox project was meant as a prototype/POC and certainly
far from being perfect.
i like the idea of a cleaner abstraction of the hierarchical model beneath
the MicroKernel api, such as the proposed Tree interface. however,
when it comes to trading efficiency for usability we should focus on
efficiency in the MicroKernel implementation.
i am e.g. concerned about the java.util.Map dependency. problematic
methods are IMO entrySet(), keySet(), containsValue() and values().
objects exposing the Map interface are usually assumed to be
fully contained in memory (at least that's my perception) and
methods like entrySet(), keySet() etc very efficient.
now consider nodes with millions of direct child nodes.
calling tree.values() will either blow your heap or requires
a non-trivial, rather complex implementation.
therefore, i'd prefer that the Tree interface didn't extend Map
but rather expose the specific methods required by a
MicroKernel implementation.
cheers
stefan
BR,
Jukka Zitting
public class MicroKernelImpl implements MicroKernel {
public boolean nodeExists(String path, String revisionId)
throws MicroKernelException {
Tree tree = getTree(revisionId);
for (String name : splitPathToElements(path)) {
if (tree == null) {
return false;
}
tree = tree.get(name);
}
return tree != null !tree.isLeaf();
}
public String getNodes(String path, String revisionId)
throws MicroKernelException {
return getNodes(path, revisionId, 1, 0, -1);
}
public String getNodes(
String path, String revisionId, int depth, long offset, int count)
throws MicroKernelException {
Tree tree = getTree(revisionId);
for (String name : splitPathToElements(path)) {
if (tree == null) {
throw new MicroKernelException(Path not found: + path);
}
tree = tree.get(name);
}
if (tree != null !tree.isLeaf()) {
return serializeToJson(tree, depth, offset, count);
} else {
throw new MicroKernelException(Path not found: + path);
}
}
}
Re: [jr3] Tree model
On Wed, Feb 29, 2012 at 8:55 AM, Thomas Mueller muel...@adobe.com wrote: Hi, I think we all have more or less the same basic idea. Well, I would call it Node and not Tree because the term node more closely matches what we do. But first about what we seem to agree: * A persistent and immutable data structure has many benefits (for example concurrency). * Mutable data strucutures also have benefits: it avoids creating lots of garbage and a new root node for each and every modification. I think we should use a structure that is immutable when reading, but mutable when writing. Write methods should return a new object (for example cloneAndAddChildNode), but only when necessary, that is, if the revision doesn't match. When the revision matches, the internal state is changed instead, and the cloneAndAddChildNode method returns 'this'. A first implementation is org.apache.jackrabbit.mk.simple.NodeImpl. everyone has their own MicroKernel implementation. i won't comment on why we suddenly ended up with 2 independent and supposedly competing implementations of the MicroKernel API within the same sandbox project. that's the subject of a private discussion i am having with thomas. apart from that, some comments/clarifications follow inline... The reasons why we have two implementations is, Stefan and I could not agree on a few implementation details. My view is: * Stefan assumes it's important to use the content hash as the node id, while I think this hurts performance too much (as the randomly distributed node ids hurt storage performance in Jackrabbit 2). With the copy-on-write model it is even a bigger performance problem because each time a node is changed it gets a new node id (I didn't think about this first). That means even small repositories are problematic if there are many changes. when i started the MicroKernel sandbox project about a year ago i thought (and still think so) that a microkernel should support clustering ootb. furthermore, mvcc seemed to be a promising approach to address the concurrency issues we're suffering from in jackrabbit v1-2.*. there are not that many hierarchical mvcc-based repositories around to learn from. the obvious candidates IMO were svn and git. while svn and git do use a very similar internal versioning model one important difference is the choice of identifiers. svn uses a numeric counter while git is based on a content-addressed (hash) model, the content-hash identifiers are a key aspect of git's architecture. svn is client-server based while git uses a decentralized distributed model. my assumption was that our clustering implementation could leverage the content-addressed model since it should e.g. make it easier to sync remote (sub)trees based on the content hash. so far, WRT a clustering implementation, we're still on square 1. as long as we don't have a clear idea of how to support clustering i am rather reluctant to already give up on the content-addressable model. * Stefan implemented a different way to represent large child node lists. He used a h-tree (the hash code of the child node name), which means child nodes are pseudo-randomly distributed. I think this hurts performance too much (same reason as above: a stored index on randomly distributed keys is required). the h-tree approach was my first take at supporting flat hierarchies. it's intentionally simple and does have a few advantages (e.g. efficient diffing of 2 large child node entries collections) it's probably not the final answer to the problem of flat hierarchies. since we can't assume that child node names do follow a specific pattern (e.g. n1-n) i don't follow your performance-related reasoning. * Stefan believes concurrent write operations are very important while I believe this will not increase write throughput as much as it complicates the implementation (Stefan implementations merges changes while my implementation does not). * Stefans implementation re-constructs the journal by diffing the node tree. I believe this is troublesome because it is not always possible to re-construct the journal with regards to re-order and move operations. Also I believe this adds more complexity that the possible benefit (because the journal doesn't need to be stored). In my implementation the journal is stored. i've considered storing the diff of a commit in the revision a while ago. while it would be relatively easy to implement i currently don't see an immediate benefit compared to diffing which OTOH is very efficient thanks to the content-addressable model. i imagine that in a clustering scenario there's a need to compute the changes between 2 non-consecutive revisions, potentially spanning a large number of intermediate revisions. just diffing 2 revsisions is IMO probably more efficient than reconstructing the changes from a large number of revisions. cheers stefan There is quite a lot of common code, for example the data store,
Re: [jr3 optional features]
On Tue, Feb 28, 2012 at 3:19 PM, Michael Dürig mic...@gmail.com wrote: On 28.2.12 13:17, Alexander Klimetschek wrote: Am 23.02.2012 um 12:33 schrieb Michael Dürig: Having node.type.management.orderable.child.nodes.supported = false might be a bit harsh. But orderable child node lists and large number of child nodes are definitely in each other's way. I think we should come up with a way to let users choose. Users can already chose: using the node type parameter orderable. A repository-global decision to use either or does not really help, as in most cases you will have the need for both cases (huge unordered bunch + smaller ordered list). That's right and I think this is the way to go. We should however make it clear, that having orderable child nodes comes with a cost. A remaining issue is that currently nt:unstructured is orderable. So we might want to factor orderable out into a mixin. i have no idea how that would work. can you please give an example? we could add a new node type (e.g. nt:scalable), specified like nt:unstructered but with orderable=false. cheers stefan Michael
Re: [jr3] Strategic plan
On Thu, Feb 23, 2012 at 2:04 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Thu, Feb 23, 2012 at 12:45 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Based on the various recent and older discussions, here's my very high-level suggestion on what to target and how to reach it. I put this proposal up on the wiki at [1] so we can iterate it based on emerging consensus. [1] http://wiki.apache.org/jackrabbit/Jackrabbit%203%20Strategic%20Plan +1, very well put! thanks, jukka. cheers stefan BR, Jukka Zitting
Re: [jr3 Microkernel] equals() not symmetric
On Thu, Feb 9, 2012 at 11:45 PM, Michael Dürig mdue...@apache.org wrote: Hi, I stumbled upon this by chance: The equals method for the classes ChildNodeEntriesMap and ChildNodeEntry is not symmetric. hmm, i am pretty sure they're symmetric, i.e.: a.equals(b) == b.equals(a) or are you referring to the missing hashCode() override? i admit that i've been lazy since those internal objects are not intended to be used as keys for hash tables and sorts. but you're probably right, it doesn't hurt to implement them :) cheers stefan This will most certainly lead to subtle bugs later on. Michael
Re: [jr3 Microkernel] equals() not symmetric
On Fri, Feb 10, 2012 at 12:00 PM, Ard Schrijvers a.schrijv...@onehippo.com wrote: On Fri, Feb 10, 2012 at 11:41 AM, Stefan Guggisberg stefan.guggisb...@gmail.com wrote: On Thu, Feb 9, 2012 at 11:45 PM, Michael Dürig mdue...@apache.org wrote: Hi, I stumbled upon this by chance: The equals method for the classes ChildNodeEntriesMap and ChildNodeEntry is not symmetric. hmm, i am pretty sure they're symmetric, i.e.: a.equals(b) == b.equals(a) They look symmetric to me as well. Unless you refer to the Bucket innerclass ChildNodeEntriesMap#Bucket : This one has an invalid equals method - ChildNodeEntriesTree#Bucket breaking symmetry : Using super.equals in an equals implementation almost always breaks symmetry good catch! thanks stefan Regards Ard or are you referring to the missing hashCode() override? i admit that i've been lazy since those internal objects are not intended to be used as keys for hash tables and sorts. but you're probably right, it doesn't hurt to implement them :) cheers stefan This will most certainly lead to subtle bugs later on. Michael -- Amsterdam - Oosteinde 11, 1017 WT Amsterdam Boston - 1 Broadway, Cambridge, MA 02142 US +1 877 414 4776 (toll free) Europe +31(0)20 522 4466 www.onehippo.com
Re: [jr3 microkernel] Change log consolidation
On Sun, Feb 5, 2012 at 6:25 PM, Michael Dürig mdue...@apache.org wrote: On 4.2.12 20:07, Stefan Guggisberg wrote: On Fri, Feb 3, 2012 at 7:44 PM, Michael Dürigmdue...@apache.org wrote: Hi, While working on a new transient space implementation [1] I discovered that recreating a list of changes from transient modifications to the hierarchy is like opening a can of worms. Rethinking things it turned out, that it is much simpler to directly consolidate the change log. This approach is much more flexible and versatile since knowledge of the persisted hierarchy is not necessary at all. Thus this approach should work equally well with change logs for jr3, the Microkernel, Jackrabbit core, JCR and SPI. The algorithm is capable of creating minimal change logs from any valid change log (that is from any change log that can be applied to some hierarchy). I extensively tested the algorithm on randomly created change logs [3]. This resulted in some interesting numbers: consolidation results in an decrease of about 45% of these randomly generated change logs. Furthermore the resulting size of the H2 database files *decreased up to 200%*! The implementation [2] is currently part of the jackrabbit-microkernel module in the sandbox. However it does not have any crucial dependencies so it should be easy to adapt for other usages. The gory details of the algorithm are based on some algebraic properties of move operations on paths as detailed in the following paragraphs. The change log consolidation algorithm implemented in the reduce method [2] is based on algebraic properties of move operations on paths. The other operations (add node, remove node and set property) are generalized to move operations. Consolidation relies on reduction and commutation rules of move operations. A move operation resembles a map on a hierarchy (of nodes and properties). A change log consisting of k move operations m_1 to m_k is thus the composition of the individual moves: m_1 *, ..., * m_k (using * for function composition: f(g(x)) = (f * g)(x)). Some definitions, notation and propositions: * Let NIL denote a path which never occurs in any hierarchy. * Order on paths: let p, q be paths. - p q iff p != NIL and q != NIL and p is an ancestor of q. - p= q iff p q or p == q != NIL * Conflict of paths: let p, q be paths. - p ~ q (p conflicts with q) iff either p= q or q= p * Substitution in paths: let p, q, r be paths. - [p - q]r = r if p is not an ancestor of r and - [p - q]r = s where s is the path resulting from replacing the ancestor p in r with q otherwise. * Let p, q be paths. Then p:q denotes a move operation where the node at p is moved to a new node at q. * Valid moves: leq p, q be paths. - p:q is valid iff p !~ q or p = q - if p:q is not valid, it is invalid Invalid moves are exactly those which would result in a node being moved to an ancestor/descendant of itself. * Identity on moves: let p, q be paths. - p:q = ID iff p = q. * Conflict on moves: let p, q, r, s be paths. - p:q ~ r:s (p:q conflicts with r:s) iff either p ~ r or p ~ s or q ~ r or q ~ s. * Strict commutativity of moves: let m, n be moves. - m * n = n * m iff m !~ n * Substitutions in moves: let p, q, r, s be paths. - [p - q]r:s = [p - q]r:[p - q]s * Let p be a path and let +p denote an add node operation and let -p denote a remove node operation for a node at path p. - +p = NIL:p That is, adding a node is represented by a move from a unknown source. - p = p:NIL. That is, removing a node is represented by a move to an unknown sink. Let m = p:q, n = r:s with p, q, r, s != NIL be valid moves with m != ID and n != ID. Then the following reduction and commutation rules apply: 1. p!~ r: m * n = n * m 2. p r: illegal (since this implies q= r which implies p ~ q and thus m invalid) 3. p = r: illegal (since this implies q= r which implies p ~ q and this m invalid) 4. p r: does not commute if q s. Otherwise m * n = n * [r - s]m 5. p!~ s: m * n = n * m 6. p s: illegal (since this implies p ~ q and thus m invalid) 7. p = s: does not commute 8. p s: illegal (since p s implies there is an s already which will conflict with r:s) 9. q!~ r: m * n = n * m 10. q r: m * n = [q - p]n * m 11. q = r: m * n = p:s (transitivity of moves) 12. q r: m * n = n * [r - s]m 13. q!~ s: m * n = n * m 14. q s: does not commute if p r. Otherwise m * n = [q - p]n * m 15. q = s: illegal (since s conflicts with r:s) 16. q s: illegal (since s conflicts with r:s) Allowing add node and remove node operations the following additional conditions apply: Let m = p:q, n = r:s be valid moves with m != ID and n != ID. Then the reduction and commutations rules 1. to 16. apply with extra conditions on 4., 10., 12. and 14.: 4'. if s = NIL and q = NIL then m * n = -r. Otherwise if s
Re: [jr3 microkernel] Change log consolidation
On Mon, Feb 6, 2012 at 2:27 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Mon, Feb 6, 2012 at 1:53 PM, Michael Dürig mdue...@apache.org wrote: An alternative that AFAICT achieves the same effect in perhaps an easier to understand manner would be to use the state of the content tree instead of changes to that state as the key concept. [...] That's more or less what I started with [1] and what I referred to as can of worms in my original mail. Detecting and normalizing/consolidating moves turned out to be too tricky there. You basically have the same cases I identified (1. - 16.) but its much more difficult to tell them apart. Instead of separate Added/Existing/Moved/Removed instances in the ChangeTree, did you consider keeping the modified content just as (say) TransientNode instances, without trying to keep track of how they came to exist? Then, when you actually need the change log, you should still be able to construct it by diffing the transient tree against the persistent base state of the content tree. The only caveat I know of is that moves can only be reliably detected for referenceable nodes or ones with an equivalent internal unique ID (which we shouldn't have trouble doing if needed). BTW, that's how it the transient space is implemented in the current jackrabbit-core. cheers stefan BR, Jukka Zitting
Re: [jr3 microkernel] Change log consolidation
On Mon, Feb 6, 2012 at 2:39 PM, Thomas Mueller muel...@adobe.com wrote: Hi, Instead of separate Added/Existing/Moved/Removed instances in the ChangeTree, did you consider keeping the modified content just as (say) TransientNode instances, without trying to keep track of how they came to exist? Then, when you actually need the change log, you should still be able to construct it by diffing the transient tree against the persistent base state of the content tree. The only caveat I know of is that moves can only be reliably detected for referenceable nodes or ones with an equivalent internal unique ID (which we shouldn't have trouble doing if needed). So far we don't have any internal unique ID, and I would rather not add one. I think reconstructing the changes by comparing the data is (a) unnecessarily complicated i don't agree, why would that be complicated? when using a content-addressable model diff'ing get's even extremely efficient. (b) wouldn't work for some cases and therefore break observation i partially agree. however, the current jackrabbit implementation creates events based on diff'ing states and IMO it works pretty well in practice. i am not aware of real world uses cases affected. The JCR API does define operations (move, add, remove, reorder...), and for observation we need them. The most simple solution is to keep the events. Why throw the events away if you need them later. An example for (b) is multiple reorder operations within the same node. personally i don't see the practical value in representing multiple reorder operations within a single save rather than consolidating them. cheers stefan Regards, Thomas
Re: [jr3 microkernel] Change log consolidation
On Mon, Feb 6, 2012 at 3:10 PM, Julian Reschke julian.resc...@gmx.de wrote: On 2012-02-06 15:02, Stefan Guggisberg wrote: On Mon, Feb 6, 2012 at 2:39 PM, Thomas Muellermuel...@adobe.com wrote: Hi, Instead of separate Added/Existing/Moved/Removed instances in the ChangeTree, did you consider keeping the modified content just as (say) TransientNode instances, without trying to keep track of how they came to exist? Then, when you actually need the change log, you should still be able to construct it by diffing the transient tree against the persistent base state of the content tree. The only caveat I know of is that moves can only be reliably detected for referenceable nodes or ones with an equivalent internal unique ID (which we shouldn't have trouble doing if needed). So far we don't have any internal unique ID, and I would rather not add one. I think reconstructing the changes by comparing the data is (a) unnecessarily complicated i don't agree, why would that be complicated? when using a content-addressable model diff'ing get's even extremely efficient. (b) wouldn't work for some cases and therefore break observation i partially agree. however, the current jackrabbit implementation creates events based on diff'ing states and IMO it works pretty well in practice. i am not aware of real world uses cases affected. https://issues.apache.org/jira/browse/JCR-3207 agreed, but personally i don't consider this a real world use case. cheers stefan ... Best regards, Julian
Re: [jr3 microkernel] Change log consolidation
On Mon, Feb 6, 2012 at 3:23 PM, Michael Dürig mdue...@apache.org wrote:
- Much simpler.
erm, i beg to differ ... ;)
So do I ;-)
Apart from the benefits, it is a plain necessity for transient space
implementations on top of the Microkernel: without proper consolidation
users could end up not being able to save their (valid) transient
modifications. Consider a first user doing
/a:/t/x +/t/x/y:{}/t/x:/b
if in the meanwhile another user removes x the save operation for the
first
user would fail.
how could another user remove /t/x? it only exists in the first user's
transient space.
Sorry typo. My last sentence should read: if in the meanwhile another user
removes *+/t* the save operation for the first user would fail.
ok, that's a valid point.
cheers
stefan
Michael
cheers
stefan
After consolidation, above change log would look like
+/a/y:{}/a:/b
and can be saved.
Michael
cheers
stefan
Michael
[1] http://markmail.org/message/qkkcvtmtapas2cx4
[2]
http://svn.apache.org/viewvc/jackrabbit/sandbox/jackrabbit-microkernel/src/main/java/org/apache/jackrabbit/state/ChangeLog.java?view=markup
[3]
http://svn.apache.org/viewvc/jackrabbit/sandbox/jackrabbit-microkernel/src/test/java/org/apache/jackrabbit/state/ChangeLogFuzzTest.java?view=markup
Re: [jr3 microkernel] Change log consolidation
On Fri, Feb 3, 2012 at 7:44 PM, Michael Dürig mdue...@apache.org wrote: Hi, While working on a new transient space implementation [1] I discovered that recreating a list of changes from transient modifications to the hierarchy is like opening a can of worms. Rethinking things it turned out, that it is much simpler to directly consolidate the change log. This approach is much more flexible and versatile since knowledge of the persisted hierarchy is not necessary at all. Thus this approach should work equally well with change logs for jr3, the Microkernel, Jackrabbit core, JCR and SPI. The algorithm is capable of creating minimal change logs from any valid change log (that is from any change log that can be applied to some hierarchy). I extensively tested the algorithm on randomly created change logs [3]. This resulted in some interesting numbers: consolidation results in an decrease of about 45% of these randomly generated change logs. Furthermore the resulting size of the H2 database files *decreased up to 200%*! The implementation [2] is currently part of the jackrabbit-microkernel module in the sandbox. However it does not have any crucial dependencies so it should be easy to adapt for other usages. The gory details of the algorithm are based on some algebraic properties of move operations on paths as detailed in the following paragraphs. The change log consolidation algorithm implemented in the reduce method [2] is based on algebraic properties of move operations on paths. The other operations (add node, remove node and set property) are generalized to move operations. Consolidation relies on reduction and commutation rules of move operations. A move operation resembles a map on a hierarchy (of nodes and properties). A change log consisting of k move operations m_1 to m_k is thus the composition of the individual moves: m_1 *, ..., * m_k (using * for function composition: f(g(x)) = (f * g)(x)). Some definitions, notation and propositions: * Let NIL denote a path which never occurs in any hierarchy. * Order on paths: let p, q be paths. - p q iff p != NIL and q != NIL and p is an ancestor of q. - p = q iff p q or p == q != NIL * Conflict of paths: let p, q be paths. - p ~ q (p conflicts with q) iff either p = q or q = p * Substitution in paths: let p, q, r be paths. - [p - q]r = r if p is not an ancestor of r and - [p - q]r = s where s is the path resulting from replacing the ancestor p in r with q otherwise. * Let p, q be paths. Then p:q denotes a move operation where the node at p is moved to a new node at q. * Valid moves: leq p, q be paths. - p:q is valid iff p !~ q or p = q - if p:q is not valid, it is invalid Invalid moves are exactly those which would result in a node being moved to an ancestor/descendant of itself. * Identity on moves: let p, q be paths. - p:q = ID iff p = q. * Conflict on moves: let p, q, r, s be paths. - p:q ~ r:s (p:q conflicts with r:s) iff either p ~ r or p ~ s or q ~ r or q ~ s. * Strict commutativity of moves: let m, n be moves. - m * n = n * m iff m !~ n * Substitutions in moves: let p, q, r, s be paths. - [p - q]r:s = [p - q]r:[p - q]s * Let p be a path and let +p denote an add node operation and let -p denote a remove node operation for a node at path p. - +p = NIL:p That is, adding a node is represented by a move from a unknown source. - p = p:NIL. That is, removing a node is represented by a move to an unknown sink. Let m = p:q, n = r:s with p, q, r, s != NIL be valid moves with m != ID and n != ID. Then the following reduction and commutation rules apply: 1. p!~ r: m * n = n * m 2. p r: illegal (since this implies q = r which implies p ~ q and thus m invalid) 3. p = r: illegal (since this implies q = r which implies p ~ q and this m invalid) 4. p r: does not commute if q s. Otherwise m * n = n * [r - s]m 5. p!~ s: m * n = n * m 6. p s: illegal (since this implies p ~ q and thus m invalid) 7. p = s: does not commute 8. p s: illegal (since p s implies there is an s already which will conflict with r:s) 9. q!~ r: m * n = n * m 10. q r: m * n = [q - p]n * m 11. q = r: m * n = p:s (transitivity of moves) 12. q r: m * n = n * [r - s]m 13. q!~ s: m * n = n * m 14. q s: does not commute if p r. Otherwise m * n = [q - p]n * m 15. q = s: illegal (since s conflicts with r:s) 16. q s: illegal (since s conflicts with r:s) Allowing add node and remove node operations the following additional conditions apply: Let m = p:q, n = r:s be valid moves with m != ID and n != ID. Then the reduction and commutations rules 1. to 16. apply with extra conditions on 4., 10., 12. and 14.: 4'. if s = NIL and q = NIL then m * n = -r. Otherwise if s = NIL then m, n do not commute. 10'. illegal if p = NIL 12'. if s = NIL then m * n = -r * -p 14'. illegal if p = NIL sounds very
Re: [jr3 Microkernel] compiler settings in pom.xml
On Tue, Jan 31, 2012 at 9:21 AM, Thomas Mueller muel...@adobe.com wrote: Hi, +1 for changing to 1.6. yup. cheers stefan Regards, Thomas On 1/30/12 5:54 PM, Dominique Pfister dpfis...@adobe.com wrote: Hi, Just stumbled across this compilation setting in microkernel's pom.xml: plugin artifactIdmaven-compiler-plugin/artifactId version2.3.2/version configuration source1.5/source target1.5/target /configuration /plugin When actually _using_ a 1.5 jdk (on Mac OS X this can be done with the Java Preferences tool), the maven-compiler-plugin will report 12 errors due to use of Java 1.6 methods. So my question is: should we change this setting from 1.5 to 1.6 (which I favor) or review our code? Regards Dominique
Re: [jr3 Microkernel] compiler settings in pom.xml
On Tue, Jan 31, 2012 at 12:28 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Mon, Jan 30, 2012 at 5:54 PM, Dominique Pfister dpfis...@adobe.com wrote: So my question is: should we change this setting from 1.5 to 1.6 (which I favor) or review our code? +1 to 1.6 And while we're at it, would people be interested in using a language enhancement tool like Lombok [1] to reduce the amount of commonly needed boilerplate code? The downside is that the such custom extensions increase the entry barrier for people trying to understand the code and might make some tool integration (debugging, etc.) a bit harder. Personally I think the benefits would be worth it. [1] http://projectlombok.org/ -0, i am not a big fan of *magic* code generating frameworks. i prefer to see (and debug) plain java code in my ide. cheers stefan BR, Jukka Zitting
[jira] [Commented] (JCR-3221) Jackrabbit in Sling won't bootstrap against oracle
[ https://issues.apache.org/jira/browse/JCR-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13195533#comment-13195533 ] Stefan Guggisberg commented on JCR-3221: Rohit Nijhawan added a comment - 27/Jan/12 22:31 [...] Even against derby (Remember, there are no unique constraint indexes on the derby ddl) [...] FWIW: there's a PRIMARY KEY constraint in the CREATE TABLE statement. a primary key *uniquely* identifies a row in the table. Jackrabbit in Sling won't bootstrap against oracle -- Key: JCR-3221 URL: https://issues.apache.org/jira/browse/JCR-3221 Project: Jackrabbit Content Repository Issue Type: Test Components: config Affects Versions: 2.2.10 Environment: Windows 7, Java JRE 1.6.0_29 Reporter: Rohit Nijhawan Original Estimate: 48h Remaining Estimate: 48h 1. Trying to use jackrabbit persistence config to Oracle under Sling 2. Trying to run the jackrabbit standalone server against Oracle in Sling, seeing this error repeatedly. If I run a DELETE FROM JCR_DEFAULT_BUNDLE, the server starts up in sling but only 28/75 bundles are active and only 101/152 services launch after all the bundles are manually made active by pressing the || play button beside them. AuthenticationSupport service never runs. I can log in but not upload content. And in the the jackrabbit standalone server, if I delete from JCR_DEFAULT_BUNDLE, the server never starts up fully. It stays at Starting the server... I have tried both: the pool.OraclePersistenceManager and bundle.OraclePersistenceManager classes. I've seen similar issues with 'writing the bundle' error but not one that was enforced on a unique constraint from an index. 2012-01-26 10:32:14.533 ERROR [main] BundleDbPersistenceManager.java:1108 FATAL error while writing the bundle: deadbeef-cafe-babe-cafe-babecafebabe java.sql.SQLException: ORA-1: unique constraint (MIC_COMMON_SB.JCR_DEFAULT_BUNDLE_IDX) violated at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:113) ~[na:Oracle JDBC Driver version - 10.2.0.5.0] at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331) ~[na:Oracle JDBC Driver version - 10.2.0.5.0] at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288) ~[na:Oracle JDBC Driver version - 10.2.0.5.0] at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:754) ~[na:Oracle JDBC Driver version - 10.2.0.5.0] at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:219) ~[na:Oracle JDBC Driver version - 10.2.0.5.0] at oracle.jdbc.driver.T4CPreparedStatement.executeForRows(T4CPreparedStatement.java:972) ~[na:Oracle JDBC Driver version - 10.2.0.5.0] at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1192) ~[na:Oracle JDBC Driver version - 10.2.0.5.0] at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3415) ~[na:Oracle JDBC Driver version - 10.2.0.5.0] at oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:3521) ~[na:Oracle JDBC Driver version - 10.2.0.5.0] at org.apache.commons.dbcp.DelegatingPreparedStatement.execute(DelegatingPreparedStatement.java:169) ~[jackrabbit-standalone-2.2.10.jar:na] at org.apache.commons.dbcp.DelegatingPreparedStatement.execute(DelegatingPreparedStatement.java:169) ~[jackrabbit-standalone-2.2.10.jar:na] at org.apache.jackrabbit.core.util.db.ConnectionHelper.execute(ConnectionHelper.java:474) ~[jackrabbit-standalone-2.2.10.jar:na] at org.apache.jackrabbit.core.util.db.ConnectionHelper.reallyUpdate(ConnectionHelper.java:335) ~[jackrabbit-standalone-2.2.10.jar:na] at org.apache.jackrabbit.core.util.db.ConnectionHelper$2.call(ConnectionHelper.java:323) ~[jackrabbit-standalone-2.2.10.jar:na] at org.apache.jackrabbit.core.util.db.ConnectionHelper$2.call(ConnectionHelper.java:319) ~[jackrabbit-standalone-2.2.10.jar:na] at org.apache.jackrabbit.core.util.db.ConnectionHelper$RetryManager.doTry(ConnectionHelper.java:487) ~[jackrabbit-standalone-2.2.10.jar:na] at org.apache.jackrabbit.core.util.db.ConnectionHelper.update(ConnectionHelper.java:319) ~[jackrabbit-standalone-2.2.10.jar:na] at org.apache.jackrabbit.core.persistence.pool.BundleDbPersistenceManager.storeBundle(BundleDbPersistenceManager.java:1095) [jackrabbit-standalone-2.2.10.jar:na] at org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.putBundle(AbstractBundlePersistenceManager.java:699) [jackrabbit-standalone-2.2.10.jar:na
Re: Reloading node types in clustered environment
On Fri, Jan 27, 2012 at 10:35 AM, Berry van Halderen b.vanhalde...@1hippo.com wrote: On Tue, Dec 6, 2011 at 4:40 PM, Berry van Halderen b.vanhalde...@1hippo.com wrote: We've run into log messages that have come us to suspect one of our practices, namely to reregister node types. The reregistering occurs in a clustered environment, where other clustered nodes keep on using the node types, but on rare occasion certain exceptions are thrown, most particular an exception from getEffetiveNodeType when retrieving a node from the persistent store. I've still to evaluate if it is indeed the case, but we're wondering if it is at all safe to do changing node type operations in a clustered environment. Note, before 2.2.x we did not see these kind of errors, currently on 2.2.9 we are. I was able myself to track it down. It turns out that before re-registering there was also a call to unregister a node type. That caused a small gap between the unregister and the re-register where other cluster nodes could have received the unregister but not the new type. I've fixed this in our own code, but still I'm a bit worried about this change of behavior It used to be impossible to unregister a node type when it was still in use (or at least never to unregister a node type). Not being able to unregister a node type when still in use seems to be the most correct semantics. agreed, but unortunately also the most expensive/difficult to implement... AFAIK it's currently not possible to unregister a node type through the public api (javax.jcr.NodeTypeManager#unregisterNodeType) the key here is the following method: NodeTypeRegistry.checkForReferencesInContent() this method currently throws unconditionally. the javadoc explains why. But what actually happened in Jackrabbit was actually quite scary. By being able to unregister a node type in use, other nodes load and modify a node with a mixin type that is being unregistered. The mixin type is silently dropped from the node, but any properties tied to the mixin node type are kept. There is a window where such a node can be persisted back into database. What is then left in the persisted storage is a node with properties that cannot be part of that node according to its node type. And this node cannot be loaded, cannot be deleted, cannot be fixed. The only option is to go into sql level to delete the node or fix the binary bundle data stored in the record. Maybe it's a good idea that we're not able to remove node types that are still in use, wdyt? theoretically, yes. the hard part is to determine whether it's actually in use... cheers stefan \Berry
Re: Reloading node types in clustered environment
On Fri, Jan 27, 2012 at 11:30 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Fri, Jan 27, 2012 at 10:35 AM, Berry van Halderen b.vanhalde...@1hippo.com wrote: I've fixed this in our own code, but still I'm a bit worried about this change of behavior It used to be impossible to unregister a node type when it was still in use (or at least never to unregister a node type). Not being able to unregister a node type when still in use seems to be the most correct semantics. That should still be the case. The NodeTypeRegistry.unregisterNodeTypes() method calls the protected checkForReferencesInContent() method before actually removing the type. The default implementation of checkForReferencesInContent() simply throws a RepositoryException with a not yet implemented message, which in practice prevents any node types from being unregisted. Until a the checkForReferencesInContent() is properly implemented (see the javadoc for ideas on how to do that), it's possible for downstream projects or deployments to override the method in case they already have some other mechanism for guaranteeing that a node type can safely be removed. I suppose the repository you're using does override the method, but doesn't give such a strong guarantee of consistency. doh! jukka beat me by a few seconds ;) cheers stefan BR, Jukka Zitting
Re: Storing large number of files
On Thu, Jan 26, 2012 at 3:09 AM, Peri Subrahmanya peri.subrahma...@gmail.com wrote: I am using JCR 2.3.7 (latest stable release) for storing large number of files. I am keeping the node sizes to 10K (requirement is to store upto 100M records) but I am seeing a performance issues no matter how I organize the node structure. Using Oracle DB for datastore. Takes around 50 minutes to save 50K files (5kB each). Is there any way to improve the performance or what would be the recommended way. yes, don't use oracle db for datastore. use the filesystem based datastore. cheers stefan Thanks -PeriS
Re: [jr3 Microkernel] how should we handle failed save operations?
On Wed, Jan 25, 2012 at 6:04 PM, Michael Dürig mdue...@apache.org wrote: Hi, In an earlier discussion (probably offline), we decided to not implement Item.refresh() since it doesn't go well with the MVCC model jr3 is based on. Furthermore, JCR doesn't have an Item.undo() method for undoing changes. please note that Item.refresh() will most likely be deprecated in JCR 2.1. This may lead to problems when a Session.save() fails due to the underlying Microkernel.commit failing because it detected a conflict. Now there might be some transient changes (like deletions) which can't be selectively undone by the user. So the user is left with a transient space containing his changes but he can only discard them as a whole. Not very satisfactory. this is IMO a rather theoretical problem. i am not aware of any jcr client code which actually does re-try a failed save operation after having partially discarded and fixed transient changes by calling Item.refresh(false); however, i agree that, theroretically, it is an issue ;) Possible solutions: 1) The Microkernel makes as much effort as possible to three way merge changes. +1, agreed. 2) The user needs to do a session refresh with keep changes = true and save again. 3) Introduce a Item.undo method on the JCR API. i don't think we need that because IMO there's no real world use case. cheers stefan 1) Mitigates the problem such that it only occurs rarely. 2) Is really nothing more than moving the problem of the failed commit due to a conflict from the Microkernel to the transient space: now the transient space needs to do conflict resolution. 3) Is what I think we should do. This enable the user to resolve his conflicts selectively. Michael
Re: [jr3 Microkernel] how should we handle failed save operations?
On Thu, Jan 26, 2012 at 9:48 AM, Thomas Mueller muel...@adobe.com wrote: Hi, I would try 1). I would not try 3) because the user wouldn't know which item conflicted (well he could parse the message, but that would be weird). Also, I would try to avoid a new API. For the case 'double delete' another solution is possible. * session1 deleted node /test and does some other changes * session2 deleted node /test and does some other changes * session1 save (successful) * session2 save (fails: /test can't be deleted because it doesn't exist any more) 4): The microkernel could ignore delete operations on paths that don't currently exist. This is somewhat similar to what databases do: delete from test where id=1 will be successful if there is no row with id 1. Or with JCR setProperty(..., null) for a non-existent property (which currently works fine). BTW: the current microkernel prototype doesn't consider concurrent removal of a specific node a conflict, i.e. it already implements the proposed behavior. cheers stefan Regards, Thomas On 1/25/12 6:04 PM, Michael Dürig mdue...@apache.org wrote: Hi, In an earlier discussion (probably offline), we decided to not implement Item.refresh() since it doesn't go well with the MVCC model jr3 is based on. Furthermore, JCR doesn't have an Item.undo() method for undoing changes. This may lead to problems when a Session.save() fails due to the underlying Microkernel.commit failing because it detected a conflict. Now there might be some transient changes (like deletions) which can't be selectively undone by the user. So the user is left with a transient space containing his changes but he can only discard them as a whole. Not very satisfactory. Possible solutions: 1) The Microkernel makes as much effort as possible to three way merge changes. 2) The user needs to do a session refresh with keep changes = true and save again. 3) Introduce a Item.undo method on the JCR API. 1) Mitigates the problem such that it only occurs rarely. 2) Is really nothing more than moving the problem of the failed commit due to a conflict from the Microkernel to the transient space: now the transient space needs to do conflict resolution. 3) Is what I think we should do. This enable the user to resolve his conflicts selectively. Michael
Re: [jr3 Microkernel] how should we handle failed save operations?
On Thu, Jan 26, 2012 at 2:42 PM, Michael Dürig mdue...@apache.org wrote:
BTW: the current microkernel prototype doesn't consider concurrent
removal of a specific node a conflict, i.e. it already implements the
proposed behavior.
Hmm no?
String head = mk.getHeadRevision();
head = mk.commit(/, +\qoo\:{}, head, );
String r1 = mk.commit(/, -\qoo\, head, );
String r2 = mk.commit(/, -\qoo\, head, );
The commit for r2 gives me an error:
org.apache.jackrabbit.mk.api.MicroKernelException:
org.apache.jackrabbit.mk.store.NotFoundException: /qoo
i should have been more specific. i meant concurrent, i.e.
overlapping, not sequential commits ;)
but you're right, the above scenario could/should be
handled gracefully.
cheers
stefan
Michael
cheers
stefan
Regards,
Thomas
On 1/25/12 6:04 PM, Michael Dürigmdue...@apache.org wrote:
Hi,
In an earlier discussion (probably offline), we decided to not implement
Item.refresh() since it doesn't go well with the MVCC model jr3 is based
on. Furthermore, JCR doesn't have an Item.undo() method for undoing
changes.
This may lead to problems when a Session.save() fails due to the
underlying Microkernel.commit failing because it detected a conflict.
Now there might be some transient changes (like deletions) which can't
be selectively undone by the user. So the user is left with a transient
space containing his changes but he can only discard them as a whole.
Not very satisfactory.
Possible solutions:
1) The Microkernel makes as much effort as possible to three way merge
changes.
2) The user needs to do a session refresh with keep changes = true and
save again.
3) Introduce a Item.undo method on the JCR API.
1) Mitigates the problem such that it only occurs rarely.
2) Is really nothing more than moving the problem of the failed commit
due to a conflict from the Microkernel to the transient space: now the
transient space needs to do conflict resolution.
3) Is what I think we should do. This enable the user to resolve his
conflicts selectively.
Michael
Re: [jr3 Microkernel] semantics of revisionId in commit method
On Wed, Jan 25, 2012 at 5:40 PM, Michael Dürig mic...@gmail.com wrote: Hi, Microkernel.commit() has a revisionId parameter. Could someone (Stefan?) clarify the semantics of this parameter? The Javadoc only says revision the changes are based on. But it fails to explain the actual effect of that parameter. the revisionId parameter of the commit method provides the context of the changes specified by the jsonDiff parameter. while it's true that all changes are always applied on the current HEAD revision, the 'baseRevision' of a commit allows for smarter 3-way merges/conflict resolutions. an example: assume a node /foo exists in rev0 of the tree and sessions s1 and s2 are both based on rev0. now s1 moves /foo to /bar while s2 sets a property on /foo : // s1 mk.commit(/, \foo\: \bar\, rev0, ); // s2 mk.commit(/, ^\foo/prop\ : \blah\, rev0, ); knowing the context of the commit (- rev0) allows the 2nd commit to apply the property modification on /bar instead of throwing a path not found: /foo exception. please note that this specific use case is currently not yet implemented in MicroKernelImpl. cheers stefan Michael
Re: [jr3 Microkernel] semantics of revisionId in commit method
On Thu, Jan 26, 2012 at 4:56 PM, Michael Dürig mdue...@apache.org wrote: Thanks for clarifying. To summarize (if I got it right) the revision parameter specifies the base revision for a three way merge of the transient changes into the current head revision. correct So this can actually be used to implement 1) (see http://markmail.org/message/e2ipk54t2bhrepab) right? yes cheers stefan Michael On 26.1.12 14:31, Stefan Guggisberg wrote: On Wed, Jan 25, 2012 at 5:40 PM, Michael Dürigmic...@gmail.com wrote: Hi, Microkernel.commit() has a revisionId parameter. Could someone (Stefan?) clarify the semantics of this parameter? The Javadoc only says revision the changes are based on. But it fails to explain the actual effect of that parameter. the revisionId parameter of the commit method provides the context of the changes specified by the jsonDiff parameter. while it's true that all changes are always applied on the current HEAD revision, the 'baseRevision' of a commit allows for smarter 3-way merges/conflict resolutions. an example: assume a node /foo exists in rev0 of the tree and sessions s1 and s2 are both based on rev0. now s1 moves /foo to /bar while s2 sets a property on /foo : // s1 mk.commit(/, \foo\: \bar\, rev0, ); // s2 mk.commit(/, ^\foo/prop\ : \blah\, rev0, ); knowing the context of the commit (- rev0) allows the 2nd commit to apply the property modification on /bar instead of throwing a path not found: /foo exception. please note that this specific use case is currently not yet implemented in MicroKernelImpl. cheers stefan Michael
Re: [jr3] Orderable child nodes: required (to be the default)?
On Sat, Jan 21, 2012 at 3:00 AM, Tobias Bocanegra tri...@adobe.com wrote: nt:unstructured has orderable childnodes, and we also preach to use nt:unstructured whereever you can. Also, i assume that a lot of applications benefit from node ordering (like a CMS). So I think that the majority of the repositories have a lot of nodes with ordered childnodes. agreed, at least for small child node lists (e.g. 1k child nodes). but i doubt there's a need for large (e.g. 1M entries) orderable child node lists. thus i would not put too much effort in having an efficient non-ordered format, but making the ordered storage as fast as possible. i am thinking of large child node collections with stable order. however, they wouldn't be insertion-ordered nor client-orderable. that's the compromise. using lexicographical ordering for unordered child nodes would certainly be a good option, that would be an implementation detail. as long as the order is stable (repeated reads of the same node revision should provide the same order of the child nodes) we shouldn't make any promises about how the order is defined. cheers stefan [...] as i can reduce the lookup (but not insert). also, i think that re-orderings happen relatively rarely. regards, toby On Fri, Jan 20, 2012 at 9:13 AM, Stefan Guggisberg stefan.guggisb...@gmail.com wrote: On Fri, Jan 20, 2012 at 5:43 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, Thinking about this more generally, it would definitely be useful to be able to use a more efficient underlying storage for unorderable nodes. However, there still are hard use cases that require us to support orderable nodes as indicated by the type of the parent node. Thus the implementation basically has two options: 1) Use a single data structure for all nodes, like Jackrabbit currently does. This simplifies the implementation but prevents us from enjoying the performance and scalability benefits of unorderable nodes. 2) Use two data structures, one for orderable and another for unorderable nodes. This is more complex (not least because it links node types to the underlying storage model), but is probably required if we want to efficiently support up to millions of child nodes per a single parent. i agree that it's probably required for efficiently handling both large and small child node lists. i am not sure that it necessarily means linking node types to the underlying storage modal. the microkernel prototype currently has no notion of node types and that's IMO a good thing. node types have a way to dominant role in the current jackrabbit core implementation. jackrabbit started out as the official reference implementation for jsr-170, the focus was on supporting every feature of the spec. in jr3 i guess we can and should trade some 'note type correctness' for improved efficiency. It might also be possible to have the underlying storage model unorderable, and just include extra ordering metadata at a higher layer where also node types are handled. Option 2b, if you like, with probably fairly significant overhead when iterating over nodes (the implementation would probably need to pre-fetch all child nodes in advance to access their ordering metadata). If we do have native support for unorderable nodes, then I wouldn't promise any particular ordering (alphabetic, insertion order, etc.) but rather leave it undefined like in Java's Map interface. The underlying implementation is then free to use whatever ordering it thinks is best. i agree. cheers stefan PS. Note that ordering affects not just node traversal, but also the document ordering used in search results. Though in practice we already now disable document ordering of search results by default. BR, Jukka Zitting
Re: [jr3] Orderable child nodes: required (to be the default)?
On Fri, Jan 20, 2012 at 4:09 PM, Thomas Mueller muel...@adobe.com wrote: Hi, The current Jackrabbit implementation uses orderable child nodes by default, meaning nodes are returned in the same order as they are created. As an example, if I create the nodes /test/c, then /test/b, and then /test/a, and then read the node list, I will get them back in that same order. I'm wondering if this is really required (at all, and to be the default behavior). Specially if there are a lot of child nodes. Instead of using the insertion order, I propose to sort the child node list alphabetically: /test/a, /test/b, /test/c - no matter in what order the nodes where created. This will allow an efficient lookup (using binary search), and for large child node lists (more than one thousand child nodes per node) modifications would be about twice as fast as using insertion order (plus it would need less disk space). Would it be a problem if Jackrabbit 3 sorts child nodes by name (always, or at least by default)? i guess no. unless that this behavior is expected/mandated. Another option would be to use (insertion) order until the child node list gets too large (for example 1000 elements), and from then on sort the child nodes by name (the previous ordering would then be lost). i am currently working on a similar approach in the microkernel prototype (sandbox). i am thinking about switching from 'insertion ordered' to 'unordered' (the order depends on the implementation, in my case it's based on the hashcode of the child node name) once a certain threshold is reached. cheers stefan Regards, Thomas
Re: [jr3] Orderable child nodes: required (to be the default)?
On Fri, Jan 20, 2012 at 4:56 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Fri, Jan 20, 2012 at 4:35 PM, Thomas Mueller muel...@adobe.com wrote: If we use alphabetical child node lists by default for Jackrabbit 3, then we would need to use a different default node type? Right, though I suppose there are quite a few applications that use nt:unstructured either as-is or as a base type for many purposes. Is it even possible to use a different node type than nt:unstructured in Jackrabbit 3? It is. The default use of nt:unstructured in Jackrabbit 1.x and 2.x boils down to the use of nt:unstructured as the base type of rep:root. It should be fairly straightforward to change the root type to specify an unorderable type as the default for any child nodes. yes, i agree. cheers stefan Doing so may cause some breakage in existing clients that don't explicitly specify the types they want, but that breakage should be manageable with proper release notes and workaround instructions. BR, Jukka Zitting
Re: [jr3] Orderable child nodes: required (to be the default)?
On Fri, Jan 20, 2012 at 5:43 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, Thinking about this more generally, it would definitely be useful to be able to use a more efficient underlying storage for unorderable nodes. However, there still are hard use cases that require us to support orderable nodes as indicated by the type of the parent node. Thus the implementation basically has two options: 1) Use a single data structure for all nodes, like Jackrabbit currently does. This simplifies the implementation but prevents us from enjoying the performance and scalability benefits of unorderable nodes. 2) Use two data structures, one for orderable and another for unorderable nodes. This is more complex (not least because it links node types to the underlying storage model), but is probably required if we want to efficiently support up to millions of child nodes per a single parent. i agree that it's probably required for efficiently handling both large and small child node lists. i am not sure that it necessarily means linking node types to the underlying storage modal. the microkernel prototype currently has no notion of node types and that's IMO a good thing. node types have a way to dominant role in the current jackrabbit core implementation. jackrabbit started out as the official reference implementation for jsr-170, the focus was on supporting every feature of the spec. in jr3 i guess we can and should trade some 'note type correctness' for improved efficiency. It might also be possible to have the underlying storage model unorderable, and just include extra ordering metadata at a higher layer where also node types are handled. Option 2b, if you like, with probably fairly significant overhead when iterating over nodes (the implementation would probably need to pre-fetch all child nodes in advance to access their ordering metadata). If we do have native support for unorderable nodes, then I wouldn't promise any particular ordering (alphabetic, insertion order, etc.) but rather leave it undefined like in Java's Map interface. The underlying implementation is then free to use whatever ordering it thinks is best. i agree. cheers stefan PS. Note that ordering affects not just node traversal, but also the document ordering used in search results. Though in practice we already now disable document ordering of search results by default. BR, Jukka Zitting
[jira] [Commented] (JCR-3194) ConcurrentModificationException in CacheManager.
[
https://issues.apache.org/jira/browse/JCR-3194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13178810#comment-13178810
]
Stefan Guggisberg commented on JCR-3194:
only happens with log level set to DEBUG.
ConcurrentModificationException in CacheManager.
Key: JCR-3194
URL: https://issues.apache.org/jira/browse/JCR-3194
Project: Jackrabbit Content Repository
Issue Type: Bug
Affects Versions: 2.3.4
Reporter: Mat Lowery
Using the test code below, I was able to produce this stack:
java.util.ConcurrentModificationException
at java.util.WeakHashMap$HashIterator.nextEntry(WeakHashMap.java:762)
at java.util.WeakHashMap$KeyIterator.next(WeakHashMap.java:795)
at
org.apache.jackrabbit.core.cache.CacheManager.logCacheStats(CacheManager.java:164)
at
org.apache.jackrabbit.core.cache.CacheManager.cacheAccessed(CacheManager.java:137)
at
org.apache.jackrabbit.core.cache.AbstractCache.recordCacheAccess(AbstractCache.java:122)
at
org.apache.jackrabbit.core.cache.ConcurrentCache.get(ConcurrentCache.java:122)
at
org.apache.jackrabbit.core.state.MLRUItemStateCache.retrieve(MLRUItemStateCache.java:71)
at
org.apache.jackrabbit.core.state.ItemStateReferenceCache.retrieve(ItemStateReferenceCache.java:139)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.getNonVirtualItemState(SharedItemStateManager.java:1716)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.getItemState(SharedItemStateManager.java:268)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.getNodeState(LocalItemStateManager.java:110)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(LocalItemStateManager.java:175)
at
org.apache.jackrabbit.core.state.XAItemStateManager.getItemState(XAItemStateManager.java:260)
at
org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:161)
at
org.apache.jackrabbit.core.ItemManager.getItemData(ItemManager.java:382)
at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:328)
at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:622)
at
org.apache.jackrabbit.core.ItemManager.getRootNode(ItemManager.java:531)
at
org.apache.jackrabbit.core.SessionImpl.getRootNode(SessionImpl.java:760)
at test.JackrabbitTest$1.run(JackrabbitTest.java:37)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
-
package test;
import java.io.File;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicBoolean;
import java.util.concurrent.atomic.AtomicInteger;
import javax.jcr.Repository;
import javax.jcr.RepositoryException;
import javax.jcr.Session;
import javax.jcr.SimpleCredentials;
import org.apache.jackrabbit.core.TransientRepository;
public class JackrabbitTest {
public static void main(final String[] args) throws Exception {
File dir = File.createTempFile(jackrabbit-test, );
dir.delete();
dir.mkdir();
System.out.println(created temporary directory: +
dir.getAbsolutePath());
dir.deleteOnExit();
final Repository jcrRepo = new TransientRepository(dir);
final AtomicBoolean passed = new AtomicBoolean(true);
final AtomicInteger counter = new AtomicInteger(0);
ExecutorService executor = Executors.newFixedThreadPool(50);
Runnable runnable = new Runnable() {
@Override
public void run() {
try {
Session session = jcrRepo.login(
new SimpleCredentials(admin,
admin.toCharArray()));
session.getRootNode().addNode(n +
counter.getAndIncrement()); //unique name
session.save();
session.logout();
} catch (RepositoryException e) {
e.printStackTrace();
passed.set(false);
}
}
};
System.out.println(Running threads);
for (int i = 0; i 500; i++) {
executor.execute(runnable);
}
executor.shutdown(); //Disable new tasks from being submitted
if (!executor.awaitTermination(120, TimeUnit.SECONDS)) {
System.err.println(timeout);
System.exit(1);
}
if (!passed.get()) {
System.err.println(one or more threads got an exception);
System.exit(1);
} else {
System.out.println(all threads ran with no exceptions);
System.exit(0);
}
}
}
--
This message is automatically generated
[jira] [Commented] (JCR-3194) ConcurrentModificationException in CacheManager.
[
https://issues.apache.org/jira/browse/JCR-3194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13178811#comment-13178811
]
Stefan Guggisberg commented on JCR-3194:
this is a regression of JCR-3098
ConcurrentModificationException in CacheManager.
Key: JCR-3194
URL: https://issues.apache.org/jira/browse/JCR-3194
Project: Jackrabbit Content Repository
Issue Type: Bug
Affects Versions: 2.3.4
Reporter: Mat Lowery
Using the test code below, I was able to produce this stack:
java.util.ConcurrentModificationException
at java.util.WeakHashMap$HashIterator.nextEntry(WeakHashMap.java:762)
at java.util.WeakHashMap$KeyIterator.next(WeakHashMap.java:795)
at
org.apache.jackrabbit.core.cache.CacheManager.logCacheStats(CacheManager.java:164)
at
org.apache.jackrabbit.core.cache.CacheManager.cacheAccessed(CacheManager.java:137)
at
org.apache.jackrabbit.core.cache.AbstractCache.recordCacheAccess(AbstractCache.java:122)
at
org.apache.jackrabbit.core.cache.ConcurrentCache.get(ConcurrentCache.java:122)
at
org.apache.jackrabbit.core.state.MLRUItemStateCache.retrieve(MLRUItemStateCache.java:71)
at
org.apache.jackrabbit.core.state.ItemStateReferenceCache.retrieve(ItemStateReferenceCache.java:139)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.getNonVirtualItemState(SharedItemStateManager.java:1716)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.getItemState(SharedItemStateManager.java:268)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.getNodeState(LocalItemStateManager.java:110)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(LocalItemStateManager.java:175)
at
org.apache.jackrabbit.core.state.XAItemStateManager.getItemState(XAItemStateManager.java:260)
at
org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:161)
at
org.apache.jackrabbit.core.ItemManager.getItemData(ItemManager.java:382)
at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:328)
at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:622)
at
org.apache.jackrabbit.core.ItemManager.getRootNode(ItemManager.java:531)
at
org.apache.jackrabbit.core.SessionImpl.getRootNode(SessionImpl.java:760)
at test.JackrabbitTest$1.run(JackrabbitTest.java:37)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
-
package test;
import java.io.File;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicBoolean;
import java.util.concurrent.atomic.AtomicInteger;
import javax.jcr.Repository;
import javax.jcr.RepositoryException;
import javax.jcr.Session;
import javax.jcr.SimpleCredentials;
import org.apache.jackrabbit.core.TransientRepository;
public class JackrabbitTest {
public static void main(final String[] args) throws Exception {
File dir = File.createTempFile(jackrabbit-test, );
dir.delete();
dir.mkdir();
System.out.println(created temporary directory: +
dir.getAbsolutePath());
dir.deleteOnExit();
final Repository jcrRepo = new TransientRepository(dir);
final AtomicBoolean passed = new AtomicBoolean(true);
final AtomicInteger counter = new AtomicInteger(0);
ExecutorService executor = Executors.newFixedThreadPool(50);
Runnable runnable = new Runnable() {
@Override
public void run() {
try {
Session session = jcrRepo.login(
new SimpleCredentials(admin,
admin.toCharArray()));
session.getRootNode().addNode(n +
counter.getAndIncrement()); //unique name
session.save();
session.logout();
} catch (RepositoryException e) {
e.printStackTrace();
passed.set(false);
}
}
};
System.out.println(Running threads);
for (int i = 0; i 500; i++) {
executor.execute(runnable);
}
executor.shutdown(); //Disable new tasks from being submitted
if (!executor.awaitTermination(120, TimeUnit.SECONDS)) {
System.err.println(timeout);
System.exit(1);
}
if (!passed.get()) {
System.err.println(one or more threads got an exception);
System.exit(1);
} else {
System.out.println(all threads ran with no exceptions);
System.exit(0);
}
}
}
--
This message is automatically generated by JIRA
[jira] [Resolved] (JCR-3194) ConcurrentModificationException in CacheManager.
[
https://issues.apache.org/jira/browse/JCR-3194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved JCR-3194.
Resolution: Fixed
fixed in svn r1226863.
ConcurrentModificationException in CacheManager.
Key: JCR-3194
URL: https://issues.apache.org/jira/browse/JCR-3194
Project: Jackrabbit Content Repository
Issue Type: Bug
Affects Versions: 2.3.4
Reporter: Mat Lowery
Using the test code below, I was able to produce this stack:
java.util.ConcurrentModificationException
at java.util.WeakHashMap$HashIterator.nextEntry(WeakHashMap.java:762)
at java.util.WeakHashMap$KeyIterator.next(WeakHashMap.java:795)
at
org.apache.jackrabbit.core.cache.CacheManager.logCacheStats(CacheManager.java:164)
at
org.apache.jackrabbit.core.cache.CacheManager.cacheAccessed(CacheManager.java:137)
at
org.apache.jackrabbit.core.cache.AbstractCache.recordCacheAccess(AbstractCache.java:122)
at
org.apache.jackrabbit.core.cache.ConcurrentCache.get(ConcurrentCache.java:122)
at
org.apache.jackrabbit.core.state.MLRUItemStateCache.retrieve(MLRUItemStateCache.java:71)
at
org.apache.jackrabbit.core.state.ItemStateReferenceCache.retrieve(ItemStateReferenceCache.java:139)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.getNonVirtualItemState(SharedItemStateManager.java:1716)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.getItemState(SharedItemStateManager.java:268)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.getNodeState(LocalItemStateManager.java:110)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(LocalItemStateManager.java:175)
at
org.apache.jackrabbit.core.state.XAItemStateManager.getItemState(XAItemStateManager.java:260)
at
org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:161)
at
org.apache.jackrabbit.core.ItemManager.getItemData(ItemManager.java:382)
at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:328)
at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:622)
at
org.apache.jackrabbit.core.ItemManager.getRootNode(ItemManager.java:531)
at
org.apache.jackrabbit.core.SessionImpl.getRootNode(SessionImpl.java:760)
at test.JackrabbitTest$1.run(JackrabbitTest.java:37)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
-
package test;
import java.io.File;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.atomic.AtomicBoolean;
import java.util.concurrent.atomic.AtomicInteger;
import javax.jcr.Repository;
import javax.jcr.RepositoryException;
import javax.jcr.Session;
import javax.jcr.SimpleCredentials;
import org.apache.jackrabbit.core.TransientRepository;
public class JackrabbitTest {
public static void main(final String[] args) throws Exception {
File dir = File.createTempFile(jackrabbit-test, );
dir.delete();
dir.mkdir();
System.out.println(created temporary directory: +
dir.getAbsolutePath());
dir.deleteOnExit();
final Repository jcrRepo = new TransientRepository(dir);
final AtomicBoolean passed = new AtomicBoolean(true);
final AtomicInteger counter = new AtomicInteger(0);
ExecutorService executor = Executors.newFixedThreadPool(50);
Runnable runnable = new Runnable() {
@Override
public void run() {
try {
Session session = jcrRepo.login(
new SimpleCredentials(admin,
admin.toCharArray()));
session.getRootNode().addNode(n +
counter.getAndIncrement()); //unique name
session.save();
session.logout();
} catch (RepositoryException e) {
e.printStackTrace();
passed.set(false);
}
}
};
System.out.println(Running threads);
for (int i = 0; i 500; i++) {
executor.execute(runnable);
}
executor.shutdown(); //Disable new tasks from being submitted
if (!executor.awaitTermination(120, TimeUnit.SECONDS)) {
System.err.println(timeout);
System.exit(1);
}
if (!passed.get()) {
System.err.println(one or more threads got an exception);
System.exit(1);
} else {
System.out.println(all threads ran with no exceptions);
System.exit(0);
}
}
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please
Re: [jr3 microkernel] New transient space implementation
On Thu, Dec 29, 2011 at 6:19 PM, Michael Dürig mic...@gmail.com wrote: Hi, Over at the sandbox [1] I implemented a new (AFAIK) approach for the JCR transient space. The gist of it is in the ChangeTree class [2] while some more Microkernel specific things are factored out into the TransientSpace class [3]. great work! it's good to see a fresh take on jcr client implementation. some comments from the peanut gallery follow inline ;) The key idea is to only store changes to the node hierarchy in the ChangeTree and to do that in a way which allows reconstructing a list of corresponding operations (add, remove, move for nodes and set for properties) from that ChangeTree. This differs from other implementations where the list of operations is kept *together* with the modified hierarchy. Furthermore with the ChangeTree approach no untouched nodes need to be kept in memory. that's also true for the existing jackrabbit-core implementation. Finally the list of operations reconstructed from a ChangeTree is minimal. That is, all cancelling operations are reduced as much as possible: same here, jackrabbit-core does consolidate transient changes as well. cheers stefan add followed by remove of the same item results in no operations, add followed by move of the same node results in the node being added at the target of the move, move followed by remove of a node results in the node being removed at the source of the move and move followed by another move of a node results in a single move from the original source to the eventual target. More details are in the class comment of ChangeTree and even more details in the implementation ;-) Michael [1] http://svn.apache.org/viewvc/jackrabbit/sandbox/jackrabbit-microkernel/ [2] http://svn.apache.org/viewvc/jackrabbit/sandbox/jackrabbit-microkernel/src/main/java/org/apache/jackrabbit/state/ChangeTree.java?view=markup [3] http://svn.apache.org/viewvc/jackrabbit/sandbox/jackrabbit-microkernel/src/main/java/org/apache/jackrabbit/state/TransientSpace.java?view=markup
Re: [Jackrabbit Wiki] Update of Jsop by stefan
On Wed, Dec 14, 2011 at 11:39 AM, Julian Reschke julian.resc...@gmx.de wrote:
On 2011-12-14 11:28, Apache Wiki wrote:
Dear Wiki user,
You have subscribed to a wiki page or wiki category on Jackrabbit Wiki
for change notification.
The Jsop page has been changed by stefan:
http://wiki.apache.org/jackrabbit/Jsop?action=diffrev1=30rev2=31
Comment:
added 'copy'
SET ::= ^ STRING : ATOM | ARRAY
REMOVE ::= - STRING
MOVE ::= STRING : (STRING | { STRING : STRING })
+ COPY ::= * STRING : (STRING | { STRING : STRING })
TEST ::= = STRING : ATOM | ARRAY
METADATA ::= @ OBJECT
EXTENSION ::= OP STRING : (OBJECT | ATOM | ARRAY)
@@ -129, +130 @@
* removeNodeDiff
* removePropertyDiff
* moveNodeDiff
+ * copyNodeDiff
* testProperty
* metaData
...
Not convinced.
i think it's useful and needed. how else would
you support the javax.jcr.Workspace#copy use case?
If we think this is needed we should bring it up within the IETF so JSON
Patch gets this, too.
sure, please go ahead.
Or have we given up on that?
why would that be the case?
cheers
stefan
Best regards, Julian
Re: [j3 Microkernel] commit method
On Mon, Dec 12, 2011 at 10:36 AM, Stefan Guggisberg stefan.guggisb...@gmail.com wrote: On Fri, Dec 9, 2011 at 3:13 PM, Michael Dürig mdue...@apache.org wrote: Hi, Currently the commit method look like this: String commit(String path, String jsonDiff, String revisionId, String message) The path argument has to be an absolute path and the paths of the jsonDiff operations are relative paths. The target path of the operations are determined by concatenating the path with the paths of the jsonDiff operations. To facilitate the usage of this API where only absolute paths are involved, I suggest to expand the scope of the commit method such that the empty string (or null?) is allowed for the path argument. In this case all jsonDiff operations need to specify an absolute path. sounds reasonable. probably easy to support, i'll check the current implementation. implemented in svn r1214161. cheers stefan cheers stefan Michael
Re: [Jackrabbit Wiki] Update of Jsop by stefan
On Wed, Dec 14, 2011 at 3:54 PM, Michael Dürig mdue...@apache.org wrote: On 14.12.11 14:18, Julian Reschke wrote: The use case is that the client should have a way to detect the JCR data type for unstructured data (JSON doesn't have a 'date' data type). For the MicroKernel, we currently use a different convention: we encode the data type in the value. insert-anti-JSON-pro-XML-rant-here/ Maybe sometimes simple is too simple :-) When we started using 'JSOP' and JSON for the jr3 Microkernel based implementation, we didn't have a clear picture on how to map things to JCR. The conception then was 'decorate it on top somehow'. As it is apparent from this discussion, this isn't as easy as it seems without resorting to ad-hoc extensions. WRT 'copy': not simple? ad-hoc extension? to what? a non-existing specification? cheers stefan This discussion just touched two of the paint points: copy and data types. Others are: observation, locking, name spaces and remapping, access control, ordering, properties and nodes with the same name, same name siblings... Michael
Re: [j3 Microkernel] commit method
On Fri, Dec 9, 2011 at 3:13 PM, Michael Dürig mdue...@apache.org wrote: Hi, Currently the commit method look like this: String commit(String path, String jsonDiff, String revisionId, String message) The path argument has to be an absolute path and the paths of the jsonDiff operations are relative paths. The target path of the operations are determined by concatenating the path with the paths of the jsonDiff operations. To facilitate the usage of this API where only absolute paths are involved, I suggest to expand the scope of the commit method such that the empty string (or null?) is allowed for the path argument. In this case all jsonDiff operations need to specify an absolute path. sounds reasonable. probably easy to support, i'll check the current implementation. cheers stefan Michael
[jira] [Commented] (JCR-3172) implement PERSIST events for the EventJournal
[ https://issues.apache.org/jira/browse/JCR-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13166220#comment-13166220 ] Stefan Guggisberg commented on JCR-3172: +1 for the patch (JCR-3172.diff) implement PERSIST events for the EventJournal - Key: JCR-3172 URL: https://issues.apache.org/jira/browse/JCR-3172 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core, observation Reporter: Julian Reschke Assignee: Julian Reschke Priority: Minor Attachments: JCR-3172.diff See http://www.day.com/specs/jcr/2.0/12_Observation.html#12.6.3%20Event%20Bundling%20in%20Journaled%20Observation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: no PERSIST events?
On Tue, Dec 6, 2011 at 3:03 PM, Julian Reschke julian.resc...@gmx.de wrote: On 2011-12-06 14:53, Stefan Guggisberg wrote: ... ah right, jsr 283, journaled observation, ... now i vaguely remember ;) AFAIK jackrabbit doesn't support event bundling, i.e. PERSIST events are never dispatched. ... Bundling would be helpful when the event journal needs to get remoted (it gives the producing side an indication about where's a boundary for chunking...). i see, good point. Should I open a JIRA task for this? yes. i guess it shouldn't be to difficult to dispatch PERSIST events after every save and workspace operation. o.a.jackrabbit.core.observation.EventStateCollection#createEventStates could be an ideal place to generate them. cheers stefan Best regards, Julian
[jira] [Commented] (JCR-3172) implement PERSIST events for the EventJournal
[ https://issues.apache.org/jira/browse/JCR-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13164400#comment-13164400 ] Stefan Guggisberg commented on JCR-3172: we'll probably have to add a PERSIST event at the end of o.a.jackrabbit.core.observation.EventStateCollection#createEventStates implement PERSIST events for the EventJournal - Key: JCR-3172 URL: https://issues.apache.org/jira/browse/JCR-3172 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core, observation Reporter: Julian Reschke Priority: Minor See http://www.day.com/specs/jcr/2.0/12_Observation.html#12.6.3%20Event%20Bundling%20in%20Journaled%20Observation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3172) implement PERSIST events for the EventJournal
[ https://issues.apache.org/jira/browse/JCR-3172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13164460#comment-13164460 ] Stefan Guggisberg commented on JCR-3172: Wouldn't be EventJournalImpl the obvious place? It iterates through EventBundles and could add PERSIST each time the end of a bundle was reached.. yes, perhaps. i am not familiar with the details of EventJournalImpl and what the criteria of event bundling are. anyway, EventStateCollection#createEventStates is probably the wrong place since PERSIST events should only appear in the event journal. implement PERSIST events for the EventJournal - Key: JCR-3172 URL: https://issues.apache.org/jira/browse/JCR-3172 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core, observation Reporter: Julian Reschke Priority: Minor See http://www.day.com/specs/jcr/2.0/12_Observation.html#12.6.3%20Event%20Bundling%20in%20Journaled%20Observation -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: no PERSIST events?
On Mon, Dec 5, 2011 at 5:17 PM, Julian Reschke julian.resc...@gmx.de wrote: Hi, I was just looking at a stream of events and noticed that we don't seem to generate PERSIST events? Is there a good reason for this, or is this just something we haven't done yet? can you please provide some context information? i'll then try to answer your question. right now i have no clue what you're talking about :) cheers stefan Best regards, Julian
Re: no PERSIST events?
On Tue, Dec 6, 2011 at 12:19 PM, Julian Reschke julian.resc...@gmx.de wrote: On 2011-12-06 11:42, Stefan Guggisberg wrote: On Mon, Dec 5, 2011 at 5:17 PM, Julian Reschkejulian.resc...@gmx.de wrote: Hi, I was just looking at a stream of events and noticed that we don't seem to generate PERSIST events? Is there a good reason for this, or is this just something we haven't done yet? can you please provide some context information? i'll then try to answer your question. Sure :-) JSR 283 defines in http://www.day.com/specs/jcr/2.0/12_Observation.html#12.6.3%20Event%20Bundling%20in%20Journaled%20Observation: In journaled observation dispatching is done by the implementation writing to the event journal. If event bundling is supported a PERSIST event is dispatched when a persistent change is made to workspace bracketing the set of events associated with that change. This exposes event bundle boundaries in the event journal. Note that a PERSIST event will never appear within an EventIterator since, in asynchronous observation, the iterator itself serves to define the event bundle. In repositories that do not support event bundling, PERSIST events do not appear in the event journal. ah right, jsr 283, journaled observation, ... now i vaguely remember ;) AFAIK jackrabbit doesn't support event bundling, i.e. PERSIST events are never dispatched. cheers stefan ... Best regards, Julian
Re: [jr3 microkernel] Write skew
On Thu, Dec 1, 2011 at 2:01 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Thu, Dec 1, 2011 at 1:13 PM, Michael Dürig mdue...@apache.org wrote: But this will introduce a race condition. With other words: this only make the time window during which such a inconsistency could slip in smaller. I think what we'd really need is an atomic test and set operation. Right, either the refresh-check-persist model for save() needs to be atomic (possibly with optimistic locking as described) or we need an eventual consistency model that can automatically resolve such conflicts. Has this already been thought about? How does the current microkernel implementation handle such cases? the current microkernel prototype commit roughly works as follows: 1. all changes are persisted 2. within a synchronized block, 2a. - if the head revision has changed since we started persisting our changes, a 3-way merge is done starting from the root node (ideally only the root node needs to be merged) 2b. - the new head revision is persisted if an unmergeable conflict is detected in step 2a, an exception is thrown. that currently only happens on concurrent property modifications. details can be found here (doCommit mergeNode methods) : [0] cheers stefan [0] http://svn.apache.org/viewvc/jackrabbit/sandbox/microkernel/src/main/java/org/apache/jackrabbit/mk/model/CommitBuilder.java?view=markup BR, Jukka Zitting
Re: [jr3 microkernel] Write skew
On Thu, Dec 1, 2011 at 2:26 PM, Michael Dürig mdue...@apache.org wrote: On 1.12.11 13:01, Jukka Zitting wrote: Hi, On Thu, Dec 1, 2011 at 1:13 PM, Michael Dürigmdue...@apache.org wrote: But this will introduce a race condition. With other words: this only make the time window during which such a inconsistency could slip in smaller. I think what we'd really need is an atomic test and set operation. Right, either the refresh-check-persist model for save() needs to be atomic (possibly with optimistic locking as described) or we need an eventual consistency model that can automatically resolve such conflicts. Has this already been thought about? How does the current microkernel implementation handle such cases? Currently the microkernel does nothing about this. That's what this whole discussion is about after all ;-) and please bear in mind that the microkernel project in the jackrabbit sandbox is a prototype and represents WIP... ;) cheers stefan Eventually consistent approaches are IMO very hard to get right with JCR since most operation are assumed to be persisted after dispatch. One solution I see is to have changes caused by conflict resolution (i.e. during convergence) to appear as normal changes as if they where done by other sessions (see [1]). This would however require changing the revision model of the microkernel from linear shaped to tree shaped. For the current problem I'd rather have the microkernel to expose some test-and-set semantics as Tom describes in [2]. That way a client of the microkernel could apply changes atomically. A third and most general solution which puts away with write skew for good is described in [3]. This requires examining the commit log for certain read-write conflicts on save. Michael [1] http://wiki.apache.org/jackrabbit/Clustering%20the%20Microkernel#Replication [2] http://markmail.org/message/c32jpeoxklgcrybr [3] http://dl.acm.org/citation.cfm?id=1376690
Re: [jr3 microkernel] Write skew
On Thu, Dec 1, 2011 at 3:49 PM, Thomas Mueller muel...@adobe.com wrote: Hi, A test-and-set operation necessarily requires at least some level of atomicity which can quickly become a bottleneck for a clustered setup. Test-and-set is a problem in a clustered 'eventually consistent' model, that's true. I don't know how test-and-set could be used in that way. Possibly the easiest solution is that each node modification sets the node type again (to the expected value) even if the user didn't change it. But I don't think we should try to increase concurrency of write operations within the *same* repository because that's not a problem at all. i beg to differ ;) in jr2 saves are serialized. IMO that's a *real* problem, especially when saving large change sets. this problem can be addressed e.g. with an MVCC based model. cheers stefan Jackrabbit 2 is slow for other reasons. In my view, the main problems for Jackrabbit 2 are: - the more nodes the slower because of the randomly distributed node ids - the more open sessions the slower because of internal event processing - the more child nodes the slower because the list is stored as one unit - jackrabbit core is slow internally for other reasons we didn't analyze - indexing everything with Lucene is a performance problem at some point - in a cluster, writes do not scale as writing is basically synchronized None of that problems is related to transaction isolation. I'm not saying we shouldn't try to use MVCC. But it never was a problem that Jackrabbit 2 doesn't use MVCC. Regards, Thomas
Re: [jr3 microkernel] Write skew
On Wed, Nov 30, 2011 at 3:21 PM, Michael Dürig mdue...@apache.org wrote: On 30.11.11 13:57, Alexander Klimetschek wrote: I expect there is a lot of code outside that relies on the copy-on-write nature of JR 2 - i.e. that anything the session did not touch yet is always live. Introducing snapshot isolation (which would be copy-on-read IIUC) would break those cases (but usually these errors will depend on concurrency, thus hard to spot). Now looking at the specs, I am confused: in JCR 1.0 it was up to the implementation to be using copy-on-read or copy-on-write [0]. In JCR 2.0 that text was replaced by [1] (IIUC, didn't find anything else) which seems to be defining copy-on-write as the standard behavior now: A change that is persisted is visible to all other sessions bound to the same persistent workspace that have sufficient read permission. That would mean that JR 3 cannot do snapshot isolation! But I might be missing something... Good catch! Two points: 1) Does visible mean immediately visible on next access or visible after refresh? The second case would work with snapshot isolation. 2) Event though I'd like it to be different, spec. compliance hasn't been a top priority on this project so far. i guess what you mean by 'spec compliance' is 'support of all and every optional features in the JCR spec'. and i agree with that. jr3 should IMO be spec compliant in the sense that it passes the TCK. which optional features should be supported is TBD. we don't need another JCR 2.0/2.1 reference implementation. we already have one with jackrabbit 2.x cheers stefan Michael [0] http://www.day.com/specs/jcr/1.0/7.1.3.4_Seeing_Changes_Made_by_Other_Sessions.html [1] http://www.day.com/specs/jcr/2.0/10_Writing.html#10.1.4%20Visibility%20of%20Changes Cheers, Alex -- Alexander Klimetschek Developer // Adobe (Day) // Berlin - Basel
[jira] [Updated] (JCR-3160) Session#move doesn't trigger rebuild of parent node aggregation
[ https://issues.apache.org/jira/browse/JCR-3160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg updated JCR-3160: --- Component/s: (was: jackrabbit-core) query Session#move doesn't trigger rebuild of parent node aggregation --- Key: JCR-3160 URL: https://issues.apache.org/jira/browse/JCR-3160 Project: Jackrabbit Content Repository Issue Type: Bug Components: query Reporter: Alex Parvulescu Assignee: Alex Parvulescu Priority: Minor Attachments: JCR-3160.patch The summary says it all. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jr3 Microkernel] NPE on conflicting commits
On Thu, Nov 24, 2011 at 11:50 PM, Michael Dürig mic...@gmail.com wrote:
There is another case where conflicting commits cause an NPE. This time its
a conflict between add and remove. See testcase in forwarded commit message.
thanks, i'll have a look.
cheers
stefan
Michael
Original Message
Subject: svn commit: r1206008 -
/jackrabbit/sandbox/jackrabbit-mk/jackrabbit-spi2microkernel/src/test/java/org/apache/jackrabbit/spi2microkernel/MicrokernelTest.java
Date: Thu, 24 Nov 2011 22:45:33 -
From: mdue...@apache.org
Reply-To: dev@jackrabbit.apache.org
To: comm...@jackrabbit.apache.org
Author: mduerig
Date: Thu Nov 24 22:45:32 2011
New Revision: 1206008
URL: http://svn.apache.org/viewvc?rev=1206008view=rev
Log:
Microkernel based Jackrabbit prototype (WIP)
add test case for pathological add delete conflict
Modified:
jackrabbit/sandbox/jackrabbit-mk/jackrabbit-spi2microkernel/src/test/java/org/apache/jackrabbit/spi2microkernel/MicrokernelTest.java
Modified:
jackrabbit/sandbox/jackrabbit-mk/jackrabbit-spi2microkernel/src/test/java/org/apache/jackrabbit/spi2microkernel/MicrokernelTest.java
URL:
http://svn.apache.org/viewvc/jackrabbit/sandbox/jackrabbit-mk/jackrabbit-spi2microkernel/src/test/java/org/apache/jackrabbit/spi2microkernel/MicrokernelTest.java?rev=1206008r1=1206007r2=1206008view=diff
==
---
jackrabbit/sandbox/jackrabbit-mk/jackrabbit-spi2microkernel/src/test/java/org/apache/jackrabbit/spi2microkernel/MicrokernelTest.java
(original)
+++
jackrabbit/sandbox/jackrabbit-mk/jackrabbit-spi2microkernel/src/test/java/org/apache/jackrabbit/spi2microkernel/MicrokernelTest.java
Thu Nov 24 22:45:32 2011
@@ -196,6 +196,27 @@ public class MicrokernelTest {
@Test
@Ignore
// todo fix microkernel
+ public void conflictingAddDelete() {
+ MicroKernel mk = getMicroKernel();
+ String head = mk.getHeadRevision();
+
+ head = mk.commit(/, +\a\ : {} \r+\b\ : {}\n, head, );
+
+ String r1 = mk.commit(/, -\b\ \r +\a/x\ : {}, head, );
+ assertFalse(mk.nodeExists(/b, r1));
+ assertTrue(mk.nodeExists(/a, r1));
+ assertTrue(mk.nodeExists(/a/x, r1));
+
+ String r2 = mk.commit(/, -\a\ \r +\b/x\ : {}, head, );
+ // todo not really sure what the result should be. Currently this
throws a NPE...
+// assertFalse(mk.nodeExists(/a, r2));
+// assertTrue(mk.nodeExists(/b, r2));
+// assertTrue(mk.nodeExists(/b/x, r2));
+ }
+
+ @Test
+ @Ignore
+ // todo fix microkernel
public void reorderNode() {
MicroKernel mk = getMicroKernel();
String head = mk.getHeadRevision();
Re: [jr3 Microkernel] NPE on conflicting commits
fixed in svn r1206183.
thanks
stefan
On Fri, Nov 25, 2011 at 11:29 AM, Stefan Guggisberg ste...@apache.org wrote:
On Thu, Nov 24, 2011 at 11:50 PM, Michael Dürig mic...@gmail.com wrote:
There is another case where conflicting commits cause an NPE. This time its
a conflict between add and remove. See testcase in forwarded commit message.
thanks, i'll have a look.
cheers
stefan
Michael
Original Message
Subject: svn commit: r1206008 -
/jackrabbit/sandbox/jackrabbit-mk/jackrabbit-spi2microkernel/src/test/java/org/apache/jackrabbit/spi2microkernel/MicrokernelTest.java
Date: Thu, 24 Nov 2011 22:45:33 -
From: mdue...@apache.org
Reply-To: dev@jackrabbit.apache.org
To: comm...@jackrabbit.apache.org
Author: mduerig
Date: Thu Nov 24 22:45:32 2011
New Revision: 1206008
URL: http://svn.apache.org/viewvc?rev=1206008view=rev
Log:
Microkernel based Jackrabbit prototype (WIP)
add test case for pathological add delete conflict
Modified:
jackrabbit/sandbox/jackrabbit-mk/jackrabbit-spi2microkernel/src/test/java/org/apache/jackrabbit/spi2microkernel/MicrokernelTest.java
Modified:
jackrabbit/sandbox/jackrabbit-mk/jackrabbit-spi2microkernel/src/test/java/org/apache/jackrabbit/spi2microkernel/MicrokernelTest.java
URL:
http://svn.apache.org/viewvc/jackrabbit/sandbox/jackrabbit-mk/jackrabbit-spi2microkernel/src/test/java/org/apache/jackrabbit/spi2microkernel/MicrokernelTest.java?rev=1206008r1=1206007r2=1206008view=diff
==
---
jackrabbit/sandbox/jackrabbit-mk/jackrabbit-spi2microkernel/src/test/java/org/apache/jackrabbit/spi2microkernel/MicrokernelTest.java
(original)
+++
jackrabbit/sandbox/jackrabbit-mk/jackrabbit-spi2microkernel/src/test/java/org/apache/jackrabbit/spi2microkernel/MicrokernelTest.java
Thu Nov 24 22:45:32 2011
@@ -196,6 +196,27 @@ public class MicrokernelTest {
@Test
@Ignore
// todo fix microkernel
+ public void conflictingAddDelete() {
+ MicroKernel mk = getMicroKernel();
+ String head = mk.getHeadRevision();
+
+ head = mk.commit(/, +\a\ : {} \r+\b\ : {}\n, head, );
+
+ String r1 = mk.commit(/, -\b\ \r +\a/x\ : {}, head, );
+ assertFalse(mk.nodeExists(/b, r1));
+ assertTrue(mk.nodeExists(/a, r1));
+ assertTrue(mk.nodeExists(/a/x, r1));
+
+ String r2 = mk.commit(/, -\a\ \r +\b/x\ : {}, head, );
+ // todo not really sure what the result should be. Currently this
throws a NPE...
+// assertFalse(mk.nodeExists(/a, r2));
+// assertTrue(mk.nodeExists(/b, r2));
+// assertTrue(mk.nodeExists(/b/x, r2));
+ }
+
+ @Test
+ @Ignore
+ // todo fix microkernel
public void reorderNode() {
MicroKernel mk = getMicroKernel();
String head = mk.getHeadRevision();
Re: [jr3 microkernel] Move overwrites target node
On Fri, Nov 25, 2011 at 1:03 PM, Michael Dürig mdue...@apache.org wrote: Hi, I just discovered that the move operation does not fail when the target nodes already exists. Is that expected? no :) fixed in svn r1206201. thanks stefan When node 'b' exists already, the following commit will overwrite it with node 'a': mk.commit(/, \a\ : \b\ , head, ); In contrast adding a node 'b' in the same situation would fail with a message saying that node 'b' exists already. Michael
[jira] [Commented] (JCR-3141) Upgrade to Tika 1.0
[ https://issues.apache.org/jira/browse/JCR-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13146219#comment-13146219 ] Stefan Guggisberg commented on JCR-3141: please check the transitive dependencies. IMO we should strip all 'exotic' and rarely used dependencies. Upgrade to Tika 1.0 --- Key: JCR-3141 URL: https://issues.apache.org/jira/browse/JCR-3141 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core, jackrabbit-jcr-server Reporter: Jukka Zitting Assignee: Jukka Zitting Labels: tika Tika 1.0 was released today and has many improvements over the earlier 0.10 release. We should upgrade. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JCR-3131) NPE in ItemManager when calling Session.save() with nothing to save
[
https://issues.apache.org/jira/browse/JCR-3131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Guggisberg resolved JCR-3131.
Resolution: Fixed
Fix Version/s: 2.4
fixed in svn revision 1196062 by committing the patch with some changes (i've
chosen a somewhat simpler approach).
NPE in ItemManager when calling Session.save() with nothing to save
---
Key: JCR-3131
URL: https://issues.apache.org/jira/browse/JCR-3131
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 2.3.2
Reporter: Bertrand Delacretaz
Assignee: Stefan Guggisberg
Priority: Minor
Fix For: 2.4
Attachments: JCR-3131.patch
I'm getting an NPE on the id.denoteNodes() call below, in ItemManager:
private ItemData retrieveItem(ItemId id) {
synchronized (itemCache) {
ItemData data = itemCache.get(id);
if (data == null id.denotesNode()) {
...
because the id is null after taking the second branch of this if in
SessionSaveOperation.perform:
if (context.getSessionImpl().hasPermission(/, Session.ACTION_READ))
{
id = context.getRootNodeId();
} else {
id =
context.getItemStateManager().getIdOfRootTransientNodeState();
}
context.toString() says:
session-author-3623:
ItemManager (org.apache.jackrabbit.core.ItemManager@1e911ccc)
Items in cache:
SessionItemStateManager
(org.apache.jackrabbit.core.state.SessionItemStateManager@15472b43)
[transient]
{}[attic]
{}
which I assume means there's nothing to save.
The correct behavior is probably to do nothing in perform to avoid the NPE.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3117) Stats for the PersistenceManager
[ https://issues.apache.org/jira/browse/JCR-3117?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13130443#comment-13130443 ] Stefan Guggisberg commented on JCR-3117: patch looks good, thanks! Stats for the PersistenceManager Key: JCR-3117 URL: https://issues.apache.org/jira/browse/JCR-3117 Project: Jackrabbit Content Repository Issue Type: Sub-task Components: jackrabbit-core Reporter: Alex Parvulescu Priority: Minor Attachments: JCR-3117.patch Statistics for the PersistenceManager impl that cover: - bundle cache access count, - bundle cache miss count, - bundle cache miss avg duration (this avg includes the penalty of having to load from the underlying storage / can be interpreted as avg read latency as there is no cache involved) - bundle writes per second What it doesn't cover is : - number of bundles - size of workspace as these are values that are expensive to compute on demand, and caching them would imply being able to store the values (which is not possible currently). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Property constraints modification
hi kamil,
On Thu, Oct 13, 2011 at 12:38 PM, Kamil Nezval kamil.nez...@xitee.com wrote:
Hi,
I've been playing around with a possibility to modify already registered
node types and found 2 things (bugs?) regarding to changing property
constraints:
1) according to the java doc
(http://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/spi/commons/node
type/NodeTypeDefDiff.html) it should be possible to remove all constraints
from a property, but it is not (marked as a MAJOR change).
correct, that's a bug in the current implementation.
2) it's allowed (TRIVIAL) to set a constraint to a property that had no
constraint at all before, which is wrong, because it could affect the
consistency of existing repository content.
correct again, good catch!
could you please file a jira issue [0]?
thanks!
stefan
[0] http://jackrabbit.apache.org/issue-tracker.html
In NodeTypeDefDiff.PropDefDiff.init() there is this test that covers both
situations:
if (!set1.equals(set2)) {
// valueConstraints have been modified
if (set2.containsAll(set1)) {
// new set is a superset of old set
// = constraints have been removed
// (TRIVIAL change, since constraints are OR'ed)
type = TRIVIAL;
} else {
// constraint have been removed/modified (MAJOR change);
// since we're unable to semantically compare
// value constraints (e.g. regular expressions), all
// modifications are considered a MAJOR change.
type = MAJOR;
}
}
where set1 is a list of original constraints and set2 contains new
constraints.
I think the correct version should be something like this (not saying
exactly):
if (!set1.equals(set2)) {
// valueConstraints have been modified
if (set2.isEmpty()) {
// removing all constraints is a TRIVIAL change
type = TRIVIAL;
} else if (set1.isEmpty()){
// setting constraints is a MAJOR change
type = MAJOR;
} else if (set2.containsAll(set1))) {
// new set is a superset of old set
// = constraints have been added
// (TRIVIAL change, since constraints are OR'ed)
type = TRIVIAL;
} else {
type = MAJOR;
}
Could anyone confirm my thoughts? Or am I missing anything?
Thanks.
Kamil
Re: svn commit: r1182835 - in /jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core: cache/AbstractCache.java cache/CacheManager.java persistence/bundle/AbstractBundlePersistenceM
- if (log.isDebugEnabled()) {
+ if (log.isInfoEnabled()) {
what's the justification for changing the log level from debug to info?
On Thu, Oct 13, 2011 at 3:19 PM, alexparvule...@apache.org wrote:
Author: alexparvulescu
Date: Thu Oct 13 13:19:38 2011
New Revision: 1182835
URL: http://svn.apache.org/viewvc?rev=1182835view=rev
Log:
JCR-3098 Add hit miss statistics and logging to caches
- patch by Bart van der Schans, continued
Modified:
jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/cache/AbstractCache.java
jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/cache/CacheManager.java
jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/persistence/bundle/AbstractBundlePersistenceManager.java
Modified:
jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/cache/AbstractCache.java
URL:
http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/cache/AbstractCache.java?rev=1182835r1=1182834r2=1182835view=diff
==
---
jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/cache/AbstractCache.java
(original)
+++
jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/cache/AbstractCache.java
Thu Oct 13 13:19:38 2011
@@ -114,6 +114,7 @@ public abstract class AbstractCache impl
* interval has passed since the previous listener call.
*/
protected void recordCacheAccess() {
+ totalAccessCount.incrementAndGet();
long count = accessCount.incrementAndGet();
if (count % ACCESS_INTERVAL == 0) {
CacheAccessListener listener = accessListener.get();
@@ -121,7 +122,6 @@ public abstract class AbstractCache impl
listener.cacheAccessed(count);
}
}
- totalAccessCount.incrementAndGet();
}
protected void recordCacheMiss() {
@@ -186,13 +186,13 @@ public abstract class AbstractCache impl
long u = getMemoryUsed() / 1024;
long m = getMaxMemorySize() / 1024;
StringBuilder c = new StringBuilder();
- c.append(Cache name=);
+ c.append(cachename=);
c.append(this.toString());
c.append(, elements=);
c.append(getElementCount());
- c.append(, used memory=);
+ c.append(, usedmemorykb=);
c.append(u);
- c.append(, max memory=);
+ c.append(, maxmemorykb=);
c.append(m);
c.append(, access=);
c.append(getTotalAccessCount());
Modified:
jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/cache/CacheManager.java
URL:
http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/cache/CacheManager.java?rev=1182835r1=1182834r2=1182835view=diff
==
---
jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/cache/CacheManager.java
(original)
+++
jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/cache/CacheManager.java
Thu Oct 13 13:19:38 2011
@@ -156,17 +156,18 @@ public class CacheManager implements Cac
* Log info about the caches.
*/
private void logCacheStats() {
- if (log.isDebugEnabled()) {
+ if (log.isInfoEnabled()) {
long now = System.currentTimeMillis();
if (now nextLogStats) {
return;
}
for (Cache cache : caches.keySet()) {
- log.debug(cache.getCacheInfoAsString());
+ log.info(cache.getCacheInfoAsString());
}
nextLogStats = now + minLogStatsInterval;
}
}
+
/**
* Re-calculate the maximum memory for each cache, and set the new limits.
*/
Modified:
jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/persistence/bundle/AbstractBundlePersistenceManager.java
URL:
http://svn.apache.org/viewvc/jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/persistence/bundle/AbstractBundlePersistenceManager.java?rev=1182835r1=1182834r2=1182835view=diff
==
---
jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/persistence/bundle/AbstractBundlePersistenceManager.java
(original)
+++
jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/persistence/bundle/AbstractBundlePersistenceManager.java
Thu Oct 13 13:19:38 2011
@@ -28,6 +28,8 @@ import javax.jcr.PropertyType;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
+import org.apache.jackrabbit.core.cache.Cache;
+import org.apache.jackrabbit.core.cache.CacheAccessListener;
import
Re: svn commit: r1182835 - in /jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core: cache/AbstractCache.java cache/CacheManager.java persistence/bundle/AbstractBundlePersistenceM
hi bart,
On Thu, Oct 13, 2011 at 4:44 PM, Bart van der Schans
b.vandersch...@onehippo.com wrote:
Hi Stefan,
On Thu, Oct 13, 2011 at 4:27 PM, Stefan Guggisberg
stefan.guggisb...@gmail.com wrote:
- if (log.isDebugEnabled()) {
+ if (log.isInfoEnabled()) {
what's the justification for changing the log level from debug to info?
This is to make a distinction between the debug logging of the cache
resizing which logs quite a bit of info every second and the logging
of the cache (access/hit/miss) stats which log every minute
(configurable). It's comparable to the logging of the stats of the
bundle cache in 1.x which was also set on info.
thanks for the explanation. i'd prefer to stick to the debug log level
for this kind of polled, i.e. repeating status information. the info
log level is
imo fine for logging single status change events (e.g. 'repository started')
cheers
stefan
Regards,
Bart
Re: svn commit: r1182835 - in /jackrabbit/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core: cache/AbstractCache.java cache/CacheManager.java persistence/bundle/AbstractBundlePersistenceM
On Thu, Oct 13, 2011 at 5:23 PM, Bart van der Schans
b.vandersch...@onehippo.com wrote:
On Thu, Oct 13, 2011 at 4:51 PM, Stefan Guggisberg
stefan.guggisb...@gmail.com wrote:
hi bart,
On Thu, Oct 13, 2011 at 4:44 PM, Bart van der Schans
b.vandersch...@onehippo.com wrote:
Hi Stefan,
On Thu, Oct 13, 2011 at 4:27 PM, Stefan Guggisberg
stefan.guggisb...@gmail.com wrote:
- if (log.isDebugEnabled()) {
+ if (log.isInfoEnabled()) {
what's the justification for changing the log level from debug to info?
This is to make a distinction between the debug logging of the cache
resizing which logs quite a bit of info every second and the logging
of the cache (access/hit/miss) stats which log every minute
(configurable). It's comparable to the logging of the stats of the
bundle cache in 1.x which was also set on info.
thanks for the explanation. i'd prefer to stick to the debug log level
for this kind of polled, i.e. repeating status information. the info
log level is
imo fine for logging single status change events (e.g. 'repository started')
In general I agree. In this particular case, how can we log the stats
on debug without flooding the logs with the debug output from the
resizeAll() method?
ok, i get your point.
Can we use TRACE log level for the resizing
logging?
i guess yes, that's a good idea.
cheers
stefan
Or is there some configuration trick in the logging (log4j)
config that I'm missing that can be used to achieve that? I guess this
problem will solve itself once we get the JMX bindings in place.
Regards,
Bart
cheers
stefan
Regards,
Bart
[jira] [Resolved] (JCR-3112) NodeTypeDefDiff.PropDefDiff.init() constraints change check bugs
[ https://issues.apache.org/jira/browse/JCR-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved JCR-3112. Resolution: Fixed Fix Version/s: 2.3.2 fixed in svn r1182929 NodeTypeDefDiff.PropDefDiff.init() constraints change check bugs Key: JCR-3112 URL: https://issues.apache.org/jira/browse/JCR-3112 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-spi-commons Affects Versions: 2.3.1 Reporter: Kamil Nezval Fix For: 2.3.2 Two bugs have been found in NodeTypeDefDiff.PropDefDiff.init() when try to modify property constraints of an already registered node type: 1) according to the java doc it should be possible to remove all constraints from a property, but it is not (marked as a MAJOR change). 2) it's allowed (TRIVIAL) to set a constraint to a property that had no constraint at all before, which is wrong, because it could affect the consistency of existing repository content. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3107) Speed up hierarchy cache initialization
[ https://issues.apache.org/jira/browse/JCR-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg updated JCR-3107: --- Component/s: query Speed up hierarchy cache initialization --- Key: JCR-3107 URL: https://issues.apache.org/jira/browse/JCR-3107 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-core, query Reporter: Martin Böttcher Attachments: JCR-3107.patch Initializing a workspace can take quite a long time if there is a big number of nodes and some search indexes involved. The reason is that the setup of the CachingIndexReader is processed using chunks of a certain size (actually 400K) in order to reduce the memory footprint. As soon as the number of documents exceeds this limit some operations (actually traversing complete indexes) are performed again and again. It seems that the current algorithm initializeParents in the CachingIndexReader class can't be optimized without increasing the memory consumption. Therefore it should be a promising approach to persist the state of this class (actually it's main member array and map) and reload it on startup. The load of the state can be done implicitly in the initializing phase of the cache. This is obvious. The correct point of time to call the save operation isn't obvious at all. I tried the doClose method of the class and it seems sufficient. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3063) NullPointerException in ItemManager
[ https://issues.apache.org/jira/browse/JCR-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13116296#comment-13116296 ] Stefan Guggisberg commented on JCR-3063: I restored the JCR-2171 fix in revision 1176465 to prevent the deadlock. ok In the same revision I added explicit checks against the NPEs and CMEs thrown by the test case. The CMEs are avoided by explicit synchronization and NPEs cause InvalidItemStateExceptions instead. hmm, i don't think we can get rid of the related concurrency issues completely. the JCR-2171 fix is IMO wrong. i am sure we'll run into more similar issues sooner or later. OTOH i agree that the deadlock issue is severe and needs to be addressed. if possible i would prefer if we'd try to solve the deadlock issue without the JCR-2171 fix. NullPointerException in ItemManager --- Key: JCR-3063 URL: https://issues.apache.org/jira/browse/JCR-3063 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 2.2.5, 2.2.8 Reporter: Unico Hommes Fix For: 2.2.9 Attachments: NPEandCMETest.java We have a lot of these occurring: java.lang.NullPointerException at org.apache.jackrabbit.core.ItemManager.getDefinition(ItemManager.java:206) at org.apache.jackrabbit.core.ItemData.getDefinition(ItemData.java:99) at org.apache.jackrabbit.core.AbstractNodeData.getNodeDefinition(AbstractNodeData.java:73) at org.apache.jackrabbit.core.NodeImpl.getDefinition(NodeImpl.java:2430) at org.apache.jackrabbit.core.ItemValidator.isProtected(ItemValidator.java:373) at org.apache.jackrabbit.core.ItemValidator.checkCondition(ItemValidator.java:273) at org.apache.jackrabbit.core.ItemValidator.checkRemove(ItemValidator.java:254) at org.apache.jackrabbit.core.ItemRemoveOperation.perform(ItemRemoveOperation.java:63) at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200) at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91) at org.apache.jackrabbit.core.ItemImpl.remove(ItemImpl.java:322) at org.apache.jackrabbit.core.NPEandCMETest$TestTask.run(NPEandCMETest.java:87) at java.lang.Thread.run(Thread.java:679) I'll attach a junit test to reproduce this exception. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3063) NullPointerException in ItemManager
[ https://issues.apache.org/jira/browse/JCR-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13113490#comment-13113490 ] Stefan Guggisberg commented on JCR-3063: this is a regression of JCR-2171. NullPointerException in ItemManager --- Key: JCR-3063 URL: https://issues.apache.org/jira/browse/JCR-3063 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 2.2.5, 2.2.8 Reporter: Unico Hommes Attachments: NPEandCMETest.java We have a lot of these occurring: java.lang.NullPointerException at org.apache.jackrabbit.core.ItemManager.getDefinition(ItemManager.java:206) at org.apache.jackrabbit.core.ItemData.getDefinition(ItemData.java:99) at org.apache.jackrabbit.core.AbstractNodeData.getNodeDefinition(AbstractNodeData.java:73) at org.apache.jackrabbit.core.NodeImpl.getDefinition(NodeImpl.java:2430) at org.apache.jackrabbit.core.ItemValidator.isProtected(ItemValidator.java:373) at org.apache.jackrabbit.core.ItemValidator.checkCondition(ItemValidator.java:273) at org.apache.jackrabbit.core.ItemValidator.checkRemove(ItemValidator.java:254) at org.apache.jackrabbit.core.ItemRemoveOperation.perform(ItemRemoveOperation.java:63) at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200) at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91) at org.apache.jackrabbit.core.ItemImpl.remove(ItemImpl.java:322) at org.apache.jackrabbit.core.NPEandCMETest$TestTask.run(NPEandCMETest.java:87) at java.lang.Thread.run(Thread.java:679) I'll attach a junit test to reproduce this exception. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JCR-3063) NullPointerException in ItemManager
[ https://issues.apache.org/jira/browse/JCR-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved JCR-3063. Resolution: Fixed Fix Version/s: 2.3.0 fixed in svn r1174822 by reverting the change introduced by JCR-2171. JCR-2171 doesn't include a test case. however, i am optimistic that the dead lock issue has been resolved as of JCR-2650. NullPointerException in ItemManager --- Key: JCR-3063 URL: https://issues.apache.org/jira/browse/JCR-3063 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 2.2.5, 2.2.8 Reporter: Unico Hommes Fix For: 2.3.0 Attachments: NPEandCMETest.java We have a lot of these occurring: java.lang.NullPointerException at org.apache.jackrabbit.core.ItemManager.getDefinition(ItemManager.java:206) at org.apache.jackrabbit.core.ItemData.getDefinition(ItemData.java:99) at org.apache.jackrabbit.core.AbstractNodeData.getNodeDefinition(AbstractNodeData.java:73) at org.apache.jackrabbit.core.NodeImpl.getDefinition(NodeImpl.java:2430) at org.apache.jackrabbit.core.ItemValidator.isProtected(ItemValidator.java:373) at org.apache.jackrabbit.core.ItemValidator.checkCondition(ItemValidator.java:273) at org.apache.jackrabbit.core.ItemValidator.checkRemove(ItemValidator.java:254) at org.apache.jackrabbit.core.ItemRemoveOperation.perform(ItemRemoveOperation.java:63) at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200) at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91) at org.apache.jackrabbit.core.ItemImpl.remove(ItemImpl.java:322) at org.apache.jackrabbit.core.NPEandCMETest$TestTask.run(NPEandCMETest.java:87) at java.lang.Thread.run(Thread.java:679) I'll attach a junit test to reproduce this exception. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (JCR-1848) ConcurrentModificationException in SessionItemStateManager when multiple updates happening
[ https://issues.apache.org/jira/browse/JCR-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg reassigned JCR-1848: -- Assignee: Stefan Guggisberg ConcurrentModificationException in SessionItemStateManager when multiple updates happening -- Key: JCR-1848 URL: https://issues.apache.org/jira/browse/JCR-1848 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: core 1.4.6 Reporter: Chris Wilkes Assignee: Stefan Guggisberg Attachments: NPEandCMETest.java I'll post a trimmed down version of how I can get this error to be thrown. I bring this up as the code in SessionItemStateManager explicitly checks for a ItemNotFoundException so it looks like there was some thought put in to what happens if the underlying data changes. java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793) at java.util.HashMap$ValueIterator.next(HashMap.java:822) at java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1010) at org.apache.jackrabbit.core.state.SessionItemStateManager.getDescendantTransientItemStates(SessionItemStateManager.java:405) at org.apache.jackrabbit.core.ItemImpl.getTransientStates(ItemImpl.java:317) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1080) at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:897) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3063) NullPointerException in ItemManager
[ https://issues.apache.org/jira/browse/JCR-3063?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13104607#comment-13104607 ] Stefan Guggisberg commented on JCR-3063: i am now able to reproduce the NPEs and CMEs, thanks for providing a test case! NullPointerException in ItemManager --- Key: JCR-3063 URL: https://issues.apache.org/jira/browse/JCR-3063 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 2.2.5, 2.2.8 Reporter: Unico Hommes Attachments: NPEandCMETest.java We have a lot of these occurring: java.lang.NullPointerException at org.apache.jackrabbit.core.ItemManager.getDefinition(ItemManager.java:206) at org.apache.jackrabbit.core.ItemData.getDefinition(ItemData.java:99) at org.apache.jackrabbit.core.AbstractNodeData.getNodeDefinition(AbstractNodeData.java:73) at org.apache.jackrabbit.core.NodeImpl.getDefinition(NodeImpl.java:2430) at org.apache.jackrabbit.core.ItemValidator.isProtected(ItemValidator.java:373) at org.apache.jackrabbit.core.ItemValidator.checkCondition(ItemValidator.java:273) at org.apache.jackrabbit.core.ItemValidator.checkRemove(ItemValidator.java:254) at org.apache.jackrabbit.core.ItemRemoveOperation.perform(ItemRemoveOperation.java:63) at org.apache.jackrabbit.core.session.SessionState.perform(SessionState.java:200) at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:91) at org.apache.jackrabbit.core.ItemImpl.remove(ItemImpl.java:322) at org.apache.jackrabbit.core.NPEandCMETest$TestTask.run(NPEandCMETest.java:87) at java.lang.Thread.run(Thread.java:679) I'll attach a junit test to reproduce this exception. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3040) JMX Stats for the Session
[ https://issues.apache.org/jira/browse/JCR-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13101150#comment-13101150 ] Stefan Guggisberg commented on JCR-3040: @alex thanks for the reworked patch (JCR-3040-v2.patch). looks good so far. JMX Stats for the Session - Key: JCR-3040 URL: https://issues.apache.org/jira/browse/JCR-3040 Project: Jackrabbit Content Repository Issue Type: Sub-task Components: jackrabbit-core Reporter: Alex Parvulescu Assignee: Alex Parvulescu Attachments: JCR-3040-v2.patch, JCR-3040.patch, jr-test.log I've named them Core stats. This will include: - number of sessions currently opened - session read / write operations per second The stats refresh once a minute. This is disabled by default, so it will not affect performance. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Update on j3
hi jukka On Thu, Sep 1, 2011 at 2:11 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, The level of activity on the j3 sandbox has been pretty nice in the past few weeks. Would someone working on the code care to give a short update on the latest developments? The commit messages have been rather terse for now... we're still at a very early stage and the code base is still far from stabilizing. we're experimenting with different ideas/approaches which sometimes get discarded soon after (much like in a proper sandbox ;). that's why commit msgs might be terse at times. the goal is to have a working spi-based stack with the microkernel underneath (jcr2spi-spi2mk). such a stack would serve us as a POC for the technical viability of a MVCC-based microkernel approach. furthermore it would allow to benchmark the mk-based stack against jackrabbit-core and jcr2spi-spi2jcr. one thing we've learned so far is that the spi abstraction layer probably needs to be largely re-written/re-designed in order to fully take advantage of a MVCC-based microkernel. cheers stefan BR, Jukka Zitting
[jira] [Commented] (JCR-2272) Errors during concurrent session import of nodes with same UUIDs
[ https://issues.apache.org/jira/browse/JCR-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13095291#comment-13095291 ] Stefan Guggisberg commented on JCR-2272: as of JCR-2650 STATUS_STALE_MODIFIED is not applicable anymore Errors during concurrent session import of nodes with same UUIDs Key: JCR-2272 URL: https://issues.apache.org/jira/browse/JCR-2272 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core, xml Affects Versions: 2.0-alpha8 Reporter: Tobias Bocanegra Attachments: JCR-2272.patch, JCR-2272_NPE.patch, JCR-2272__Errors_during_concurrent_session_import_of_nodes_with_same_UUIDs.patch, JCR-2272_revised.patch 21.08.2009 16:22:14 *ERROR* [Executor 0] ConnectionRecoveryManager: could not execute statement, reason: The statement was aborted because it would have caused a duplicate key value in a unique or primary key constraint or unique index identified by 'SQL090821042140130' defined on 'DEFAULT_BUNDLE'., state/code: 23505/2 (ConnectionRecoveryManager.java, line 453) 21.08.2009 16:22:14 *ERROR* [Executor 0] BundleDbPersistenceManager: failed to write bundle: 6c292772-349e-42b3-8255-7729615c67de (BundleDbPersistenceManager.java, line 1212) ERROR 23505: The statement was aborted because it would have caused a duplicate key value in a unique or primary key constraint or unique index identified by 'SQL090821042140130' defined on 'DEFAULT_BUNDLE'. at org.apache.derby.iapi.error.StandardException.newException(Unknown Source) at org.apache.derby.impl.sql.execute.IndexChanger.insertAndCheckDups(Unknown Source) at org.apache.derby.impl.sql.execute.IndexChanger.doInsert(Unknown Source) at org.apache.derby.impl.sql.execute.IndexChanger.insert(Unknown Source) at org.apache.derby.impl.sql.execute.IndexSetChanger.insert(Unknown Source) at org.apache.derby.impl.sql.execute.RowChangerImpl.insertRow(Unknown Source) at org.apache.derby.impl.sql.execute.InsertResultSet.normalInsertCore(Unknown Source) at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown Source) at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown Source) at org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(Unknown Source) at org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(Unknown Source) at org.apache.jackrabbit.core.persistence.bundle.util.ConnectionRecoveryManager.executeStmtInternal(ConnectionRecoveryManager.java:371) at org.apache.jackrabbit.core.persistence.bundle.util.ConnectionRecoveryManager.executeStmtInternal(ConnectionRecoveryManager.java:298) at org.apache.jackrabbit.core.persistence.bundle.util.ConnectionRecoveryManager.executeStmt(ConnectionRecoveryManager.java:261) at org.apache.jackrabbit.core.persistence.bundle.util.ConnectionRecoveryManager.executeStmt(ConnectionRecoveryManager.java:239) at org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.storeBundle(BundleDbPersistenceManager.java:1209) at org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.putBundle(AbstractBundlePersistenceManager.java:709) at org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.storeInternal(AbstractBundlePersistenceManager.java:651) at org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.store(AbstractBundlePersistenceManager.java:527) at org.apache.jackrabbit.core.persistence.bundle.BundleDbPersistenceManager.store(BundleDbPersistenceManager.java:563) at org.apache.jackrabbit.core.state.SharedItemStateManager$Update.end(SharedItemStateManager.java:724) at org.apache.jackrabbit.core.state.SharedItemStateManager.update(SharedItemStateManager.java:1101) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:351) at org.apache.jackrabbit.core.state.XAItemStateManager.update(XAItemStateManager.java:354) at org.apache.jackrabbit.core.state.LocalItemStateManager.update(LocalItemStateManager.java:326) at org.apache.jackrabbit.core.state.SessionItemStateManager.update(SessionItemStateManager.java:326) at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1098) at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:925) at org.apache.jackrabbit.core.ConcurrentImportTest$1.execute(ConcurrentImportTest.java:73) at org.apache.jackrabbit.core.AbstractConcurrencyTest$Executor.run(AbstractConcurrencyTest.java:209
Re: Jackrabbit workspace copy
On Thu, Aug 25, 2011 at 9:43 AM, vikash vikash.kon...@gmail.com wrote: Hi, I have 2 different jackrabbit instances running at staging and production machine and I am using workspaces. Can I copy a staging workspace to production workspace and how? no, you'll have to export/import the content. see e.g. [1], [2]. Is workspace copy method works inside the same instance only? yes cheers stefan [1] http://www.day.com/maven/jsr170/javadocs/jcr-1.0/javax/jcr/Session.html#exportSystemView(java.lang.String, java.io.OutputStream, boolean, boolean) [2] http://www.day.com/maven/jsr170/javadocs/jcr-1.0/javax/jcr/Workspace.html#importXML(java.lang.String, java.io.InputStream, int) -Vikash -- View this message in context: http://jackrabbit.510166.n4.nabble.com/Jackrabbit-workspace-copy-tp3767571p3767571.html Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
[jira] [Commented] (JCR-3060) Add utility methods for path creation
[ https://issues.apache.org/jira/browse/JCR-3060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090114#comment-13090114 ] Stefan Guggisberg commented on JCR-3060: the method names are IMO misleading (createPath suggests that a Path object is created). how about e.g. - getOrCreateNode - getOrCreateByPath Add utility methods for path creation - Key: JCR-3060 URL: https://issues.apache.org/jira/browse/JCR-3060 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-jcr-commons Affects Versions: 2.2.7 Reporter: Carsten Ziegeler Priority: Minor Attachments: JcrUtils.java.patch While the JcrUtil class has methods to create a node, it does not have methods to create paths. This patch adds several methods which allow to create or get complete node paths -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3060) Add utility methods for path creation
[ https://issues.apache.org/jira/browse/JCR-3060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13090154#comment-13090154 ] Stefan Guggisberg commented on JCR-3060: no, if you'll change the names to something more appropriate that's fine with me. Add utility methods for path creation - Key: JCR-3060 URL: https://issues.apache.org/jira/browse/JCR-3060 Project: Jackrabbit Content Repository Issue Type: Improvement Components: jackrabbit-jcr-commons Affects Versions: 2.2.7 Reporter: Carsten Ziegeler Priority: Minor Attachments: JcrUtils.java.patch While the JcrUtil class has methods to create a node, it does not have methods to create paths. This patch adds several methods which allow to create or get complete node paths -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Failed to get values of URI typed properties
2011/8/19 Suat Gönül suatgo...@gmail.com: Hi everybody, I can create a URI typed property for a node and set its value by a code snippet as follows: Node n; //somehow initialize the node String uriprop = uriprop; String val = http://www.example.org;; n.setProperty(uriprop, val, PropertyType.URI); After this code, when I try to get the value I set with the code below, javax.jcr.ValueFormatException: Unknown value type 11 exception is thrown. Property p = n.getProperty(uriprop); p.getValue(); Is this a bug, or is there any way to get values of URI typed properties? you're accessing the repository through RMI, right? it seems that jackrabbit-jcr-rmi doesn't yet support all new JCR 2.0 property types. here's the related container issue: https://issues.apache.org/jira/browse/JCRRMI-26 cheers stefan BTW, I also tried set the value through session.getValueFactory().createValue(val, PropertyType.URI), but this code also throws the same exception. I also tried to obtain string value with p.getString(), but again the same exception. As far as I see, this property is not handled in org.apache.jackrabbit.rmi.value.SerialValueFactory class though I am not sure it is the exact responsible class from the property value retrieval. Best, Suat
[jira] [Commented] (JCR-3040) JMX Stats for the Session
[ https://issues.apache.org/jira/browse/JCR-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086931#comment-13086931 ] Stefan Guggisberg commented on JCR-3040: I also don't see the regression risk, [...] how about this one for example? ;) https://builds.apache.org/job/Jackrabbit-trunk/ws/trunk/jackrabbit-core/src/main/java/org/apache/jackrabbit/core/jmx/query/QueryStatManager.java:[107,37] type javax.management.openmbean.OpenType does not take parameters i am not a jmx expert but my gut feeling tells me that there could be potential issues with different deployments/environments/etc... that's why i don't like ootb jmx support. in your patch you're calling javax.management.* code unconditionally from the RepositoryImpl constructor. IMO that should at least be made dependent on configuration. JMX Stats for the Session - Key: JCR-3040 URL: https://issues.apache.org/jira/browse/JCR-3040 Project: Jackrabbit Content Repository Issue Type: Sub-task Components: jackrabbit-core Reporter: Alex Parvulescu Assignee: Alex Parvulescu Attachments: JCR-3040.patch, jr-test.log I've named them Core stats. This will include: - number of sessions currently opened - session read / write operations per second The stats refresh once a minute. This is disabled by default, so it will not affect performance. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3040) JMX Stats for the Session
[
https://issues.apache.org/jira/browse/JCR-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13086381#comment-13086381
]
Stefan Guggisberg commented on JCR-3040:
thanks for the patch and sharing some test results!
WRT the results:
the spread of the test results is huge, i don't think that they allow any
conclusion WRT to the potential performance impact.
WRT the patch:
i agree with thomas's comments. apart from those i've got a few remarks
regarding the RepositoryImpl changes:
- i'd prefer to move the sessionCreated() and sessionLoggedOut() calls outside
of the 'synchronized (activeSessions) {}' block.
- MBeanServer.registerMBean() is called on every startup, whether the stats
are enabled or not.
i'd prefer if that call would only be made depending on e.g. a system
property.
WRT to adding JMX support to jackrabbit core:
just based on 'slight interest' i'm rather reluctant adding major features to
jackrabbit core
with considerable risk of causing regressions.
JMX Stats for the Session
-
Key: JCR-3040
URL: https://issues.apache.org/jira/browse/JCR-3040
Project: Jackrabbit Content Repository
Issue Type: Sub-task
Components: jackrabbit-core
Reporter: Alex Parvulescu
Assignee: Alex Parvulescu
Attachments: JCR-3040.patch, jr-test.log
I've named them Core stats. This will include:
- number of sessions currently opened
- session read / write operations per second
The stats refresh once a minute.
This is disabled by default, so it will not affect performance.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3040) JMX Stats for the Session
[ https://issues.apache.org/jira/browse/JCR-3040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13079388#comment-13079388 ] Stefan Guggisberg commented on JCR-3040: the description of JCR-2936 states that There has been a slight interest in the past for adding JMX support.. JCR-3040 however does come with a huge commit, affecting critical parts of jackrabbit-core, with (IMO) considerable risk of causing regressions. i would have appreciated if a patch had been provided for discussion rather than committing the changes within 1 minute after creating the issue. if there's only 'slight interest' i am rather conservative WRT performing major changes in jackrabbit-core. JMX Stats for the Session - Key: JCR-3040 URL: https://issues.apache.org/jira/browse/JCR-3040 Project: Jackrabbit Content Repository Issue Type: Sub-task Components: jackrabbit-core Reporter: Alex Parvulescu Assignee: Alex Parvulescu I've named them Core stats. This will include: - number of sessions currently opened - session read / write operations per second The stats refresh once a minute. This is disabled by default, so it will not affect performance. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-2936) JMX Bindings for Jackrabbit
[ https://issues.apache.org/jira/browse/JCR-2936?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13079391#comment-13079391 ] Stefan Guggisberg commented on JCR-2936: It is not enabled by default, so just being there should not affect the overall performance too much. what do you mean by not too much? can you provide performance figures? JMX Bindings for Jackrabbit --- Key: JCR-2936 URL: https://issues.apache.org/jira/browse/JCR-2936 Project: Jackrabbit Content Repository Issue Type: New Feature Components: jackrabbit-core Reporter: Alex Parvulescu Priority: Minor Attachments: JCR-2936-part2.patch, JCR-2936.patch There has been a slight interest in the past for adding JMX support. This would be the first stab at it. It is a Top 15 slow query log. (the 15 part is configurable) It is not enabled by default, so just being there should not affect the overall performance too much. You can enable it and play a little, tell me what you think. I've also added a test case that does a duration comparison with and without the logger. The most important part of this issue is that it should open the way for some proper monitoring tools support around queries, caches, anything/everything Jackrabbit. As usual, please let me know what you guys think -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: JIRA issues status
On Wed, Jul 27, 2011 at 3:26 PM, Edouard Hue edouard@gmail.com wrote: Hi all, Could someone tell me why the issue JCR-3030 doesn't show up in the Task board ? Should I have left its status to open instead of patch available ? the task board is IMO irrelevant, AFAIK it's not actively used (at least i don't use it ;). personally i only care whether an issue is resolved or not. cheers stefan Regards, Edouard
[jira] [Commented] (JCR-3018) save leading to ReferentialIntegrityException leaves the repository in inconsistent state
[ https://issues.apache.org/jira/browse/JCR-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13065836#comment-13065836 ] Stefan Guggisberg commented on JCR-3018: On the other hand, we should discuss in the EG what the expectations are for the usability of Node objects after a failed save operation. agreed save leading to ReferentialIntegrityException leaves the repository in inconsistent state - Key: JCR-3018 URL: https://issues.apache.org/jira/browse/JCR-3018 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Reporter: Julian Reschke Priority: Minor This is similar to JCR-2503. After a failed save() due to ReferentialIntegrityException and a subsequent successfull save() operation, nodes that were transient upon the first save and were persisted in the 2nd save will be corrupted, a getPath() operation failing with: javax.jcr.InvalidItemStateException: Item does not exist anymore: 75fe7eb7-7747-476e-bba8-c7f6b7f6e1a8 at org.apache.jackrabbit.core.ItemImpl.itemSanityCheck(ItemImpl.java:116) at org.apache.jackrabbit.core.ItemImpl.perform(ItemImpl.java:90) at org.apache.jackrabbit.core.ItemImpl.getPath(ItemImpl.java:376) The test is identical to the one added for JCR-2503, except that the node does not get refetched using getNodeByIdentifier. (test case follows) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3014) Identifier paths for inexistent items throw exception
[ https://issues.apache.org/jira/browse/JCR-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13066212#comment-13066212 ] Stefan Guggisberg commented on JCR-3014: your solution is more involved, there will be a lot of changes you're right. i've chosen a simpler approach now. it's not very elegant but it solves the problem with minimal risk of regressions and all existing tests passing. Identifier paths for inexistent items throw exception - Key: JCR-3014 URL: https://issues.apache.org/jira/browse/JCR-3014 Project: Jackrabbit Content Repository Issue Type: Bug Reporter: Marcel Reutegger Assignee: Alex Parvulescu Fix For: 2.3.0 The following fails with a RepositoryException but it should rather return false: session.itemExists([ + UUID.randomUUID() + ]) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JCR-3014) Identifier paths for inexistent items throw exception
[ https://issues.apache.org/jira/browse/JCR-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved JCR-3014. Resolution: Fixed Assignee: Stefan Guggisberg (was: Alex Parvulescu) fixed in revision 1147320. Identifier paths for inexistent items throw exception - Key: JCR-3014 URL: https://issues.apache.org/jira/browse/JCR-3014 Project: Jackrabbit Content Repository Issue Type: Bug Reporter: Marcel Reutegger Assignee: Stefan Guggisberg Fix For: 2.3.0 The following fails with a RepositoryException but it should rather return false: session.itemExists([ + UUID.randomUUID() + ]) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JCR-3023) NPE on logout in SessionImpl
[ https://issues.apache.org/jira/browse/JCR-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved JCR-3023. Resolution: Duplicate this is essentially a duplicate of JCR-3022 NPE on logout in SessionImpl Key: JCR-3023 URL: https://issues.apache.org/jira/browse/JCR-3023 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 2.1.1, 2.1.2, 2.1.3, 2.1.5 Reporter: Carl Hall Got this on Sling shutdown. Looks like it just needs a null check before calling close. 08.06.2011 14:01:28.484 *WARN* [Finalizer] org.apache.jackrabbit.core.SessionImpl error while closing AccessManager java.lang.NullPointerException at org.apache.jackrabbit.core.SessionImpl.logout(SessionImpl.java:1252) at org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:410) at org.apache.jackrabbit.core.SessionImpl.finalize(SessionImpl.java:1680) at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method) at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83) at java.lang.ref.Finalizer.access$100(Finalizer.java:14) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3022) NPE on logout in XASessionImpl
[ https://issues.apache.org/jira/browse/JCR-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13065224#comment-13065224 ] Stefan Guggisberg commented on JCR-3022: logout is obviously called from the finalize method. this indicates that the session hasn't been closed explicitly by the application. you should therefore see debug log msgs like this: Unclosed session detected. The session was opened here: [stacktrace...] however, i can't explain how the versionMgr field could possibly be null. versionMgr is declared as 'final' and is instantiated in the SessionImpl constructor. it can't be set to null because it's final. please provide detailed information about your environment/deployment. is this issue reproducible with a simple test case? NPE on logout in XASessionImpl -- Key: JCR-3022 URL: https://issues.apache.org/jira/browse/JCR-3022 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 2.1.1, 2.1.2, 2.1.3, 2.1.5, 2.2.7 Reporter: Carl Hall Found this in our logs when shutting down Sling. Not seen very frequently though. Seems like a null check before calling ((InternalXAVersionManager) versionMgr).close() would clear the message but maybe this null needs to be logged. v2.2 = org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:392) v2.1 = org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:413) 08.06.2011 14:01:28.484 *WARN* [Finalizer] org.apache.jackrabbit.core.XASessionImpl error while closing InternalXAVersionManager java.lang.NullPointerException at org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:413) at org.apache.jackrabbit.core.SessionImpl.finalize(SessionImpl.java:1680) at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method) at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83) at java.lang.ref.Finalizer.access$100(Finalizer.java:14) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JCR-3022) NPE on logout in XASessionImpl
[ https://issues.apache.org/jira/browse/JCR-3022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg updated JCR-3022: --- Priority: Minor (was: Major) not a major issue NPE on logout in XASessionImpl -- Key: JCR-3022 URL: https://issues.apache.org/jira/browse/JCR-3022 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Affects Versions: 2.1.1, 2.1.2, 2.1.3, 2.1.5, 2.2.7 Reporter: Carl Hall Priority: Minor Found this in our logs when shutting down Sling. Not seen very frequently though. Seems like a null check before calling ((InternalXAVersionManager) versionMgr).close() would clear the message but maybe this null needs to be logged. v2.2 = org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:392) v2.1 = org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:413) 08.06.2011 14:01:28.484 *WARN* [Finalizer] org.apache.jackrabbit.core.XASessionImpl error while closing InternalXAVersionManager java.lang.NullPointerException at org.apache.jackrabbit.core.XASessionImpl.logout(XASessionImpl.java:413) at org.apache.jackrabbit.core.SessionImpl.finalize(SessionImpl.java:1680) at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method) at java.lang.ref.Finalizer.runFinalizer(Finalizer.java:83) at java.lang.ref.Finalizer.access$100(Finalizer.java:14) at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:160) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JCR-3013) ArrayIndexOutOfBoundsException: ConcurrentCache
[
https://issues.apache.org/jira/browse/JCR-3013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064462#comment-13064462
]
Stefan Guggisberg commented on JCR-3013:
Would it be more appropriate to change the accessCount in AbstractCache to an
AtomicLong? This would be more in line with the signature of getAccessCount()
which returns a long.
while using AtomicLong would certainly reduce the probability that this problem
occurs
guarding against numeric overflow would IMO still be required.
ArrayIndexOutOfBoundsException: ConcurrentCache
---
Key: JCR-3013
URL: https://issues.apache.org/jira/browse/JCR-3013
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 2.2.5, 2.2.7
Environment: My Platform:
- Linux Debian (64)
- sun
java version 1.6.0_22
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Java HotSpot(TM) 64-Bit Server VM (build 17.1-b03, mixed mode)
- MemTotal: 49563216 kB
- Intel(R) Xeon(R) CPU E5530 @ 2.40GHz
- apache sling / JCR Cluster
Reporter: Michael Klenk
Fix For: 2.3.0
Attachments: ConcurrentCache.patch
ArrayIndexOutOfBoundsException after several days of uptime.
I'm experiencing some strange ArrayIndexOutOfBoundsExceptions on
accessing the jackrabbit ConcurrentCache in 2.2.5. in Line 241 during
shrinkIfNeeded check.
Caused by: java.lang.ArrayIndexOutOfBoundsException: -14
at
org.apache.jackrabbit.core.cache.ConcurrentCache.shrinkIfNeeded(ConcurrentCache.java:241)
I reviewed jackrabbit-code and I'm sure it's caused by that
AtomicInteger for realizing accessCounter in AbstractCache, which will
have become negative during increasing over the Integer.MAX_VALUE constant.
// Semi-random start index to prevent bias against the first
segments
int start = (int) getAccessCount() % segments.length;
for (int i = start; isTooBig(); i = (i + 1) % segments.length) {
synchronized (segments[i]) {
___
Uncaught Throwable java.lang.ArrayIndexOutOfBoundsException: -7
at
org.apache.jackrabbit.core.cache.ConcurrentCache.shrinkIfNeeded(ConcurrentCache.java:241)
at
org.apache.jackrabbit.core.cache.ConcurrentCache.put(ConcurrentCache.java:176)
at
org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.getBundle(AbstractBundlePersistenceManager.java:657)
at
org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.load(AbstractBundlePersistenceManager.java:400)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.loadItemState(SharedItemStateManager.java:1819)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.getNonVirtualItemState(SharedItemStateManager.java:1739)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.getItemState(SharedItemStateManager.java:261)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.getNodeState(LocalItemStateManager.java:107)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(LocalItemStateManager.java:172)
at
org.apache.jackrabbit.core.state.XAItemStateManager.getItemState(XAItemStateManager.java:260)
at
org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:161)
at
org.apache.jackrabbit.core.ItemManager.getItemData(ItemManager.java:370)
at
org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:316)
at
org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:610)
at
org.apache.jackrabbit.core.SessionImpl.getNodeById(SessionImpl.java:493)
at
org.apache.jackrabbit.core.SessionImpl.getNodeByIdentifier(SessionImpl.java:1045)
at sun.reflect.GeneratedMethodAccessor31.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.sling.jcr.base.SessionProxyHandler$SessionProxyInvocationHandler.invoke(SessionProxyHandler.java:109)
at $Proxy2.getNodeByIdentifier(Unknown Source)
at
de.dig.cms.frontend.servlet.helper.ResourceUtil.findResourceById(ResourceUtil.java:44)
at
de.dig.cms.frontend.servlet.CMSContentEnrichServletFilter.doFilter(CMSContentEnrichServletFilter.java:194)
at
org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:60)
at
de.dig.cms.frontend.servlet.CacheControlFilter.doFilter(CacheControlFilter.java:120
[jira] [Commented] (JCR-3014) Identifier paths for inexistent items throw exception
[ https://issues.apache.org/jira/browse/JCR-3014?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13064650#comment-13064650 ] Stefan Guggisberg commented on JCR-3014: i don't agree with the current changes. IMO we should fix the IdentifierResolver interface and its implementations instead. public Path getPath(String identifier) throws MalformedPathException; should be changed to public Path getPath(String identifier) throws ItemNotFoundException, MalformedIdentifierException; Identifier paths for inexistent items throw exception - Key: JCR-3014 URL: https://issues.apache.org/jira/browse/JCR-3014 Project: Jackrabbit Content Repository Issue Type: Bug Reporter: Marcel Reutegger Assignee: Alex Parvulescu Fix For: 2.3.0 The following fails with a RepositoryException but it should rather return false: session.itemExists([ + UUID.randomUUID() + ]) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (JCR-3016) inconsistent repository after overlapping node add operations
[ https://issues.apache.org/jira/browse/JCR-3016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Guggisberg resolved JCR-3016. Resolution: Fixed Fix Version/s: 2.3.0 fixed in svn revision 1144695 inconsistent repository after overlapping node add operations - Key: JCR-3016 URL: https://issues.apache.org/jira/browse/JCR-3016 Project: Jackrabbit Content Repository Issue Type: Bug Components: jackrabbit-core Reporter: Julian Reschke Assignee: Stefan Guggisberg Fix For: 2.3.0 Attachments: OverlappingNodeAddTest.diff, OverlappingNodeAddTest.java It seems I can reproduce a sequence of operations that cause the repository to be inconsistent. The short version: 2 sessions add a same-named child node to the same parent folder (not allowing same-name-siblings). Session 1's save() succeeds. Session 2's save() fails, but succeeds on retry (!). After the operation, the child node created by session 1 is still present, but the parent doesn't list it as child node anymore. (will add test case) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: ArrayIndexOutOfBoundsException in jackrabbit-core: ConcurrentCache
hi michael,
On Tue, Jun 28, 2011 at 2:25 PM, Michael Klenk kl...@dig.de wrote:
Hi,
it seems, there exists no bug for this issue right now. The problem described
below crashes our application several times a week. Could you please check if
this problem is a Jackrabbit bug, or if it is an application bug due to a
missing reset (event?) of accessCounter.
yes, it's a jackrabbit bug. could you please create a jira issue? i'll
take care of the rest.
thanks!
stefan
For the moment I've patched the class ConcurrentCache like shown in patch.
system: Apache sling with jackrabbit 2.2.5 for Content Management System.
Thanks in advance
Michael
Original-Nachricht
Betreff: ArrayIndexOutOfBoundsException in jackrabbit-core: ConcurrentCache
Datum: Mon, 20 Jun 2011 21:09:32 +0200
Von: Michael Klenk kl...@dig.de
Antwort an: us...@jackrabbit.apache.org
An: us...@jackrabbit.apache.org
Hi everyone,
I'm experiencing some strange ArrayIndexOutOfBoundsExceptions on
accessing the jackrabbit ConcurrentCache in 2.2.5. in Line 241 during
shrinkIfNeeded check.
Caused by: java.lang.ArrayIndexOutOfBoundsException: -14
at
org.apache.jackrabbit.core.cache.ConcurrentCache.shrinkIfNeeded(ConcurrentCache.java:241)
I reviewed jackrabbit-code and I'm sure it's caused by that
AtomicInteger for realizing accessCounter in AbstractCache, which will
have become negative during increasing over the Integer.MAX_VALUE constant.
// Semi-random start index to prevent bias against the first
segments
int start = (int) getAccessCount() % segments.length;
for (int i = start; isTooBig(); i = (i + 1) % segments.length) {
synchronized (segments[i]) {
Is there any bug already reported about this problem? Is a fix or some
workaround availlable? Can anyone confirm this problem? I haven't found
any...
Thanks in advance
Michael
___
Uncaught Throwable java.lang.ArrayIndexOutOfBoundsException: -7
at
org.apache.jackrabbit.core.cache.ConcurrentCache.shrinkIfNeeded(ConcurrentCache.java:241)
at
org.apache.jackrabbit.core.cache.ConcurrentCache.put(ConcurrentCache.java:176)
at
org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.getBundle(AbstractBundlePersistenceManager.java:657)
at
org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.load(AbstractBundlePersistenceManager.java:400)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.loadItemState(SharedItemStateManager.java:1819)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.getNonVirtualItemState(SharedItemStateManager.java:1739)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.getItemState(SharedItemStateManager.java:261)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.getNodeState(LocalItemStateManager.java:107)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(LocalItemStateManager.java:172)
at
org.apache.jackrabbit.core.state.XAItemStateManager.getItemState(XAItemStateManager.java:260)
at
org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:161)
at
org.apache.jackrabbit.core.ItemManager.getItemData(ItemManager.java:370)
at
org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:316)
at
org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:610)
at
org.apache.jackrabbit.core.SessionImpl.getNodeById(SessionImpl.java:493)
at
org.apache.jackrabbit.core.SessionImpl.getNodeByIdentifier(SessionImpl.java:1045)
at sun.reflect.GeneratedMethodAccessor31.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.sling.jcr.base.SessionProxyHandler$SessionProxyInvocationHandler.invoke(SessionProxyHandler.java:109)
at $Proxy2.getNodeByIdentifier(Unknown Source)
at
de.dig.cms.frontend.servlet.helper.ResourceUtil.findResourceById(ResourceUtil.java:44)
at
de.dig.cms.frontend.servlet.CMSContentEnrichServletFilter.doFilter(CMSContentEnrichServletFilter.java:194)
at
org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:60)
at
de.dig.cms.frontend.servlet.CacheControlFilter.doFilter(CacheControlFilter.java:120)
at
org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:60)
at
de.dig.cms.cache.impl.WallCacheServletFilter.processCacheableRequest(WallCacheServletFilter.java:244)
at
de.dig.cms.cache.impl.WallCacheServletFilter.processCacheableRequestWithLatch(WallCacheServletFilter.java:185)
at
[jira] [Commented] (JCR-2985) Transient space bug in combination with removeItem() + addNode() + itemExists()
[
https://issues.apache.org/jira/browse/JCR-2985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13060575#comment-13060575
]
Stefan Guggisberg commented on JCR-2985:
i was able to reproduce the issue. it's most likely a
CachingHierarchyManager-related issue.
Transient space bug in combination with removeItem() + addNode() +
itemExists()
---
Key: JCR-2985
URL: https://issues.apache.org/jira/browse/JCR-2985
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 2.2.5
Environment: Win7
Reporter: Thomas Auinger
Please see my original mailing list mail, and reply from Jukka following below
Hi,
I just tested against the brandnew 2.2.7, and can still repro this bug. Would
you please check yourself? The test class code is below.
Simply grab a repositorty.xml file (I took mine from
jackrabbit-core-2.2.7-sources.jar\org\apache\jackrabbit\core\repository.xml).
When you start the test on a missing or empty repo-folder, it works. Running
it a second time doesn't.
Thanks!
Tom
package de.byteconsult.spoon.cmd;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileNotFoundException;
import javax.jcr.Node;
import javax.jcr.Repository;
import javax.jcr.RepositoryException;
import javax.jcr.Session;
import javax.jcr.SimpleCredentials;
import org.apache.jackrabbit.core.RepositoryImpl;
import org.apache.jackrabbit.core.config.RepositoryConfig;
import org.junit.Assert;
import org.junit.Test;
public class TestRepoBug {
@Test
public void addTest() throws Exception {
Repository repo =
this.createFileBasedRepository(target/test-jackrabbit,
src/test/resources/test-repository.xml);
if (repo != null) {
System.out.println(Version: +
repo.getDescriptor(Repository.REP_VERSION_DESC));
SimpleCredentials credentials = new
SimpleCredentials(admin, admin.toCharArray());
Session session = repo.login(credentials);
String path = /test;
if (session.itemExists(path)) {
System.out.println(removing item at + path);
session.removeItem(path);
}
Node node = session.getRootNode().addNode(test);
boolean existsBefore = session.itemExists(path);
node.getPath();
boolean existsAfter = session.itemExists(path);
Assert.assertTrue(Node must already exist before
calling node.getPath(), existsBefore);
Assert.assertTrue(Node must still exist after calling
node.getPath(), existsAfter);
session.save();
}
else {
Assert.fail(Failed to create repository);
}
}
protected Repository createFileBasedRepository(String folderPath,
String repositoryXmlPath)
throws RepositoryException, FileNotFoundException {
// create homedir
File homeDir = new File(folderPath);
homeDir.mkdirs();
File confFile = new File(repositoryXmlPath);
if (!confFile.isFile()) {
throw new IllegalArgumentException(Repository config
file is not a valid file:
+ confFile.getAbsolutePath());
}
// create RepositoryConfig instance
RepositoryConfig repositoryConfig = RepositoryConfig.create(new
FileInputStream(confFile),
homeDir.getAbsolutePath());
Repository repository = RepositoryImpl.create(repositoryConfig);
return repository;
}
}
-Ursprüngliche Nachricht-
Von: Tobias Bocanegra [mailto:tri...@adobe.com]
Gesendet: Mittwoch, 8. Juni 2011 09:05
An: us...@jackrabbit.apache.org
Betreff: Re: Session Question
hi,
i tested it with jackrabbit 2.2.5 and 2.2.6 and i always get 'true', 'true'.
but with this test case:
@Test
public void addTest() throws RepositoryException {
TransientRepository repo = new TransientRepository();
System.out.println(Version: +
repo.getDescriptor(Repository.REP_VERSION_DESC));
Session session = repo.login();
String path = /test;
if (session.itemExists(path)) {
System.out.println(removing item at + path);
session.removeItem(path);
}
Node node = session.getRootNode().addNode(test);
System.out.println(session.itemExists(path
Re: ArrayIndexOutOfBoundsException in jackrabbit-core: ConcurrentCache
hi michael,
On Tue, Jun 28, 2011 at 2:25 PM, Michael Klenk kl...@dig.de wrote:
**
Hi,
it seems, there exists no bug for this issue right now. The problem
described below crashes our application several times a week. Could you
please check if this problem is a Jackrabbit bug, or if it is an application
bug due to a missing reset (event?) of accessCounter.
what's your platform (jvm vendor and version)?
cheers
stefan
For the moment I've patched the class ConcurrentCache like shown in patch.
system: Apache sling with jackrabbit 2.2.5 for Content Management System.
Thanks in advance
Michael
Original-Nachricht Betreff: ArrayIndexOutOfBoundsException
in jackrabbit-core: ConcurrentCache Datum: Mon, 20 Jun 2011 21:09:32
+0200 Von: Michael Klenk kl...@dig.de kl...@dig.de Antwort an:
us...@jackrabbit.apache.org An: us...@jackrabbit.apache.org
Hi everyone,
I'm experiencing some strange ArrayIndexOutOfBoundsExceptions on
accessing the jackrabbit ConcurrentCache in 2.2.5. in Line 241 during
shrinkIfNeeded check.
Caused by: java.lang.ArrayIndexOutOfBoundsException: -14
at
org.apache.jackrabbit.core.cache.ConcurrentCache.shrinkIfNeeded(ConcurrentCache.java:241)
I reviewed jackrabbit-code and I'm sure it's caused by that
AtomicInteger for realizing accessCounter in AbstractCache, which will
have become negative during increasing over the Integer.MAX_VALUE constant.
// Semi-random start index to prevent bias against the first
segments
int start = (int) getAccessCount() % segments.length;
for (int i = start; isTooBig(); i = (i + 1) % segments.length) {
synchronized (segments[i]) {
Is there any bug already reported about this problem? Is a fix or some
workaround availlable? Can anyone confirm this problem? I haven't found
any...
Thanks in advance
Michael
___
Uncaught Throwable java.lang.ArrayIndexOutOfBoundsException: -7
at
org.apache.jackrabbit.core.cache.ConcurrentCache.shrinkIfNeeded(ConcurrentCache.java:241)
at
org.apache.jackrabbit.core.cache.ConcurrentCache.put(ConcurrentCache.java:176)
at
org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.getBundle(AbstractBundlePersistenceManager.java:657)
at
org.apache.jackrabbit.core.persistence.bundle.AbstractBundlePersistenceManager.load(AbstractBundlePersistenceManager.java:400)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.loadItemState(SharedItemStateManager.java:1819)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.getNonVirtualItemState(SharedItemStateManager.java:1739)
at
org.apache.jackrabbit.core.state.SharedItemStateManager.getItemState(SharedItemStateManager.java:261)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.getNodeState(LocalItemStateManager.java:107)
at
org.apache.jackrabbit.core.state.LocalItemStateManager.getItemState(LocalItemStateManager.java:172)
at
org.apache.jackrabbit.core.state.XAItemStateManager.getItemState(XAItemStateManager.java:260)
at
org.apache.jackrabbit.core.state.SessionItemStateManager.getItemState(SessionItemStateManager.java:161)
at
org.apache.jackrabbit.core.ItemManager.getItemData(ItemManager.java:370)
at
org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:316)
at
org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:610)
at
org.apache.jackrabbit.core.SessionImpl.getNodeById(SessionImpl.java:493)
at
org.apache.jackrabbit.core.SessionImpl.getNodeByIdentifier(SessionImpl.java:1045)
at sun.reflect.GeneratedMethodAccessor31.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.sling.jcr.base.SessionProxyHandler$SessionProxyInvocationHandler.invoke(SessionProxyHandler.java:109)
at $Proxy2.getNodeByIdentifier(Unknown Source)
at
de.dig.cms.frontend.servlet.helper.ResourceUtil.findResourceById(ResourceUtil.java:44)
at
de.dig.cms.frontend.servlet.CMSContentEnrichServletFilter.doFilter(CMSContentEnrichServletFilter.java:194)
at
org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:60)
at
de.dig.cms.frontend.servlet.CacheControlFilter.doFilter(CacheControlFilter.java:120)
at
org.apache.sling.engine.impl.filter.AbstractSlingFilterChain.doFilter(AbstractSlingFilterChain.java:60)
at
de.dig.cms.cache.impl.WallCacheServletFilter.processCacheableRequest(WallCacheServletFilter.java:244)
at
de.dig.cms.cache.impl.WallCacheServletFilter.processCacheableRequestWithLatch(WallCacheServletFilter.java:185)
at
[jira] [Commented] (JCR-3007) setProperty access control evaluation does not properly cope with XA transactions
[
https://issues.apache.org/jira/browse/JCR-3007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13057302#comment-13057302
]
Stefan Guggisberg commented on JCR-3007:
+1, patch looks good
setProperty access control evaluation does not properly cope with XA
transactions
-
Key: JCR-3007
URL: https://issues.apache.org/jira/browse/JCR-3007
Project: Jackrabbit Content Repository
Issue Type: Bug
Components: jackrabbit-core
Affects Versions: 2.2.7
Reporter: Lars Krapf
Labels: jackrabbit-core,, security,, transactions
Attachments: transaction.patch
This is another instance of the problems with ACL evaluation within
transactions described in https://issues.apache.org/jira/browse/JCR-2999.
In this case PropertyImpl#getParent() called from
PropertyImpl#checkSetValue() is trying to check read permissions of the yet
uncommited parent and thus fails with an ItemNotFound exception.
The problem is reproducible with the following test:
public void testTransaction() throws Exception {
// make sure testUser has all privileges
Privilege[] privileges = privilegesFromName(Privilege.JCR_ALL);
givePrivileges(path, privileges, getRestrictions(superuser, path));
// create new node and lock it
Session s = getTestSession();
UserTransaction utx = new UserTransactionImpl(s);
utx.begin();
// add node and save it
Node n = s.getNode(childNPath);
if (n.hasNode(nodeName1)) {
Node c = n.getNode(nodeName1);
c.remove();
s.save();
}
// create node and save
Node n2 = n.addNode(nodeName1);
s.save(); // - node is NEW - no failure
// set a property on a child node of an uncommited parent
n2.setProperty(propertyName1, testSetProperty);
s.save(); // - fail because PropertyImpl#getParent called from
PropertyImpl#checkSetValue
//was checking read permission on the not yet
commited parent
// commit
utx.commit();
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
