July 2015 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-3578) server becomes unresponsive after running for a while

by Jorge Herrera (JIRA)

[ https://issues.jboss.org/browse/TEIID-3578?page=com.atlassian.jira.plugin... ] Jorge Herrera commented on TEIID-3578: -------------------------------------- I switched from DB logging to file based logging, and the server has been up and responsive since friday. Will keep monitoring. But for now this specific issue seems to be resolved. > server becomes unresponsive after running for a while > ----------------------------------------------------- > > Key: TEIID-3578 > URL: https://issues.jboss.org/browse/TEIID-3578 > Project: Teiid > Issue Type: Bug > Components: Server > Affects Versions: 8.7.1 > Environment: RHEL 6, AWS VM, JBoss EAP (standalone) 6.3.2.GA > JBoss Data Virtualization 6.1.0.ER4 > Reporter: Jorge Herrera > Assignee: Steven Hawkins > Attachments: server.log, server_startup.log, stackTrace_TEIID-3578, threaddump.txt > > > Server becomes unresponsive, it does ack new sessions, but nothing else, admin-console, and direct queries are completely unresponsive. If I reboot the server it works just fine. Disk space / RAM / CPU all seem just fine. > [root@BIJDVDev2 ~]# df > Filesystem 1K-blocks Used Available Use% Mounted on > /dev/xvde1 6062016 4601808 1397596 77% / > none 7619624 0 7619624 0% /dev/shm > [BIJDVDev2.dev.a1.vary.redhat.com] [11:38:48 AM] > [root@BIJDVDev2 ~]# top > top - 11:43:05 up 14 days, 13:31, 1 user, load average: 0.00, 0.00, 0.00 > Tasks: 151 total, 1 running, 150 sleeping, 0 stopped, 0 zombie > Cpu(s): 0.1%us, 0.1%sy, 0.0%ni, 99.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st > Mem: 15239248k total, 5387488k used, 9851760k free, 203540k buffers > Swap: 0k total, 0k used, 0k free, 2887904k cached -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3583) Need documentation on possible property settings to use

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3583?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3583: --------------------------------------- This issue should probably focus on the end requirement, which is heap throttling. There are a couple of considerations/clarifications needed. First is that we make no hard guarantees on heap usage - parameters like these can only influence the pattern of consumption and are based upon estimates (and of course the vm will still accumulate garbage well over any target). Second we may need to clarify what they mean by active throttling - are they looking to adjust these parameters at runtime (not currently possible) or even down to a query level (not currently possible). Third as mentioned above the affect will largely be dependent upon workload and how the other values have been set. Under a high uniform query volume reducing the max-reserve-kb may not influence memory consumption very much if max-processing-kb / max active plans allow for a large memory usage. Is it possible that we can get a better understanding of their goals? Also some of the work that was done for TEIID-2429 mitigates the need to adjust these values. If max-processing-kb is left at its default, then we'll automatically assume a balanced allocation plan such that we'll nominally not exceed max-reserve-kb by just plan processing. > Need documentation on possible property settings to use > ------------------------------------------------------- > > Key: TEIID-3583 > URL: https://issues.jboss.org/browse/TEIID-3583 > Project: Teiid > Issue Type: Enhancement > Reporter: Van Halbert > Assignee: Steven Hawkins > > In the Administration and Configuration Guide there is some indication on how to perform active heap throttling. > "Memory Management Considerations " there is a reference to parameters like: > max-processing-kb and the max-reserve-kb. > Anyway there is no indication of the indicative values to associate to those parameters to obtain a certain result. > It would be good to get some examples to understand the cause and effect of the changes ( max-reserve-kb and related settings ). -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3502) Teiid returns integer/long overflow values

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3502?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3502: --------------------------------------- This is only partially resolved for 8.11 and 8.11.1 given that odbc metadata failures will occur with large precision values. > Teiid returns integer/long overflow values > ------------------------------------------ > > Key: TEIID-3502 > URL: https://issues.jboss.org/browse/TEIID-3502 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.7.1.6_2 > Reporter: Juraj Duráni > Assignee: Steven Hawkins > Fix For: 8.12, 8.11.2 > > > The values from basic math operations, such as: > SELECT abs(-2147483648) > SELECT -2147483648 -1 > SELECT 2147483648 +1 > etc. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3502) Teiid returns integer/long overflow values

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3502?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-3502: ---------------------------------- Fix Version/s: 8.11.2 (was: 8.11.1) > Teiid returns integer/long overflow values > ------------------------------------------ > > Key: TEIID-3502 > URL: https://issues.jboss.org/browse/TEIID-3502 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.7.1.6_2 > Reporter: Juraj Duráni > Assignee: Steven Hawkins > Fix For: 8.12, 8.11.2 > > > The values from basic math operations, such as: > SELECT abs(-2147483648) > SELECT -2147483648 -1 > SELECT 2147483648 +1 > etc. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3563) Problems with capabilities initialization

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3563?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-3563: ---------------------------------- Fix Version/s: 8.11.2 (was: 8.11.1) > Problems with capabilities initialization > ----------------------------------------- > > Key: TEIID-3563 > URL: https://issues.jboss.org/browse/TEIID-3563 > Project: Teiid > Issue Type: Bug > Components: JDBC Connector > Affects Versions: 8.11 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.7.1.6_2, 8.12, 8.11.2 > > > TEIID-3474 and somewhat TEIID-3483 introduced an issue with initializing capabilities. Postgresql effectively requires the database version set as a workaround. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3501) IN clause - teradata does not support "CAST( ... AS ...)" statement in "IN(...)"

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3501?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-3501. ----------------------------------- Resolution: Done > IN clause - teradata does not support "CAST( ... AS ...)" statement in "IN(...)" > -------------------------------------------------------------------------------- > > Key: TEIID-3501 > URL: https://issues.jboss.org/browse/TEIID-3501 > Project: Teiid > Issue Type: Bug > Affects Versions: 8.7.1.6_2 > Environment: teradata version: 15 > Reporter: Juraj Duráni > Assignee: Steven Hawkins > Fix For: 8.12, 8.11.2 > > > The teradata DB does not support CAST statement in IN. Query (1), teradata exception (2), source specific command (3), query that teradata accepts (4). > (1) SELECT BQT1.SmallA.IntKey FROM BQT1.SmallA WHERE BQT1.SmallA.TimeStampValue IN (convert('2000-01-01 00:00:12.0', timestamp), convert('2000-01-01 00:00:45.0', timestamp)) ORDER BY IntKey > (2) SELECT g_0.intkey AS c_0 FROM smalla AS g_0 WHERE g_0.timestampvalue IN (cast('2000-01-01 00:00:12.0' AS TIMESTAMP(6)), cast('2000-01-01 00:00:45.0' AS TIMESTAMP(6))) ORDER BY 1 > (3) SELECT g_0.intkey AS c_0 FROM smalla AS g_0 WHERE g_0.timestampvalue IN ('2000-01-01 00:00:12.0', '2000-01-01 00:00:45.0') ORDER BY 1 > (4) Caused by: java.sql.SQLException: [Teradata Database] [TeraJDBC 15.10.00.05] [Error 3706] [SQLState 42000] Syntax error: expected something between ')' and ','. > at com.teradata.jdbc.jdbc_4.util.ErrorFactory.makeDatabaseSQLException(ErrorFactory.java:308) > ... -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3587) Add ability to load translator module based "slot" classfication

by Ramesh Reddy (JIRA)

Ramesh Reddy created TEIID-3587: ----------------------------------- Summary: Add ability to load translator module based "slot" classfication Key: TEIID-3587 URL: https://issues.jboss.org/browse/TEIID-3587 Project: Teiid Issue Type: Enhancement Components: Server Affects Versions: 8.0 Reporter: Ramesh Reddy Assignee: Ramesh Reddy Fix For: 8.12 Currently translator configuration in the Teiid sub-system can only load from module name, which always points to "main" slot. This configuration needs to be expanded such that user can define a specific "slot" of module to use to load the configured translator -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3586) Literal date comparisons with databasetimezone set are incorrect

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-3586: ------------------------------------- Summary: Literal date comparisons with databasetimezone set are incorrect Key: TEIID-3586 URL: https://issues.jboss.org/browse/TEIID-3586 Project: Teiid Issue Type: Bug Components: JDBC Connector Affects Versions: 8.0 Reporter: Steven Hawkins Assignee: Steven Hawkins Priority: Critical Fix For: 8.12 If the database timezone property is set and a literal comparison is used, then the date value will be shifted from the local timezone into the database timezone, but it should be the other way around. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3562) Teradata15 - teiid shifts date/time/timestamp values according to timezone.

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3562?page=com.atlassian.jira.plugin... ] Steven Hawkins reopened TEIID-3562: ----------------------------------- > Teradata15 - teiid shifts date/time/timestamp values according to timezone. > --------------------------------------------------------------------------- > > Key: TEIID-3562 > URL: https://issues.jboss.org/browse/TEIID-3562 > Project: Teiid > Issue Type: Bug > Affects Versions: 8.7.1.6_2 > Environment: teradata version - 15.00.01.01 > teradata driver version - 15.10.00.05 > Reporter: Juraj Duráni > Assignee: Steven Hawkins > Attachments: Main.java, out_GMT+0500, out_GMT_not_set > > > Teiid shifts date/time/timestamp values returned from teradata according to user.timezone value [1], [2]. However, when I execute source-specific command, teradata returns correct values [3]. > [1] > *Query:* SELECT * FROM smalla ORDER BY IntKey > *-Duser.timezone:* GMT+5 > *Result:* > || IntKey || DateValue || TimeValue || TimeStampValue || > |0 | 1999-12-31 | 19:00:00 | 1999-12-31 19:00:00.0| > |1 | 2000-01-01 | 20:00:00 | 1999-12-31 19:00:01.0| > |2 | 2000-01-02 | 21:00:00 | 1999-12-31 19:00:02.0| > |3 | 2000-01-03 | 22:00:00 | 1999-12-31 19:00:03.0| > |...|...|...|...| > [2] > *Query:* SELECT * FROM smalla ORDER BY IntKey > *-Duser.timezone:* GMT+1 > *Result:* > || IntKey || DateValue || TimeValue || TimeStampValue || > |0 | 1999-12-31 | 23:00:00 | 1999-12-31 23:00:00.0| > |1 | 2000-01-01 | 00:00:00 | 1999-12-31 23:00:01.0| > |2 | 2000-01-02 | 01:00:00 | 1999-12-31 23:00:02.0| > |3 | 2000-01-03 | 02:00:00 | 1999-12-31 23:00:03.0| > |...|...|...|...| > [3] > *Query:* SELECT g_0.IntKey AS c_0, g_0.DateValue AS c_1, g_0.TimeValue AS c_2, g_0.TimestampValue AS c_3 FROM smalla AS g_0 ORDER BY 1 > *local timezone:* GMT+1/GMT+5 > *Result:* > || c_0 || c_1 || c_2 || c_3 || > |0 | 2000-01-01 | 00:00:00 | 2000-01-01 00:00:00.0| > |1 | 2000-01-02 | 01:00:00 | 2000-01-01 00:00:01.0| > |2 | 2000-01-03 | 02:00:00 | 2000-01-01 00:00:02.0| > |3 | 2000-01-04 | 03:00:00 | 2000-01-01 00:00:03.0| > |...|...|...|...| -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3562) Teradata15 - teiid shifts date/time/timestamp values according to timezone.

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3562?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3562: --------------------------------------- I see two issues. The first is that our literal format logic is shifting the timezone value in the wrong direction. This will be corrected by a separate JIRA as it still won't resolve Teradata's behavior. The other is that Teradata's handling is not expected. For example for me in GMT-5, without any other settings, for intkey = 0 I see 2000-01-01 05:00:00.0 for the timestampvalue. If I search using a literal comparison using 2000-01-01 00:00:00, I'll still see 05:00:00 in the result. If I search using a preparedstatement using 2000-01-01 00:00:00, I get no results. - Both of those behaviors seem like driver issues. Repeating the same with H2 or Oracle will provide the same 00:00 result with all queries. Setting the database timezone to GMT, then I'll see 2000-01-01 00:00:00.0 for intkey 0 from a select. A literal comparison with 2000-01-01 00:00:00 produces no results, but a preparedstatement will work as expected. This again differs from other databases. A possible fix is to modify the translator to not shift the literal value as it appears teradata has some unexpected additional handling. Alternatively I looked at having the teradata connection explicitly set the client time zone without setting the database timezone using "set time zone 'GMT-5'". Here again the behavior seems inconsistent. While the desired value 2000-01-01 00:00:00 is shown. Using that same value in a literal or prepared statement binding returned no results. > Teradata15 - teiid shifts date/time/timestamp values according to timezone. > --------------------------------------------------------------------------- > > Key: TEIID-3562 > URL: https://issues.jboss.org/browse/TEIID-3562 > Project: Teiid > Issue Type: Bug > Affects Versions: 8.7.1.6_2 > Environment: teradata version - 15.00.01.01 > teradata driver version - 15.10.00.05 > Reporter: Juraj Duráni > Assignee: Steven Hawkins > Attachments: Main.java, out_GMT+0500, out_GMT_not_set > > > Teiid shifts date/time/timestamp values returned from teradata according to user.timezone value [1], [2]. However, when I execute source-specific command, teradata returns correct values [3]. > [1] > *Query:* SELECT * FROM smalla ORDER BY IntKey > *-Duser.timezone:* GMT+5 > *Result:* > || IntKey || DateValue || TimeValue || TimeStampValue || > |0 | 1999-12-31 | 19:00:00 | 1999-12-31 19:00:00.0| > |1 | 2000-01-01 | 20:00:00 | 1999-12-31 19:00:01.0| > |2 | 2000-01-02 | 21:00:00 | 1999-12-31 19:00:02.0| > |3 | 2000-01-03 | 22:00:00 | 1999-12-31 19:00:03.0| > |...|...|...|...| > [2] > *Query:* SELECT * FROM smalla ORDER BY IntKey > *-Duser.timezone:* GMT+1 > *Result:* > || IntKey || DateValue || TimeValue || TimeStampValue || > |0 | 1999-12-31 | 23:00:00 | 1999-12-31 23:00:00.0| > |1 | 2000-01-01 | 00:00:00 | 1999-12-31 23:00:01.0| > |2 | 2000-01-02 | 01:00:00 | 1999-12-31 23:00:02.0| > |3 | 2000-01-03 | 02:00:00 | 1999-12-31 23:00:03.0| > |...|...|...|...| > [3] > *Query:* SELECT g_0.IntKey AS c_0, g_0.DateValue AS c_1, g_0.TimeValue AS c_2, g_0.TimestampValue AS c_3 FROM smalla AS g_0 ORDER BY 1 > *local timezone:* GMT+1/GMT+5 > *Result:* > || c_0 || c_1 || c_2 || c_3 || > |0 | 2000-01-01 | 00:00:00 | 2000-01-01 00:00:00.0| > |1 | 2000-01-02 | 01:00:00 | 2000-01-01 00:00:01.0| > |2 | 2000-01-03 | 02:00:00 | 2000-01-01 00:00:02.0| > |3 | 2000-01-04 | 03:00:00 | 2000-01-01 00:00:03.0| > |...|...|...|...| -- This message was sent by Atlassian JIRA (v6.3.15#6346)

10 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues July 2015