[JBoss JIRA] (TEIID-5301) With MongoDB, a query with subquery in HAVING clause doesn't return any results
by Jan Martiska (JIRA)
Jan Martiska created TEIID-5301:
-----------------------------------
Summary: With MongoDB, a query with subquery in HAVING clause doesn't return any results
Key: TEIID-5301
URL: https://issues.jboss.org/browse/TEIID-5301
Project: Teiid
Issue Type: Bug
Components: Misc. Connectors
Affects Versions: 8.12.12.6_4
Reporter: Jan Martiska
Assignee: Steven Hawkins
Example:
{noformat}
SELECT INTKEY FROM BQT1.SMALLA GROUP BY INTKEY HAVING INTKEY = (SELECT INTKEY FROM BQT1.SMALLA WHERE INTKEY = 20)
{noformat}
This will not return any results even if there are rows with INTKEY=20.
If I use a value instead of subquery, it works as expected, this will return a result:
{noformat}
SELECT INTKEY FROM BQT1.SMALLA GROUP BY INTKEY HAVING INTKEY = 20;
{noformat}
Furthermore, if the subquery returns null, the whole query fails with a NPE:
{noformat}
SELECT INTKEY FROM BQT1.SMALLA GROUP BY INTKEY HAVING INTKEY = (SELECT null);
13:43:50,250 ERROR [org.teiid.CONNECTOR] (Worker1_QueryProcessorQueue1) Connector worker process failed for atomic-request=mo0zm9PiOEre.0.3.0: java.lang.NullPointerException
at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:936) [rt.jar:1.8.0_151]
at org.teiid.translator.mongodb.MongoDBSelectVisitor.getExpressionAlias(MongoDBSelectVisitor.java:808) [translator-mongodb-8.12.11.6_4-redhat-64-12.jar:8.12.11.6_4-redhat-64-12]
at org.teiid.translator.mongodb.MongoDBSelectVisitor.visit(MongoDBSelectVisitor.java:641) [translator-mongodb-8.12.11.6_4-redhat-64-12.jar:8.12.11.6_4-redhat-64-12]
at org.teiid.language.Comparison.acceptVisitor(Comparison.java:110) [teiid-api-8.12.11.6_4-redhat-64-12.jar:8.12.11.6_4-redhat-64-12]
at org.teiid.language.visitor.AbstractLanguageVisitor.visitNode(AbstractLanguageVisitor.java:51) [teiid-api-8.12.11.6_4-redhat-64-12.jar:8.12.11.6_4-redhat-64-12]
at org.teiid.translator.mongodb.MongoDBSelectVisitor.append(MongoDBSelectVisitor.java:81) [translator-mongodb-8.12.11.6_4-redhat-64-12.jar:8.12.11.6_4-redhat-64-12]
at org.teiid.translator.mongodb.MongoDBSelectVisitor.visit(MongoDBSelectVisitor.java:574) [translator-mongodb-8.12.11.6_4-redhat-64-12.jar:8.12.11.6_4-redhat-64-12]
at org.teiid.language.Select.acceptVisitor(Select.java:110) [teiid-api-8.12.11.6_4-redhat-64-12.jar:8.12.11.6_4-redhat-64-12]
at org.teiid.language.visitor.AbstractLanguageVisitor.visitNode(AbstractLanguageVisitor.java:51) [teiid-api-8.12.11.6_4-redhat-64-12.jar:8.12.11.6_4-redhat-64-12]
at org.teiid.translator.mongodb.MongoDBQueryExecution.execute(MongoDBQueryExecution.java:60) [translator-mongodb-8.12.11.6_4-redhat-64-12.jar:8.12.11.6_4-redhat-64-12]
at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.execute(ConnectorWorkItem.java:361)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_151]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_151]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_151]
at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_151]
at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211)
at com.sun.proxy.$Proxy79.execute(Unknown Source)
at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:306)
at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:112)
at org.teiid.dqp.internal.process.DataTierTupleSource$1.call(DataTierTupleSource.java:108)
at java.util.concurrent.FutureTask.run(FutureTask.java:266) [rt.jar:1.8.0_151]
at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65)
at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:284)
at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:119)
at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:210)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_151]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_151]
at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_151]
13:43:50,257 WARN [org.teiid.PROCESSOR] (Worker0_QueryProcessorQueue2) TEIID30020 Processing exception for request mo0zm9PiOEre.0 'TEIID30504 local: null'. Originally TeiidProcessingException ConcurrentHashMap.java:936. Enable more detailed logging to see the entire stacktrace.
{noformat}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 1 month
[JBoss JIRA] (TEIID-5296) With MongoDB, timestamp operations throw exceptions when called on null or missing values
by Jan Martiska (JIRA)
[ https://issues.jboss.org/browse/TEIID-5296?page=com.atlassian.jira.plugin... ]
Jan Martiska commented on TEIID-5296:
-------------------------------------
I tried also a few numeric and string functions and didn't run into this, looks like this is specific to Mongo's date/time functions..
> With MongoDB, timestamp operations throw exceptions when called on null or missing values
> -----------------------------------------------------------------------------------------
>
> Key: TEIID-5296
> URL: https://issues.jboss.org/browse/TEIID-5296
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.11.6_4
> Reporter: Jan Martiska
> Assignee: Steven Hawkins
>
> When a query contains timestamp operations like {{DAYOFMONTH}}, {{DAYOFWEEK}},.. and these are executed when some cells contain null (or missing field), MongoDB throws an exception. This exception is not handled by Teiid in any way and will fail the whole VDB query:
> {noformat}
> Remote com.mongodb.CommandFailureException:
> { "serverUsed" : "localhost:27017" ,
> "ok" : 0.0 , "errmsg" : "can't convert from BSON type null to Date" ,
> "code" : 16006 , "
> codeName" : "Location16006"}
> {noformat}
> Perhaps Teiid could work around this somehow so that the VDB query will not fail and affected cells will contain null in the result?
> For example, this Mongo aggregation pipeline which extracts hours from timestamps:
> {noformat}
> db.collection.aggregate([
> {
> $project : {
> hour: {$hour: "$DATEVALUE"}
> }
> }
> ])
> {noformat}
> could be transformed to this:
> {noformat}
> db.collection.aggregate([
> {
> $project : {
> hour: { $cond:
> [ { $or: [
> { $eq: [ "$DATEVALUE", null ] },
> { $eq: [ { $type: "$DATEVALUE" }, "missing" ] }
> ]
> },
> null,
> { $hour: "$DATEVALUE" }
> ]
> }
> }
> }
> ])
> {noformat}
> after this transformation, the {{hour}} field will be null as expected for documents where {{DATEVALUE}} is null or missing completely
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 1 month
[JBoss JIRA] (TEIID-5295) Comparisons of timestamps don't work correctly for MongoDB
by Jan Martiska (JIRA)
[ https://issues.jboss.org/browse/TEIID-5295?page=com.atlassian.jira.plugin... ]
Jan Martiska commented on TEIID-5295:
-------------------------------------
[~shawkins] It's in the view model:
{noformat}
CREATE FOREIGN TABLE SmallA
(...)
TIMEVALUE time
(...)
{noformat}
Is this supposed to ignore the date-part stored in MongoDB and only view the time part? Do I get this correctly?
Oh right I see I used "timestamps" in the title, should have used "time values", I'll fix that.
> Comparisons of timestamps don't work correctly for MongoDB
> ----------------------------------------------------------
>
> Key: TEIID-5295
> URL: https://issues.jboss.org/browse/TEIID-5295
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.11.6_4
> Reporter: Jan Martiska
> Assignee: Steven Hawkins
>
> Examples of queries which don't behave as expected when running against MongoDB:
> {noformat}
> SELECT BQT1.SmallA.TimeValue FROM BQT1.SmallA WHERE BQT1.SmallA.TimeValue > '17:00:00'
> {noformat}
> returns ALL timevalues which are not null
> {noformat}
> SELECT BQT1.SmallA.TimeValue FROM BQT1.SmallA WHERE BQT1.SmallA.TimeValue < '17:00:00'
> {noformat}
> returns NO timevalues even though there are some less than 17:00
> {noformat}
> SELECT BQT1.SmallA.TimeValue FROM BQT1.SmallA WHERE BQT1.SmallA.TimeValue = '15:00:00'
> {noformat}
> returns nothing
> {noformat}
> SELECT BQT1.SmallA.IntKey FROM BQT1.SmallA WHERE BQT1.SmallA.TimeValue IN (convert('05:00:00', time), convert('15:00:00', time))
> {noformat}
> returns nothing
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 1 month
[JBoss JIRA] (TEIID-5295) Comparisons of time values don't work correctly for MongoDB
by Jan Martiska (JIRA)
[ https://issues.jboss.org/browse/TEIID-5295?page=com.atlassian.jira.plugin... ]
Jan Martiska updated TEIID-5295:
--------------------------------
Summary: Comparisons of time values don't work correctly for MongoDB (was: Comparisons of timestamps don't work correctly for MongoDB)
> Comparisons of time values don't work correctly for MongoDB
> -----------------------------------------------------------
>
> Key: TEIID-5295
> URL: https://issues.jboss.org/browse/TEIID-5295
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.11.6_4
> Reporter: Jan Martiska
> Assignee: Steven Hawkins
>
> Examples of queries which don't behave as expected when running against MongoDB:
> {noformat}
> SELECT BQT1.SmallA.TimeValue FROM BQT1.SmallA WHERE BQT1.SmallA.TimeValue > '17:00:00'
> {noformat}
> returns ALL timevalues which are not null
> {noformat}
> SELECT BQT1.SmallA.TimeValue FROM BQT1.SmallA WHERE BQT1.SmallA.TimeValue < '17:00:00'
> {noformat}
> returns NO timevalues even though there are some less than 17:00
> {noformat}
> SELECT BQT1.SmallA.TimeValue FROM BQT1.SmallA WHERE BQT1.SmallA.TimeValue = '15:00:00'
> {noformat}
> returns nothing
> {noformat}
> SELECT BQT1.SmallA.IntKey FROM BQT1.SmallA WHERE BQT1.SmallA.TimeValue IN (convert('05:00:00', time), convert('15:00:00', time))
> {noformat}
> returns nothing
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 1 month
[JBoss JIRA] (TEIID-5296) With MongoDB, timestamp operations throw exceptions when called on null or missing values
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5296?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5296:
---------------------------------------
Does this occur with any function operating on null values, or only on the date/time functions?
> With MongoDB, timestamp operations throw exceptions when called on null or missing values
> -----------------------------------------------------------------------------------------
>
> Key: TEIID-5296
> URL: https://issues.jboss.org/browse/TEIID-5296
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.11.6_4
> Reporter: Jan Martiska
> Assignee: Steven Hawkins
>
> When a query contains timestamp operations like {{DAYOFMONTH}}, {{DAYOFWEEK}},.. and these are executed when some cells contain null (or missing field), MongoDB throws an exception. This exception is not handled by Teiid in any way and will fail the whole VDB query:
> {noformat}
> Remote com.mongodb.CommandFailureException:
> { "serverUsed" : "localhost:27017" ,
> "ok" : 0.0 , "errmsg" : "can't convert from BSON type null to Date" ,
> "code" : 16006 , "
> codeName" : "Location16006"}
> {noformat}
> Perhaps Teiid could work around this somehow so that the VDB query will not fail and affected cells will contain null in the result?
> For example, this Mongo aggregation pipeline which extracts hours from timestamps:
> {noformat}
> db.collection.aggregate([
> {
> $project : {
> hour: {$hour: "$DATEVALUE"}
> }
> }
> ])
> {noformat}
> could be transformed to this:
> {noformat}
> db.collection.aggregate([
> {
> $project : {
> hour: { $cond:
> [ { $or: [
> { $eq: [ "$DATEVALUE", null ] },
> { $eq: [ { $type: "$DATEVALUE" }, "missing" ] }
> ]
> },
> null,
> { $hour: "$DATEVALUE" }
> ]
> }
> }
> }
> ])
> {noformat}
> after this transformation, the {{hour}} field will be null as expected for documents where {{DATEVALUE}} is null or missing completely
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 1 month
[JBoss JIRA] (TEIID-5296) With MongoDB, timestamp operations throw exceptions when called on null or missing values
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5296?page=com.atlassian.jira.plugin... ]
Work on TEIID-5296 started by Steven Hawkins.
---------------------------------------------
> With MongoDB, timestamp operations throw exceptions when called on null or missing values
> -----------------------------------------------------------------------------------------
>
> Key: TEIID-5296
> URL: https://issues.jboss.org/browse/TEIID-5296
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.11.6_4
> Reporter: Jan Martiska
> Assignee: Steven Hawkins
>
> When a query contains timestamp operations like {{DAYOFMONTH}}, {{DAYOFWEEK}},.. and these are executed when some cells contain null (or missing field), MongoDB throws an exception. This exception is not handled by Teiid in any way and will fail the whole VDB query:
> {noformat}
> Remote com.mongodb.CommandFailureException:
> { "serverUsed" : "localhost:27017" ,
> "ok" : 0.0 , "errmsg" : "can't convert from BSON type null to Date" ,
> "code" : 16006 , "
> codeName" : "Location16006"}
> {noformat}
> Perhaps Teiid could work around this somehow so that the VDB query will not fail and affected cells will contain null in the result?
> For example, this Mongo aggregation pipeline which extracts hours from timestamps:
> {noformat}
> db.collection.aggregate([
> {
> $project : {
> hour: {$hour: "$DATEVALUE"}
> }
> }
> ])
> {noformat}
> could be transformed to this:
> {noformat}
> db.collection.aggregate([
> {
> $project : {
> hour: { $cond:
> [ { $or: [
> { $eq: [ "$DATEVALUE", null ] },
> { $eq: [ { $type: "$DATEVALUE" }, "missing" ] }
> ]
> },
> null,
> { $hour: "$DATEVALUE" }
> ]
> }
> }
> }
> ])
> {noformat}
> after this transformation, the {{hour}} field will be null as expected for documents where {{DATEVALUE}} is null or missing completely
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 1 month
[JBoss JIRA] (TEIID-5295) Comparisons of timestamps don't work correctly for MongoDB
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5295?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5295:
---------------------------------------
[~jmartisk] Are you modeling the time type directly, or do you have a view layer converting to time? MongoDB does not directly support a time type, so the behavior will likely not be as expected unless using a view.
> Comparisons of timestamps don't work correctly for MongoDB
> ----------------------------------------------------------
>
> Key: TEIID-5295
> URL: https://issues.jboss.org/browse/TEIID-5295
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.11.6_4
> Reporter: Jan Martiska
> Assignee: Steven Hawkins
>
> Examples of queries which don't behave as expected when running against MongoDB:
> {noformat}
> SELECT BQT1.SmallA.TimeValue FROM BQT1.SmallA WHERE BQT1.SmallA.TimeValue > '17:00:00'
> {noformat}
> returns ALL timevalues which are not null
> {noformat}
> SELECT BQT1.SmallA.TimeValue FROM BQT1.SmallA WHERE BQT1.SmallA.TimeValue < '17:00:00'
> {noformat}
> returns NO timevalues even though there are some less than 17:00
> {noformat}
> SELECT BQT1.SmallA.TimeValue FROM BQT1.SmallA WHERE BQT1.SmallA.TimeValue = '15:00:00'
> {noformat}
> returns nothing
> {noformat}
> SELECT BQT1.SmallA.IntKey FROM BQT1.SmallA WHERE BQT1.SmallA.TimeValue IN (convert('05:00:00', time), convert('15:00:00', time))
> {noformat}
> returns nothing
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 1 month
[JBoss JIRA] (TEIID-5300) ClassCastException during query Optimization
by Mike Higgins (JIRA)
Mike Higgins created TEIID-5300:
-----------------------------------
Summary: ClassCastException during query Optimization
Key: TEIID-5300
URL: https://issues.jboss.org/browse/TEIID-5300
Project: Teiid
Issue Type: Bug
Environment: Teiid 10.1
Reporter: Mike Higgins
Assignee: Steven Hawkins
Using Teiid 10.1 against an Oracle database, if I submit a query with exactly two bind variables such as the following:
SELECT "Small Molecules"."MOLREGNO", "Small Molecules"."CHEMBL_ID",
"Small Molecules_2"."FULL_MWT", CHEMBL_20.ACTIVITIES."ACTIVITY_ID",
CHEMBL_20.ACTIVITIES."ACTIVITY_ID", ((CHEMBL_20.ACTIVITIES."ASSAY_ID" ||
'#') || CHEMBL_20.ACTIVITIES."STANDARD_TYPE") "ID_RESULT",
CHEMBL_20.ACTIVITIES."STANDARD_UNITS",
CHEMBL_20.ACTIVITIES."ACTIVITY_COMMENT",
CHEMBL_20.ACTIVITIES."STANDARD_VALUE"
FROM (SELECT CHEMBL_20.COMPOUND_STRUCTURES."MOLREGNO",
SM_DICTIONARY_PRIME."CHEMBL_ID" FROM chembl_20.compound_structures INNER
JOIN chembl_20.molecule_dictionary SM_DICTIONARY_PRIME ON (
CHEMBL_20.COMPOUND_STRUCTURES."MOLREGNO" = SM_DICTIONARY_PRIME."MOLREGNO")
UNION ALL SELECT CHEMBL_20.SM_REPOSITORY."MOLREGNO",
CHEMBL_20.SM_REPOSITORY."CHEMBL_ID" FROM chembl_20.sm_repository)
"Small Molecules" LEFT OUTER JOIN chembl_20.compound_properties
"Small Molecules_2" ON ("Small Molecules"."MOLREGNO" =
"Small Molecules_2"."MOLREGNO") INNER JOIN chembl_20.activities ON ((
"Small Molecules"."MOLREGNO" = CHEMBL_20.ACTIVITIES."MOLREGNO") AND ((
CHEMBL_20.ACTIVITIES."STANDARD_TYPE" = 'IC50') AND (
CHEMBL_20.ACTIVITIES."ASSAY_ID" IN ('654926', '654933'))))
WHERE ("Small Molecules"."MOLREGNO" IN (?, ?)
I get the following traceback, indicating that a class that does not implement Comparable is being stored in a TreeMap:
[exec] 23 Mar 2018 15:04:28,282 [Worker67_QueryProcessorQueue3267] ERROR PROCESSOR- TEIID30019 Unexpected exception for request RkVKlFhEnEgf.0: java.lang.ClassCastException: org.teiid.query.sql.symbol.Reference cannot be cast to java.lang.Comparable
[exec] at java.util.TreeMap.getEntry(TreeMap.java:349)
[exec] at java.util.TreeMap.containsKey(TreeMap.java:232)
[exec] at java.util.TreeSet.contains(TreeSet.java:234)
[exec] at java.util.AbstractCollection.containsAll(AbstractCollection.java:318)
[exec] at org.teiid.query.sql.lang.SetCriteria.equals(SetCriteria.java:136)
[exec] at org.teiid.query.optimizer.relational.rules.RuleCopyCriteria.copyCriteria(RuleCopyCriteria.java:169)
[exec] at org.teiid.query.optimizer.relational.rules.RuleCopyCriteria.createCriteria(RuleCopyCriteria.java:341)
[exec] at org.teiid.query.optimizer.relational.rules.RuleCopyCriteria.tryToCopy(RuleCopyCriteria.java:268)
[exec] at org.teiid.query.optimizer.relational.rules.RuleCopyCriteria.visitChildern(RuleCopyCriteria.java:384)
[exec] at org.teiid.query.optimizer.relational.rules.RuleCopyCriteria.tryToCopy(RuleCopyCriteria.java:294)
[exec] at org.teiid.query.optimizer.relational.rules.RuleCopyCriteria.visitChildern(RuleCopyCriteria.java:384)
[exec] at org.teiid.query.optimizer.relational.rules.RuleCopyCriteria.tryToCopy(RuleCopyCriteria.java:294)
[exec] at org.teiid.query.optimizer.relational.rules.RuleCopyCriteria.execute(RuleCopyCriteria.java:99)
[exec] at org.teiid.query.optimizer.relational.RelationalPlanner.executeRules(RelationalPlanner.java:995)
[exec] at org.teiid.query.optimizer.relational.RelationalPlanner.optimize(RelationalPlanner.java:228)
[exec] at org.teiid.query.optimizer.QueryOptimizer.optimizePlan(QueryOptimizer.java:179)
[exec] at org.teiid.dqp.internal.process.Request.generatePlan(Request.java:458)
[exec] at org.teiid.dqp.internal.process.PreparedStatementRequest.generatePlan(PreparedStatementRequest.java:124)
[exec] at org.teiid.dqp.internal.process.Request.processRequest(Request.java:486)
[exec] at org.teiid.dqp.internal.process.PreparedStatementRequest.processRequest(PreparedStatementRequest.java:345)
[exec] at org.teiid.dqp.internal.process.RequestWorkItem.processNew(RequestWorkItem.java:660)
[exec] at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:339)
[exec] at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:47)
[exec] at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:276)
[exec] at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:280)
[exec] at org.teiid.dqp.internal.process.ThreadReuseExecutor$RunnableWrapper.run(ThreadReuseExecutor.java:115)
[exec] at org.teiid.dqp.internal.process.ThreadReuseExecutor$3.run(ThreadReuseExecutor.java:206)
[exec] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[exec] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[exec] at java.lang.Thread.run(Thread.java:745)
[exec]
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 1 month