[JBoss JIRA] (TEIID-5585) Insert of a disk backed temporary lob into a temp table is un-readable
by Steven Hawkins (Jira)
Steven Hawkins created TEIID-5585:
-------------------------------------
Summary: Insert of a disk backed temporary lob into a temp table is un-readable
Key: TEIID-5585
URL: https://issues.jboss.org/browse/TEIID-5585
Project: Teiid
Issue Type: Bug
Components: Query Engine
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 12.0
This can be reproduced with a script like:
insert into #temp select 1 as x, cast(repeat('1', 4000) as clob) y;
insert into #temp select 2, concat((select y from #temp where x = 1), (select y from #temp where x = 1));
insert into #temp select 3, concat((select y from #temp where x = 2), (select y from #temp where x = 2));
insert into #temp select 4, concat((select y from #temp where x = 3), (select y from #temp where x = 3));
-- will fail
insert into #temp select 5, concat((select y from #temp where x = 4), (select y from #temp where x = 4));
The #4 clob is unreadable as the backing filestore is removed after insert.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (TEIID-5581) No @nextlink for virtualized procedure
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5581?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5581:
---------------------------------------
I went ahead and merged the pr for 12. This will also be added to 11.2. [~cmondesir] please link to a bz if you need a further back port.
> No @nextlink for virtualized procedure
> --------------------------------------
>
> Key: TEIID-5581
> URL: https://issues.jboss.org/browse/TEIID-5581
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 8.12.16.6_4
> Reporter: Colin Mondesir
> Assignee: Steven Hawkins
> Priority: Major
> Attachments: example.xmi, procExample_Odata_Results.xml, procExample_SELECT.sql
>
>
> If we query a table "Field" via VDB, we get the following line in XML :
> <a:link rel="next" href="http://<IP-address>:8080/odata4/UDVvdb.13/BusinessObjects/Field?$skiptoken=6lS4u9tYdm4j,256"/>
> This allow end-user to loop on results easily.
> But when we call virtualized procedure, we do not see that line.
> It looks like :
> <m:value xmlns:m="http://docs.oasis-open.org/odata/ns/metadata" xmlns:d="http://docs.oasis-open.org/odata/ns/data" xmlns:a="http://www.w3.org/2005/Atom" m:type="#Collection(UDVvdb.13.Wellmap.getOffsetWells_ResultSet)" m:context="$metadata#Collection(UDVvdb.13.Wellmap.getOffsetWells_ResultSet)">
> [List of <m:element>]
> </m:value>
> Odata batch is currently limited to 256 so without a next link it's not possible to get to the rest of the data.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (TEIID-5563) Separate the Teiid WildFly distribution into their own repo or module
by Ramesh Reddy (Jira)
[ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-5563:
-------------------------------------
There is never better timing, since we are in flow I suggest take the plunge :)
> Separate the Teiid WildFly distribution into their own repo or module
> ---------------------------------------------------------------------
>
> Key: TEIID-5563
> URL: https://issues.jboss.org/browse/TEIID-5563
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits, Integration Tests
> Affects Versions: 12.x
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Major
>
> With the different types of distributions now being built based on Teiid like
> * WildFly
> * Thorntail
> * SpringBoot
> * Embedded
> Having main `github.com/teiid` repo contain artifacts for WildFly distribution poses an unnecessary dependency burden on other distributions. For example, the resource adapters are mainly for use with WildFly and Thorntail V2. They can still be applicable to embedded and SpringBoot as either non-managed connection factories, or require the user to provide appropriate management / pooling. When they are pulled into environments like SpringBoot they will bring several wildfly dependencies / and JEE constructs that are unnecessary - specifically the dependencies jboss-jaxws-api (teiid-api), javax.activation (teiid-core), jboss-transaction-api (teiid-api), and jboss-connector-api (teiid-api).
> This proposal is to separate "teiid" core modules along with all translators into one repository and move all the resource adapters along with any feature-packs and module building into a sperate repository like "teiid-wildfly". With the goal of providing similar connectivity in SpringBoot using as much common logic from SpringBoot (Spring Data in particular) and even Fuse as possible.
> Basically, when finished, the core Teiid modules only provide Maven artifacts along with their clean pom.xml with for direct and maybe transitive dependencies. None of the WildFly based modules support will be here. At worst this may introduce duplicate dependencies into the WildFly environment as we will need to manage all core / translator dependencies independently from those provided by WildFly. Where possible the teiid-api / core modules will need to use the generic javax dependency - or even remove the dependency if possible.
> The "teiid-wildfly" module on the other hand, will exactly preserve what is in the current repo as far feature packs and module building and overall WildFly distribution building.
> A follow-on task we can task we can look into is, converting the main teiid then to use basepom rather than the jboss-parent pom. However, the recommendation is this should be done after, not simultaneously.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (TEIID-5521) Add build plugins used by basepom to help with dependency handling
by Van Halbert (Jira)
[ https://issues.jboss.org/browse/TEIID-5521?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-5521:
------------------------------------
And due to my never using these plugins before, just realized that teiid-komodo has these turned off. So I will use this jira for teiid and create another in teiidtools for komodo.
> Add build plugins used by basepom to help with dependency handling
> ------------------------------------------------------------------
>
> Key: TEIID-5521
> URL: https://issues.jboss.org/browse/TEIID-5521
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits
> Affects Versions: 12.x
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Major
> Fix For: 12.1
>
>
> Utilize plugins that basebom uses, which will help reduce half the headaches you go though during the productization with versions.
> plugins:
> * duplicate-finder-maven-plugin
> * maven-dependency-plugin
> * maven-dependency-versions-check-plugin
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (TEIID-5521) Add build plugins used by basepom to help with dependency handling
by Van Halbert (Jira)
[ https://issues.jboss.org/browse/TEIID-5521?page=com.atlassian.jira.plugin... ]
Van Halbert edited comment on TEIID-5521 at 1/4/19 9:49 AM:
------------------------------------------------------------
The 3 plugins indicated above, are defined in the teiid-komodo pom.xml. So the next step is add those to the teiid project. Or should we change the parent for Teiid to the basebom?
was (Author: van.halbert):
The 3 plugins indicated above, are defined in the teiid-komodo pom.xml. So the next step is add those to the teiid project.
> Add build plugins used by basepom to help with dependency handling
> ------------------------------------------------------------------
>
> Key: TEIID-5521
> URL: https://issues.jboss.org/browse/TEIID-5521
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits
> Affects Versions: 12.x
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Major
> Fix For: 12.1
>
>
> Utilize plugins that basebom uses, which will help reduce half the headaches you go though during the productization with versions.
> plugins:
> * duplicate-finder-maven-plugin
> * maven-dependency-plugin
> * maven-dependency-versions-check-plugin
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (TEIID-5521) Add build plugins used by basepom to help with dependency handling
by Van Halbert (Jira)
[ https://issues.jboss.org/browse/TEIID-5521?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-5521:
------------------------------------
The 3 plugins indicated above, are defined in the teiid-komodo pom.xml. So the next step is add those to the teiid project.
> Add build plugins used by basepom to help with dependency handling
> ------------------------------------------------------------------
>
> Key: TEIID-5521
> URL: https://issues.jboss.org/browse/TEIID-5521
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits
> Affects Versions: 12.x
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Major
> Fix For: 12.1
>
>
> Utilize plugins that basebom uses, which will help reduce half the headaches you go though during the productization with versions.
> plugins:
> * duplicate-finder-maven-plugin
> * maven-dependency-plugin
> * maven-dependency-versions-check-plugin
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (TEIID-5563) Separate the Teiid WildFly distribution into their own repo or module
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5563:
---------------------------------------
So the proposal for Teiid 12 is to redo the group and some of the artifact names under the wildfly module - they will have a consistent parent, go back to using the term connector, and replace jboss with wildfly where appropriate.
This will affect a limited number of users of Teiid embedded that have followed the teiid embedded examples (which will need updated) that reference the resource adapter jars.
I'm fine if we defer the change to translators group id.
> Separate the Teiid WildFly distribution into their own repo or module
> ---------------------------------------------------------------------
>
> Key: TEIID-5563
> URL: https://issues.jboss.org/browse/TEIID-5563
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits, Integration Tests
> Affects Versions: 12.x
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Major
>
> With the different types of distributions now being built based on Teiid like
> * WildFly
> * Thorntail
> * SpringBoot
> * Embedded
> Having main `github.com/teiid` repo contain artifacts for WildFly distribution poses an unnecessary dependency burden on other distributions. For example, the resource adapters are mainly for use with WildFly and Thorntail V2. They can still be applicable to embedded and SpringBoot as either non-managed connection factories, or require the user to provide appropriate management / pooling. When they are pulled into environments like SpringBoot they will bring several wildfly dependencies / and JEE constructs that are unnecessary - specifically the dependencies jboss-jaxws-api (teiid-api), javax.activation (teiid-core), jboss-transaction-api (teiid-api), and jboss-connector-api (teiid-api).
> This proposal is to separate "teiid" core modules along with all translators into one repository and move all the resource adapters along with any feature-packs and module building into a sperate repository like "teiid-wildfly". With the goal of providing similar connectivity in SpringBoot using as much common logic from SpringBoot (Spring Data in particular) and even Fuse as possible.
> Basically, when finished, the core Teiid modules only provide Maven artifacts along with their clean pom.xml with for direct and maybe transitive dependencies. None of the WildFly based modules support will be here. At worst this may introduce duplicate dependencies into the WildFly environment as we will need to manage all core / translator dependencies independently from those provided by WildFly. Where possible the teiid-api / core modules will need to use the generic javax dependency - or even remove the dependency if possible.
> The "teiid-wildfly" module on the other hand, will exactly preserve what is in the current repo as far feature packs and module building and overall WildFly distribution building.
> A follow-on task we can task we can look into is, converting the main teiid then to use basepom rather than the jboss-parent pom. However, the recommendation is this should be done after, not simultaneously.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (TEIID-5563) Separate the Teiid WildFly distribution into their own repo or module
by Van Halbert (Jira)
[ https://issues.jboss.org/browse/TEIID-5563?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-5563:
------------------------------------
Now that the wildfly reorg is done, can this be closed and a new one opened to focus on what's to be done next?
> Separate the Teiid WildFly distribution into their own repo or module
> ---------------------------------------------------------------------
>
> Key: TEIID-5563
> URL: https://issues.jboss.org/browse/TEIID-5563
> Project: Teiid
> Issue Type: Task
> Components: Build/Kits, Integration Tests
> Affects Versions: 12.x
> Reporter: Van Halbert
> Assignee: Van Halbert
> Priority: Major
>
> With the different types of distributions now being built based on Teiid like
> * WildFly
> * Thorntail
> * SpringBoot
> * Embedded
> Having main `github.com/teiid` repo contain artifacts for WildFly distribution poses an unnecessary dependency burden on other distributions. For example, the resource adapters are mainly for use with WildFly and Thorntail V2. They can still be applicable to embedded and SpringBoot as either non-managed connection factories, or require the user to provide appropriate management / pooling. When they are pulled into environments like SpringBoot they will bring several wildfly dependencies / and JEE constructs that are unnecessary - specifically the dependencies jboss-jaxws-api (teiid-api), javax.activation (teiid-core), jboss-transaction-api (teiid-api), and jboss-connector-api (teiid-api).
> This proposal is to separate "teiid" core modules along with all translators into one repository and move all the resource adapters along with any feature-packs and module building into a sperate repository like "teiid-wildfly". With the goal of providing similar connectivity in SpringBoot using as much common logic from SpringBoot (Spring Data in particular) and even Fuse as possible.
> Basically, when finished, the core Teiid modules only provide Maven artifacts along with their clean pom.xml with for direct and maybe transitive dependencies. None of the WildFly based modules support will be here. At worst this may introduce duplicate dependencies into the WildFly environment as we will need to manage all core / translator dependencies independently from those provided by WildFly. Where possible the teiid-api / core modules will need to use the generic javax dependency - or even remove the dependency if possible.
> The "teiid-wildfly" module on the other hand, will exactly preserve what is in the current repo as far feature packs and module building and overall WildFly distribution building.
> A follow-on task we can task we can look into is, converting the main teiid then to use basepom rather than the jboss-parent pom. However, the recommendation is this should be done after, not simultaneously.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months
[JBoss JIRA] (TEIID-5583) Provide ability to monitor how much memory matviews are using
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5583?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5583:
---------------------------------------
> But we have no feature that allows us to monitor how exactly how much memory matviews are actually using, this makes adjusting the heap to match changing requirement difficult.
Generally you do not need to adjust the heap for materialization. Only page metadata and the table structures are held in heap memory - the actual data pages are pushed to lower storage tiers as necessary.
>From the linked case it should first be determined what is holding the memory that is causing the OOM exception.
> Provide ability to monitor how much memory matviews are using
> -------------------------------------------------------------
>
> Key: TEIID-5583
> URL: https://issues.jboss.org/browse/TEIID-5583
> Project: Teiid
> Issue Type: Enhancement
> Reporter: Colin Mondesir
> Assignee: Steven Hawkins
> Priority: Major
>
> In the docs it says "Internal materialization (and temp tables in general) have memory overhead for each page. A rough guideline is that there can be 100 million rows in all materialized tables across all VDBs for every gigabyte of heap."
> But we have no feature that allows us to monitor how exactly how much memory matviews are actually using, this makes adjusting the heap to match changing requirement difficult.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 6 months