Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
fix (and test) AbstractMultimap.WrappedCollection retainAll bug

  1. … 1 more file in changeset.
AbstractMultimap code cleanups

AbstractMultimap state management/NPE hardening

  1. … 1 more file in changeset.
correct iteration bug introduced with MODE-2743 fix

  1. … 1 more file in changeset.
MODE-2743: AbstractMultimap susceptible to size invalidation via collection iterators

  1. … 1 more file in changeset.
MODE-2524 Removes deprecated API

  1. … 16 more files in changeset.
MODE-2516 Updates JDK to 1.8 and jboss-parent to the latest version (19) This is the first significant commit of the 5.x series and contains a number of significant changes: - the naming of Maven version properties changed to adopt the standard pattern: 'version.<groupId>.<artifactId>' - build system and dependency updates so that the latest Maven plugin versions function correctly - updating source code to avoid compiler and javadoc warnings

  1. … 154 more files in changeset.
MODE-2195 Makes the event bus size configurable

  1. … 17 more files in changeset.
MODE-2345 Updated event-related metrics using the new 4.x ring buffer.

  1. … 7 more files in changeset.
MODE-2297 Corrected query engine to properly report mismatched set operation columns

  1. … 7 more files in changeset.
MODE-2160 Completed the first stab at a local index provider. There are only a few very limited test cases, but they do pass and show that the provider is able to be included in the query plan, properly selected for use, and properly used during query execution.

    • -0
    • +49
    • -0
    • +60
  1. … 57 more files in changeset.
MODE-2088 Made a few corrections based upon code review feedback.

  1. … 5 more files in changeset.
MODE-2088 Eliminated the ring buffer's ability to submit entries in the same thread, which simplifies the consumers and makes them not need to be concurrent. Also changed the WorkspaceCache to register its own listeners that are better optimized for what they do. Kept the ability for the RepositoryChangeBus to have in-thread listeners (notified in the caller's thread), but these listeners only receive events via this route. Changed the JcrRepository to register various listeners directly on the bus rather than via the RepositoryCache (which was a listener and just delegated the register and unregister methods to the change bus). At this point, all tests pass successfully (multiple build passes).

  1. … 24 more files in changeset.
MODE-2088 RepositoryChangeBus actually requires producers to be on multiple threads, and this was causing problems for the 'single-thread-producer' initial implementation. Added simple locking in the RingBuffer.add(...) methods, and verified that this fixes the sequencer problems.

Interestingly, the time for my build is approximately 30-40 seconds slower (repeatedly) with the locking enabled, so we probably do want to consider getting rid of the locking but still supporting multiple producers.

  1. … 2 more files in changeset.
MODE-2088 Updated the RingBuffer implementation and finished the CircularChangeBus which is now used by the repository.

    • -7
    • +13
  1. … 28 more files in changeset.
MODE-2088 Created RingBufferBuilder utility that can handle more options, and added garbage collection to the ring buffer. The latter is a thread that follows all other consumers, nulling out the entries that have already been processed. This will reduce the overall footprint, even when the entry objects may be large. Garbage collection is optional and disabled by default.

    • -0
    • +42
    • -0
    • +142
    • -0
    • +120
    • -0
    • +118
    • -67
    • +25
    • -0
    • +72
  1. … 1 more file in changeset.
MODE-2088 Added support for dynamically removing consumers, added more tests, and improved resiliency.

    • -0
    • +53
  1. … 3 more files in changeset.
MODE-2088 Ring buffer implementation, suitable for evaluation and trial.

    • -0
    • +64
    • -0
    • +51
    • -0
    • +117
    • -0
    • +41
    • -0
    • +293
    • -0
    • +216
    • -0
    • +48
    • -0
    • +20
  1. … 4 more files in changeset.
MODE-2160 Refactored the query engine and index provider SPI.

Changed how index providers are initialized, changed the indexing to use only events, changed the reindexing mechanism to use a much simplified IndexWriter, and added a partial LocalIndex and provider implementation (still needs work).

  1. … 114 more files in changeset.
MODE-2018 Implemented new query engine.

Refactored the query functionality to now use several new service provider interfaces (SPI),

and implemented a new query engine that can take advantage of administrator-defined indexes.

When no such indexes are defined, the query engine is able to still answer the queries

by "scanning" all nodes in the repository. This is like a regular relational database:

all query functionality works (albeith slowly) even when no indexes are defined, though

to improve performance simply define an appropriate index based upon the query or queries

that are being used.

All of ModeShape's query parsing, planning, and optimization steps are basically unchanged

from the previous query system. There is one addition to the rule-based optimizer: a new

rule looks at query plans and adds the potential indexes that might be of use in each

access query portion of a query plan. Then, the query execution process (see below)

chooses one of the identified indexes based upon the selectivity and cardinality. If no index

is available for that portion of the query plan, then the query engine simply iterates

over all queryable nodes in the repository.

A new kind of component, called a "query index provider", allows the query engine to delegate

various responsibilities around indexes to these providers. For example, a provider must

provide an index planner that can examine the constraints that apply to an access query

and determine if any of the provider's indexes can be used. When they are, ModeShape

adds those indexes to the query plan. If the query engine uses one of those indexes,

then provider must be able to return all of those nodes that satisfy the criteria

as described earlier by its index planner. Finally, as ModeShape content changes, ModeShape

will notify the index providers' of the changes so that they can ensure their indexes

are kept up-to-date with the content.

This means that a provider can implement the functionality using any kind of technology,

and consequently, that ModeShape can begin to leverage multiple kinds of search and index

technology within its query system. The ModeShape community anticipates having providers

that use Lucene, Solr, and ElasticSearch. ModeShape will also likely come with a provider

that maintains file-system based indexes. Additionally, providers can optionally support

indexes on one or more properties. Thus, it will be possible to mix and match

these providers, selecting the best technology for the specific kind of index.

The new query engine does the execution in a very different way than the previous engine,

which used Lucene to determine the tuples (that is, the values in each row) for each access

query and that were then further processed and combined to form the tuples that were returned

in the result set. The new engine instead uses a new concept of a "stream of node keys"

for each access query: what actually implements that stream depends on many factors.

A node sequence is an abstraction of a stream of "rows" containing one or more node keys.

The interfaces are designed to make it possibly to lazily implement a stream in a very

efficient manner. Specifically, a node stream is actually comprised of multiple "batches"

of rows, and batches can be of any size.

Consider when the engine findes no indexes are available for a certain access query. The

engine simply uses a "node sequence" (or NodeSequence) implementation that returns in batches

a row for each node in the repository.

But if an access query involves a criteria on the path of a node, such as

"... WHERE ISSAMENODE('/foo/bar') ...", then ModeShape knows that this query (or portion of

a query) will have only one result, namely the node at "/foo/bar". ModeShape doesn't need

an index to quickly find this node; it merely has to navigate to that path to find the one

node that satisfies this query. ModeShape has several other optimizations, too: it knows

when a query involves all children or descendants of a node at a given path, and can take

this into account when optimizing and executing the query. All of these are handled with

special NodeSequence implementations optimized for each case.

For many access queries (i.e., part of a larger query), the engine will use one of the

indexes identified by one of the providers. When this happens, ModeShape uses other

NodeSequence implementations that utilize the underlying indexes to find the nodes that satisfy

some of the criteria.

The above describes how the engine uses a single NodeSequence instance for each each access

query in a larger query. But how does the engine combine these to determine the ultimate

query results? Basically, the engine constructs a series of functions that process one or more

NodeSequence instances to filter and combine into other NodeSequences.

For example, a custom index might be used to find all nodes that have a 'jcr:lastModified'

timestamp within some range. Presumably this index is used because it has a higher selectivity,

meaning that it will filter out more nodes and return fewer nodes than other indexes.

Other criteria that are also applied to this access query might then be applied by a filter

that processes the actual nodes' property values.

While the result of this commit is a functioning query engine that is shown to work in most

of the query-related unit and integration tests, there still are a few areas that are not complete.


* The new engine does not support full-text search, and currently throws an exception

* No index providers are implemented. Therefore, all queries involve "scanning" the repository.

This can be time consuming, especially for federated repositories. Consequently, all such

tests that query federated content have been disabled/ignored.

    • -0
    • +33
    • -0
    • +65
    • -0
    • +69
  1. … 227 more files in changeset.
MODE-2148 Added checkstyle to our build, and corrected numerous potential problems or issues in the code. Also removed lots of meaningless JavaDoc

  1. … 352 more files in changeset.
MODE-2041 Corrected numerous compiler warninings, JavaDoc errors and warnings, and removed quite a few JavaDoc comments that are inherited via @Override.

  1. … 79 more files in changeset.
MODE-2081 Changed the license for ModeShape code to ASL 2.0.

  1. … 145 more files in changeset.
MODE-2033 Added the ability to expose non critical errors & warnings occurring during repository startup, including those caused by schema validation.

  1. … 15 more files in changeset.
Corrected compiler warnings and removed unnecessary JavaDoc

  1. … 20 more files in changeset.
Corrected JavaDoc and compiler warnings/errors

  1. … 19 more files in changeset.
MODE-1908 Reformatted code and added a missing unit test.

  1. … 9 more files in changeset.
MODE-1908 Refactored AbstractBinaryStore and the BinaryStore interface so that the latter is used

  1. … 5 more files in changeset.
MODE-1552 Corrected how works with descendant shared nodes

The method is deprecated, but the behavior was incorrect when there were

shared nodes below the node being saved and where the shared nodes were in the same

shared set as nodes that were not descendants. This behavior was corrected while keeping relatively efficient, although it's still not as efficient as a regular

All TCK unit tests pass with these fixes!

    • -0
    • +60
  1. … 15 more files in changeset.
Fixed javadoc errors that occurred when moving from Eclipse Helios to Eclipse Indigo. Also fixed a pom error that occurred when upgrading Eclipse.

  1. … 20 more files in changeset.