June 2014 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-3022) refine removed vdb handling

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-3022: ------------------------------------- Summary: refine removed vdb handling Key: TEIID-3022 URL: https://issues.jboss.org/browse/TEIID-3022 Project: Teiid Issue Type: Quality Risk Security Level: Public (Everyone can see) Components: Server Affects Versions: 8.1 Reporter: Steven Hawkins Assignee: Steven Hawkins With TEIID-2105 the server will reject requests against a non-active vdb, which includes a removed vdb. This is against the original intent of allowing for lazy cleanup. We should either have a vdb remove proactively terminate all sessions and fully cleanup or we should reinstate the lazy logic. At this point it probably makes the most sense to go the first route as there is other logic (materialization management for one) now checking the vdb state and assuming that removal will invalidate the vdb. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3018) Reflect view transformation sql into SYSTEM schema

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3018?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-3018. ----------------------------------- Fix Version/s: 8.8 Resolution: Done Added VIEWS and STOREDPROCEDURES tables - https://docs.jboss.org/author/display/TEIID/System+Tables This information was not yet added to the SYS TABLE/PROCEDURE since we already established a precedent with TRIGGERS and non-public information, and it would require api changes for us to better calculate the permissions to see the definition body (since we don't minimize projection down to the system tables, we'd currently have to compute all columns). We also left the informational column as "body" rather than "definition" since it will only contain the statement/query expression/etc. rather than the full DDL declaration - this is largely due to how we store the information on the metadata object and don't want to incur the overhead of the DDL generation. It may be necessary at some point though to provide the entire statement. > Reflect view transformation sql into SYSTEM schema > -------------------------------------------------- > > Key: TEIID-3018 > URL: https://issues.jboss.org/browse/TEIID-3018 > Project: Teiid > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Mark Addleman > Assignee: Steven Hawkins > Fix For: 8.8 > > > It would nice to reflect view transformation SQL in the SYSTEM schema > See https://community.jboss.org/message/879519?et=watches.email.thread#879519 for more detail -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3020) Materialized View timeout on loading

by Mark Addleman (JIRA)

[ https://issues.jboss.org/browse/TEIID-3020?page=com.atlassian.jira.plugin... ] Mark Addleman commented on TEIID-3020: -------------------------------------- Thanks. The existing behavior is exactly what we want. > Materialized View timeout on loading > ------------------------------------ > > Key: TEIID-3020 > URL: https://issues.jboss.org/browse/TEIID-3020 > Project: Teiid > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Mark Addleman > Assignee: Steven Hawkins > > Materialized view should timeout on loading if the translator/data source takes too long to respond. > Perhaps time out when the initiating JDBC statement times out or is cancelled? > See https://community.jboss.org/thread/242372 for more info -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3020) Materialized View timeout on loading

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3020?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3020: --------------------------------------- With TEIID-2840 the default materialization load behavior is tied to the initiating query by default (previously. If it is timed out, the session is ended, etc. then the load will be aborted. > Materialized View timeout on loading > ------------------------------------ > > Key: TEIID-3020 > URL: https://issues.jboss.org/browse/TEIID-3020 > Project: Teiid > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Mark Addleman > Assignee: Steven Hawkins > > Materialized view should timeout on loading if the translator/data source takes too long to respond. > Perhaps time out when the initiating JDBC statement times out or is cancelled? > See https://community.jboss.org/thread/242372 for more info -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3020) Materialized View timeout on loading

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3020?page=com.atlassian.jira.plugin... ] Steven Hawkins edited comment on TEIID-3020 at 6/30/14 9:55 AM: ---------------------------------------------------------------- With TEIID-2840 the default materialization load behavior is tied to the initiating query by default (previously the default behavior typically would fork the load without invalidating). If it is timed out, the session is ended, etc. then the load will be aborted. was (Author: shawkins): With TEIID-2840 the default materialization load behavior is tied to the initiating query by default (previously. If it is timed out, the session is ended, etc. then the load will be aborted. > Materialized View timeout on loading > ------------------------------------ > > Key: TEIID-3020 > URL: https://issues.jboss.org/browse/TEIID-3020 > Project: Teiid > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Mark Addleman > Assignee: Steven Hawkins > > Materialized view should timeout on loading if the translator/data source takes too long to respond. > Perhaps time out when the initiating JDBC statement times out or is cancelled? > See https://community.jboss.org/thread/242372 for more info -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3021) Serialization of long sqlexception/warning next chains can lead to oom

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3021?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-3021. ----------------------------------- Resolution: Done Changed the logic to not output the chain when it is a nested exception holder. > Serialization of long sqlexception/warning next chains can lead to oom > ---------------------------------------------------------------------- > > Key: TEIID-3021 > URL: https://issues.jboss.org/browse/TEIID-3021 > Project: Teiid > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Affects Versions: 8.1 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.7.1, 8.8 > > > The serialization logic for exception chains is not correct and will output exponentially too many instances of chained exceptions, which can lead to out of memory conditions. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3021) Serialization of long sqlexception/warning next chains can lead to oom

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3021?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated TEIID-3021: ------------------------------------------- Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1114589 > Serialization of long sqlexception/warning next chains can lead to oom > ---------------------------------------------------------------------- > > Key: TEIID-3021 > URL: https://issues.jboss.org/browse/TEIID-3021 > Project: Teiid > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Server > Affects Versions: 8.1 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.7.1, 8.8 > > > The serialization logic for exception chains is not correct and will output exponentially too many instances of chained exceptions, which can lead to out of memory conditions. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3021) Serialization of long sqlexception/warning next chains can lead to oom

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-3021: ------------------------------------- Summary: Serialization of long sqlexception/warning next chains can lead to oom Key: TEIID-3021 URL: https://issues.jboss.org/browse/TEIID-3021 Project: Teiid Issue Type: Bug Security Level: Public (Everyone can see) Components: Server Affects Versions: 8.1 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 8.7.1, 8.8 The serialization logic for exception chains is not correct and will output exponentially too many instances of chained exceptions, which can lead to out of memory conditions. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3020) Materialized View timeout on loading

by Mark Addleman (JIRA)

Mark Addleman created TEIID-3020: ------------------------------------ Summary: Materialized View timeout on loading Key: TEIID-3020 URL: https://issues.jboss.org/browse/TEIID-3020 Project: Teiid Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Mark Addleman Assignee: Steven Hawkins Materialized view should timeout on loading if the translator/data source takes too long to respond. Perhaps time out when the initiating JDBC statement times out or is cancelled? See https://community.jboss.org/thread/242372 for more info -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3019) Change SYSADMIN.refreshMatViewRow to support a list of rows instead of just one

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3019?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3019: --------------------------------------- Since this function was already updated to support composite keys via an array it would likely be best to start with a new refresh procedure that takes a two dimensional array for the bulk update. > Change SYSADMIN.refreshMatViewRow to support a list of rows instead of just one > ------------------------------------------------------------------------------- > > Key: TEIID-3019 > URL: https://issues.jboss.org/browse/TEIID-3019 > Project: Teiid > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Server > Reporter: Debbie Steigner > Assignee: Steven Hawkins > > Currently SYSADMIN.refreshMatViewRow supports only passing one key value so it will be nice to be able to pass multiple values or array of values for bulk updates. -- This message was sent by Atlassian JIRA (v6.2.6#6264)

10 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues June 2014