[jira] [Commented] (OAK-8963) RDBBlobStore: on SQL Server, specify binary collations upon table creation
[
https://issues.apache.org/jira/browse/OAK-8963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17063750#comment-17063750
]
Solomon Rutzky commented on OAK-8963:
-
Based on the {{DATA}} column being {{VARBINARY(MAX)}} there is clearly no
support for SQL Server 2000. Hence, the {{ID}} columns should use:
{code:sql}
COLLATE Latin1_General_BIN2
{code}
> RDBBlobStore: on SQL Server, specify binary collations upon table creation
> --
>
> Key: OAK-8963
> URL: https://issues.apache.org/jira/browse/OAK-8963
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Reporter: Julian Reschke
>Priority: Minor
> Attachments: OAK-8963.diff
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8926) add RDBBlobStore performance test
[
https://issues.apache.org/jira/browse/OAK-8926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17063746#comment-17063746
]
Solomon Rutzky commented on OAK-8926:
-
I'm not sure that "primary keys" is the correct term to use in the comment
directly above. I can't say much about the MySQL results, but for SQL Server I
would need to see the configuration of the DB and maybe some other stuff to
better determine the issue. A more likely reason for the SQL Server performance
is that the clustered index (the physical ordering of the table) is the {{ID}}
column, _and_ the {{ID}} values are non-sequential.
> add RDBBlobStore performance test
> -
>
> Key: OAK-8926
> URL: https://issues.apache.org/jira/browse/OAK-8926
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_22
> Fix For: 1.26.0
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (OAK-8918) RDBBlobStore: warn when legacy (SQLServer) default collation is active
[
https://issues.apache.org/jira/browse/OAK-8918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17063685#comment-17063685
]
Solomon Rutzky edited comment on OAK-8918 at 3/21/20, 3:36 AM:
---
Hi [~reschke]. I just looked at the code a little more closely and noticed a
minor issue with these changes. Assuming that the "collation_name" value on
this line:
[http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/rdb/RDBBlobStoreDB.java?revision=1874271=markup#l83]
comes from this line:
[http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/rdb/RDBCommonVendorSpecificCode.java?revision=1874174=markup#l96]
then the warning message on this line (i.e. "Default server collation is..."):
[http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/rdb/RDBBlobStoreDB.java?revision=1874271=markup#l85]
is not entirely correct. The collation being discovered in
RDBCommonVendorSpecificCode via {{sys.databases}} is the _database_ default
collation, not the server (or instance) default collation. While they are often
the same, there is no guarantee that they are the same. And to be clear, the
database collation is the more correct choice, so the warning message should be
updated to reflect that.
Now, to be even more pedantic, the {{ID}} column uses the database's default
collation because the {{COLLATE}} clause is not ( yet: OAK-8963 ) specified.
The assumption here is that the database's default collation has not changed
since the tables were created. Again, this is true most of the time, but cannot
be guaranteed. At the very least it should be noted that, in the current state
of the code (assuming the commits noted in this issue), it's at least
_possible_ that a false positive will result in the user being shown a warning
for a situation that is, in fact, _not_ a problem (e.g. if the DB's collation
is changed from a non-"SQL_" collation to a "SQL_" collation after the tables
were created).
*IN FACT*, now that I have explained the steps of that scenario I realize that
even in the case where the column's collation does match the database's default
collation, and that collation is a "{{SQL_*}}" collation, if the user gets the
warning message and makes the change recommended in OAK-8908 (i.e. changing the
collation of the two ID columns to {{Latin1_General_BIN}} ), then they will
_still_ receive this warning because the code isn't checking the collation of
the _columns_. Hence, it would seem that this issue has been implemented
incorrectly, and should instead be changed to:
{code:sql}
SELECT col.[collation_name]
FROM sys.columns col
WHERE col.[object_id] = OBJECT_ID(?)
AND col.[name] = N'ID';
{code}
where the "{{?}}" is set to "{{tableName}}". Just call it twice, once for each
table.
was (Author: solomon.rutzky):
Hi [~reschke]. I just looked at the code a little more closely and noticed a
minor issue with these changes. Assuming that the "collation_name" value on
this line:
[http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/rdb/RDBBlobStoreDB.java?revision=1874271=markup#l83]
comes from this line:
[http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/rdb/RDBCommonVendorSpecificCode.java?revision=1874174=markup#l96]
then the warning message on this line (i.e. "Default server collation is..."):
[http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/rdb/RDBBlobStoreDB.java?revision=1874271=markup#l85]
is not entirely correct. The collation being discovered in
RDBCommonVendorSpecificCode via {{sys.databases}} is the _database_ default
collation, not the server (or instance) default collation. While they are often
the same, there is no guarantee that they are the same. And to be clear, the
database collation is the more correct choice, so the warning message should be
updated to reflect that.
Now, to be even more pedantic, the {{ID}} column uses the database's default
collation because the {{COLLATE}} clause is not ( yet ) specified. The
assumption here is that the database's default collation has not changed since
the tables were created. Again, this is true most of the time, but cannot be
guaranteed. At the very least it should be noted that, in the current state of
the code (assuming the commits noted in this issue), it's at least _possible_
that a false positive will result in the user being shown a warning for a
situation that is, in fact, _not_ a problem (e.g. if the DB's collation is
changed from a non-"SQL_" collation to a
[jira] [Comment Edited] (OAK-8918) RDBBlobStore: warn when legacy (SQLServer) default collation is active
[
https://issues.apache.org/jira/browse/OAK-8918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17063685#comment-17063685
]
Solomon Rutzky edited comment on OAK-8918 at 3/21/20, 3:34 AM:
---
Hi [~reschke]. I just looked at the code a little more closely and noticed a
minor issue with these changes. Assuming that the "collation_name" value on
this line:
[http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/rdb/RDBBlobStoreDB.java?revision=1874271=markup#l83]
comes from this line:
[http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/rdb/RDBCommonVendorSpecificCode.java?revision=1874174=markup#l96]
then the warning message on this line (i.e. "Default server collation is..."):
[http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/rdb/RDBBlobStoreDB.java?revision=1874271=markup#l85]
is not entirely correct. The collation being discovered in
RDBCommonVendorSpecificCode via {{sys.databases}} is the _database_ default
collation, not the server (or instance) default collation. While they are often
the same, there is no guarantee that they are the same. And to be clear, the
database collation is the more correct choice, so the warning message should be
updated to reflect that.
Now, to be even more pedantic, the {{ID}} column uses the database's default
collation because the {{COLLATE}} clause is not ( yet ) specified. The
assumption here is that the database's default collation has not changed since
the tables were created. Again, this is true most of the time, but cannot be
guaranteed. At the very least it should be noted that, in the current state of
the code (assuming the commits noted in this issue), it's at least _possible_
that a false positive will result in the user being shown a warning for a
situation that is, in fact, _not_ a problem (e.g. if the DB's collation is
changed from a non-"SQL_" collation to a "SQL_" collation after the tables were
created).
*IN FACT*, now that I have explained the steps of that scenario I realize that
even in the case where the column's collation does match the database's default
collation, and that collation is a "{{SQL_*}}" collation, if the user gets the
warning message and makes the change recommended in OAK-8908 (i.e. changing the
collation of the two ID columns to {{Latin1_General_BIN}} ), then they will
_still_ receive this warning because the code isn't checking the collation of
the _columns_. Hence, it would seem that this issue has been implemented
incorrectly, and should instead be changed to:
{code:sql}
SELECT col.[collation_name]
FROM sys.columns col
WHERE col.[object_id] = OBJECT_ID(?)
AND col.[name] = N'ID';
{code}
where the "{{?}}" is set to "{{tableName}}". Just call it twice, once for each
table.
was (Author: solomon.rutzky):
Hi [~reschke]. I just looked at the code a little bit closer and noticed a
minor issue with these changes. Assuming that the "collation_name" value on
this line:
[http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/rdb/RDBBlobStoreDB.java?revision=1874271=markup#l83]
comes from this line:
[http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/rdb/RDBCommonVendorSpecificCode.java?revision=1874174=markup#l96]
then the warning message on this line (i.e. "Default server collation is..."):
[http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/rdb/RDBBlobStoreDB.java?revision=1874271=markup#l85]
is not entirely correct. The collation being discovered in
RDBCommonVendorSpecificCode via {{sys.databases}} is the _database_ default
collation, not the server (or instance) default collation. While they are often
the same, there is no guarantee that they are the same.
Now, to be even more pedantic, the {{ID}} column uses the database's default
collation because the {{COLLATE}} clause is not (yet) specified. The assumption
here is that the database's default collation has not changed since the tables
were created. Again, this is true most of the time, but cannot be guaranteed.
I'm not sure how much effort should be spent in being 100% accurate here, but
at the very least it should be noted that in the current state of the code
(assuming the commits noted in this issue), it is at least _possible_ that a
false positive will result in the user being shown a warning for a situation
that is, in fact, _not_ a problem.
*IN FACT*, even in the case where the column's collation does match the
database's default collation, and that collation is a
[jira] [Commented] (OAK-8918) RDBBlobStore: warn when legacy (SQLServer) default collation is active
[
https://issues.apache.org/jira/browse/OAK-8918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17063685#comment-17063685
]
Solomon Rutzky commented on OAK-8918:
-
Hi [~reschke]. I just looked at the code a little bit closer and noticed a
minor issue with these changes. Assuming that the "collation_name" value on
this line:
[http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/rdb/RDBBlobStoreDB.java?revision=1874271=markup#l83]
comes from this line:
[http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/rdb/RDBCommonVendorSpecificCode.java?revision=1874174=markup#l96]
then the warning message on this line (i.e. "Default server collation is..."):
[http://svn.apache.org/viewvc/jackrabbit/oak/trunk/oak-store-document/src/main/java/org/apache/jackrabbit/oak/plugins/document/rdb/RDBBlobStoreDB.java?revision=1874271=markup#l85]
is not entirely correct. The collation being discovered in
RDBCommonVendorSpecificCode via {{sys.databases}} is the _database_ default
collation, not the server (or instance) default collation. While they are often
the same, there is no guarantee that they are the same.
Now, to be even more pedantic, the {{ID}} column uses the database's default
collation because the {{COLLATE}} clause is not (yet) specified. The assumption
here is that the database's default collation has not changed since the tables
were created. Again, this is true most of the time, but cannot be guaranteed.
I'm not sure how much effort should be spent in being 100% accurate here, but
at the very least it should be noted that in the current state of the code
(assuming the commits noted in this issue), it is at least _possible_ that a
false positive will result in the user being shown a warning for a situation
that is, in fact, _not_ a problem.
*IN FACT*, even in the case where the column's collation does match the
database's default collation, and that collation is a "{{SQL_*}}" collation, if
the user does make the change recommended in OAK-8908 (i.e. changing the
collation of the two ID columns to {{Latin1_General_BIN}} ), then they will
still receive this warning because the code isn't checking the collation of the
columns. Hence, it's possible that this issue has been implemented incorrectly,
and should instead be changed to:
{code:sql}
SELECT col.[collation_name]
FROM sys.columns col
WHERE col.[object_id] = OBJECT_ID(?)
AND col.[name] = N'ID';
{code}
where the "{{?}}" is set to "{{tableName}}".
> RDBBlobStore: warn when legacy (SQLServer) default collation is active
> --
>
> Key: OAK-8918
> URL: https://issues.apache.org/jira/browse/OAK-8918
> Project: Jackrabbit Oak
> Issue Type: Technical task
> Components: rdbmk
>Reporter: Julian Reschke
>Assignee: Julian Reschke
>Priority: Minor
> Labels: candidate_oak_1_8
> Fix For: 1.26.0, 1.10.9, 1.22.2
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (OAK-8964) oak-run: UtilsTest fails when Mongo not present
[
https://issues.apache.org/jira/browse/OAK-8964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger resolved OAK-8964.
---
Fix Version/s: 1.8.22
Resolution: Fixed
Fixed in 1.8 branch: http://svn.apache.org/r1875483
> oak-run: UtilsTest fails when Mongo not present
> ---
>
> Key: OAK-8964
> URL: https://issues.apache.org/jira/browse/OAK-8964
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Affects Versions: 1.8.21
>Reporter: Julian Reschke
>Assignee: Marcel Reutegger
>Priority: Minor
> Fix For: 1.8.22
>
>
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.004
> s <<< FAILURE! - in org.apache.jackrabbit.oak.run.UtilsTest
> [ERROR] validateMongoUri(org.apache.jackrabbit.oak.run.UtilsTest) Time
> elapsed: 3.004 s <<< ERROR!
> com.mongodb.MongoTimeoutException: Timed out after 3000 ms while waiting to
> connect. Client view of cluster state is {type=UNKNOWN,
> servers=[{address=127.0.0.1:27017, type=UNKNOWN, state=CONNECTING,
> exception={com.mongodb.MongoSocketOpenException: Exception opening socket},
> caused by {java.net.ConnectException: Connection refused: connect}}]
> at
> org.apache.jackrabbit.oak.run.UtilsTest.validateMongoUri(UtilsTest.java:38)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (OAK-8964) oak-run: UtilsTest fails when Mongo not present
[
https://issues.apache.org/jira/browse/OAK-8964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marcel Reutegger reassigned OAK-8964:
-
Assignee: Marcel Reutegger
> oak-run: UtilsTest fails when Mongo not present
> ---
>
> Key: OAK-8964
> URL: https://issues.apache.org/jira/browse/OAK-8964
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Affects Versions: 1.8.21
>Reporter: Julian Reschke
>Assignee: Marcel Reutegger
>Priority: Minor
>
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.004
> s <<< FAILURE! - in org.apache.jackrabbit.oak.run.UtilsTest
> [ERROR] validateMongoUri(org.apache.jackrabbit.oak.run.UtilsTest) Time
> elapsed: 3.004 s <<< ERROR!
> com.mongodb.MongoTimeoutException: Timed out after 3000 ms while waiting to
> connect. Client view of cluster state is {type=UNKNOWN,
> servers=[{address=127.0.0.1:27017, type=UNKNOWN, state=CONNECTING,
> exception={com.mongodb.MongoSocketOpenException: Exception opening socket},
> caused by {java.net.ConnectException: Connection refused: connect}}]
> at
> org.apache.jackrabbit.oak.run.UtilsTest.validateMongoUri(UtilsTest.java:38)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OAK-8964) oak-run: UtilsTest fails when Mongo not present
[
https://issues.apache.org/jira/browse/OAK-8964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-8964:
Description:
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.004 s
<<< FAILURE! - in org.apache.jackrabbit.oak.run.UtilsTest
[ERROR] validateMongoUri(org.apache.jackrabbit.oak.run.UtilsTest) Time
elapsed: 3.004 s <<< ERROR!
com.mongodb.MongoTimeoutException: Timed out after 3000 ms while waiting to
connect. Client view of cluster state is {type=UNKNOWN,
servers=[{address=127.0.0.1:27017, type=UNKNOWN, state=CONNECTING,
exception={com.mongodb.MongoSocketOpenException: Exception opening socket},
caused by {java.net.ConnectException: Connection refused: connect}}]
at
org.apache.jackrabbit.oak.run.UtilsTest.validateMongoUri(UtilsTest.java:38)
> oak-run: UtilsTest fails when Mongo not present
> ---
>
> Key: OAK-8964
> URL: https://issues.apache.org/jira/browse/OAK-8964
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Affects Versions: 1.8.21
>Reporter: Julian Reschke
>Priority: Minor
>
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.004
> s <<< FAILURE! - in org.apache.jackrabbit.oak.run.UtilsTest
> [ERROR] validateMongoUri(org.apache.jackrabbit.oak.run.UtilsTest) Time
> elapsed: 3.004 s <<< ERROR!
> com.mongodb.MongoTimeoutException: Timed out after 3000 ms while waiting to
> connect. Client view of cluster state is {type=UNKNOWN,
> servers=[{address=127.0.0.1:27017, type=UNKNOWN, state=CONNECTING,
> exception={com.mongodb.MongoSocketOpenException: Exception opening socket},
> caused by {java.net.ConnectException: Connection refused: connect}}]
> at
> org.apache.jackrabbit.oak.run.UtilsTest.validateMongoUri(UtilsTest.java:38)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OAK-8964) oak-run: UtilsTest fails when Mongo not present
[
https://issues.apache.org/jira/browse/OAK-8964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17063363#comment-17063363
]
Julian Reschke commented on OAK-8964:
-
cc [~mreutegg], [~vholani]
> oak-run: UtilsTest fails when Mongo not present
> ---
>
> Key: OAK-8964
> URL: https://issues.apache.org/jira/browse/OAK-8964
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: run
>Affects Versions: 1.8.21
>Reporter: Julian Reschke
>Priority: Minor
>
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.004
> s <<< FAILURE! - in org.apache.jackrabbit.oak.run.UtilsTest
> [ERROR] validateMongoUri(org.apache.jackrabbit.oak.run.UtilsTest) Time
> elapsed: 3.004 s <<< ERROR!
> com.mongodb.MongoTimeoutException: Timed out after 3000 ms while waiting to
> connect. Client view of cluster state is {type=UNKNOWN,
> servers=[{address=127.0.0.1:27017, type=UNKNOWN, state=CONNECTING,
> exception={com.mongodb.MongoSocketOpenException: Exception opening socket},
> caused by {java.net.ConnectException: Connection refused: connect}}]
> at
> org.apache.jackrabbit.oak.run.UtilsTest.validateMongoUri(UtilsTest.java:38)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (OAK-8964) oak-run: UtilsTest fails when Mongo not present
Julian Reschke created OAK-8964: --- Summary: oak-run: UtilsTest fails when Mongo not present Key: OAK-8964 URL: https://issues.apache.org/jira/browse/OAK-8964 Project: Jackrabbit Oak Issue Type: Bug Components: run Affects Versions: 1.8.21 Reporter: Julian Reschke -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (OAK-4356) DocumentNodeStoreIT.modifiedResetWithDiff fails for various RDBs
[ https://issues.apache.org/jira/browse/OAK-4356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke closed OAK-4356. --- > DocumentNodeStoreIT.modifiedResetWithDiff fails for various RDBs > > > Key: OAK-4356 > URL: https://issues.apache.org/jira/browse/OAK-4356 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: documentmk, rdbmk >Affects Versions: 1.0.30 >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Minor > > java.lang.NullPointerException: Lease End Time not set > at > com.google.common.base.Preconditions.checkNotNull(Preconditions.java:209) > at > org.apache.jackrabbit.oak.plugins.document.ClusterNodeInfoDocument.getLeaseEndTime(ClusterNodeInfoDocument.java:43) > at > org.apache.jackrabbit.oak.plugins.document.LastRevRecoveryAgent.recover(LastRevRecoveryAgent.java:84) > at > org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.checkLastRevRecovery(DocumentNodeStore.java:506) > at > org.apache.jackrabbit.oak.plugins.document.DocumentNodeStore.(DocumentNodeStore.java:483) > at > org.apache.jackrabbit.oak.plugins.document.DocumentMK$Builder.getNodeStore(DocumentMK.java:667) > at > org.apache.jackrabbit.oak.plugins.document.DocumentNodeStoreIT.modifiedResetWithDiff(DocumentNodeStoreIT.java:70) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at > org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at > org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at > org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) > at > org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27) > at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78) > at > org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at org.junit.runners.Suite.runChild(Suite.java:128) > at org.junit.runners.Suite.runChild(Suite.java:27) > at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290) > at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71) > at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288) > at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58) > at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268) > at org.junit.runners.ParentRunner.run(ParentRunner.java:363) > at > org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86) > at > org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382) > at > org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:192) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OAK-8908) RDBBlobStore on SQL Server: bad performance when default collation is of type SQL*
[ https://issues.apache.org/jira/browse/OAK-8908?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17063313#comment-17063313 ] Julian Reschke commented on OAK-8908: - Opened OAK-8963 for specifying the collation upon table creation. This probably does not hurt, but does not seem to help wih the general perf issues found for MySQL and SQL Server, see OAK-8926. > RDBBlobStore on SQL Server: bad performance when default collation is of type > SQL* > -- > > Key: OAK-8908 > URL: https://issues.apache.org/jira/browse/OAK-8908 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Assignee: Julian Reschke >Priority: Major > Fix For: 1.28.0 > > Attachments: OAK-8908-1.6.diff, OAK-8908.diff > > > RDBBlobStore uses a 64-char primary key (digest in hex). > Unfortunately, this causes performance issues on MS SQL Server, when the > collation for that column is of type "SQL*" (see links). These types of > collations are deprecated, but still the default for installations on the > "EN_US" locale. > The performance loss can be observed by changing the collation on an existing > install, and then enable performance logging on RDBBlobStore. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OAK-8963) RDBBlobStore: on SQL Server, specify binary collations upon table creation
[ https://issues.apache.org/jira/browse/OAK-8963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julian Reschke updated OAK-8963: Attachment: OAK-8963.diff > RDBBlobStore: on SQL Server, specify binary collations upon table creation > -- > > Key: OAK-8963 > URL: https://issues.apache.org/jira/browse/OAK-8963 > Project: Jackrabbit Oak > Issue Type: Technical task > Components: rdbmk >Reporter: Julian Reschke >Priority: Minor > Attachments: OAK-8963.diff > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-8963) RDBBlobStore: on SQL Server, specify binary collations upon table creation
Julian Reschke created OAK-8963: --- Summary: RDBBlobStore: on SQL Server, specify binary collations upon table creation Key: OAK-8963 URL: https://issues.apache.org/jira/browse/OAK-8963 Project: Jackrabbit Oak Issue Type: Technical task Components: rdbmk Reporter: Julian Reschke -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OAK-8962) Move lucene and elastic benchmarks out of oak-benchmarks to avoid elastic and lucene dep conflicts
Nitin Gupta created OAK-8962: Summary: Move lucene and elastic benchmarks out of oak-benchmarks to avoid elastic and lucene dep conflicts Key: OAK-8962 URL: https://issues.apache.org/jira/browse/OAK-8962 Project: Jackrabbit Oak Issue Type: Bug Reporter: Nitin Gupta Assignee: Nitin Gupta -- This message was sent by Atlassian Jira (v8.3.4#803005)
