[JBoss JIRA] (TEIID-5581) No @nextlink for virtualized procedure
by Johnathon Lee (Jira)
[ https://issues.jboss.org/browse/TEIID-5581?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-5581:
---------------------------------
Fix Version/s: 8.12.18.6_4
> 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
> Fix For: 12.0, 11.2.2, 8.12.18.6_4
>
> 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, 3 months
[JBoss JIRA] (TEIID-4508) DDL procedure update count not handled correctly
by Johnathon Lee (Jira)
[ https://issues.jboss.org/browse/TEIID-4508?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-4508:
---------------------------------
Fix Version/s: 8.12.18.6_4
> DDL procedure update count not handled correctly
> ------------------------------------------------
>
> Key: TEIID-4508
> URL: https://issues.jboss.org/browse/TEIID-4508
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 7.0
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 9.1, 9.0.5, 8.12.18.6_4
>
>
> The handling for procedure.updateCount was based upon the index file logic that effectively needed to have 1 subtracted from the value. So when ddl specified 2, it was actually be interpreted as 1. The index metadata workaround needs to be moved and the rest of the handling needs to be made consistent.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 3 months
[JBoss JIRA] (TEIID-5500) Improve OData performance
by Ramesh Reddy (Jira)
[ https://issues.jboss.org/browse/TEIID-5500?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-5500:
-------------------------------------
Hopefully to update the server-ext framework for this should not be too much work.
Originally I did not pursue this because we were always working with a small batch size of 256 which is default, so EntityCollection size of limited in terms of memory exhaustion. But having the "chunked" response is the key thing here for managing the client side of the equation, which I did not consider before. But I do think Olingo supports the inflight parsing on the client side, which is not necessarily a concern from Teiid point of view.
> Improve OData performance
> -------------------------
>
> Key: TEIID-5500
> URL: https://issues.jboss.org/browse/TEIID-5500
> Project: Teiid
> Issue Type: Enhancement
> Components: OData, Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 12.2
>
>
> See https://developer.jboss.org/thread/277783
> There is a significant overhead for OData vs. JDBC for a single client especially in terms of latency.
> We should investigate pre-building additional batch results and entity caching in general.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 3 months
[JBoss JIRA] (TEIID-5680) Improve performance of odata expand operations
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5680?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-5680.
-----------------------------------
Resolution: Done
Marking the issue as effectively resolved by identifying 2 underlying issues that address the concerns here.
> Improve performance of odata expand operations
> ----------------------------------------------
>
> Key: TEIID-5680
> URL: https://issues.jboss.org/browse/TEIID-5680
> Project: Teiid
> Issue Type: Enhancement
> Components: OData
> Reporter: Christoph John
> Assignee: Steven Hawkins
> Priority: Major
> Attachments: test2.txt
>
>
> Hello Ramesh and Steven,
> this is a follow up regarding an observation in the discussion from TEIID-5643. I thought I open an extra issue for the topic as this seems not to be related to TEIID-5500.
> As you already know, I am using SAPUI5 as frontend for ODATA requests. SAPUI5 supports binding of a user interface control group (like a list with its list items) to a single ODATA path at a time only. If the control group items require additional information which is stored in a different table in the database, I have to expand those parameters in the odata query.
> When doing so, I am running in a serious performance issue with TEIID, which would render the approach of using sapui5 with Teiid infeasible if we cannot find a way to speedup the issue. At the moment I have a small table with entries (table Diary with about 20 records) for which the query extracts several items (just a single one in the example given below). Now the filtered item is expanded with data from a larger table in the database (FDBProducts with about 680.000 records). The whole query takes about 15s to be processed. The query is given as:
> https://morpheus.fritz.box/odata4/svc/my_nutri_diary/Diary?$select=Amount...
> I checked the output when using
> <logger category="org.teiid.CONNECTOR"><level name="TRACE"/></logger>
> This shows the problem. It seems the join operation is not pushed down to the database but the data are rather joined within Teiid. Teiid therefore downloads the entire dataset of the large FDBProducts table, which makes the expand approach infeasible for real world datasets with a certain size. So my question is, if you can modify Teiid to push down the entire join operation to the underlaying database (I assume this would be the most efficient approach), or alternatively query just the items from the table to be joined which where filtered from the first table if the first option is not possible?
> Thanks for your help.
> Christoph
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 3 months
[JBoss JIRA] (TEIID-4856) OData - Teiid throws IndexOutOfBoundsException if user requests value of nonexistent propery
by Johnathon Lee (Jira)
[ https://issues.jboss.org/browse/TEIID-4856?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-4856:
---------------------------------
Fix Version/s: 8.12.18.6_4
> OData - Teiid throws IndexOutOfBoundsException if user requests value of nonexistent propery
> --------------------------------------------------------------------------------------------
>
> Key: TEIID-4856
> URL: https://issues.jboss.org/browse/TEIID-4856
> Project: Teiid
> Issue Type: Bug
> Components: OData
> Affects Versions: 9.3
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 9.3, 8.12.18.6_4
>
>
> If user requests property of entity which is not present, Teiid returns 404 (this is correct behavior). However, if user requests value of the property ($value), Teiid returns 500 which is cause by IndexOutOfBoundsException \[1\]. VDB \[2\].
> http://localhost:8080/odata4/vdb/test/t1(1)/fk/id/ - returns 404
> http://localhost:8080/odata4/vdb/test/t1(1)/fk/id/$value - returns 500
> {code:text|title=\[1\] Exception}
> 09:20:27,462 ERROR [org.teiid.ODATA] (default task-26) TEIID16052 Unable to process odata request due to: Index: 0, Size: 0: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
> at java.util.ArrayList.rangeCheck(ArrayList.java:638)
> at java.util.ArrayList.get(ArrayList.java:414)
> at org.teiid.olingo.service.TeiidServiceHandler$1.visit(TeiidServiceHandler.java:189)
> at org.apache.olingo.server.core.responses.PrimitiveValueResponse.accepts(PrimitiveValueResponse.java:113)
> at org.teiid.olingo.service.TeiidServiceHandler.read(TeiidServiceHandler.java:179)
> at org.apache.olingo.server.core.requests.DataRequest$ValueRequest.execute(DataRequest.java:674)
> at org.apache.olingo.server.core.requests.DataRequest.execute(DataRequest.java:255)
> at org.apache.olingo.server.core.ServiceDispatcher.internalExecute(ServiceDispatcher.java:160)
> at org.apache.olingo.server.core.ServiceDispatcher.execute(ServiceDispatcher.java:98)
> at org.apache.olingo.server.core.OData4HttpHandler.process(OData4HttpHandler.java:67)
> at org.teiid.olingo.web.ODataServlet.service(ODataServlet.java:43)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at org.teiid.olingo.web.ODataFilter.internalDoFilter(ODataFilter.java:228)
> at org.teiid.olingo.web.ODataFilter.doFilter(ODataFilter.java:100)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at org.teiid.olingo.web.gzip.GzipFilter.doFilter(GzipFilter.java:61)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at org.teiid.olingo.web.CorsFilter.doFilter(CorsFilter.java:80)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:60)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:744)
> {code}
> {code:xml|title=\[2\] VDB}
> <vdb name="vdb" version="1">
> <model name="test" type="VIRTUAL">
> <metadata>
> CREATE VIEW t1 (
> id integer PRIMARY KEY,
> fid integer,
> CONSTRAINT fk FOREIGN KEY (fid) REFERENCES t1(id))
> AS
> SELECT 1, null;
> </metadata>
> </model>
> </vdb>
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 3 months
[JBoss JIRA] (TEIID-5690) getVDBs in domain mode is returning the VDBs of one cluster
by Mark Tawk (Jira)
Mark Tawk created TEIID-5690:
--------------------------------
Summary: getVDBs in domain mode is returning the VDBs of one cluster
Key: TEIID-5690
URL: https://issues.jboss.org/browse/TEIID-5690
Project: Teiid
Issue Type: Bug
Reporter: Mark Tawk
Assignee: Steven Hawkins
The method "getDomainAwareList" used into "getVDBs()" is always used with the parameter "singleInstance" set to true.
That's why "getVDBs()" is returning only the VDBs of one cluster.
or "singleInstance" should be set to false when having multiple clusters
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 3 months
[JBoss JIRA] (TEIID-5688) groupby functionality not working with Teiid
by Ramesh Reddy (Jira)
[ https://issues.jboss.org/browse/TEIID-5688?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-5688:
-------------------------------------
The lead for that project on parental leave, I am guessing it would be at least a couple more weeks before any progress on this.
> groupby functionality not working with Teiid
> --------------------------------------------
>
> Key: TEIID-5688
> URL: https://issues.jboss.org/browse/TEIID-5688
> Project: Teiid
> Issue Type: Bug
> Reporter: Christoph John
> Assignee: Steven Hawkins
> Priority: Major
>
> Hello together,
> I tried to get the distinct values of a certain column in a mysql table and used the following query
> https://morpheus.fritz.box/odata4/svc/my_nutri_diary/Diary?$select=fkIdPr...
> However, it seems the apply=group is ignored from Teiid. I retrieve all records with fkIdProductCode and not just a single one. In the example below the first and last record both have the same fkIdProductCode. I would expect to retrieve just a single result. The result in my example looks as follows:
> {
> @odata.context: "https://morpheus.fritz.box/odata4/svc/my_nutri_diary/$metadata#Diary(idDi...",
> value: [
> {
> @odata.id: "https://morpheus.fritz.box/odata4/svc/my_nutri_diary/Diary(17)",
> idDiaryEntry: 17,
> fkIdProductCode: 17
> },
> {
> @odata.id: "https://morpheus.fritz.box/odata4/svc/my_nutri_diary/Diary(18)",
> idDiaryEntry: 18,
> fkIdProductCode: 38
> },
> {
> @odata.id: "https://morpheus.fritz.box/odata4/svc/my_nutri_diary/Diary(19)",
> idDiaryEntry: 19,
> fkIdProductCode: 482
> },
> {
> @odata.id: "https://morpheus.fritz.box/odata4/svc/my_nutri_diary/Diary(20)",
> idDiaryEntry: 20,
> fkIdProductCode: 1564
> },
> {
> @odata.id: "https://morpheus.fritz.box/odata4/svc/my_nutri_diary/Diary(21)",
> idDiaryEntry: 21,
> fkIdProductCode: 17
> }
> ]
> }
> So as a matter of principle, I would like to get each fkIdProductCode in the Diary table just once and expand its name via a navigationProperty. Is there some other workaround, how I could achieve this?
> Thanks for your help
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 3 months