[jira] [Updated] (OAK-2714) Test failures on Jenkins
[ https://issues.apache.org/jira/browse/OAK-2714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-2714: --- Description: This issue is for tracking test failures seen at our Jenkins instance that might yet be transient. Once a failure happens too often we should remove it here and create a dedicated issue for it. || Test || Builds || Fixture || JVM || | org.apache.jackrabbit.oak.plugins.index.lucene.IndexCopierTest.reuseLocalDir | 81 | DOCUMENT_RDB | 1.7 | | org.apache.jackrabbit.oak.jcr.OrderedIndexIT.oak2035 | 76, 128 | SEGMENT_MK , DOCUMENT_RDB | 1.6 | | org.apache.jackrabbit.oak.plugins.segment.standby.StandbyTestIT.testSyncLoop | 64 | ?| ? | | org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest.testRDBDocumentStore_CustomBlobStore | 52, 181, 399 | SEGMENT_MK, DOCUMENT_NS | 1.7 | | org.apache.jackrabbit.oak.run.osgi.JsonConfigRepFactoryTest.testRepositoryTar | 41 | ?| ? | | org.apache.jackrabbit.test.api.observation.PropertyAddedTest.testMultiPropertyAdded | 29 | ?| ? | | org.apache.jackrabbit.oak.plugins.segment.HeavyWriteIT.heavyWrite | 35 | SEGMENT_MK | ? | | org.apache.jackrabbit.oak.jcr.query.QueryPlanTest.propertyIndexVersusNodeTypeIndex | 90 | DOCUMENT_RDB | 1.6 | | org.apache.jackrabbit.oak.jcr.observation.ObservationTest.removeSubtreeFilter | 94 | DOCUMENT_RDB | 1.6 | | org.apache.jackrabbit.oak.jcr.observation.ObservationTest.disjunctPaths | 121, 157, 396 | DOCUMENT_RDB | 1.6, 1.7, 1.8 | | org.apache.jackrabbit.oak.jcr.ConcurrentFileOperationsTest.concurrent | 110, 382 | DOCUMENT_RDB | 1.6 | | org.apache.jackrabbit.oak.jcr.MoveRemoveTest.removeExistingNode | 115 | DOCUMENT_RDB | 1.7 | | org.apache.jackrabbit.oak.jcr.RepositoryTest.addEmptyMultiValue | 115 | DOCUMENT_RDB | 1.7 | | org.apache.jackrabbit.oak.stats.ClockTest.testClockDriftFast | 115, 142 | SEGMENT_MK, DOCUMENT_NS | 1.6, 1.8 | | org.apache.jackrabbit.oak.plugins.index.solr.query.SolrQueryIndexTest | 148, 151, 490, 656, 679 | SEGMENT_MK, DOCUMENT_NS, DOCUMENT_RDB | 1.6, 1.7, 1.8 | | org.apache.jackrabbit.oak.jcr.observation.ObservationTest.testReorder | 155 | DOCUMENT_RDB | 1.8 | | org.apache.jackrabbit.oak.osgi.OSGiIT.bundleStates | 163, 656 | SEGMENT_MK, DOCUMENT_RDB, DOCUMENT_NS | 1.6, 1.7 | | org.apache.jackrabbit.oak.jcr.query.SuggestTest | 171 | SEGMENT_MK | 1.8 | | org.apache.jackrabbit.oak.jcr.nodetype.NodeTypeTest.updateNodeType | 243, 400 | DOCUMENT_RDB | 1.6, 1.8 | | org.apache.jackrabbit.oak.jcr.query.QueryPlanTest.nodeType | 272 | DOCUMENT_RDB | 1.8 | | org.apache.jackrabbit.oak.jcr.observation.ObservationTesttestMove | 308 | DOCUMENT_RDB | 1.6 | | org.apache.jackrabbit.oak.jcr.version.VersionablePathNodeStoreTest.testVersionablePaths | 361 | DOCUMENT_RDB | 1.7 | | org.apache.jackrabbit.oak.plugins.document.DocumentDiscoveryLiteServiceTest | 361, 608 | DOCUMENT_NS, SEGMENT_MK | 1.7, 1.8 | | org.apache.jackrabbit.oak.jcr.ConcurrentAddIT.addNodesSameParent | 427, 428 | DOCUMENT_NS, SEGMENT_MK | 1.7 | | Build crashes: malloc(): memory corruption | 477 | DOCUMENT_NS | 1.6 | | org.apache.jackrabbit.oak.upgrade.cli.SegmentToJdbcTest.validateMigration | 486 | DOCUMENT_NS | 1.7| | org.apache.jackrabbit.j2ee.TomcatIT.testTomcat | 489, 493, 597, 648 | DOCUMENT_NS, SEGMENT_MK | 1.7 | | org.apache.jackrabbit.oak.plugins.index.solr.index.SolrIndexEditorTest | 490, 623, 624, 656, 679 | DOCUMENT_RDB | 1.7 | | org.apache.jackrabbit.oak.plugins.index.solr.server.EmbeddedSolrServerProviderTest.testEmbeddedSolrServerInitialization | 490, 656, 679 | DOCUMENT_RDB | 1.7 | | org.apache.jackrabbit.oak.run.osgi.PropertyIndexReindexingTest.propertyIndexState | 492 | DOCUMENT_NS | 1.6 | | org.apache.jackrabbit.j2ee.TomcatIT | 589 | SEGMENT_MK | 1.8 | | org.apache.jackrabbit.oak.run.osgi.DocumentNodeStoreConfigTest.testRDBDocumentStoreRestart | 621 | DOCUMENT_NS | 1.8 | | org.apache.jackrabbit.oak.plugins.index.solr.util.NodeTypeIndexingUtilsTest.testSynonymsFileCreation | 627 | DOCUMENT_RDB |1.7 | | org.apache.jackrabbit.oak.spi.security.authorization.cug.impl.* | 648 | SEGMENT_MK, DOCUMENT_NS | 1.8 | | org.apache.jackrabbit.oak.remote.http.handler.RemoteServerIT | 643 | DOCUMNET_NS | 1.7, 1.8 | | org.apache.jackrabbit.oak.plugins.index.solr.util.NodeTypeIndexingUtilsTest | 663 | SEGMENT_MK | 1.7 | | org.apache.jackrabbit.oak.plugins.document.blob.RDBBlobStoreTest | 673, 674 | SEGMENT_MK | 1.8 | | org.apache.jackrabbit.oak.plugins.document.persistentCache.BroadcastTest | 648, 679 | SEGMENT_MK, DOCUMENT_NS | 1.8 | | org.apache.jackrabbit.oak.security.authentication.ldap.LdapProviderTest | 689 | SEGMENT_M
[jira] [Commented] (OAK-3899) TokenLoginModule ignores shared key javax.security.auth.login.name
[
https://issues.apache.org/jira/browse/OAK-3899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15108026#comment-15108026
]
Alexander Klimetschek commented on OAK-3899:
To explain our use case a bit:
We have a custom external identity provider (for an external user &
authentication system). One authentication mechanism is using oauth, in which
an authorization code is sent with the request after a login page, and we pass
this code through from an Apache Sling AuthenticationHandler to the repository
login. This is done using SimpleCredentials (because a. the ExternalLoginModule
only supports this at this time and b. the retrieve-token-back feature of the
TokenLoginModule only works with SimpleCredentials as well), which gets a null
userId, empty password and a special attribute containing the code.
After this initial login using the code, we want to continue the browser
"session" with the oak login token. Because of that, the SimpleCredentials also
gets the {{.token}} attribute set in the authentication handler so after the
session login the token is present there and can be set as a cookie on the same
response for subsequent requests. This would make the whole process seamless,
avoiding extra (privileged) sessions.
Workaround:
I can use a utility (granite TokenUtil) to create the token after the session
was created and use the session user id to use for the token. This creates 2
extra sessions as it uses impersonation from a privileged session, which is
overhead I would like to avoid.
> TokenLoginModule ignores shared key javax.security.auth.login.name
> --
>
> Key: OAK-3899
> URL: https://issues.apache.org/jira/browse/OAK-3899
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.3.14
>Reporter: Alexander Klimetschek
> Attachments: OAK-3899.patch
>
>
> The {{TokenLoginModule}} and specifically TokenProviderImpl [only look at
> SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/1144914c053ec9c2723450261fabfee1bd9d0e58/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165]
> when creating a token.
> However, in certain situations, such as with the ExternalLoginModule and
> non-username/password credentials, the SimpleCredentials are used but don't
> have a user id as the real user id is determined not by the caller of
> {{Repository.login()}}, but by the external identity provider inside the
> ExternalLoginModule (and the credentials might not include any kind of user
> id, say an opaque token from an external service). In this case,
> {{SimpleCredentials.getUserID()}} returns null and the token implementation
> fails to create a token and does not return it in the {{.token}} attribute of
> the credentials.
> Instead, the TokenLoginModule should look at the shared
> {{javax.security.auth.login.name}} attribute, which can de-facto override a
> {{SimpleCredentials.getUserID()}}, as it happens in the ExternalLoginModule.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3761) Oak crypto API and implementation
[ https://issues.apache.org/jira/browse/OAK-3761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated OAK-3761: Flags: Patch > Oak crypto API and implementation > - > > Key: OAK-3761 > URL: https://issues.apache.org/jira/browse/OAK-3761 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: security >Affects Versions: 1.3.12 >Reporter: Timothee Maret >Assignee: angela > Attachments: OAK-3761.patch > > > As discussed in [0], this issue tracks adding a simple API and implementation > for encryption/decryption in Oak. > [0] > http://oak.markmail.org/search/?q=crypto#query:crypto+page:1+mid:iwsfd66lku2dzs2n+state:results -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (OAK-3761) Oak crypto API and implementation
[
https://issues.apache.org/jira/browse/OAK-3761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15107957#comment-15107957
]
Timothee Maret edited comment on OAK-3761 at 1/20/16 4:25 AM:
--
The patch adds two modules, {{oak-crypto-api}} and {{oak-crypto-impl}}.
{{oak-crypto-api}} defines a single {{SymmetricCipher}} interface which
contains a single method for decrypting ciphertext.
As suggested by [~chetanm] on oak-dev mailing list, the API does *not* expose
the encryption method as of this version.
The API could be extended in the future in order to collect all features of
symmetric ciphers (stream cipher, PBE, etc.).
{{oak-crypto-impl}} provides a default implementation of the {{oak-crypto-api}}
API module.
The implementation depends exclusively on security features available on
compliant Java SE 7 platforms [0] ({{AES/CBC/PKCS5Padding}}, {{HmacSHA256}},
{{SecureRandom}}).
The {{SecretKey}} keys required for encryption are stored encrypted (using AES
key wrap algo) on the file system.
Storing the keys in a keystore may make more sense, however there seems to be
no suitable portable keystore as of Java 7.
Indeed, the only required and portable keystore with Java SE 7 compatible
platforms is {{PKCS12}} [0].
The {{PKCS12}} keystore implementation is limited though and, at least on
Oracle JRE/JDK 1.7, does not allow to store {{SecretKey}} keys (only
{{PrivateKey}} keys).
An alternative could be to use asymmetric key wrapping based on a {{KeyPair}}
obtained from a {{PKCS12}} keystore).
However, this is not feasible with Java SE 7 APIs only as there is no JRE/JDK
API that allows signing certificates (setingup the keys using the JRE tooling
external to the JRE would be feasible but more painful to setup).
Other alternatives would be to either require Oracle JRE/JDK 1.8 and OpenJDK
1.8 or to use JCEKS keystores (proprietary) with Oracle 1.7.
Both approaches would allow to store {{SecretKey}} keys in a keystore.
Finally, the module exposes a simple servlet where which allows to encrypt data.
Access to this servlet is currently not restricted.
Details regarding its usage can be found in the module README.
[0]
https://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#impl
was (Author: marett):
The patch adds two modules, {{oak-crypto-api}} and {{oak-crypto-impl}}.
{{oak-crypto-api}} defines a single {{SymmetricCipher}} interface which
contains a single method for decrypting ciphertext.
As suggested by [~chetanm] on oak-dev mailing list, the API does *not* expose
the encryption method as of this version.
The API could be extended in the future in order to collect all features of
symmetric ciphers (stream cipher, PBE, etc.).
{{oak-crypto-impl}} provides a default implementation of the {{oak-crypto-api}}
API module.
The implementation depends exclusively on security features available on
compliant Java SE 7 platforms [0] ({{AES/CBC/PKCS5Padding}}, {{HmacSHA256}},
{{SecureRandom}}).
The (SecretKey) keys required for encryption are stored encrypted (using AES
key wrap algorithm) on the file system.
Storing the keys in a keystore may make more sense, however there seems to be
no suitable portable keystore as of Java 7.
Indeed, the only required and portable keystore with Java SE 7 compatible
platforms is PKCS#12 [0].
The PKCS12 keystore implementation is limited though and, at least on Oracle
JRE/JDK 1.7, does not allow to store SecretKey keys (only PrivateKey keys).
Using asymmetric key wrapping (based on a KeyPair from a PKCS12 keystore) is
not feasible with Java SE 7 APIs only, indeed there is no API that allow
signing certificates (we'd need to setup keys using the JRE tooling external to
the JRE).
Oracle JRE/JDK 1.8 and OpenJDK 1.8 or JCEKS keystores (proprietary) with Oracle
1.7 would allow to store SecretKey keys in PKCS12 keystore though.
Finally, the module exposes a simple servlet where which allows to encrypt data.
Access to this servlet is currently not restricted.
Details regarding its usage can be found in the module README.
[0]
https://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#impl
> Oak crypto API and implementation
> -
>
> Key: OAK-3761
> URL: https://issues.apache.org/jira/browse/OAK-3761
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: security
>Affects Versions: 1.3.12
>Reporter: Timothee Maret
>Assignee: angela
> Attachments: OAK-3761.patch
>
>
> As discussed in [0], this issue tracks adding a simple API and implementation
> for encryption/decryption in Oak.
> [0]
> http://oak.markmail.org/search/?q=crypto#query:crypto+page:1+mid:iwsfd66lku2dzs2n+state:results
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3761) Oak crypto API and implementation
[ https://issues.apache.org/jira/browse/OAK-3761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15107961#comment-15107961 ] Timothee Maret commented on OAK-3761: - [~anchela], [~chetanm] could someone have a look at the patch ? The CryptoServlet is currently not requiring any sort of authentication. Is there a generic support for authentication regarding servlets resources in Oak ? > Oak crypto API and implementation > - > > Key: OAK-3761 > URL: https://issues.apache.org/jira/browse/OAK-3761 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: security >Affects Versions: 1.3.12 >Reporter: Timothee Maret >Assignee: angela > Attachments: OAK-3761.patch > > > As discussed in [0], this issue tracks adding a simple API and implementation > for encryption/decryption in Oak. > [0] > http://oak.markmail.org/search/?q=crypto#query:crypto+page:1+mid:iwsfd66lku2dzs2n+state:results -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3761) Oak crypto API and implementation
[
https://issues.apache.org/jira/browse/OAK-3761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15107957#comment-15107957
]
Timothee Maret commented on OAK-3761:
-
The patch adds two modules, {{oak-crypto-api}} and {{oak-crypto-impl}}.
{{oak-crypto-api}} defines a single {{SymmetricCipher}} interface which
contains a single method for decrypting ciphertext.
As suggested by [~chetanm] on oak-dev mailing list, the API does *not* expose
the encryption method as of this version.
The API could be extended in the future in order to collect all features of
symmetric ciphers (stream cipher, PBE, etc.).
{{oak-crypto-impl}} provides a default implementation of the {{oak-crypto-api}}
API module.
The implementation depends exclusively on security features available on
compliant Java SE 7 platforms [0] ({{AES/CBC/PKCS5Padding}}, {{HmacSHA256}},
{{SecureRandom}}).
The (SecretKey) keys required for encryption are stored encrypted (using AES
key wrap algorithm) on the file system.
Storing the keys in a keystore may make more sense, however there seems to be
no suitable portable keystore as of Java 7.
Indeed, the only required and portable keystore with Java SE 7 compatible
platforms is PKCS#12 [0].
The PKCS12 keystore implementation is limited though and, at least on Oracle
JRE/JDK 1.7, does not allow to store SecretKey keys (only PrivateKey keys).
Using asymmetric key wrapping (based on a KeyPair from a PKCS12 keystore) is
not feasible with Java SE 7 APIs only, indeed there is no API that allow
signing certificates (we'd need to setup keys using the JRE tooling external to
the JRE).
Oracle JRE/JDK 1.8 and OpenJDK 1.8 or JCEKS keystores (proprietary) with Oracle
1.7 would allow to store SecretKey keys in PKCS12 keystore though.
Finally, the module exposes a simple servlet where which allows to encrypt data.
Access to this servlet is currently not restricted.
Details regarding its usage can be found in the module README.
[0]
https://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#impl
> Oak crypto API and implementation
> -
>
> Key: OAK-3761
> URL: https://issues.apache.org/jira/browse/OAK-3761
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: security
>Affects Versions: 1.3.12
>Reporter: Timothee Maret
>Assignee: angela
> Attachments: OAK-3761.patch
>
>
> As discussed in [0], this issue tracks adding a simple API and implementation
> for encryption/decryption in Oak.
> [0]
> http://oak.markmail.org/search/?q=crypto#query:crypto+page:1+mid:iwsfd66lku2dzs2n+state:results
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3761) Oak crypto API and implementation
[ https://issues.apache.org/jira/browse/OAK-3761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothee Maret updated OAK-3761: Attachment: OAK-3761.patch Attaching SVN compatible patch (otherwise available on github https://github.com/tmaret/jackrabbit-oak/commit/8380f8da9c4d04e5c0d53ae07d93ffaaa47ace97.patch) > Oak crypto API and implementation > - > > Key: OAK-3761 > URL: https://issues.apache.org/jira/browse/OAK-3761 > Project: Jackrabbit Oak > Issue Type: New Feature > Components: security >Affects Versions: 1.3.12 >Reporter: Timothee Maret >Assignee: angela > Attachments: OAK-3761.patch > > > As discussed in [0], this issue tracks adding a simple API and implementation > for encryption/decryption in Oak. > [0] > http://oak.markmail.org/search/?q=crypto#query:crypto+page:1+mid:iwsfd66lku2dzs2n+state:results -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3790) Back Port Support including and excluding paths for PropertyIndex to Oak 1.2 branch
[ https://issues.apache.org/jira/browse/OAK-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-3790: --- Fix Version/s: (was: 1.2.10) 1.2.11 > Back Port Support including and excluding paths for PropertyIndex to Oak 1.2 > branch > --- > > Key: OAK-3790 > URL: https://issues.apache.org/jira/browse/OAK-3790 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: query >Reporter: Bjoern Weide > Fix For: 1.2.11 > > > It would be good to back port OAK-3263 to the 1.2 branch. It's a new feature, > but I think an extremely helpful one. (I opened a new ticket since OAK-3263 > is already closed). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3176) Provide an option to include a configured boost query while searching
[ https://issues.apache.org/jira/browse/OAK-3176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-3176: --- Fix Version/s: (was: 1.2.10) 1.2.11 > Provide an option to include a configured boost query while searching > - > > Key: OAK-3176 > URL: https://issues.apache.org/jira/browse/OAK-3176 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: solr >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: 1.4, 1.2.11 > > > For tweaking relevancy it's sometimes useful to include a boost query that > gets applied at query time and modifies the ranking accordingly. > This can be done also by setting it by hand as a default parameter to the > /select request handler, but for convenience it'd be good if the Solr > instance configuration files wouldn't be touched. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3613) Backport TarMK revision gc related issues
[ https://issues.apache.org/jira/browse/OAK-3613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amit Jain updated OAK-3613: --- Fix Version/s: (was: 1.2.10) 1.2.11 > Backport TarMK revision gc related issues > - > > Key: OAK-3613 > URL: https://issues.apache.org/jira/browse/OAK-3613 > Project: Jackrabbit Oak > Issue Type: Task > Components: segmentmk >Reporter: Michael Dürig >Assignee: Michael Dürig > Labels: compaction, gc > Fix For: 1.2.11, 1.0.27 > > Attachments: > 0001-OAK-2870-Introduce-a-SegmentNodeStoreBuilder-to-help.patch, > 1.2-OAK-2870.patch, OAK-1995-1.0.patch, OAK-1995-1.2.zip, OsgiUtil-1.0.patch, > OsgiUtil-1.2.patch > > > Some of the issues related to TarMK revision gc should be back ported to the > branches. This issue is for keeping track of which issues and which svn > revisions we consider for back porting. The task consists of the following > steps: > # Identify issue to back port > # Merge the respective commits into a private forks of the 1.0 and 1.2 > branches > # Run tests on builds from the private forks > # On success merge the private forks to the 1.0 and 1.2 branches and update > the fix versions of the respective issues. > * Update the svn merge info with the respective merged svn revisions. > * Update the fix versions of the affected issues. > [~dhasler]: FYI > [~alex.parvulescu], [~frm]: please refrain from merging potential conflicting > changes into the branches in the meanwhile. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3899) TokenLoginModule ignores shared key javax.security.auth.login.name
[
https://issues.apache.org/jira/browse/OAK-3899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated OAK-3899:
---
Description:
The {{TokenLoginModule}} and specifically TokenProviderImpl [only look at
SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/1144914c053ec9c2723450261fabfee1bd9d0e58/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165]
when creating a token.
However, in certain situations, such as with the ExternalLoginModule and
non-username/password credentials, the SimpleCredentials are used but don't
have a user id as the real user id is determined not by the caller of
{{Repository.login()}}, but by the external identity provider inside the
ExternalLoginModule (and the credentials might not include any kind of user id,
say an opaque token from an external service). In this case,
{{SimpleCredentials.getUserID()}} returns null and the token implementation
fails to create a token and does not return it in the {{.token}} attribute of
the credentials.
Instead, the TokenLoginModule should look at the shared
{{javax.security.auth.login.name}} attribute, which can de-facto override a
{{SimpleCredentials.getUserID()}}, as it happens in the ExternalLoginModule.
was:
The {{TokenLoginModule}} and specifically TokenProviderImpl [only look at
SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165]
when creating a token.
However, in certain situations, such as with the ExternalLoginModule and
non-username/password credentials, the SimpleCredentials are used but don't
have a user id as the real user id is determined not by the caller of
{{Repository.login()}}, but by the external identity provider inside the
ExternalLoginModule (and the credentials might not include any kind of user id,
say an opaque token from an external service). In this case,
{{SimpleCredentials.getUserID()}} returns null and the token implementation
fails to create a token and does not return it in the {{.token}} attribute of
the credentials.
Instead, the TokenLoginModule should look at the shared
{{javax.security.auth.login.name}} attribute, which can de-facto override a
{{SimpleCredentials.getUserID()}}, as it happens in the ExternalLoginModule.
> TokenLoginModule ignores shared key javax.security.auth.login.name
> --
>
> Key: OAK-3899
> URL: https://issues.apache.org/jira/browse/OAK-3899
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.3.14
>Reporter: Alexander Klimetschek
> Attachments: OAK-3899.patch
>
>
> The {{TokenLoginModule}} and specifically TokenProviderImpl [only look at
> SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/1144914c053ec9c2723450261fabfee1bd9d0e58/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165]
> when creating a token.
> However, in certain situations, such as with the ExternalLoginModule and
> non-username/password credentials, the SimpleCredentials are used but don't
> have a user id as the real user id is determined not by the caller of
> {{Repository.login()}}, but by the external identity provider inside the
> ExternalLoginModule (and the credentials might not include any kind of user
> id, say an opaque token from an external service). In this case,
> {{SimpleCredentials.getUserID()}} returns null and the token implementation
> fails to create a token and does not return it in the {{.token}} attribute of
> the credentials.
> Instead, the TokenLoginModule should look at the shared
> {{javax.security.auth.login.name}} attribute, which can de-facto override a
> {{SimpleCredentials.getUserID()}}, as it happens in the ExternalLoginModule.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3899) TokenLoginModule ignores shared key javax.security.auth.login.name
[
https://issues.apache.org/jira/browse/OAK-3899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated OAK-3899:
---
Description:
The {{TokenLoginModule}} and specifically TokenProviderImpl [only look at
SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165]
when creating a token.
However, in certain situations, such as with the ExternalLoginModule and
non-username/password credentials, the SimpleCredentials are used but don't
have a user id as the real user id is determined not by the caller of
{{Repository.login()}}, but by the external identity provider inside the
ExternalLoginModule (and the credentials might not include any kind of user id,
say an opaque token from an external service). In this case,
{{SimpleCredentials.getUserID()}} returns null and the token implementation
fails to create a token and does not return it in the {{.token}} attribute of
the credentials.
Instead, the TokenLoginModule should look at the shared
{{javax.security.auth.login.name}} attribute, which can de-facto override a
{{SimpleCredentials.getUserID()}}, as it happens in the ExternalLoginModule.
was:
The {{TokenLoginModule}} and specifically [TokenProviderImpl only look at
SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165]
when creating a token.
However, in certain situations, such as with the ExternalLoginModule and
non-username/password credentials, the SimpleCredentials are used but don't
have a user id as the real user id is determined not by the caller of
{{Repository.login()}}, but by the external identity provider inside the
ExternalLoginModule (and the credentials might not include any kind of user id,
say an opaque token from an external service). In this case,
{{SimpleCredentials.getUserID()}} returns null and the token implementation
fails to create a token and does not return it in the {{.token}} attribute of
the credentials.
Instead, the TokenLoginModule should look at the shared
{{javax.security.auth.login.name}} attribute, which can de-facto override a
{{SimpleCredentials.getUserID()}}, as it happens in the ExternalLoginModule.
> TokenLoginModule ignores shared key javax.security.auth.login.name
> --
>
> Key: OAK-3899
> URL: https://issues.apache.org/jira/browse/OAK-3899
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.3.14
>Reporter: Alexander Klimetschek
> Attachments: OAK-3899.patch
>
>
> The {{TokenLoginModule}} and specifically TokenProviderImpl [only look at
> SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165]
> when creating a token.
> However, in certain situations, such as with the ExternalLoginModule and
> non-username/password credentials, the SimpleCredentials are used but don't
> have a user id as the real user id is determined not by the caller of
> {{Repository.login()}}, but by the external identity provider inside the
> ExternalLoginModule (and the credentials might not include any kind of user
> id, say an opaque token from an external service). In this case,
> {{SimpleCredentials.getUserID()}} returns null and the token implementation
> fails to create a token and does not return it in the {{.token}} attribute of
> the credentials.
> Instead, the TokenLoginModule should look at the shared
> {{javax.security.auth.login.name}} attribute, which can de-facto override a
> {{SimpleCredentials.getUserID()}}, as it happens in the ExternalLoginModule.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-3899) TokenLoginModule ignores shared key javax.security.auth.login.name
[
https://issues.apache.org/jira/browse/OAK-3899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15107761#comment-15107761
]
Alexander Klimetschek edited comment on OAK-3899 at 1/20/16 12:53 AM:
--
Attached a [patch|^OAK-3899.patch], that basically takes the shared attribute
{{javax.security.auth.login.name}} over the {{SimpleCredentials.getUserID()}}
if it's not null.
It was a bit tricky, as this logic including the
write-back-token-to-credentials happens inside the TokenProviderImpl. The use
of the {{TokenProvider.createToken(Credentials)}} method prevents one from
passing the separate shared login name. Thus I had to move this logic to the
TokenLoginModule, and effectively deprecating
{{TokenProvider.createToken(Credentials)}} (being called from the
TokenLoginModule was it's only usage within Oak at least).
I think this makes sense: the token provider should be concerned only with
creating & managing tokens in the repository (or whatever persistence is
wanted). Parsing jcr Credentials and sending back the new token in the
{{.token}} attribute if it's a SimpleCredentials is orthogonal and better left
with the TokenLoginModule anyway.
was (Author: alexander.klimetschek):
Attached a patch, that basically takes the shared attribute
{{javax.security.auth.login.name}} over the {{SimpleCredentials.getUserID()}}
if it's not null.
It was a bit tricky, as this logic including the
write-back-token-to-credentials happens inside the TokenProviderImpl. The use
of the {{TokenProvider.createToken(Credentials)}} method prevents one from
passing the separate shared login name. Thus I had to move this logic to the
TokenLoginModule, and effectively deprecating
{{TokenProvider.createToken(Credentials)}} (being called from the
TokenLoginModule was it's only usage within Oak at least).
I think this makes sense: the token provider should be concerned only with
creating & managing tokens in the repository (or whatever persistence is
wanted). Parsing jcr Credentials and sending back the new token in the
{{.token}} attribute if it's a SimpleCredentials is orthogonal and better left
with the TokenLoginModule anyway.
> TokenLoginModule ignores shared key javax.security.auth.login.name
> --
>
> Key: OAK-3899
> URL: https://issues.apache.org/jira/browse/OAK-3899
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.3.14
>Reporter: Alexander Klimetschek
> Attachments: OAK-3899.patch
>
>
> The {{TokenLoginModule}} and specifically [TokenProviderImpl only look at
> SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165]
> when creating a token.
> However, in certain situations, such as with the ExternalLoginModule and
> non-username/password credentials, the SimpleCredentials are used but don't
> have a user id as the real user id is determined not by the caller of
> {{Repository.login()}}, but by the external identity provider inside the
> ExternalLoginModule (and the credentials might not include any kind of user
> id, say an opaque token from an external service). In this case,
> {{SimpleCredentials.getUserID()}} returns null and the token implementation
> fails to create a token and does not return it in the {{.token}} attribute of
> the credentials.
> Instead, the TokenLoginModule should look at the shared
> {{javax.security.auth.login.name}} attribute, which can de-facto override a
> {{SimpleCredentials.getUserID()}}, as it happens in the ExternalLoginModule.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3899) TokenLoginModule ignores shared key javax.security.auth.login.name
[
https://issues.apache.org/jira/browse/OAK-3899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated OAK-3899:
---
Description:
The {{TokenLoginModule}} and specifically [TokenProviderImpl only look at
SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165]
when creating a token.
However, in certain situations, such as with the ExternalLoginModule and
non-username/password credentials, the SimpleCredentials are used but don't
have a user id as the real user id is determined not by the caller of
{{Repository.login()}}, but by the external identity provider inside the
ExternalLoginModule (and the credentials might not include any kind of user id,
say an opaque token from an external service). In this case,
{{SimpleCredentials.getUserID()}} returns null and the token implementation
fails to create a token and does not return it in the {{.token}} attribute of
the credentials.
Instead, the TokenLoginModule should look at the shared
{{javax.security.auth.login.name}} attribute, which can de-facto override a
{{SimpleCredentials.getUserID()}}, as it happens in the ExternalLoginModule.
was:
The {{TokenLoginModule}} and specifically [TokenProviderImpl only look at
SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165]
when creating a token.
However, in certain situations, such as with the ExternalLoginModule and
non-username/password credentials, the SimpleCredentials are used but don't
have a user id as the real user id is determined not by the caller of
{{Repository.login()}}, but by the external identity provider inside the
ExternalLoginModule (and the credentials might not include any kind of user id,
say an opaque token from an external service). In this case,
{{SimpleCredentials.getUserID()}} returns null and the token implementation
fails to create a token and return it in the {{.token}} attribute of the
credentials.
Instead, the TokenLoginModule should look at the shared
{{javax.security.auth.login.name}} attribute, which can de-facto override a
{{SimpleCredentials.getUserID()}}, as it happens in the ExternalLoginModule.
> TokenLoginModule ignores shared key javax.security.auth.login.name
> --
>
> Key: OAK-3899
> URL: https://issues.apache.org/jira/browse/OAK-3899
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.3.14
>Reporter: Alexander Klimetschek
> Attachments: OAK-3899.patch
>
>
> The {{TokenLoginModule}} and specifically [TokenProviderImpl only look at
> SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165]
> when creating a token.
> However, in certain situations, such as with the ExternalLoginModule and
> non-username/password credentials, the SimpleCredentials are used but don't
> have a user id as the real user id is determined not by the caller of
> {{Repository.login()}}, but by the external identity provider inside the
> ExternalLoginModule (and the credentials might not include any kind of user
> id, say an opaque token from an external service). In this case,
> {{SimpleCredentials.getUserID()}} returns null and the token implementation
> fails to create a token and does not return it in the {{.token}} attribute of
> the credentials.
> Instead, the TokenLoginModule should look at the shared
> {{javax.security.auth.login.name}} attribute, which can de-facto override a
> {{SimpleCredentials.getUserID()}}, as it happens in the ExternalLoginModule.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3899) TokenLoginModule ignores shared key javax.security.auth.login.name
[
https://issues.apache.org/jira/browse/OAK-3899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated OAK-3899:
---
Description:
The {{TokenLoginModule}} and specifically [TokenProviderImpl only look at
SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165]
when creating a token.
However, in certain situations, such as with the ExternalLoginModule and
non-username/password credentials, the SimpleCredentials are used but don't
have a user id as the real user id is determined not by the caller of
{{Repository.login()}}, but by the external identity provider inside the
ExternalLoginModule (and the credentials might not include any kind of user id,
say an opaque token from an external service). In this case,
{{SimpleCredentials.getUserID()}} returns null and the token implementation
fails to create a token and return it in the {{.token}} attribute of the
credentials.
Instead, the TokenLoginModule should look at the shared
{{javax.security.auth.login.name}} attribute, which can de-facto override a
{{SimpleCredentials.getUserID()}}, as it happens in the ExternalLoginModule.
was:
The {{TokenLoginModule}} and specifically [TokenProviderImpl only look at
SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165]
when creating a token.
However, in certain situations, such as with the ExternalLoginModule and
non-username/password credentials, the SimpleCredentials are used but don't
have a user id as the real user id is determined not by the caller of
{{Repository.login()}}, but by the external identity provider inside the
ExternalLoginModule (and the credentials might not include any kind of user id,
say an opaque token from an external service). In this case, {{getUserID()}}
returns null and the token implementation fails to create a token and return it
in the {{.token}} attribute of the credentials.
Instead, the TokenLoginModule should look at the shared
{{javax.security.auth.login.name}} attribute, which can de-facto override a
{{SimpleCredentials.getUserID()}}, as it happens in the ExternalLoginModule.
> TokenLoginModule ignores shared key javax.security.auth.login.name
> --
>
> Key: OAK-3899
> URL: https://issues.apache.org/jira/browse/OAK-3899
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.3.14
>Reporter: Alexander Klimetschek
> Attachments: OAK-3899.patch
>
>
> The {{TokenLoginModule}} and specifically [TokenProviderImpl only look at
> SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165]
> when creating a token.
> However, in certain situations, such as with the ExternalLoginModule and
> non-username/password credentials, the SimpleCredentials are used but don't
> have a user id as the real user id is determined not by the caller of
> {{Repository.login()}}, but by the external identity provider inside the
> ExternalLoginModule (and the credentials might not include any kind of user
> id, say an opaque token from an external service). In this case,
> {{SimpleCredentials.getUserID()}} returns null and the token implementation
> fails to create a token and return it in the {{.token}} attribute of the
> credentials.
> Instead, the TokenLoginModule should look at the shared
> {{javax.security.auth.login.name}} attribute, which can de-facto override a
> {{SimpleCredentials.getUserID()}}, as it happens in the ExternalLoginModule.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3899) TokenLoginModule ignores shared key javax.security.auth.login.name
[
https://issues.apache.org/jira/browse/OAK-3899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated OAK-3899:
---
Description:
The {{TokenLoginModule}} and specifically [TokenProviderImpl only look at
SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165]
when creating a token.
However, in certain situations, such as with the ExternalLoginModule and
non-username/password credentials, the SimpleCredentials are used but don't
have a user id as the real user id is determined not by the caller of
{{Repository.login()}}, but by the external identity provider inside the
ExternalLoginModule (and the credentials might not include any kind of user id,
say an opaque token from an external service). In this case, {{getUserID()}}
returns null and the token implementation fails to create a token and return it
in the {{.token}} attribute of the credentials.
Instead, the TokenLoginModule should look at the shared
{{javax.security.auth.login.name}} attribute, which can de-facto override a
{{SimpleCredentials.getUserID()}}, as it happens in the ExternalLoginModule.
was:
The {{TokenLoginModule}} and specifically [TokenProviderImpl only look at
SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165]
when creating a token.
However, in certain situations, such as with the ExternalLoginModule and
non-username/password credentials, the SimpleCredentials are used but don't
have a user id as the real user id is determined not by the caller of
{{Repository.login()}}, but by the external identity provider (and the
credentials might not include any kind of user id, say an opaque token from an
external service). In this case, {{getUserID()}} returns null and the token
implementation fails to create a token and return it in the {{.token}}
attribute of the credentials.
Instead, the TokenLoginModule should look at the shared
{{javax.security.auth.login.name}} attribute, which can de-facto override a
{{SimpleCredentials.getUserID()}}, as it happens in the ExternalLoginModule.
> TokenLoginModule ignores shared key javax.security.auth.login.name
> --
>
> Key: OAK-3899
> URL: https://issues.apache.org/jira/browse/OAK-3899
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.3.14
>Reporter: Alexander Klimetschek
> Attachments: OAK-3899.patch
>
>
> The {{TokenLoginModule}} and specifically [TokenProviderImpl only look at
> SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165]
> when creating a token.
> However, in certain situations, such as with the ExternalLoginModule and
> non-username/password credentials, the SimpleCredentials are used but don't
> have a user id as the real user id is determined not by the caller of
> {{Repository.login()}}, but by the external identity provider inside the
> ExternalLoginModule (and the credentials might not include any kind of user
> id, say an opaque token from an external service). In this case,
> {{getUserID()}} returns null and the token implementation fails to create a
> token and return it in the {{.token}} attribute of the credentials.
> Instead, the TokenLoginModule should look at the shared
> {{javax.security.auth.login.name}} attribute, which can de-facto override a
> {{SimpleCredentials.getUserID()}}, as it happens in the ExternalLoginModule.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3899) TokenLoginModule ignores shared key javax.security.auth.login.name
[
https://issues.apache.org/jira/browse/OAK-3899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated OAK-3899:
---
Description:
The {{TokenLoginModule}} and specifically [TokenProviderImpl only look at
SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165]
when creating a token.
However, in certain situations, such as with the ExternalLoginModule and
non-username/password credentials, the SimpleCredentials are used but don't
have a user id as the real user id is determined not by the caller of
{{Repository.login()}}, but by the external identity provider (and the
credentials might not include any kind of user id, say an opaque token from an
external service). In this case, {{getUserID()}} returns null and the token
implementation fails to create a token and return it in the {{.token}}
attribute of the credentials.
Instead, the TokenLoginModule should look at the shared
{{javax.security.auth.login.name}} attribute, which can de-facto override a
{{SimpleCredentials.getUserID()}}, as it happens in the ExternalLoginModule.
was:
The {{TokenLoginModule}} and specifically [TokenProviderImpl only look at
SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165]
when creating a token.
However, in certain situations, such as the ExternalLoginModule, the
SimpleCredentials are used but don't have a user id as the real user id is
determined not by the caller of {{Repository.login()}}, but by the external
identity provider (and the credentials might not include any kind of user id,
say an opaque token from an external service). In this case, {{getUserID()}}
returns null and the token implementation fails to create a token and return it
in the {{.token}} attribute of the credentials.
Instead, the TokenLoginModule should look at the shared
{{javax.security.auth.login.name}} attribute, which can de-facto override a
{{SimpleCredentials.getUserID()}}, as it happens in the ExternalLoginModule.
> TokenLoginModule ignores shared key javax.security.auth.login.name
> --
>
> Key: OAK-3899
> URL: https://issues.apache.org/jira/browse/OAK-3899
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.3.14
>Reporter: Alexander Klimetschek
> Attachments: OAK-3899.patch
>
>
> The {{TokenLoginModule}} and specifically [TokenProviderImpl only look at
> SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165]
> when creating a token.
> However, in certain situations, such as with the ExternalLoginModule and
> non-username/password credentials, the SimpleCredentials are used but don't
> have a user id as the real user id is determined not by the caller of
> {{Repository.login()}}, but by the external identity provider (and the
> credentials might not include any kind of user id, say an opaque token from
> an external service). In this case, {{getUserID()}} returns null and the
> token implementation fails to create a token and return it in the {{.token}}
> attribute of the credentials.
> Instead, the TokenLoginModule should look at the shared
> {{javax.security.auth.login.name}} attribute, which can de-facto override a
> {{SimpleCredentials.getUserID()}}, as it happens in the ExternalLoginModule.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3899) TokenLoginModule ignores shared key javax.security.auth.login.name
[
https://issues.apache.org/jira/browse/OAK-3899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated OAK-3899:
---
Description:
The {{TokenLoginModule}} and specifically [TokenProviderImpl only look at
SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165]
when creating a token.
However, in certain situations, such as the ExternalLoginModule, the
SimpleCredentials are used but don't have a user id as the real user id is
determined not by the caller of {{Repository.login()}}, but by the external
identity provider (and the credentials might not include any kind of user id,
say an opaque token from an external service). In this case, {{getUserID()}}
returns null and the token implementation fails to create a token and return it
in the {{.token}} attribute of the credentials.
Instead, the TokenLoginModule should look at the shared
{{javax.security.auth.login.name}} attribute, which can de-facto override a
{{SimpleCredentials.getUserID()}}, as it happens in the ExternalLoginModule.
was:
The TokenLoginModule and specifically [TokenProviderImpl only look at
SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165]
when creating a token.
However, in certain situations, such as the ExternalLoginModule, the
SimpleCredentials are used but don't have a user id as the real user id is
determined not by the caller of repository.login(), but by the external
identity provider (and the credentials might not include any kind of user id,
say an opaque token from an external service). In this case, getUserID()
returns null and the token implementation fails to create a token and return it
in the ".token" attribute of the credentials.
Instead, the TokenLoginModule should look at the shared
"javax.security.auth.login.name" parameter, which can de-facto override a
SimpleCredentials.getUserID(), as it happens in the ExternalLoginModule.
> TokenLoginModule ignores shared key javax.security.auth.login.name
> --
>
> Key: OAK-3899
> URL: https://issues.apache.org/jira/browse/OAK-3899
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.3.14
>Reporter: Alexander Klimetschek
> Attachments: OAK-3899.patch
>
>
> The {{TokenLoginModule}} and specifically [TokenProviderImpl only look at
> SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165]
> when creating a token.
> However, in certain situations, such as the ExternalLoginModule, the
> SimpleCredentials are used but don't have a user id as the real user id is
> determined not by the caller of {{Repository.login()}}, but by the external
> identity provider (and the credentials might not include any kind of user id,
> say an opaque token from an external service). In this case, {{getUserID()}}
> returns null and the token implementation fails to create a token and return
> it in the {{.token}} attribute of the credentials.
> Instead, the TokenLoginModule should look at the shared
> {{javax.security.auth.login.name}} attribute, which can de-facto override a
> {{SimpleCredentials.getUserID()}}, as it happens in the ExternalLoginModule.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3899) TokenLoginModule ignores shared key javax.security.auth.login.name
[
https://issues.apache.org/jira/browse/OAK-3899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Klimetschek updated OAK-3899:
---
Attachment: OAK-3899.patch
Attached a patch, that basically takes the shared attribute
{{javax.security.auth.login.name}} over the {{SimpleCredentials.getUserID()}}
if it's not null.
It was a bit tricky, as this logic including the
write-back-token-to-credentials happens inside the TokenProviderImpl. The use
of the {{TokenProvider.createToken(Credentials)}} method prevents one from
passing the separate shared login name. Thus I had to move this logic to the
TokenLoginModule, and effectively deprecating
{{TokenProvider.createToken(Credentials)}} (being called from the
TokenLoginModule was it's only usage within Oak at least).
I think this makes sense: the token provider should be concerned only with
creating & managing tokens in the repository (or whatever persistence is
wanted). Parsing jcr Credentials and sending back the new token in the
{{.token}} attribute if it's a SimpleCredentials is orthogonal and better left
with the TokenLoginModule anyway.
> TokenLoginModule ignores shared key javax.security.auth.login.name
> --
>
> Key: OAK-3899
> URL: https://issues.apache.org/jira/browse/OAK-3899
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core
>Affects Versions: 1.3.14
>Reporter: Alexander Klimetschek
> Attachments: OAK-3899.patch
>
>
> The TokenLoginModule and specifically [TokenProviderImpl only look at
> SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165]
> when creating a token.
> However, in certain situations, such as the ExternalLoginModule, the
> SimpleCredentials are used but don't have a user id as the real user id is
> determined not by the caller of repository.login(), but by the external
> identity provider (and the credentials might not include any kind of user id,
> say an opaque token from an external service). In this case, getUserID()
> returns null and the token implementation fails to create a token and return
> it in the ".token" attribute of the credentials.
> Instead, the TokenLoginModule should look at the shared
> "javax.security.auth.login.name" parameter, which can de-facto override a
> SimpleCredentials.getUserID(), as it happens in the ExternalLoginModule.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3899) TokenLoginModule ignores shared key javax.security.auth.login.name
[ https://issues.apache.org/jira/browse/OAK-3899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Klimetschek updated OAK-3899: --- Description: The TokenLoginModule and specifically [TokenProviderImpl only look at SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165] when creating a token. However, in certain situations, such as the ExternalLoginModule, the SimpleCredentials are used but don't have a user id as the real user id is determined not by the caller of repository.login(), but by the external identity provider (and the credentials might not include any kind of user id, say an opaque token from an external service). In this case, getUserID() returns null and the token implementation fails to create a token and return it in the ".token" attribute of the credentials. Instead, the TokenLoginModule should look at the shared "javax.security.auth.login.name" parameter, which can de-facto override a SimpleCredentials.getUserID(), as it happens in the ExternalLoginModule. was: The TokenLoginModule and specifically [TokenProviderImpl only look at SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165] when creating a token. However, in certain situations, such as the ExternalLoginModule, the SimpleCredentials are used but don't have a user id as the real user id is determined not by the caller of repository.login(), but by the external identity provider (and the credentials might not include any kind of user id, say an opaque token from an external service). In this case, getUserID() returns null and the token implementation fails to create a token and return it in the ".token" attribute of the credentials. > TokenLoginModule ignores shared key javax.security.auth.login.name > -- > > Key: OAK-3899 > URL: https://issues.apache.org/jira/browse/OAK-3899 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core >Affects Versions: 1.3.14 >Reporter: Alexander Klimetschek > > The TokenLoginModule and specifically [TokenProviderImpl only look at > SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165] > when creating a token. > However, in certain situations, such as the ExternalLoginModule, the > SimpleCredentials are used but don't have a user id as the real user id is > determined not by the caller of repository.login(), but by the external > identity provider (and the credentials might not include any kind of user id, > say an opaque token from an external service). In this case, getUserID() > returns null and the token implementation fails to create a token and return > it in the ".token" attribute of the credentials. > Instead, the TokenLoginModule should look at the shared > "javax.security.auth.login.name" parameter, which can de-facto override a > SimpleCredentials.getUserID(), as it happens in the ExternalLoginModule. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3899) TokenLoginModule ignores shared key javax.security.auth.login.name
Alexander Klimetschek created OAK-3899: -- Summary: TokenLoginModule ignores shared key javax.security.auth.login.name Key: OAK-3899 URL: https://issues.apache.org/jira/browse/OAK-3899 Project: Jackrabbit Oak Issue Type: Bug Components: core Affects Versions: 1.3.14 Reporter: Alexander Klimetschek The TokenLoginModule and specifically [TokenProviderImpl only look at SimpleCredentials.getUserID()|https://github.com/apache/jackrabbit-oak/blob/trunk/oak-core/src/main/java/org/apache/jackrabbit/oak/security/authentication/token/TokenProviderImpl.java#L165] when creating a token. However, in certain situations, such as the ExternalLoginModule, the SimpleCredentials are used but don't have a user id as the real user id is determined not by the caller of repository.login(), but by the external identity provider (and the credentials might not include any kind of user id, say an opaque token from an external service). In this case, getUserID() returns null and the token implementation fails to create a token and return it in the ".token" attribute of the credentials. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3865) New strategy to optimize secondary reads
[
https://issues.apache.org/jira/browse/OAK-3865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15107573#comment-15107573
]
Tomek Rękawek commented on OAK-3865:
{quote}
Isn't M1 the RevisionVector of the current root node? It is already updated
with ever local commit and when external changes are pulled in from other
cluster nodes.
{quote}
I thought about the case in which a document has been externally modified and
read from the Mongo, but the related lastRev changes to ancestors haven't been
written and/or read by the background processes. Something like:
Mongo primary: /@r5
Mongo secondary: /@r5
Oak_1: background read /@r5 (->M1)
Oak_2: write /content/xyz@r10
Oak_2: write /content/abc@r11
Oak_1: read /content/xyz@r10 from primary
Oak_1: can I read /content/abc from secondary? sure, as we have /@5 both on
secondary and M1
Oak_2: background write /@12
Oak_1: background read /@12 (-> M1)
Mongo primary: finish the replication of /content/xyz and /content/abc to the
secondary
So, the /content/abc has been modified after /content/xyz, but Oak_1 got the
new /content/xyz and the old /content/abc. This could be prevented by
maintaining a separate M1 and updating it with all the read/find/query
operations, which isn't that hard.
{quote}
> Regarding the documents modified by the local Oak instance
Isn't this already handled automatically with your algorithm? A local change
results in an update of M1 and will therefore prevent a read from a secondary
until the change arrived there.
{quote}
It'd be exactly as you wrote - we wouldn't read anything from the secondary
until all our changes are fully replicated. If an instance updates the
repository regularly, we'll be permanently cut off from the secondary
instances. We can optimise this further and use the primary only for locally
modified documents (it's easy to create a list) that hasn't been replicated yet
(we know this from M2). For all the other documents the described algorithm
applies.
> New strategy to optimize secondary reads
>
>
> Key: OAK-3865
> URL: https://issues.apache.org/jira/browse/OAK-3865
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mongomk
>Reporter: Tomek Rękawek
> Fix For: 1.4
>
> Attachments: diagram.png
>
>
> *Introduction*
> In the current trunk we'll only read document _D_ from the secondary instance
> if:
> (1) we have the parent _P_ of document _D_ cached and
> (2) the parent hasn't been modified in 6 hours.
> The OAK-2106 tried to optimise (2) by estimating lag using MongoDB replica
> stats. It was unreliable, so the second approach was to read the last
> revisions directly from each Mongo instance. If the modification date of _P_
> is before last revisions on all secondary Mongos, then secondary can be used.
> The main problem with this approach is that we still need to have the _P_ to
> be in cache. I think we need another way to optimise the secondary reading,
> as right now only about 3% of requests connects to the secondary, which is
> bad especially for the global-clustering case (Mongo and Oak instances across
> the globe). The optimisation provided in OAK-2106 doesn't make the things
> much better and may introduce some consistency issues.
> *Proposal*
> I had following constraints in mind preparing this:
> 1. Let's assume we have a sequence of commits with revisions _R1_, _R2_ and
> _R3_ modifying nodes _N1_, _N2_ and _N3_. If we already read the _N1_ from
> revision _R2_ then reading from a secondary shouldn't result in getting older
> revision (eg. _R1_).
> 2. If an Oak instance modifies a document, then reading from a secondary
> shouldn't result in getting the old version (before modification).
> So, let's have two maps:
> * _M1_ the most recent document revision read from the Mongo for each cluster
> id,
> * _M2_ the oldest last rev value for root document for each cluster id read
> from all the secondary instances.
> Maintaining _M1_:
> For every read from the Mongo we'll check if the lastRev for some cluster id
> is newer than _M1_ entry. If so, we'll update _M1_. For all writes we'll add
> the saved revision id with the current cluster id in _M1_.
> Maintaining _M2_:
> It should be periodically updated. Such mechanism is already prepared in the
> OAK-2106 patch.
> The method deciding whether we can read from the secondary instance should
> compare two maps. If all entries in _M2_ are newer than _M1_ it means that
> the secondary instances contains at least as new repository state as we
> already accessed and therefore it's safe to read from secondary.
> Regarding the documents modified by the local Oak instance, we should
> remember all the locally-modified paths and their revisions and use primary
> Mongo to access them as long as the chan
[jira] [Updated] (OAK-3651) Remove HierarchicalCacheInvalidator
[ https://issues.apache.org/jira/browse/OAK-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3651: Summary: Remove HierarchicalCacheInvalidator (was: Remove HierarchialCacheInvalidator) > Remove HierarchicalCacheInvalidator > --- > > Key: OAK-3651 > URL: https://issues.apache.org/jira/browse/OAK-3651 > Project: Jackrabbit Oak > Issue Type: Task > Components: mongomk >Affects Versions: 1.3.10, 1.2.9 >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Labels: candidate_oak_1_0, candidate_oak_1_2, technical_debt > Fix For: 1.3.11 > > Attachments: OAK-3651-for-1.2.diff > > > As discussed in OAK-2187 and due to changes done in OAK-3002 > HierrachialCacheInvalidator is now redundant and should be removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3896) RDBDocumentStore: export tool - improve handling of export files allowing to override column order
[ https://issues.apache.org/jira/browse/OAK-3896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-3896. - Resolution: Fixed trunk: http://svn.apache.org/r172 1.2: http://svn.apache.org/r1725558 1.0: http://svn.apache.org/r1725564 > RDBDocumentStore: export tool - improve handling of export files allowing to > override column order > -- > > Key: OAK-3896 > URL: https://issues.apache.org/jira/browse/OAK-3896 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Affects Versions: 1.2.9, 1.0.26, 1.3.14 >Reporter: Julian Reschke >Assignee: Julian Reschke > Fix For: 1.2.10, 1.3.15, 1.0.27 > > > For instance, the DB2 "DEL" export format doesn't contain the column titles > and thus relies on the actual query that was used (or on the order of columns > in the database when "SELECT *" was used). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3896) RDBDocumentStore: export tool - improve handling of export files allowing to override column order
[ https://issues.apache.org/jira/browse/OAK-3896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3896: Fix Version/s: 1.0.27 > RDBDocumentStore: export tool - improve handling of export files allowing to > override column order > -- > > Key: OAK-3896 > URL: https://issues.apache.org/jira/browse/OAK-3896 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Affects Versions: 1.2.9, 1.0.26, 1.3.14 >Reporter: Julian Reschke >Assignee: Julian Reschke > Fix For: 1.2.10, 1.3.15, 1.0.27 > > > For instance, the DB2 "DEL" export format doesn't contain the column titles > and thus relies on the actual query that was used (or on the order of columns > in the database when "SELECT *" was used). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3896) RDBDocumentStore: export tool - improve handling of export files allowing to override column order
[ https://issues.apache.org/jira/browse/OAK-3896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3896: Fix Version/s: 1.2.10 > RDBDocumentStore: export tool - improve handling of export files allowing to > override column order > -- > > Key: OAK-3896 > URL: https://issues.apache.org/jira/browse/OAK-3896 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Affects Versions: 1.2.9, 1.0.26, 1.3.14 >Reporter: Julian Reschke >Assignee: Julian Reschke > Fix For: 1.2.10, 1.3.15 > > > For instance, the DB2 "DEL" export format doesn't contain the column titles > and thus relies on the actual query that was used (or on the order of columns > in the database when "SELECT *" was used). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3896) RDBDocumentStore: export tool - improve handling of export files allowing to override column order
[ https://issues.apache.org/jira/browse/OAK-3896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3896: Fix Version/s: 1.3.15 > RDBDocumentStore: export tool - improve handling of export files allowing to > override column order > -- > > Key: OAK-3896 > URL: https://issues.apache.org/jira/browse/OAK-3896 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Affects Versions: 1.2.9, 1.0.26, 1.3.14 >Reporter: Julian Reschke >Assignee: Julian Reschke > Fix For: 1.3.15 > > > For instance, the DB2 "DEL" export format doesn't contain the column titles > and thus relies on the actual query that was used (or on the order of columns > in the database when "SELECT *" was used). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3896) RDBDocumentStore: export tool - improve handling of export files allowing to override column order
[ https://issues.apache.org/jira/browse/OAK-3896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3896: Affects Version/s: 1.2.9 1.0.26 1.3.14 > RDBDocumentStore: export tool - improve handling of export files allowing to > override column order > -- > > Key: OAK-3896 > URL: https://issues.apache.org/jira/browse/OAK-3896 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Affects Versions: 1.2.9, 1.0.26, 1.3.14 >Reporter: Julian Reschke >Assignee: Julian Reschke > > For instance, the DB2 "DEL" export format doesn't contain the column titles > and thus relies on the actual query that was used (or on the order of columns > in the database when "SELECT *" was used). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3883) Avoid commit from too far in the future (due to clock skews) to go through
[ https://issues.apache.org/jira/browse/OAK-3883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-3883: -- Fix Version/s: 1.4 > Avoid commit from too far in the future (due to clock skews) to go through > -- > > Key: OAK-3883 > URL: https://issues.apache.org/jira/browse/OAK-3883 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, documentmk >Reporter: Vikas Saurabh >Assignee: Vikas Saurabh >Priority: Minor > Labels: resilience > Fix For: 1.4 > > > Following up [discussion|http://markmail.org/message/m5jk5nbby77nlqs5] \[0] > to avoid bad commits due to mis-behaving clocks. Points from the discussion: > * We can start self-destrucut mode while updating lease > * Revision creation should check that newly created revision isn't beyond > leaseEnd time > * Implementation done for OAK-2682 might be useful > [0]: http://markmail.org/message/m5jk5nbby77nlqs5 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-1557) Mark documents as deleted
[ https://issues.apache.org/jira/browse/OAK-1557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-1557: -- Fix Version/s: (was: 1.4) > Mark documents as deleted > - > > Key: OAK-1557 > URL: https://issues.apache.org/jira/browse/OAK-1557 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Reporter: Marcel Reutegger > Labels: performance, resilience > > This is an improvement to make a certain use case more efficient. When there > is a parent node with frequently added and removed child nodes, the reading > of the current list of child nodes becomes inefficient because the decision > whether a node exists at a certain revision is done in the DocumentNodeStore > and no filtering is done on the MongoDB side. > So far we figured this would be solved automatically by the MVCC garbage > collection, when documents for deleted nodes are removed. However for > locations in the repository where nodes are added and deleted again > frequently (think of a temp folder), the issue pops up before the GC had a > chance to clean up. > The Document should have an additional field, which is set when the node is > deleted in the most recent revision. Based on this field the > DocumentNodeStore can limit the query to MongoDB to documents that are not > deleted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2779) DocumentNodeStore should provide option to set initial cache size as percentage of MAX VM size
[ https://issues.apache.org/jira/browse/OAK-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-2779: -- Labels: performance (was: performance resilience) > DocumentNodeStore should provide option to set initial cache size as > percentage of MAX VM size > -- > > Key: OAK-2779 > URL: https://issues.apache.org/jira/browse/OAK-2779 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Affects Versions: 1.2 >Reporter: Will McGauley > Labels: performance > > Currently the DocumentNodeStore provides a way to configure various cache > parameters, including cache size and distribution of that size to various > caches. The distribution of caches is done as a % of the total cache size, > which is very helpful, but the overall cache size can only be set as a > literal value. > It would be helpful to achieve a good default value based on the available VM > memory as a %, instead of a literal value. By doing this the cache size > would not need to be set by each customer, and a better initial experience > would be achieved. > I suggest that 25% of the max VM size would be a good starting point. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2622) dynamic cache allocation
[ https://issues.apache.org/jira/browse/OAK-2622?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger updated OAK-2622: -- Labels: performance (was: performance resilience) > dynamic cache allocation > > > Key: OAK-2622 > URL: https://issues.apache.org/jira/browse/OAK-2622 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Affects Versions: 1.0.12 >Reporter: Stefan Egli > Labels: performance > > At the moment mongoMk's various caches are configurable (OAK-2546) but other > than that static in terms of size. Different use-cases might require > different allocations of the sub caches though. And it might not always be > possible to find a good configuration upfront for all use cases. > We might be able to come up with dynamically allocating the overall cache > size to the different sub-caches, based on which cache is how heavily loaded > or how well performing for example. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-2076) Concurrency issues while making users members of same group in clustered env
[
https://issues.apache.org/jira/browse/OAK-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-2076:
--
Labels: concurrency scalability (was: resilience)
Moved to DocumentMK scalability epic.
> Concurrency issues while making users members of same group in clustered env
>
>
> Key: OAK-2076
> URL: https://issues.apache.org/jira/browse/OAK-2076
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: mongomk
>Reporter: Swapnil Sahai
> Labels: concurrency, scalability
>
> While creating users in bulk in a clustered setup, if we also make them
> members of the same group (lets say 'everyone') then many a times it fails
> with Unresolved Conflicts.
> I think this is something that can be handled better and probably a merge can
> be attempted.
> {"changes":[],"error":{"class":"javax.jcr.InvalidItemStateException","message":"OakState0001:
> Unresolved conflicts in
> /home/groups/learncube/failover1/system/learncube-failover1-everyone/rep:membersList/6"},"status.code":500,"status.message":"","referer":""}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-1553) More sophisticated conflict resolution when concurrently adding nodes
[
https://issues.apache.org/jira/browse/OAK-1553?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-1553:
--
Labels: concurrency technical_debt (was: concurrency resilience
scalability)
Moved to technical debt. I don't think this issue affects resilience. The
system is still usable, but concurrency is limited.
> More sophisticated conflict resolution when concurrently adding nodes
> -
>
> Key: OAK-1553
> URL: https://issues.apache.org/jira/browse/OAK-1553
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: core, mongomk, segmentmk
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: concurrency, technical_debt
> Attachments: OAK-1553.patch
>
>
> {{MicroKernel.rebase}} currently specifies: "addExistingNode: A node has been
> added that is different from a node of them same name that has been added to
> the trunk."
> This is somewhat troublesome in the case where the same node with different
> but non conflicting child items is added concurrently:
> {code}
> f.add("fo").add("u1"); commit();
> f.add("fo").add("u2"); commit();
> {code}
> currently fails with a conflict because {{fo}} is not the same node for the
> both cases. See discussion http://markmail.org/message/flst4eiqvbp4gi3z
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3898) Add filter capabilities to the segment graph run mode
[
https://issues.apache.org/jira/browse/OAK-3898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig resolved OAK-3898.
Resolution: Fixed
Fix Version/s: 1.3.15
Fixed at http://svn.apache.org/viewvc?rev=1725552&view=rev
> Add filter capabilities to the segment graph run mode
> -
>
> Key: OAK-3898
> URL: https://issues.apache.org/jira/browse/OAK-3898
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: run
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: tooling
> Fix For: 1.3.15
>
>
> I like to add a filter capability to {{oak-run graph}} to specify the
> inclusion criteria of segments via a regular expression.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3898) Add filter capabilites to the segment graph run mode
Michael Dürig created OAK-3898:
--
Summary: Add filter capabilites to the segment graph run mode
Key: OAK-3898
URL: https://issues.apache.org/jira/browse/OAK-3898
Project: Jackrabbit Oak
Issue Type: Improvement
Components: run
Reporter: Michael Dürig
Assignee: Michael Dürig
I like to add a filter capability to {{oak-run graph}} to specify the inclusion
criteria of segments via a regular expression.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3865) New strategy to optimize secondary reads
[ https://issues.apache.org/jira/browse/OAK-3865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15106885#comment-15106885 ] Marcel Reutegger commented on OAK-3865: --- Sounds very promising. Isn't M1 the RevisionVector of the current root node? It is already updated with ever local commit and when external changes are pulled in from other cluster nodes. bq. Regarding the documents modified by the local Oak instance ... Isn't this already handled automatically with your algorithm? A local change results in an update of M1 and will therefore prevent a read from a secondary until the change arrived there. > New strategy to optimize secondary reads > > > Key: OAK-3865 > URL: https://issues.apache.org/jira/browse/OAK-3865 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: mongomk >Reporter: Tomek Rękawek > Fix For: 1.4 > > Attachments: diagram.png > > > *Introduction* > In the current trunk we'll only read document _D_ from the secondary instance > if: > (1) we have the parent _P_ of document _D_ cached and > (2) the parent hasn't been modified in 6 hours. > The OAK-2106 tried to optimise (2) by estimating lag using MongoDB replica > stats. It was unreliable, so the second approach was to read the last > revisions directly from each Mongo instance. If the modification date of _P_ > is before last revisions on all secondary Mongos, then secondary can be used. > The main problem with this approach is that we still need to have the _P_ to > be in cache. I think we need another way to optimise the secondary reading, > as right now only about 3% of requests connects to the secondary, which is > bad especially for the global-clustering case (Mongo and Oak instances across > the globe). The optimisation provided in OAK-2106 doesn't make the things > much better and may introduce some consistency issues. > *Proposal* > I had following constraints in mind preparing this: > 1. Let's assume we have a sequence of commits with revisions _R1_, _R2_ and > _R3_ modifying nodes _N1_, _N2_ and _N3_. If we already read the _N1_ from > revision _R2_ then reading from a secondary shouldn't result in getting older > revision (eg. _R1_). > 2. If an Oak instance modifies a document, then reading from a secondary > shouldn't result in getting the old version (before modification). > So, let's have two maps: > * _M1_ the most recent document revision read from the Mongo for each cluster > id, > * _M2_ the oldest last rev value for root document for each cluster id read > from all the secondary instances. > Maintaining _M1_: > For every read from the Mongo we'll check if the lastRev for some cluster id > is newer than _M1_ entry. If so, we'll update _M1_. For all writes we'll add > the saved revision id with the current cluster id in _M1_. > Maintaining _M2_: > It should be periodically updated. Such mechanism is already prepared in the > OAK-2106 patch. > The method deciding whether we can read from the secondary instance should > compare two maps. If all entries in _M2_ are newer than _M1_ it means that > the secondary instances contains at least as new repository state as we > already accessed and therefore it's safe to read from secondary. > Regarding the documents modified by the local Oak instance, we should > remember all the locally-modified paths and their revisions and use primary > Mongo to access them as long as the changes are not replicated to all the > secondaries. When the secondaries are up to date with the modification, we > can remove it from the local-changes collections. > Attached image diagram.png presents the idea. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3898) Add filter capabilities to the segment graph run mode
[
https://issues.apache.org/jira/browse/OAK-3898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-3898:
---
Summary: Add filter capabilities to the segment graph run mode (was: Add
filter capabilites to the segment graph run mode)
> Add filter capabilities to the segment graph run mode
> -
>
> Key: OAK-3898
> URL: https://issues.apache.org/jira/browse/OAK-3898
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: run
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: tooling
>
> I like to add a filter capability to {{oak-run graph}} to specify the
> inclusion criteria of segments via a regular expression.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3833) Allow to acquire multiple locks
[
https://issues.apache.org/jira/browse/OAK-3833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomek Rękawek updated OAK-3833:
---
Attachment: (was: OAK-3833.patch)
> Allow to acquire multiple locks
> ---
>
> Key: OAK-3833
> URL: https://issues.apache.org/jira/browse/OAK-3833
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: documentmk
>Reporter: Tomek Rękawek
> Fix For: 1.4
>
> Attachments: OAK-3833.patch
>
>
> The {{NodeDocumentLocks}} type should be extended with a new method that
> allows to acquire multiple locks. Locks should be always ordered in the same
> way to avoid deadlocks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3559) Bulk document updates in MongoDocumentStore
[ https://issues.apache.org/jira/browse/OAK-3559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15106860#comment-15106860 ] Tomek Rękawek commented on OAK-3559: [~mreutegg], do you have any other suggestions? > Bulk document updates in MongoDocumentStore > --- > > Key: OAK-3559 > URL: https://issues.apache.org/jira/browse/OAK-3559 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: mongomk >Reporter: Tomek Rękawek >Assignee: Marcel Reutegger > Fix For: 1.4 > > Attachments: OAK-3559.patch > > > Using the MongoDB [Bulk > API|https://docs.mongodb.org/manual/reference/method/Bulk/#Bulk] implement > the [batch version of createOrUpdate method|OAK-3662]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3833) Allow to acquire multiple locks
[
https://issues.apache.org/jira/browse/OAK-3833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tomek Rękawek updated OAK-3833:
---
Attachment: OAK-3833.patch
> Allow to acquire multiple locks
> ---
>
> Key: OAK-3833
> URL: https://issues.apache.org/jira/browse/OAK-3833
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: documentmk
>Reporter: Tomek Rękawek
> Fix For: 1.4
>
> Attachments: OAK-3833.patch, OAK-3833.patch
>
>
> The {{NodeDocumentLocks}} type should be extended with a new method that
> allows to acquire multiple locks. Locks should be always ordered in the same
> way to avoid deadlocks.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3897) Branch reset does not revert all changes
[ https://issues.apache.org/jira/browse/OAK-3897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15106840#comment-15106840 ] Marcel Reutegger commented on OAK-3897: --- Added ignored tests to trunk: http://svn.apache.org/r1725541 > Branch reset does not revert all changes > > > Key: OAK-3897 > URL: https://issues.apache.org/jira/browse/OAK-3897 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, documentmk >Affects Versions: 1.3.14 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Fix For: 1.4 > > > This is caused by recent changes done for OAK-3646. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3897) Branch reset does not revert all changes
[ https://issues.apache.org/jira/browse/OAK-3897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marcel Reutegger resolved OAK-3897. --- Resolution: Fixed Fix Version/s: (was: 1.4) 1.3.15 Fixed in trunk: http://svn.apache.org/r1725542 > Branch reset does not revert all changes > > > Key: OAK-3897 > URL: https://issues.apache.org/jira/browse/OAK-3897 > Project: Jackrabbit Oak > Issue Type: Bug > Components: core, documentmk >Affects Versions: 1.3.14 >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Fix For: 1.3.15 > > > This is caused by recent changes done for OAK-3646. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3865) New strategy to optimize secondary reads
[
https://issues.apache.org/jira/browse/OAK-3865?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15106837#comment-15106837
]
Tomek Rękawek commented on OAK-3865:
[~chetanm], thanks for the feedback. I came to this 3% by running the CMS in a
global clustering setup (two AWS regions). It hadn't run for more than 6 hours.
During the test I was trying to create and edit a page.
Obviously it wasn't very strict. I'll try to produce more meaningful results
comparing the current SNAPSHOT and this improvement. The OAK-3791 will
certainly make it easier to measure (no more grepping logs for
{{isSlaveOk=true}}).
> New strategy to optimize secondary reads
>
>
> Key: OAK-3865
> URL: https://issues.apache.org/jira/browse/OAK-3865
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: mongomk
>Reporter: Tomek Rękawek
> Fix For: 1.4
>
> Attachments: diagram.png
>
>
> *Introduction*
> In the current trunk we'll only read document _D_ from the secondary instance
> if:
> (1) we have the parent _P_ of document _D_ cached and
> (2) the parent hasn't been modified in 6 hours.
> The OAK-2106 tried to optimise (2) by estimating lag using MongoDB replica
> stats. It was unreliable, so the second approach was to read the last
> revisions directly from each Mongo instance. If the modification date of _P_
> is before last revisions on all secondary Mongos, then secondary can be used.
> The main problem with this approach is that we still need to have the _P_ to
> be in cache. I think we need another way to optimise the secondary reading,
> as right now only about 3% of requests connects to the secondary, which is
> bad especially for the global-clustering case (Mongo and Oak instances across
> the globe). The optimisation provided in OAK-2106 doesn't make the things
> much better and may introduce some consistency issues.
> *Proposal*
> I had following constraints in mind preparing this:
> 1. Let's assume we have a sequence of commits with revisions _R1_, _R2_ and
> _R3_ modifying nodes _N1_, _N2_ and _N3_. If we already read the _N1_ from
> revision _R2_ then reading from a secondary shouldn't result in getting older
> revision (eg. _R1_).
> 2. If an Oak instance modifies a document, then reading from a secondary
> shouldn't result in getting the old version (before modification).
> So, let's have two maps:
> * _M1_ the most recent document revision read from the Mongo for each cluster
> id,
> * _M2_ the oldest last rev value for root document for each cluster id read
> from all the secondary instances.
> Maintaining _M1_:
> For every read from the Mongo we'll check if the lastRev for some cluster id
> is newer than _M1_ entry. If so, we'll update _M1_. For all writes we'll add
> the saved revision id with the current cluster id in _M1_.
> Maintaining _M2_:
> It should be periodically updated. Such mechanism is already prepared in the
> OAK-2106 patch.
> The method deciding whether we can read from the secondary instance should
> compare two maps. If all entries in _M2_ are newer than _M1_ it means that
> the secondary instances contains at least as new repository state as we
> already accessed and therefore it's safe to read from secondary.
> Regarding the documents modified by the local Oak instance, we should
> remember all the locally-modified paths and their revisions and use primary
> Mongo to access them as long as the changes are not replicated to all the
> secondaries. When the secondaries are up to date with the modification, we
> can remove it from the local-changes collections.
> Attached image diagram.png presents the idea.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3897) Branch reset does not revert all changes
Marcel Reutegger created OAK-3897: - Summary: Branch reset does not revert all changes Key: OAK-3897 URL: https://issues.apache.org/jira/browse/OAK-3897 Project: Jackrabbit Oak Issue Type: Bug Components: core, documentmk Affects Versions: 1.3.14 Reporter: Marcel Reutegger Assignee: Marcel Reutegger Fix For: 1.4 This is caused by recent changes done for OAK-3646. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3895) Expose jmx to invalidate cache entries
[
https://issues.apache.org/jira/browse/OAK-3895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15106805#comment-15106805
]
Vikas Saurabh commented on OAK-3895:
Attaching documentmk label for now. I'm not sure if there are some cache around
segment too? Also, I was thinking for wiring this up the same way we get
consolidated cache stats - so, one impl would call up all registered
implementations (the only other one I know of is
{{MongoDocumentStore#nodesCache}}).
[~mreutegg], [~chetanm], thoughts?
> Expose jmx to invalidate cache entries
> --
>
> Key: OAK-3895
> URL: https://issues.apache.org/jira/browse/OAK-3895
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk
>Reporter: Vikas Saurabh
>Assignee: Vikas Saurabh
>Priority: Minor
>
> We have had some issues (e.g. OAK-3634) which put incorrect entry in the some
> cache. Currently, the only way to clean cache is to restart the instance (and
> remove persistent cache files if configured).
> So, it might be useful to expose some jmx to invalidate cache without
> restarting the instance. As a first step, I think we can clean all caches
> (which is equivalent to current setup but without restart). We can later
> expose invalidation methods for specific cases (say, {{cacheType, path, rev}}
> as applicable).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3895) Expose jmx to invalidate cache entries
Vikas Saurabh created OAK-3895:
--
Summary: Expose jmx to invalidate cache entries
Key: OAK-3895
URL: https://issues.apache.org/jira/browse/OAK-3895
Project: Jackrabbit Oak
Issue Type: Improvement
Components: documentmk
Reporter: Vikas Saurabh
Assignee: Vikas Saurabh
Priority: Minor
We have had some issues (e.g. OAK-3634) which put incorrect entry in the some
cache. Currently, the only way to clean cache is to restart the instance (and
remove persistent cache files if configured).
So, it might be useful to expose some jmx to invalidate cache without
restarting the instance. As a first step, I think we can clean all caches
(which is equivalent to current setup but without restart). We can later expose
invalidation methods for specific cases (say, {{cacheType, path, rev}} as
applicable).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (OAK-3896) RDBDocumentStore: export tool - improve handling of export files allowing to override column order
Julian Reschke created OAK-3896: --- Summary: RDBDocumentStore: export tool - improve handling of export files allowing to override column order Key: OAK-3896 URL: https://issues.apache.org/jira/browse/OAK-3896 Project: Jackrabbit Oak Issue Type: Technical task Components: rdbmk Reporter: Julian Reschke Assignee: Julian Reschke For instance, the DB2 "DEL" export format doesn't contain the column titles and thus relies on the actual query that was used (or on the order of columns in the database when "SELECT *" was used). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3892) RDBDocumentStore: StripedNodeDocumentLocks - special case root?
[
https://issues.apache.org/jira/browse/OAK-3892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke resolved OAK-3892.
-
Resolution: Fixed
trunk: http://svn.apache.org/r1725515
> RDBDocumentStore: StripedNodeDocumentLocks - special case root?
> ---
>
> Key: OAK-3892
> URL: https://issues.apache.org/jira/browse/OAK-3892
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Affects Versions: 1.3.14
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_0, candidate_oak_1_2
> Fix For: 1.3.15
>
> Attachments: stripes.diff
>
>
> {{StripedNodeDocumentLocks}} currently handles all document IDs the same way.
> I assume that we see a lot of updates on {{0:/}}, though. These updates would
> be blocked if another different ID fell into the same lock stripe (and was
> being updated).
> We currently have 4096, so the likelihood isn't that big; on the other hand,
> a change doesn't seem to be risky.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3892) RDBDocumentStore: StripedNodeDocumentLocks - special case root?
[
https://issues.apache.org/jira/browse/OAK-3892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-3892:
Fix Version/s: 1.3.15
> RDBDocumentStore: StripedNodeDocumentLocks - special case root?
> ---
>
> Key: OAK-3892
> URL: https://issues.apache.org/jira/browse/OAK-3892
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Affects Versions: 1.3.14
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_0, candidate_oak_1_2
> Fix For: 1.3.15
>
> Attachments: stripes.diff
>
>
> {{StripedNodeDocumentLocks}} currently handles all document IDs the same way.
> I assume that we see a lot of updates on {{0:/}}, though. These updates would
> be blocked if another different ID fell into the same lock stripe (and was
> being updated).
> We currently have 4096, so the likelihood isn't that big; on the other hand,
> a change doesn't seem to be risky.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3892) RDBDocumentStore: StripedNodeDocumentLocks - special case root?
[
https://issues.apache.org/jira/browse/OAK-3892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-3892:
Labels: candidate_oak_1_0 candidate_oak_1_2 (was: )
> RDBDocumentStore: StripedNodeDocumentLocks - special case root?
> ---
>
> Key: OAK-3892
> URL: https://issues.apache.org/jira/browse/OAK-3892
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Affects Versions: 1.3.14
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_0, candidate_oak_1_2
> Attachments: stripes.diff
>
>
> {{StripedNodeDocumentLocks}} currently handles all document IDs the same way.
> I assume that we see a lot of updates on {{0:/}}, though. These updates would
> be blocked if another different ID fell into the same lock stripe (and was
> being updated).
> We currently have 4096, so the likelihood isn't that big; on the other hand,
> a change doesn't seem to be risky.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3892) RDBDocumentStore: StripedNodeDocumentLocks - special case root?
[
https://issues.apache.org/jira/browse/OAK-3892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-3892:
Affects Version/s: 1.3.14
> RDBDocumentStore: StripedNodeDocumentLocks - special case root?
> ---
>
> Key: OAK-3892
> URL: https://issues.apache.org/jira/browse/OAK-3892
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Affects Versions: 1.3.14
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_0, candidate_oak_1_2
> Attachments: stripes.diff
>
>
> {{StripedNodeDocumentLocks}} currently handles all document IDs the same way.
> I assume that we see a lot of updates on {{0:/}}, though. These updates would
> be blocked if another different ID fell into the same lock stripe (and was
> being updated).
> We currently have 4096, so the likelihood isn't that big; on the other hand,
> a change doesn't seem to be risky.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (OAK-3651) Remove HierarchialCacheInvalidator
[ https://issues.apache.org/jira/browse/OAK-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15106691#comment-15106691 ] Julian Reschke edited comment on OAK-3651 at 1/19/16 1:17 PM: -- Proposed patch for 1.2 (reducing unnecessary differences to trunk) [~chetanm]: can you please check? was (Author: reschke): Proposed patch for 1.2 (reducing unnecessary differences to trunk) > Remove HierarchialCacheInvalidator > -- > > Key: OAK-3651 > URL: https://issues.apache.org/jira/browse/OAK-3651 > Project: Jackrabbit Oak > Issue Type: Task > Components: mongomk >Affects Versions: 1.3.10, 1.2.9 >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Labels: candidate_oak_1_0, candidate_oak_1_2, technical_debt > Fix For: 1.3.11 > > Attachments: OAK-3651-for-1.2.diff > > > As discussed in OAK-2187 and due to changes done in OAK-3002 > HierrachialCacheInvalidator is now redundant and should be removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3651) Remove HierarchialCacheInvalidator
[ https://issues.apache.org/jira/browse/OAK-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3651: Attachment: OAK-3651-for-1.2.diff Proposed patch for 1.2 (reducing unnecessary differences to trunk) > Remove HierarchialCacheInvalidator > -- > > Key: OAK-3651 > URL: https://issues.apache.org/jira/browse/OAK-3651 > Project: Jackrabbit Oak > Issue Type: Task > Components: mongomk >Affects Versions: 1.3.10, 1.2.9 >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Labels: candidate_oak_1_0, candidate_oak_1_2, technical_debt > Fix For: 1.3.11 > > Attachments: OAK-3651-for-1.2.diff > > > As discussed in OAK-2187 and due to changes done in OAK-3002 > HierrachialCacheInvalidator is now redundant and should be removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3651) Remove HierarchialCacheInvalidator
[ https://issues.apache.org/jira/browse/OAK-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3651: Labels: candidate_oak_1_0 candidate_oak_1_2 technical_debt (was: considerFor1.2 technical_debt) > Remove HierarchialCacheInvalidator > -- > > Key: OAK-3651 > URL: https://issues.apache.org/jira/browse/OAK-3651 > Project: Jackrabbit Oak > Issue Type: Task > Components: mongomk >Affects Versions: 1.3.10, 1.2.9 >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Labels: candidate_oak_1_0, candidate_oak_1_2, technical_debt > Fix For: 1.3.11 > > > As discussed in OAK-2187 and due to changes done in OAK-3002 > HierrachialCacheInvalidator is now redundant and should be removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3651) Remove HierarchialCacheInvalidator
[ https://issues.apache.org/jira/browse/OAK-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3651: Affects Version/s: 1.3.10 1.2.9 > Remove HierarchialCacheInvalidator > -- > > Key: OAK-3651 > URL: https://issues.apache.org/jira/browse/OAK-3651 > Project: Jackrabbit Oak > Issue Type: Task > Components: mongomk >Affects Versions: 1.3.10, 1.2.9 >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Labels: considerFor1.2, technical_debt > Fix For: 1.3.11 > > > As discussed in OAK-2187 and due to changes done in OAK-3002 > HierrachialCacheInvalidator is now redundant and should be removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3651) Remove HierarchialCacheInvalidator
[ https://issues.apache.org/jira/browse/OAK-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3651: Labels: considerFor1.2 technical_debt (was: technical_debt) > Remove HierarchialCacheInvalidator > -- > > Key: OAK-3651 > URL: https://issues.apache.org/jira/browse/OAK-3651 > Project: Jackrabbit Oak > Issue Type: Task > Components: mongomk >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Labels: considerFor1.2, technical_debt > Fix For: 1.3.11 > > > As discussed in OAK-2187 and due to changes done in OAK-3002 > HierrachialCacheInvalidator is now redundant and should be removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3651) Remove HierarchialCacheInvalidator
[ https://issues.apache.org/jira/browse/OAK-3651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3651: Summary: Remove HierarchialCacheInvalidator (was: Remove HierrachialCacheInvalidator) > Remove HierarchialCacheInvalidator > -- > > Key: OAK-3651 > URL: https://issues.apache.org/jira/browse/OAK-3651 > Project: Jackrabbit Oak > Issue Type: Task > Components: mongomk >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra >Priority: Minor > Labels: technical_debt > Fix For: 1.3.11 > > > As discussed in OAK-2187 and due to changes done in OAK-3002 > HierrachialCacheInvalidator is now redundant and should be removed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (OAK-3572) enhance logging in TypeEditorProvider
[ https://issues.apache.org/jira/browse/OAK-3572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke resolved OAK-3572. - Resolution: Fixed trunk: http://svn.apache.org/r1725477 1.2: http://svn.apache.org/r1725492 > enhance logging in TypeEditorProvider > - > > Key: OAK-3572 > URL: https://issues.apache.org/jira/browse/OAK-3572 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Affects Versions: 1.2.9, 1.3.14 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.2.10, 1.3.15 > > > The repo scan that is done for non "trivial" node type changes can be > expensive. The code currently logs when it's done, it would be good if it > also logged something (INFO as well?) when it's starting the scan. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3572) enhance logging in TypeEditorProvider
[ https://issues.apache.org/jira/browse/OAK-3572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3572: Affects Version/s: (was: 1.0.26) > enhance logging in TypeEditorProvider > - > > Key: OAK-3572 > URL: https://issues.apache.org/jira/browse/OAK-3572 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Affects Versions: 1.2.9, 1.3.14 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.2.10, 1.3.15 > > > The repo scan that is done for non "trivial" node type changes can be > expensive. The code currently logs when it's done, it would be good if it > also logged something (INFO as well?) when it's starting the scan. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3572) enhance logging in TypeEditorProvider
[ https://issues.apache.org/jira/browse/OAK-3572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3572: Affects Version/s: (was: 1.2.10) 1.2.9 > enhance logging in TypeEditorProvider > - > > Key: OAK-3572 > URL: https://issues.apache.org/jira/browse/OAK-3572 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Affects Versions: 1.2.9, 1.0.26, 1.3.14 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.2.10, 1.3.15 > > > The repo scan that is done for non "trivial" node type changes can be > expensive. The code currently logs when it's done, it would be good if it > also logged something (INFO as well?) when it's starting the scan. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3572) enhance logging in TypeEditorProvider
[ https://issues.apache.org/jira/browse/OAK-3572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3572: Fix Version/s: 1.2.10 > enhance logging in TypeEditorProvider > - > > Key: OAK-3572 > URL: https://issues.apache.org/jira/browse/OAK-3572 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Affects Versions: 1.2.9, 1.0.26, 1.3.14 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.2.10, 1.3.15 > > > The repo scan that is done for non "trivial" node type changes can be > expensive. The code currently logs when it's done, it would be good if it > also logged something (INFO as well?) when it's starting the scan. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3572) enhance logging in TypeEditorProvider
[ https://issues.apache.org/jira/browse/OAK-3572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3572: Fix Version/s: 1.3.15 > enhance logging in TypeEditorProvider > - > > Key: OAK-3572 > URL: https://issues.apache.org/jira/browse/OAK-3572 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Affects Versions: 1.0.26, 1.2.10, 1.3.14 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > Fix For: 1.3.15 > > > The repo scan that is done for non "trivial" node type changes can be > expensive. The code currently logs when it's done, it would be good if it > also logged something (INFO as well?) when it's starting the scan. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3894) Atomic counter documentation
[ https://issues.apache.org/jira/browse/OAK-3894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Davide Giannella updated OAK-3894: -- Fix Version/s: 1.4 > Atomic counter documentation > > > Key: OAK-3894 > URL: https://issues.apache.org/jira/browse/OAK-3894 > Project: Jackrabbit Oak > Issue Type: Documentation > Components: doc >Affects Versions: 1.3.14 >Reporter: Davide Giannella >Assignee: Davide Giannella > Fix For: 1.4 > > > Provide documentation around the usage of the atomic counter from an end user > point of view -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (OAK-3894) Atomic counter documentation
Davide Giannella created OAK-3894: - Summary: Atomic counter documentation Key: OAK-3894 URL: https://issues.apache.org/jira/browse/OAK-3894 Project: Jackrabbit Oak Issue Type: Documentation Components: doc Affects Versions: 1.3.14 Reporter: Davide Giannella Assignee: Davide Giannella Provide documentation around the usage of the atomic counter from an end user point of view -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3572) enhance logging in TypeEditorProvider
[ https://issues.apache.org/jira/browse/OAK-3572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-3572: Affects Version/s: 1.2.10 1.0.26 1.3.14 > enhance logging in TypeEditorProvider > - > > Key: OAK-3572 > URL: https://issues.apache.org/jira/browse/OAK-3572 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Affects Versions: 1.0.26, 1.2.10, 1.3.14 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > > The repo scan that is done for non "trivial" node type changes can be > expensive. The code currently logs when it's done, it would be good if it > also logged something (INFO as well?) when it's starting the scan. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (OAK-3572) enhance logging in TypeEditorProvider
[ https://issues.apache.org/jira/browse/OAK-3572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke reassigned OAK-3572: --- Assignee: Julian Reschke > enhance logging in TypeEditorProvider > - > > Key: OAK-3572 > URL: https://issues.apache.org/jira/browse/OAK-3572 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > > The repo scan that is done for non "trivial" node type changes can be > expensive. The code currently logs when it's done, it would be good if it > also logged something (INFO as well?) when it's starting the scan. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3134) Identify functionality offered by oak-run
[ https://issues.apache.org/jira/browse/OAK-3134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-3134: --- Epic Name: Split oak-run along functionalities > Identify functionality offered by oak-run > - > > Key: OAK-3134 > URL: https://issues.apache.org/jira/browse/OAK-3134 > Project: Jackrabbit Oak > Issue Type: Epic > Components: run >Reporter: Davide Giannella >Assignee: Davide Giannella > > oak-run reached the size of 50MB+ and offers indeed various functionalities > that could be moved to their own module. > This ticket is about to identify what oak-run currently offers and what/if > could be split. > ML thread: http://markmail.org/thread/w34bphrk57l7pkaz > || Functionality || Package || Module || > | micro-benchmark | org.apache.jackrabbit.oak.benchmark |oak-development | > | scalability benchmark | org.apache.jackrabbit.oak.scalability | > oak-development| > | Groovy console | org.apache.jackrabbit.oak.console, > /oak-run/src/main/groovy/org/apache/jackrabbit/oak/console | oak-operations| > | Backup | | oak-operations| > | Restore | | oak-operations| > | Debug | | oak-operations| > | Check | | oak-operations| > | Compact | | oak-operations| > | Server | | oak-development| > | Upgrade | | oak-upgrade| > | Explore | |oak-development | > | Primary | | oak-development| > | Standby | | oak-development| > | Help | | | > | Checkpoints | | oak-operations| > | Recovery | | oak-operations| > | Repair | | oak-operations| > | Tika | | | > Modules left after the actions: > **oak-development** > Used to group and execute all the tools used during development. > _deployed to maven:_ No. > **oak-operations** > Used to group and execute all the tools used normally in production > environment for tasks like maintenance & C. > _deployed to maven:_ Yes. > **oak-run** > Will group what's left after the split. > _deployed to maven:_ No. > **oak-upgrade** > Will group tools for upgrading/migrating from one repo/version to another > _deployed to maven:_ yes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-2382) Move NodeStore implementations to separate modules
[ https://issues.apache.org/jira/browse/OAK-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15106577#comment-15106577 ] Michael Dürig commented on OAK-2382: This is duplicated by OAK-3744 for the segment node store. > Move NodeStore implementations to separate modules > -- > > Key: OAK-2382 > URL: https://issues.apache.org/jira/browse/OAK-2382 > Project: Jackrabbit Oak > Issue Type: Sub-task > Components: core, segmentmk >Reporter: angela > Labels: modularization, technical_debt > Fix For: 1.4 > > > as discussed in the oak-call yesterday, i think we should take another look > at the modularization of the oak-core module. > some time ago i proposed to move the NodeStore implementations into separate > modules. > to begin with i just tried 2 separate modules: > - oak-ns-document: > everything below oak.plugins.document > - oak-ns-segment: > everything below oak.plugins.segment > segment specific > parts of oak.plugins.backup > i found the following issues: > - org.apache.jackrabbit.oak.plugins.cache is not part of the exported > packages - oak.plugins.backup contains both public API and implementations > without separation - the following test-classes have a hard dependency on one > or more ns implementations: > KernelNodeStoreCacheTest > > ClusterPermissionsTest > NodeStoreFixture to fix those we could need to be > able to run the tests with the individual nodestore modules and move those > tests that are just intended to work with a particular impl. > such a move would not only prevent us from introducing unintended package > dependencies but would also reduce the number of dependencies present with > oak-core. > as discussed yesterday we may want to pick this up again this year. > see also http://markmail.org/message/6cpbyuthub4jxase for the whole > discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3744) Move the Segment Store into its own bundle
[ https://issues.apache.org/jira/browse/OAK-3744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Dürig updated OAK-3744: --- Labels: modularization technical_debt (was: ) > Move the Segment Store into its own bundle > -- > > Key: OAK-3744 > URL: https://issues.apache.org/jira/browse/OAK-3744 > Project: Jackrabbit Oak > Issue Type: Epic > Components: segmentmk >Affects Versions: 1.4 >Reporter: Francesco Mari >Assignee: Francesco Mari > Labels: modularization, technical_debt > > This epic tracks the work done to move the Segment Store into an independent > bundle, detached from oak-core. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3862) Move integration tests in a different Maven module
[
https://issues.apache.org/jira/browse/OAK-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-3862:
---
Labels: modularization technical_debt (was: )
> Move integration tests in a different Maven module
> --
>
> Key: OAK-3862
> URL: https://issues.apache.org/jira/browse/OAK-3862
> Project: Jackrabbit Oak
> Issue Type: Improvement
>Reporter: Francesco Mari
>Assignee: Francesco Mari
> Labels: modularization, technical_debt
> Fix For: 1.4
>
>
> While moving the Segment Store and related packages into its own bundle, I
> figured out that integration tests contained in {{oak-core}} contribute to a
> cyclic dependency between the (new) {{oak-segment}} bundle and {{oak-core}}.
> The dependency is due to the usage of {{NodeStoreFixture}} to instantiate
> different implementations of {{NodeStore}} in a semi-transparent way.
> Tests depending on {{NodeStoreFixture}} are most likely integration tests. A
> clean solution to this problem would be to move those integration tests into
> a new Maven module, referencing the API and implementation modules as needed.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3126) Enable HybridMapFactory by default
[ https://issues.apache.org/jira/browse/OAK-3126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Jäggi updated OAK-3126: - Fix Version/s: (was: 1.0.26) 1.0.27 > Enable HybridMapFactory by default > -- > > Key: OAK-3126 > URL: https://issues.apache.org/jira/browse/OAK-3126 > Project: Jackrabbit Oak > Issue Type: Improvement > Components: core, mongomk >Reporter: Marcel Reutegger >Assignee: Marcel Reutegger > Fix For: 1.0.27 > > > This is a follow up issue of OAK-3112. The HybridMapFactory should be enabled > by default once it has proven to be stable. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3613) Backport TarMK revision gc related issues
[ https://issues.apache.org/jira/browse/OAK-3613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dominique Jäggi updated OAK-3613: - Fix Version/s: (was: 1.0.26) 1.0.27 > Backport TarMK revision gc related issues > - > > Key: OAK-3613 > URL: https://issues.apache.org/jira/browse/OAK-3613 > Project: Jackrabbit Oak > Issue Type: Task > Components: segmentmk >Reporter: Michael Dürig >Assignee: Michael Dürig > Labels: compaction, gc > Fix For: 1.2.10, 1.0.27 > > Attachments: > 0001-OAK-2870-Introduce-a-SegmentNodeStoreBuilder-to-help.patch, > 1.2-OAK-2870.patch, OAK-1995-1.0.patch, OAK-1995-1.2.zip, OsgiUtil-1.0.patch, > OsgiUtil-1.2.patch > > > Some of the issues related to TarMK revision gc should be back ported to the > branches. This issue is for keeping track of which issues and which svn > revisions we consider for back porting. The task consists of the following > steps: > # Identify issue to back port > # Merge the respective commits into a private forks of the 1.0 and 1.2 > branches > # Run tests on builds from the private forks > # On success merge the private forks to the 1.0 and 1.2 branches and update > the fix versions of the respective issues. > * Update the svn merge info with the respective merged svn revisions. > * Update the fix versions of the affected issues. > [~dhasler]: FYI > [~alex.parvulescu], [~frm]: please refrain from merging potential conflicting > changes into the branches in the meanwhile. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (OAK-3854) TarMK tools should check whether they run against a matching version of the repository
[
https://issues.apache.org/jira/browse/OAK-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-3854:
---
Priority: Critical (was: Major)
> TarMK tools should check whether they run against a matching version of the
> repository
> --
>
> Key: OAK-3854
> URL: https://issues.apache.org/jira/browse/OAK-3854
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: run
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Critical
> Labels: resilience, tooling
> Fix For: 1.4
>
>
> Running tools that write into a segment store might result in unwanted
> upgrading if the version of the tool uses a more recent segment version than
> the store. E.g. off line compaction currently upgrades segment format 10 to
> 11.
> To protected against inadvertent upgrades, a tool should check whether the
> segment version of the store matches its expectation (currently 11). If not,
> the tool should exit with a respective warning / error. For some tools it can
> make sense to provide a flag (e.g. {{--force}}) to override this. With this
> e.g. offline compaction can still be used for upgrading a segment store if
> explicitly told to do so.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3854) TarMK tools should check whether they run against a matching version of the repository
[
https://issues.apache.org/jira/browse/OAK-3854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Dürig updated OAK-3854:
---
Fix Version/s: 1.4
> TarMK tools should check whether they run against a matching version of the
> repository
> --
>
> Key: OAK-3854
> URL: https://issues.apache.org/jira/browse/OAK-3854
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: run
>Reporter: Michael Dürig
>Assignee: Michael Dürig
> Labels: resilience, tooling
> Fix For: 1.4
>
>
> Running tools that write into a segment store might result in unwanted
> upgrading if the version of the tool uses a more recent segment version than
> the store. E.g. off line compaction currently upgrades segment format 10 to
> 11.
> To protected against inadvertent upgrades, a tool should check whether the
> segment version of the store matches its expectation (currently 11). If not,
> the tool should exit with a respective warning / error. For some tools it can
> make sense to provide a flag (e.g. {{--force}}) to override this. With this
> e.g. offline compaction can still be used for upgrading a segment store if
> explicitly told to do so.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3842) Adjust package export declarations
[ https://issues.apache.org/jira/browse/OAK-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15106539#comment-15106539 ] Michael Dürig commented on OAK-3842: Yes I think so. We are not removing the export, just the export version declaration. > Adjust package export declarations > --- > > Key: OAK-3842 > URL: https://issues.apache.org/jira/browse/OAK-3842 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Michael Dürig >Assignee: Michael Dürig >Priority: Blocker > Labels: api, modularization, technical_debt > Fix For: 1.4 > > > We need to adjust the package export declarations such that they become > manageable with our branch / release model. > See http://markmail.org/thread/5g3viq5pwtdryapr for discussion. > I propose to remove package export declarations from all packages that we > don't consider public API / SPI beyond Oak itself. This would allow us to > evolve Oak internal stuff (e.g. things used across Oak modules) freely > without having to worry about merges to branches messing up semantic > versioning. OTOH it would force us to keep externally facing public API / SPI > reasonably stable also across the branches. Furthermore such an approach > would send the right signal to Oak API / SPI consumers regarding the > stability assumptions they can make. > An external API / SPI having a (transitive) dependency on internals might be > troublesome. In doubt I would remove the export version here until we can > make reasonable guarantees (either through decoupling the code or stabilising > the dependencies). > I would start digging through the export version and prepare an initial > proposal for further discussion. > /cc [~frm], [~chetanm], [~mmarth] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3842) Adjust package export declarations
[ https://issues.apache.org/jira/browse/OAK-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15106515#comment-15106515 ] Alex Parvulescu commented on OAK-3842: -- bq. Just spoke to Thomas Mueller. He suggests to remove all package export declarations for o.a.j.o.plugins.index and sub-packages. Will OAK-3366 still work after this change? the proposed fix was to add a hard reference to a specific type of _ IndexEditorProvider_, which we did [0], so there are OSGi services that depend on this package. [0] https://github.com/apache/jackrabbit-oak/blob/trunk/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/osgi/RepositoryManager.java#L61 > Adjust package export declarations > --- > > Key: OAK-3842 > URL: https://issues.apache.org/jira/browse/OAK-3842 > Project: Jackrabbit Oak > Issue Type: Task >Reporter: Michael Dürig >Assignee: Michael Dürig >Priority: Blocker > Labels: api, modularization, technical_debt > Fix For: 1.4 > > > We need to adjust the package export declarations such that they become > manageable with our branch / release model. > See http://markmail.org/thread/5g3viq5pwtdryapr for discussion. > I propose to remove package export declarations from all packages that we > don't consider public API / SPI beyond Oak itself. This would allow us to > evolve Oak internal stuff (e.g. things used across Oak modules) freely > without having to worry about merges to branches messing up semantic > versioning. OTOH it would force us to keep externally facing public API / SPI > reasonably stable also across the branches. Furthermore such an approach > would send the right signal to Oak API / SPI consumers regarding the > stability assumptions they can make. > An external API / SPI having a (transitive) dependency on internals might be > troublesome. In doubt I would remove the export version here until we can > make reasonable guarantees (either through decoupling the code or stabilising > the dependencies). > I would start digging through the export version and prepare an initial > proposal for further discussion. > /cc [~frm], [~chetanm], [~mmarth] -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (OAK-3842) Adjust package export declarations
[
https://issues.apache.org/jira/browse/OAK-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15106499#comment-15106499
]
Michael Dürig commented on OAK-3842:
Just spoke to [~tmueller]. He suggests to remove all package export
declarations for {{o.a.j.o.plugins.index}} and sub-packages.
> Adjust package export declarations
> ---
>
> Key: OAK-3842
> URL: https://issues.apache.org/jira/browse/OAK-3842
> Project: Jackrabbit Oak
> Issue Type: Task
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Blocker
> Labels: api, modularization, technical_debt
> Fix For: 1.4
>
>
> We need to adjust the package export declarations such that they become
> manageable with our branch / release model.
> See http://markmail.org/thread/5g3viq5pwtdryapr for discussion.
> I propose to remove package export declarations from all packages that we
> don't consider public API / SPI beyond Oak itself. This would allow us to
> evolve Oak internal stuff (e.g. things used across Oak modules) freely
> without having to worry about merges to branches messing up semantic
> versioning. OTOH it would force us to keep externally facing public API / SPI
> reasonably stable also across the branches. Furthermore such an approach
> would send the right signal to Oak API / SPI consumers regarding the
> stability assumptions they can make.
> An external API / SPI having a (transitive) dependency on internals might be
> troublesome. In doubt I would remove the export version here until we can
> make reasonable guarantees (either through decoupling the code or stabilising
> the dependencies).
> I would start digging through the export version and prepare an initial
> proposal for further discussion.
> /cc [~frm], [~chetanm], [~mmarth]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3842) Adjust package export declarations
[
https://issues.apache.org/jira/browse/OAK-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15106484#comment-15106484
]
Michael Dürig commented on OAK-3842:
I suggest we remove the package export declaration for {{lucene.util}} for now
and re-introduce it when sorted out. This might induce some upstream pain but I
figure less then having to bump the export version all the time.
> Adjust package export declarations
> ---
>
> Key: OAK-3842
> URL: https://issues.apache.org/jira/browse/OAK-3842
> Project: Jackrabbit Oak
> Issue Type: Task
>Reporter: Michael Dürig
>Assignee: Michael Dürig
>Priority: Blocker
> Labels: api, modularization, technical_debt
> Fix For: 1.4
>
>
> We need to adjust the package export declarations such that they become
> manageable with our branch / release model.
> See http://markmail.org/thread/5g3viq5pwtdryapr for discussion.
> I propose to remove package export declarations from all packages that we
> don't consider public API / SPI beyond Oak itself. This would allow us to
> evolve Oak internal stuff (e.g. things used across Oak modules) freely
> without having to worry about merges to branches messing up semantic
> versioning. OTOH it would force us to keep externally facing public API / SPI
> reasonably stable also across the branches. Furthermore such an approach
> would send the right signal to Oak API / SPI consumers regarding the
> stability assumptions they can make.
> An external API / SPI having a (transitive) dependency on internals might be
> troublesome. In doubt I would remove the export version here until we can
> make reasonable guarantees (either through decoupling the code or stabilising
> the dependencies).
> I would start digging through the export version and prepare an initial
> proposal for further discussion.
> /cc [~frm], [~chetanm], [~mmarth]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (OAK-3881) TCPBroadcaster causes shutdown delay
[
https://issues.apache.org/jira/browse/OAK-3881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger resolved OAK-3881.
---
Resolution: Fixed
Fix Version/s: (was: 1.4)
1.3.15
Applied patch (without the unintended change to ConcurrentAddNodesClusterIT) to
trunk: http://svn.apache.org/r1725448
> TCPBroadcaster causes shutdown delay
>
>
> Key: OAK-3881
> URL: https://issues.apache.org/jira/browse/OAK-3881
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, documentmk
>Affects Versions: 1.3.14
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.3.15
>
> Attachments: OAK-3881.patch
>
>
> OAK-3727 enabled the broadcasting cache by default. With this change the
> shutdown of a DocumentNodeStore gets delayed by roughly one second. This is
> also visible in the time it takes to run the tests on travis. Previously the
> build took 35 min. The build with OAK-3727 took 45 minutes.
> A thread dump shows the following threads:
> {noformat}
> "Oak TCPBroadcaster: discover #50" daemon prio=5 tid=0x7f8957837800
> nid=0x5e13 waiting on condition [0x000116b5b000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.broadcast.TCPBroadcaster.discover(TCPBroadcaster.java:268)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.broadcast.TCPBroadcaster$2.run(TCPBroadcaster.java:155)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> And the shutdown waiting for above thread:
> {noformat}
> "main" prio=5 tid=0x7f8954000800 nid=0x1303 in Object.wait()
> [0x00010cd5e000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x0007f6c80e10> (a java.lang.Thread)
> at java.lang.Thread.join(Thread.java:1281)
> - locked <0x0007f6c80e10> (a java.lang.Thread)
> at java.lang.Thread.join(Thread.java:1355)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.broadcast.TCPBroadcaster.close(TCPBroadcaster.java:379)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.close(PersistentCache.java:346)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.dispose(DocumentNodeStore.java:581)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (OAK-3881) TCPBroadcaster causes shutdown delay
[
https://issues.apache.org/jira/browse/OAK-3881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger updated OAK-3881:
--
Affects Version/s: 1.3.14
> TCPBroadcaster causes shutdown delay
>
>
> Key: OAK-3881
> URL: https://issues.apache.org/jira/browse/OAK-3881
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: core, documentmk
>Affects Versions: 1.3.14
>Reporter: Marcel Reutegger
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.3.15
>
> Attachments: OAK-3881.patch
>
>
> OAK-3727 enabled the broadcasting cache by default. With this change the
> shutdown of a DocumentNodeStore gets delayed by roughly one second. This is
> also visible in the time it takes to run the tests on travis. Previously the
> build took 35 min. The build with OAK-3727 took 45 minutes.
> A thread dump shows the following threads:
> {noformat}
> "Oak TCPBroadcaster: discover #50" daemon prio=5 tid=0x7f8957837800
> nid=0x5e13 waiting on condition [0x000116b5b000]
>java.lang.Thread.State: TIMED_WAITING (sleeping)
> at java.lang.Thread.sleep(Native Method)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.broadcast.TCPBroadcaster.discover(TCPBroadcaster.java:268)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.broadcast.TCPBroadcaster$2.run(TCPBroadcaster.java:155)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
> And the shutdown waiting for above thread:
> {noformat}
> "main" prio=5 tid=0x7f8954000800 nid=0x1303 in Object.wait()
> [0x00010cd5e000]
>java.lang.Thread.State: WAITING (on object monitor)
> at java.lang.Object.wait(Native Method)
> - waiting on <0x0007f6c80e10> (a java.lang.Thread)
> at java.lang.Thread.join(Thread.java:1281)
> - locked <0x0007f6c80e10> (a java.lang.Thread)
> at java.lang.Thread.join(Thread.java:1355)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.broadcast.TCPBroadcaster.close(TCPBroadcaster.java:379)
> at
> org.apache.jackrabbit.oak.plugins.document.persistentCache.PersistentCache.close(PersistentCache.java:346)
> at
> org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.dispose(DocumentNodeStore.java:581)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (OAK-3878) Avoid caching of NodeDocument while iterating in BlobReferenceIterator
[
https://issues.apache.org/jira/browse/OAK-3878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15106427#comment-15106427
]
Julian Reschke commented on OAK-3878:
-
We could certainly *experiment* with heuristics, but we really should re-start
the work on re-organizing the API.
> Avoid caching of NodeDocument while iterating in BlobReferenceIterator
> --
>
> Key: OAK-3878
> URL: https://issues.apache.org/jira/browse/OAK-3878
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk
>Reporter: Chetan Mehrotra
>Priority: Minor
> Fix For: 1.4
>
>
> {{BlobReferenceIterator}} in DocumentMK makes use of {{DocumentStore}} API to
> query the NodeDocument. This would cause all those NodeDocuments to be added
> to cache in DocumentStore. Due to this when blob gc is running cache usage
> would not be that effective due to all the associated churn.
> As these NodeDocument are only required for BlobGC logic and its not expected
> that this document would read again soon it would be better to skip caching
> of these documents within DocumentStore
> Similar requirement exist in VersionGC logic but there we use direct store
> based API which does not add such documents to the cache
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
