ModeShape

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Changed version to 2.8-SNAPSHOT after releasing 2.7.0.Final

  1. … 59 more files in changeset.
'Release: update versions for modeshape-2.7.0.Final'

  1. … 62 more files in changeset.
Updated release notes and authors file for 2.7.0.Final

MODE-1359 Corrected NPE during join evaluation

Added an integration test that verifies the above test code does indeed fail. After fixing the various {{Joinable}} and {{Comparable}} implementations in {{JoinComponent}} (used by both the nested loop join and merge join algorithms, the test code passes. Additionally, all other unit and integration tests pass.

This code will need to be merged into 'master' (for inclusion in 2.7.0.Final) and '3.x' (for inclusion in the 3.0 codebase).

MODE-1359 Corrected NPE during join evaluation

Added an integration test that verifies the above test code does indeed fail. After fixing the various {{Joinable}} and {{Comparable}} implementations in {{JoinComponent}} (used by both the nested loop join and merge join algorithms, the test code passes. Additionally, all other unit and integration tests pass.

This code will need to be merged into 'master' (for inclusion in 2.7.0.Final) and '3.x' (for inclusion in the 3.0 codebase).

Resolved merge conflicts

MODE-1331 updated code based on code review

-renamed some methods

-cleaned up test repository configurations

MODE-1356 fixed binary store file lock handling on Windows

Since on Windows FileLocks are tightly coupled to file descriptor instances, it was necessary to use the same channel/stream held by lock, instead of opening new channels. Also, it was necessary to add some more explicit "close" methods on streams&locks, so that the file handles are released.

Merge branch 'mode-1318' of https://github.com/tejones/modeshape into tejones-mode-1318

MODE-1358 Used buffered streams when copying file content in FileSystemBinaryStore

The FileSystemBinaryStore was not using buffered streams when copying the content; note that Channel.newInputStream(...) and Channel.newOutputStream(...) does not return buffered streams.

On OS X, using buffered streams makes a little difference. A new unit test (FileSystemBinaryStoreTest.shouldCopyFilesUsingStreams() copies a 17MB file repeatedly takes 0.05-0.10 seconds without buffered streams, but is somewhat faster at 0.02-0.07 seconds (repeatedly) with buffered stream. Some of this may be the file system caching access, but it appears the buffered stream do help. The test writes the time to write the file to the console.

Therefore, I changed the FileSystemBinaryStore to use buffered streams.

On Windows, storing that same 17MB file in the FileSystemBinaryStore takes about 30 seconds (without buffered streams). Hopefully with these changes the FileSystemBinaryStore performance does improve. Perhaps Horia can report the time of this new test on Windows.

MODE-1354 Migrated more of the unit tests to the 3.x codebase

More of the unit tests in 'modeshape-jcr' have been migrated into the 3.0 codebase

(into the module currently named 'modeshape-jcr-redux'). A few minor corrections to the

new JCR implementation were made, based upon these tests. But overall, most of the tests

were migrated and run successfully with no corrections/fixes.

  1. … 44 more files in changeset.
MODE-1353: promote version #'s in 2.5.x to 2.5.3.GA for SOA-3656

  1. … 54 more files in changeset.
MODE-1331 ported ClassFileSequencer to 3.x

-added common abstract test case for sequencers

-updated ImageSequencerTest to use base test class

-fixed "package" visibility bug (was not being set properly)

  1. … 32 more files in changeset.
MODE-1318 Changed artifact name for as 7 kit, changed dependencies to use global versions where applicable, removed unnessecary deployment files from modeshape-sunsystem, added deploy/jbossas to top-level pom.:wq

MODE-1348 Export changed to limit memory consumption with large binary values

Exporting a workspace that has a lot of large binary values can result in out-of-memory errors, since the binary values are held in memory. (See MODE-1346 for improvements within the 3.x codebase.) While it'd be very difficult to change how the binary values are handled in 2.x, it should still be possible to modify the export logic to prevent holding all workspace content in-memory.

Therefore, the following changes were made to the export process:

1) After every Binary value on an _unmodified_ property is exported, that binary value is purged from memory and allowed to be garbage collected. Note this makes the binary values unusable (see step 2).

2) At the end of the export, the node that was exported is refreshed while keeping any transient changes, throwing out of the session's cache all _unmodified_ property values (including the binary values that were purged in step 1).

Note that the above steps only apply to _unmodified_ properties. This is very often the case, as a new session is used to export persisted content from the workspace. However, sessions _with transient changes_ can be exported, which is why the two steps listed above only purge binary values on _unmodified_ properties.

All unit and integration tests pass with these changes.

MODE-1348 Export changed to limit memory consumption with large binary values

Exporting a workspace that has a lot of large binary values can result in out-of-memory errors, since the binary values are held in memory. (See MODE-1346 for improvements within the 3.x codebase.) While it'd be very difficult to change how the binary values are handled in 2.x, it should still be possible to modify the export logic to prevent holding all workspace content in-memory.

Therefore, the following changes were made to the export process:

1) After every Binary value on an _unmodified_ property is exported, that binary value is purged from memory and allowed to be garbage collected. Note this makes the binary values unusable (see step 2).

2) At the end of the export, the node that was exported is refreshed while keeping any transient changes, throwing out of the session's cache all _unmodified_ property values (including the binary values that were purged in step 1).

Note that the above steps only apply to _unmodified_ properties. This is very often the case, as a new session is used to export persisted content from the workspace. However, sessions _with transient changes_ can be exported, which is why the two steps listed above only purge binary values on _unmodified_ properties.

All unit and integration tests pass with these changes.

MODE-1349 Removed the JPA connector's caching of binary values

Although the binary value content should not be put into the 2nd level cache because of the @Lob

field, this change removes the LargeValueEntity class from the set of classes that should be

put into Hibernate's 2nd level cache, thereby removing any concern of caching these potentially

large values.

All unit and integration tests pass.

MODE-1349 Removed the JPA connector's caching of binary values

Although the binary value content should not be put into the 2nd level cache because of the @Lob

field, this change removes the LargeValueEntity class from the set of classes that should be

put into Hibernate's 2nd level cache, thereby removing any concern of caching these potentially

large values.

All unit and integration tests pass.

MODE-1350 Improved scalability of SearchEngineIndexer

Changed the SearchEngineIndexer to no longer keep the subgraph read requests in the CompositeRequestChannel, which can cause OutOfMemoryErrors when the workspace content is very large or when it contains large binary values.

MODE-1350 Improved scalability of SearchEngineIndexer

Changed the SearchEngineIndexer to no longer keep the subgraph read requests in the CompositeRequestChannel, which can cause OutOfMemoryErrors when the workspace content is very large or when it contains large binary values.

MODE-1220: Added initial ModeShape susbsytem with a repository child node and updated build to create a deployable ModeShape kit for AS7.

    • -0
    • +62
    /deploy/jbossas/assembly/kit-as7.xml
    • -0
    • +82
    /deploy/jbossas/kit/jboss-as7/domain/configuration/host.xml
  1. … 17 more files in changeset.
MODE-1324 Added methods to obtain SHA-1 has for a Binary value

Made the org.modeshape.jcr.api.Binary interface no longer deprecated (we're not using it again in

ModeShape 3.x, too), and added two methods for obtaining the SHA-1 hash of the value's content.

One of the methods returns the byte[] form of the hash, while the other returns the hexadecimal

string form of the same hash.

MODE-1346 Fixed TestingUtil methods

Several of the TestingUtil methods should have been checking the running state before

trying to shut down components.

MODE-1331 refactored ImageMetadataSequencerTest to use SingleUseAbstractTest

MODE-1347 fixed potential deadlock in RepositoryConnectionPool

-replaced the peek & take operations with one atomic operation (pool)

-added a couple of tests which test the concurrent get&close connection operations

MODE-1347 fixed potential deadlock in RepositoryConnectionPool

-replaced the peek & take operations with one atomic operation (pool)

-added a couple of tests which test the concurrent get&close connection operations

MODE-1346 Added TestingUtil to help clean up after tests

Added a new TestingUtil class with static methods patterned after Infinispan's TestingUtil

class, but which shutdown and delete the content associated with JcrEngine and

JcrRepository instances.

Minor fix to JavaDoc

MODE-1330 migrated image sequencer from 2.x to 3.x

-added new root folder for sequencers

-removed i18n sequencer class

-fixed various input/ouput path issues

    • -0
    • +156
    /sequencers/modeshape-sequencer-images/pom.xml
  1. … 23 more files in changeset.
MODE-1346 Added BinaryStore implementation

Added a new BinaryStore framework. Each JcrRepository instance now uses a BinaryStore

implementation to store all (non-trivial) Binary values. Two BinaryStore implementations

have been provided, including a FileSystemBinaryStore that stores binaries based upon

their SHA-1 hash on the local file system, and a TransientBinaryStore that stores binaries

based upon their SHA-1 hash in a directory within Java's 'java.io.tmpdir' directory.

The TransientBinaryStore is used by default, since without configuring an Infinispan

cache the content is stored in-memory anyway.

Note that with this new system in place, creating a JCR Binary value immediately stores

the stream's content inside the BinaryStore (unless it is below the minimum threshold

for storage, in which case it is stored in-memory and with the nodes), even before

the Session is saved. The JCR Binary value stores the key where the content is stored

inside the BinaryStore (the key is the hexadecimal form of the content's SHA-1 hash).

When the session is saved, the Binary's key is actually stored within the node's properties.

Note the RepositoryCache does keep track of the number of times each Binary key is referenced

by the nodes and properties, and any Binary keys that are no longer used will be

fired through the RepositoryCache listener framework via a new UnusedBinaryValue event.

The BinaryStore receives these unused keys, and marks them as unused. The repository's

garbage collection process then calls to the BinaryStore to remove any unused keys

that of a minimum age (which is defined to be twice the time period of the garbage

collection period).

Quite a few test cases were added to verify the behavior, and everything looks to be

working properly.

All unit and integration tests pass.

  1. … 88 more files in changeset.