[JBoss JIRA] (TEIID-4957) Setting Connection Type on VDB of a Domain Managed server gets set back to default after server restart
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-4957?page=com.atlassian.jira.plugin... ]
Ramesh Reddy resolved TEIID-4957.
---------------------------------
Resolution: Won't Fix
> Setting Connection Type on VDB of a Domain Managed server gets set back to default after server restart
> -------------------------------------------------------------------------------------------------------
>
> Key: TEIID-4957
> URL: https://issues.jboss.org/browse/TEIID-4957
> Project: Teiid
> Issue Type: Bug
> Components: VDB
> Affects Versions: 8.12.10.6_3
> Reporter: Debbie Steigner
> Assignee: Ramesh Reddy
> Fix For: 10.0
>
>
> After deploying a VDB to a managed server group, set the Connection type to anything but the default of By_Version, so None or Any. Now restart the server and you'll see the Connection type is reset to the default.
> What I see is that when the change is made a vdb.xml with that new connection-type is written to the /DVserverhome/domain/servers/server-two/data/teiid-data/SampleVDB_1 folder, this folder is deleted upon a restart though so the change is not kept.
> This only happens in Domain mode, running in Standalone mode saves the change because the teiid-data is not deleted on a restart.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (TEIID-5088) Infinispan Hotrod bigdecimal/biginteger compared as strings
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-5088?page=com.atlassian.jira.plugin... ]
Ramesh Reddy resolved TEIID-5088.
---------------------------------
Resolution: Done
When a Type is not natively supported by the Infinispan, then those types are artificially defined using other types, but the transformation to/from the native type is handled at the translator level. These types now will be annotated as NOT searchable, i.e. any comparisons on these types will be evaluated in Teiid engine rather than pushed to the source. So, some queries may perform very poorly because in this situation more data is brought into the Teiid than otherwise.
For the user, it is best to keep the datatypes in the Infinispan to natively supported ones.
> Infinispan Hotrod bigdecimal/biginteger compared as strings
> -----------------------------------------------------------
>
> Key: TEIID-5088
> URL: https://issues.jboss.org/browse/TEIID-5088
> Project: Teiid
> Issue Type: Bug
> Components: JDG Connector, Misc. Connectors
> Affects Versions: 8.12.x-6.4
> Reporter: Jan Stastny
> Assignee: Ramesh Reddy
> Fix For: 10.0, 8.12.x-6.4
>
>
> Biginteger and bigdecimal data types are being compared as strings, instead of numbers.
> For a vdb with following source DDL metadata:
> {code:sql|title="Source"}
> CREATE FOREIGN TABLE SmallA (
> IntKey integer,
> IntNum integer,
> DoubleNum double,
> ObjectValue object,
> BigDecimalValue bigdecimal,
> BigIntegerValue biginteger,
> CharValue char,
> StringNum string,
> StringKey string PRIMARY KEY,
> FloatNum float,
> LongNum long,
> TimeValue time,
> ShortValue short,
> ByteNum byte,
> TimeStampValue timestamp,
> BooleanValue boolean,
> DateValue date
> ) OPTIONS(UPDATABLE true, "teiid_ispn:cache" '${jdg.cache.name}');
> {code}
> and a view:
> {code:sql|title="CRUD"}
> CREATE VIEW SmallA(
> IntKey integer,
> IntNum integer,
> DoubleNum double,
> ObjectValue object,
> BigDecimalValue bigdecimal,
> BigIntegerValue biginteger,
> CharValue char,
> StringNum string,
> StringKey string PRIMARY KEY,
> FloatNum float,
> LongNum long,
> TimeValue time,
> ShortValue short,
> ByteNum byte,
> TimestampValue timestamp,
> BooleanValue boolean,
> DateValue date
> ) OPTIONS (UPDATABLE true) AS
> SELECT
> source.IntKey AS IntKey,
> source.IntNum as IntNum,
> source.DoubleNum AS DoubleNum,
> source.ObjectValue AS ObjectValue,
> source.BigDecimalValue AS BigDecimalValue,
> source.BigIntegerValue AS BigIntegerValue,
> source.CharValue AS CharValue,
> source.StringNum AS StringNum,
> source.StringKey AS StringKey,
> source.FloatNum AS FloatNum,
> source.LongNum AS LongNum,
> source.TimeValue AS TimeValue,
> source.ShortValue AS ShortValue,
> source.ByteNum AS ByteNum,
> source.TimeStampValue AS TimestampValue,
> source.BooleanValue AS BooleanValue,
> source.DateValue AS DateValue
> FROM Source.SmallA as source;
> {code}
> Following query:
> {code}
> SELECT BigIntegerValue FROM SmallA WHERE BigIntegerValue<4
> {code}
> returns
> || BigIntegerValue ||
> | 1,418,509 |
> | 2,993,990 |
> | 39,127 |
> | 132,878,502 |
> | 18,235,051 |
> | 27,147,783 |
> | 250,391,377 |
> | 278,593 |
> | 1,110,985,332 |
> | 262,593,097 |
> | 19 |
> | 26,203,918 |
> | 21,559,352 |
> | 18,812 |
> same issue applies to bigdecimal.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (TEIID-5089) Using Teiid Conn. importer in Designer, the cache name is set to "default"
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-5089?page=com.atlassian.jira.plugin... ]
Ramesh Reddy resolved TEIID-5089.
---------------------------------
Resolution: Done
The solution ended up coding is, when a table is decorated with annotation of "CACHE" to define which Infinispan Cache this table is going to be stored in, then at the protobuf generation time, a comment like /*@Cache(name=foo) */ is generated on the corresponding "message" type in the .protobuf file that is sent to Infinispan for registration.
When the same protobuf is reimported for some reason into Teiid metadata, it is capable of recognizing @cache(name=foo) annotation and set the corresponding CACHE property. Thus keeping the value of CACHE intact in a roundtrip.
> Using Teiid Conn. importer in Designer, the cache name is set to "default"
> --------------------------------------------------------------------------
>
> Key: TEIID-5089
> URL: https://issues.jboss.org/browse/TEIID-5089
> Project: Teiid
> Issue Type: Bug
> Components: Infinispan
> Affects Versions: 8.12.x-6.4
> Reporter: Van Halbert
> Assignee: Ramesh Reddy
> Fix For: 10.0, 8.12.x-6.4
>
>
> When using the Teiid Connection importer in Designer to reversen engineer the source table from an existing JDG cache. The following is an example of the DDL returned by teiid:
> {code}
> SET NAMESPACE 'http://www.teiid.org/translator/infinispan/2017' AS teiid_ispn;
> CREATE FOREIGN TABLE Person (
> id integer OPTIONS (ANNOTATION '@Id', SEARCHABLE 'Searchable', NATIVE_TYPE 'int32', "teiid_ispn:TAG" '1'),
> name string OPTIONS (SEARCHABLE 'Searchable', NATIVE_TYPE 'string', "teiid_ispn:TAG" '2'),
> salary double OPTIONS (SEARCHABLE 'Searchable', NATIVE_TYPE 'double', "teiid_ispn:TAG" '3'),
> CONSTRAINT PK_ID PRIMARY KEY(id)
> ) OPTIONS (ANNOTATION '@Indexed', NAMEINSOURCE 'JDGPersonCache.Person', UPDATABLE TRUE, "teiid_ispn:CACHE" 'default');
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (TEIID-5094) Is DISTINCT FROM evaluation with two null values
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5094?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-5094:
----------------------------------
Description: 'row(null) is distinct from row(null)" evaluates to true when false is expected. (was: 'row(null) is distinct from row(null)" evaluates to true when true is expected.)
Steps to Reproduce:
See https://github.com/teiid/teiid/blob/d0f6217824b0c4d64b1d166e8f7c69529acdf...
Given that IS DISTINCT prior to 10.0 is restricted to IF statements in procedures, this needs to should be tested using an update trigger. See the test case, both the new and the old row value contain a column with a value of null - as the GX view is defined with the second branch as "select null as x" and the user update "update gx set x = x || 'a' where y = 2" expression for the x value evaluates to null for that row.
> Is DISTINCT FROM evaluation with two null values
> ------------------------------------------------
>
> Key: TEIID-5094
> URL: https://issues.jboss.org/browse/TEIID-5094
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 8.12
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 10.0, 8.12.x-6.4, 9.3.4, 9.2.7
>
>
> 'row(null) is distinct from row(null)" evaluates to true when false is expected.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (TEIID-5092) Joining tables from S3 occasionaly fails with NumberFormatException
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-5092?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-5092:
-------------------------------------
Then submit your patch, as I do not think there is not another better option in this case. Putting a synchronized block around it will have similar penalties, and we lose the readability.
> Joining tables from S3 occasionaly fails with NumberFormatException
> -------------------------------------------------------------------
>
> Key: TEIID-5092
> URL: https://issues.jboss.org/browse/TEIID-5092
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.x-6.4
> Reporter: Andrej Šmigala
> Assignee: Steven Hawkins
> Priority: Critical
>
> Running any query that reads multiple tables from an Amazon S3 datasource sometimes fails with the following exception:
> {noformat}
> [org.teiid.CONNECTOR] (Worker0_QueryProcessorQueue3373) Connector worker process failed for atomic-request=ZwjBqkPjJdw2.386.4.689: java.lang.NumberFormatException: For input string: ""
> at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) [rt.jar:1.8.0_131]
> at java.lang.Long.parseLong(Long.java:601) [rt.jar:1.8.0_131]
> at java.lang.Long.parseLong(Long.java:631) [rt.jar:1.8.0_131]
> at java.text.DigitList.getLong(DigitList.java:195) [rt.jar:1.8.0_131]
> at java.text.DecimalFormat.parse(DecimalFormat.java:2051) [rt.jar:1.8.0_131]
> at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:1869) [rt.jar:1.8.0_131]
> at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1514) [rt.jar:1.8.0_131]
> at java.text.DateFormat.parse(DateFormat.java:364) [rt.jar:1.8.0_131]
> at org.teiid.translator.amazon.s3.S3ProcedureExecution.next(S3ProcedureExecution.java:488) [translator-amazon-s3-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.handleBatch(ConnectorWorkItem.java:433)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.more(ConnectorWorkItem.java:236)
> at sun.reflect.GeneratedMethodAccessor211.invoke(Unknown Source) [:1.8.0_131]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_131]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_131]
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211)
> at com.sun.proxy.$Proxy79.more(Unknown Source)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:309)
> 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_131]
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:280)
> 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:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> {noformat}.
> The actual input string reffered to in the stack trace occasionaly contains garbage data.
> This is caused by unsynchronized access to a static SimpleDateFormat field here: https://github.com/teiid/teiid/blob/64-8.12.x/connectors/translator-amazo...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (TEIID-5092) Joining tables from S3 occasionaly fails with NumberFormatException
by Andrej Šmigala (JIRA)
[ https://issues.jboss.org/browse/TEIID-5092?page=com.atlassian.jira.plugin... ]
Andrej Šmigala commented on TEIID-5092:
---------------------------------------
Please also note that when I added debugging info on the http connection (-Dcom.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.dump=true and the like), the error completely stopped appearing, probably due to the time it took write the debug input. So manually debugging might also prevent this issue from appearing.
> Joining tables from S3 occasionaly fails with NumberFormatException
> -------------------------------------------------------------------
>
> Key: TEIID-5092
> URL: https://issues.jboss.org/browse/TEIID-5092
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.x-6.4
> Reporter: Andrej Šmigala
> Assignee: Steven Hawkins
> Priority: Critical
>
> Running any query that reads multiple tables from an Amazon S3 datasource sometimes fails with the following exception:
> {noformat}
> [org.teiid.CONNECTOR] (Worker0_QueryProcessorQueue3373) Connector worker process failed for atomic-request=ZwjBqkPjJdw2.386.4.689: java.lang.NumberFormatException: For input string: ""
> at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) [rt.jar:1.8.0_131]
> at java.lang.Long.parseLong(Long.java:601) [rt.jar:1.8.0_131]
> at java.lang.Long.parseLong(Long.java:631) [rt.jar:1.8.0_131]
> at java.text.DigitList.getLong(DigitList.java:195) [rt.jar:1.8.0_131]
> at java.text.DecimalFormat.parse(DecimalFormat.java:2051) [rt.jar:1.8.0_131]
> at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:1869) [rt.jar:1.8.0_131]
> at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1514) [rt.jar:1.8.0_131]
> at java.text.DateFormat.parse(DateFormat.java:364) [rt.jar:1.8.0_131]
> at org.teiid.translator.amazon.s3.S3ProcedureExecution.next(S3ProcedureExecution.java:488) [translator-amazon-s3-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.handleBatch(ConnectorWorkItem.java:433)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.more(ConnectorWorkItem.java:236)
> at sun.reflect.GeneratedMethodAccessor211.invoke(Unknown Source) [:1.8.0_131]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_131]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_131]
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211)
> at com.sun.proxy.$Proxy79.more(Unknown Source)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:309)
> 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_131]
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:280)
> 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:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> {noformat}.
> The actual input string reffered to in the stack trace occasionaly contains garbage data.
> This is caused by unsynchronized access to a static SimpleDateFormat field here: https://github.com/teiid/teiid/blob/64-8.12.x/connectors/translator-amazo...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (TEIID-5092) Joining tables from S3 occasionaly fails with NumberFormatException
by Andrej Šmigala (JIRA)
[ https://issues.jboss.org/browse/TEIID-5092?page=com.atlassian.jira.plugin... ]
Andrej Šmigala commented on TEIID-5092:
---------------------------------------
It only happens occasionally, about 5 - 10 times out of roughly 400 queries.
You can use the same translator and vdb as specified in TEIID-5093 and run this query:
{code:sql}
SELECT BQT1.SmallA.IntNum, BQT1.SmallB.LongNum FROM BQT1.SmallA, BQT1.SmallB WHERE BQT1.SmallA.IntNum = BQT1.SmallB.IntNum AND BQT1.SmallA.LongNum = BQT1.SmallB.LongNum AND BQT1.SmallA.IntKey < 30 AND BQT1.SmallB.IntKey < 30
{code}
This is one of the queries that failed at least once, but as I said, it's pretty much random which query fails. You will probably need to run the query in a loop a couple tens or hundreds of times to see the error.
> Joining tables from S3 occasionaly fails with NumberFormatException
> -------------------------------------------------------------------
>
> Key: TEIID-5092
> URL: https://issues.jboss.org/browse/TEIID-5092
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.x-6.4
> Reporter: Andrej Šmigala
> Assignee: Steven Hawkins
> Priority: Critical
>
> Running any query that reads multiple tables from an Amazon S3 datasource sometimes fails with the following exception:
> {noformat}
> [org.teiid.CONNECTOR] (Worker0_QueryProcessorQueue3373) Connector worker process failed for atomic-request=ZwjBqkPjJdw2.386.4.689: java.lang.NumberFormatException: For input string: ""
> at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) [rt.jar:1.8.0_131]
> at java.lang.Long.parseLong(Long.java:601) [rt.jar:1.8.0_131]
> at java.lang.Long.parseLong(Long.java:631) [rt.jar:1.8.0_131]
> at java.text.DigitList.getLong(DigitList.java:195) [rt.jar:1.8.0_131]
> at java.text.DecimalFormat.parse(DecimalFormat.java:2051) [rt.jar:1.8.0_131]
> at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:1869) [rt.jar:1.8.0_131]
> at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1514) [rt.jar:1.8.0_131]
> at java.text.DateFormat.parse(DateFormat.java:364) [rt.jar:1.8.0_131]
> at org.teiid.translator.amazon.s3.S3ProcedureExecution.next(S3ProcedureExecution.java:488) [translator-amazon-s3-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.handleBatch(ConnectorWorkItem.java:433)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.more(ConnectorWorkItem.java:236)
> at sun.reflect.GeneratedMethodAccessor211.invoke(Unknown Source) [:1.8.0_131]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_131]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_131]
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211)
> at com.sun.proxy.$Proxy79.more(Unknown Source)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:309)
> 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_131]
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:280)
> 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:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> {noformat}.
> The actual input string reffered to in the stack trace occasionaly contains garbage data.
> This is caused by unsynchronized access to a static SimpleDateFormat field here: https://github.com/teiid/teiid/blob/64-8.12.x/connectors/translator-amazo...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months
[JBoss JIRA] (TEIID-5092) Joining tables from S3 occasionaly fails with NumberFormatException
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-5092?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-5092:
-------------------------------------
How can I recreate it? do you have any sample testcase perhaps?
> Joining tables from S3 occasionaly fails with NumberFormatException
> -------------------------------------------------------------------
>
> Key: TEIID-5092
> URL: https://issues.jboss.org/browse/TEIID-5092
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.12.x-6.4
> Reporter: Andrej Šmigala
> Assignee: Steven Hawkins
> Priority: Critical
>
> Running any query that reads multiple tables from an Amazon S3 datasource sometimes fails with the following exception:
> {noformat}
> [org.teiid.CONNECTOR] (Worker0_QueryProcessorQueue3373) Connector worker process failed for atomic-request=ZwjBqkPjJdw2.386.4.689: java.lang.NumberFormatException: For input string: ""
> at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) [rt.jar:1.8.0_131]
> at java.lang.Long.parseLong(Long.java:601) [rt.jar:1.8.0_131]
> at java.lang.Long.parseLong(Long.java:631) [rt.jar:1.8.0_131]
> at java.text.DigitList.getLong(DigitList.java:195) [rt.jar:1.8.0_131]
> at java.text.DecimalFormat.parse(DecimalFormat.java:2051) [rt.jar:1.8.0_131]
> at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:1869) [rt.jar:1.8.0_131]
> at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1514) [rt.jar:1.8.0_131]
> at java.text.DateFormat.parse(DateFormat.java:364) [rt.jar:1.8.0_131]
> at org.teiid.translator.amazon.s3.S3ProcedureExecution.next(S3ProcedureExecution.java:488) [translator-amazon-s3-8.12.11.6_4-redhat-64-6.jar:8.12.11.6_4-redhat-64-6]
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.handleBatch(ConnectorWorkItem.java:433)
> at org.teiid.dqp.internal.datamgr.ConnectorWorkItem.more(ConnectorWorkItem.java:236)
> at sun.reflect.GeneratedMethodAccessor211.invoke(Unknown Source) [:1.8.0_131]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_131]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_131]
> at org.teiid.dqp.internal.datamgr.ConnectorManager$1.invoke(ConnectorManager.java:211)
> at com.sun.proxy.$Proxy79.more(Unknown Source)
> at org.teiid.dqp.internal.process.DataTierTupleSource.getResults(DataTierTupleSource.java:309)
> 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_131]
> at org.teiid.dqp.internal.process.FutureWork.run(FutureWork.java:65)
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:280)
> 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:1142) [rt.jar:1.8.0_131]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_131]
> at java.lang.Thread.run(Thread.java:748) [rt.jar:1.8.0_131]
> {noformat}.
> The actual input string reffered to in the stack trace occasionaly contains garbage data.
> This is caused by unsynchronized access to a static SimpleDateFormat field here: https://github.com/teiid/teiid/blob/64-8.12.x/connectors/translator-amazo...
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
7 years, 2 months