Clone Tools
  • last updated a few minutes ago
Constraints: committers
Constraints: files
Constraints: dates
Copied the LICENSE files inside the top-level directory, which is recommended for projects on GitHub.

    • -0
    • +502
MODE-1756 Updated the copyright dates and contributors

MODE-1755 Implemented 'getPlan' in other implementation classes

MODE-1750 Ignored two of the TCK tests due to errors in the tests.

Corrected the link to the JCR project's JIRA in the POM file.

See MODE-1758 for more detail on the tests and their errors.

MODE-1755 Exposed the 'getPlan():String' method on ModeShape's QueryResult public API

Removed unused imports

MODE-1750 Ignored two of the TCK tests due to errors in the tests.

See MODE-1758 for more detail on the tests and their errors.

MODE-1751 - Updated the algorithm via which nodes update their referrers as result to changes in reference properties.

MODE-295 Minor fixes to the JBoss deployment

Updated Arquillian JVM memory setting, increasing the max memory and permGen size. Without those changes, I cannot run locally the integration tests.

MODE-295 More fixes to the build and made artifact names more consistent/appropriate

    • -132
    • +0
  1. … 50 more files in changeset.
MODE-1748 - Fixed the VersionException that was being thrown when content was imported and nodes were marked as checked in. The issue is identical to MODE-1450 and the fix involves propagating a "skipVersioningValidation" flag to avoid the version checks.

    • -0
    • +191
MODE-295 Minor fixes to build to incorporate CMIS into our distributions

Merge branch 'mode-1746' of git:// into rhauch-mode-1746

MODE-1745 Corrected the names of the child references, which was recently changed (incorrectly)

MODE-1745 Removed code that was commented out

MODE-1750 FullTextSearch Left/Right outer join invalid behavior on null join value

MODE-295: Add cmis dependecy to distribution/pom.xml

MODE-1745 Minor changes and additional debug statements

MODE-1745 Added repository-level locking to prevent concurrent initialization

There were cases when two processes in a cluster would each attempt to

initialize the system content, and obviously one of them would fail.

This code introduces two new fields to the single 'repository:info'

document that represents the metadata about the document. There can

be only one of these in the whole repository. One of the new fields

is 'intializer' and represents the random UUID of the process that

is performing the initialization of the repository. Each process

first looks for this document, and if it doesn't exist the process

creates a new document with the various metadata fields (including

the new 'initializer' field) and attempts to 'putIfAbsent'. It then

looks up the existing document in the store; if the 'initializer'

field matches its own, then it continues to initialize the repository

with the system content (e.g., node types, namespaces, etc.),

initial content, etc. If the document's 'initializer' value does not

match the current process, then another process is performing the

initialization and this process should wait until initialization is

complete. The latter is signified by the other new field, called

'initializedAt', which is the timestamp that the initializing process

completed the initialization. Non-initializing processes simply

block for up to 10 minutes, re-fetching the 'repository:info' document

and looking for the 'initializedAt' field. As soon as this field is

found, the non-initializing processes continue.

All of this logic is in the RepositoryCache class. The JcrRepository's

RunningState.postInitialize() method is what calls the RepositoryCache's

completeInitialization() method (which uses a transaction to ensure

the 'intializedAt' field is set atomically).

Note that any process that joins the cluster after the 'repository:info'

document has been updated with an 'initializedAt' field will immediately

proceed with starting up (since the repository initialization had

already been completed).

Also, all processes still attempts to register the node types defined

within the repository's configuration file. This is obviously redundant

when each process's configuration file contains the same node types.

However, this provides a convenient way to register new/updated node

types by simply starting up another process with an updated list of


Integration builds pass with these changes, and the test cases

in MODE-1745 and MODE-1739 run successfully when using these changes

and Infinispan 5.1.x. There are still issues when run with

Infinispan 5.2 due to the diff-based delta usage (see MODE-1745

for details).

MODE-1745 MODE-1739 Changed how Delta impls are created

Recent changes changed the way Delta implementations are created.

In particular, the SchematicEntryWholeDelta instances were created

with a clone of the document. Since subsequent changes were made

to the original document, the SchematicEntryWholeDelta didn't include

these subsequent changes and they were lost, causing various exceptions.

Also changed some of the trace logging messages on both Delta

implementations to be more useful.

I'm able to not only successfully run a full integration build,

but I'm able to successfully run the test cases for both MODE-1745

and MODE-1739 using Infinispan 5.1.2.FINAL or 5.1.8.Final.

Occassionally when running the MODE-1739 tests I do get one or two

NodeNotFoundInParentException (see MODE-1739 for details) early

on in the test (unable to find a path of an existing node when

checking permissions), but it simply fails that request and continues.

This error often happens almost immedidately in the test and is

rarely repeated more than once.

Note that in addition to this problem, the tests are not able to use

Infinispan 5.2 -- that's because we're using the SchematicEntryDelta

(a diff-based impl), and we haven't yet fixed the problem there.

MODE-1729 Removed newlines in element values in arquillian.xml

Not sure why the newlines matter, but they're okay on Windows but

break the build on OS X.

MODE-295: AS7 integration

  1. … 32 more files in changeset.
MODE-1745 Corrections to Schematic's state transfer

Several issues related to state-transfer were identified and corrected within Schematic's DeltaAware implementation. These primarily dealt with using diff-based deltas when using Infinispan 5.2.0 (tested with Beta6 and later), the implementations of the two deltas (and related classes), and how merges are made, and removal of the NullDelta class.

With these changes, the test projects in MODE-1745 and MODE-1746 work better. There still are problems with state transfer during repository initialization. See MODE-1745 for details.

MODE-1746 Minor changes to previous modifications

Several small changes to the previous commit were suggested by Horia,

and implemented with this commit.

MODE-1741 - Updated the Git connector so that indexable branches are configurable

MODE-1747 Changed default configuration for workspace caches

Changed the default (built-in) configuration for a repository's in-memory workspace caches (on top of the Infinispan cache used for content) to better work with Infinispan 5.2.

The default can always be overridden in a repository's JSON configuration file.

MODE-1746 Use explicit locks to prevent deadlocks

Added quite a few debug and trace logging calls to help investigate transaction-related operations.

Added explicit locking to prevent deadlocks. Locks for all modified nodes are now requested at the beginning of the transaction (rather than incrementally as needed to apply the changes in the same order as modified by the session). The locks will either all be acquired or none of them will be acquired, allowing the "save()" operation to retry to acquire the locks one additional time. If the locks still cannot be acquired (or if Infinispan throws a TimeoutException because the locks could not be acquired after the configured period of time), ModeShape will rollback the transaction.

The WritableSessionCache will attempts to retry the transaction if and only if the save() operation started the transaction. If there was already an existing transaction, ModeShape cannot restart it and therefore it must fail.

In all cases, should locks not be acquired during the "" call, an org.modeshape.jcr.TimeoutException will be thrown. Client applications can catch this and simply retry calling "" again as many times as desired.

Under configurations that experience a high amount of concurrent operations on the same set of nodes, the Infinispan configuration should probably use deadlock detection.

MODE-1746 Added test case to replicate deadlock scenario

Added a test method to the ConcurrentWriteTest that replicates how separate threads can deadlock while attempting to update several nodes.

MODE-295: Base CMIS library