March 2016 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-4047) OData - $top with negative value return status code 500

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-4047?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-4047: --------------------------------------- That seems like a good start. > OData - $top with negative value return status code 500 > ------------------------------------------------------- > > Key: TEIID-4047 > URL: https://issues.jboss.org/browse/TEIID-4047 > Project: Teiid > Issue Type: Sub-task > Components: OData > Reporter: Juraj Duráni > Assignee: Ramesh Reddy > > OData request with query option $top with negative value returns status code 500. The root cause is SQLException. OData service should check passed value and return e.g. 400 instead. > *URL:* http://localhost:8080/odata4/olingo_basic/Source/Customers/?$top=-1 > See http://docs.oasis-open.org/odata/odata/v4.0/errata02/os/complete/part1-pr... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (TEIID-4041) OData response does not contain header "allow"

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4041?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-4041: ------------------------------------- https://issues.apache.org/jira/browse/OLINGO-908 > OData response does not contain header "allow" > ---------------------------------------------- > > Key: TEIID-4041 > URL: https://issues.jboss.org/browse/TEIID-4041 > Project: Teiid > Issue Type: Sub-task > Components: OData > Reporter: Juraj Duráni > Assignee: Ramesh Reddy > > If user sends request to URL with unsupported HTTP method, OData service should return allowed methods in header _allow_. > *URL:* http://localhost:8080/odata4/olingo_basic/Source/SimpleTableView/ > *Method:* DELETE > *Response headers:* date=Wed, 09 Mar 2016 08:21:17 GMT, server=Apache-Coyote/1.1, content-length=192, expires=Thu, 01 Jan 1970 00:00:00 GMT+00:00, content-type=application/xml, cache-control=no-cache, pragma=No-cache, odata-version=4.0 > See http://docs.oasis-open.org/odata/odata/v4.0/errata02/os/complete/part1-pr... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (TEIID-4043) If some functionality is not supported then OData should return status code 501 instead of 500

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4043?page=com.atlassian.jira.plugin... ] Work on TEIID-4043 started by Ramesh Reddy. ------------------------------------------- > If some functionality is not supported then OData should return status code 501 instead of 500 > ---------------------------------------------------------------------------------------------- > > Key: TEIID-4043 > URL: https://issues.jboss.org/browse/TEIID-4043 > Project: Teiid > Issue Type: Sub-task > Components: OData > Reporter: Juraj Duráni > Assignee: Ramesh Reddy > > *URLs:* > - http://localhost:8080/odata4/olingo_basic/Source/Customers/?$expand=Order... > - http://localhost:8080/odata4/olingo_basic/Source/Customers/?$expand=Order... > - http://localhost:8080/odata4/olingo_basic/Source/Customers/?$expand=Order... > - http://localhost:8080/odata4/olingo_basic/Source/Customers/?$expand=Order... > None of these options is implemented, but OData service for every request returns status code 500. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (TEIID-4043) If some functionality is not supported then OData should return status code 501 instead of 500

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4043?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-4043: ------------------------------------- We will resolve this to return 501 now, but we need to enter another JIRA to implement the features at later date. > If some functionality is not supported then OData should return status code 501 instead of 500 > ---------------------------------------------------------------------------------------------- > > Key: TEIID-4043 > URL: https://issues.jboss.org/browse/TEIID-4043 > Project: Teiid > Issue Type: Sub-task > Components: OData > Reporter: Juraj Duráni > Assignee: Ramesh Reddy > > *URLs:* > - http://localhost:8080/odata4/olingo_basic/Source/Customers/?$expand=Order... > - http://localhost:8080/odata4/olingo_basic/Source/Customers/?$expand=Order... > - http://localhost:8080/odata4/olingo_basic/Source/Customers/?$expand=Order... > - http://localhost:8080/odata4/olingo_basic/Source/Customers/?$expand=Order... > None of these options is implemented, but OData service for every request returns status code 500. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (TEIID-4063) OData - $all returns 500 without message (generic error page of EAP)

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4063?page=com.atlassian.jira.plugin... ] Work on TEIID-4063 started by Ramesh Reddy. ------------------------------------------- > OData - $all returns 500 without message (generic error page of EAP) > -------------------------------------------------------------------- > > Key: TEIID-4063 > URL: https://issues.jboss.org/browse/TEIID-4063 > Project: Teiid > Issue Type: Sub-task > Components: OData > Reporter: Juraj Duráni > Assignee: Ramesh Reddy > > *URL:* http://localhost:8080/odata4/olingo_basic/Source/$all > *Result:* OData returns status code 500 without message. There is no error in the console log of Teiid server. > *Expected result:* if $all is not implemented then OData should return 501 otherwise correct result should be returned. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (TEIID-3050) allow for more incremental insert with iterator

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3050?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-3050. ----------------------------------- Fix Version/s: 9.0 8.12.5 8.13.3 (was: 8.9) Resolution: Done The logic for setting noTxn on the transaction context was not generally correct and was removed. Instead we'll always use the incremental approach. > allow for more incremental insert with iterator > ----------------------------------------------- > > Key: TEIID-3050 > URL: https://issues.jboss.org/browse/TEIID-3050 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors, Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 9.0, 8.12.5, 8.13.3 > > > The current bulk insert logic assumes that it is avoiding a global transactions by fully reading the results before sending the tuplebuffer iterator to the source for processing, which can then just use a local transaction. However if we are already operating under a transaction or the user doesn't want a transaction (such as with a staging materialized view load) then the insert should happen more incrementally. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (TEIID-3050) allow for more incremental insert with iterator

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3050?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-3050: --------------------------------------- With TEIID-3857 we already assume a transaction is needed. We should just assume incremental processing and address later if there is a need to not start an xa transaction - which is mitigated by TEIID-4076 > allow for more incremental insert with iterator > ----------------------------------------------- > > Key: TEIID-3050 > URL: https://issues.jboss.org/browse/TEIID-3050 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors, Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.9 > > > The current bulk insert logic assumes that it is avoiding a global transactions by fully reading the results before sending the tuplebuffer iterator to the source for processing, which can then just use a local transaction. However if we are already operating under a transaction or the user doesn't want a transaction (such as with a staging materialized view load) then the insert should happen more incrementally. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (TEIID-4076) Refine autoCommitTxn detect

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-4076: ------------------------------------- Summary: Refine autoCommitTxn detect Key: TEIID-4076 URL: https://issues.jboss.org/browse/TEIID-4076 Project: Teiid Issue Type: Feature Request Components: Query Engine Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 9.0 The current logic does not consider the type of source being accessed. In many circumstances we are coordinating a transaction with no sources participating. We should refine our logic to avoid unnecessary transactions. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (TEIID-3050) allow for more incremental insert with iterator

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3050?page=com.atlassian.jira.plugin... ] Steven Hawkins reopened TEIID-3050: ----------------------------------- > allow for more incremental insert with iterator > ----------------------------------------------- > > Key: TEIID-3050 > URL: https://issues.jboss.org/browse/TEIID-3050 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors, Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.9 > > > The current bulk insert logic assumes that it is avoiding a global transactions by fully reading the results before sending the tuplebuffer iterator to the source for processing, which can then just use a local transaction. However if we are already operating under a transaction or the user doesn't want a transaction (such as with a staging materialized view load) then the insert should happen more incrementally. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

[JBoss JIRA] (TEIID-4039) Resolving of entityid with $expand or $select fails

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-4039?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-4039: ------------------------------------- added https://issues.apache.org/jira/browse/OLINGO-907 I am guessing this could be a typo in the spec, where & is used instead of a ?, as the id represents full pledged URI according to the spec > Resolving of entityid with $expand or $select fails > --------------------------------------------------- > > Key: TEIID-4039 > URL: https://issues.jboss.org/browse/TEIID-4039 > Project: Teiid > Issue Type: Sub-task > Components: OData > Reporter: Juraj Duráni > Assignee: Ramesh Reddy > > *URL:* http://localhost:8080/odata4/olingo_basic/Source/$entity/?$id=Customers(1... > *Returned status code:* 404 > *URL:* http://localhost:8080/odata4/olingo_basic/Source/$entity/?$id=Customers(1... > *Returned status code:* 500 > In this case response does not contain mandatory OData-version header and server throws exception: > {code:plain} > 12:20:40,911 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/odata4].[odata4]] (http-/127.0.0.1:8080-1) JBWEB000236: Servlet.service() for servlet odata4 threw exception: java.util.EmptyStackException > at java.util.Stack.peek(Stack.java:102) [rt.jar:1.8.0-internal] > at org.apache.olingo.server.core.uri.parser.UriParseTreeVisitor.visitSelectSegment(UriParseTreeVisitor.java:2195) > at org.apache.olingo.server.core.uri.antlr.UriParserParser$SelectSegmentContext.accept(UriParserParser.java:3611) > at org.apache.olingo.server.core.uri.parser.UriParseTreeVisitor.visitSelectItem(UriParseTreeVisitor.java:2168) > at org.apache.olingo.server.core.uri.antlr.UriParserParser$SelectItemContext.accept(UriParserParser.java:3541) > at org.apache.olingo.server.core.uri.parser.UriParseTreeVisitor.visitSelectEOF(UriParseTreeVisitor.java:2153) > at org.apache.olingo.server.core.uri.parser.Parser.parseUri(Parser.java:228) > at org.apache.olingo.server.core.ErrorHandler.handleServerError(ErrorHandler.java:93) > at org.apache.olingo.server.core.ErrorHandler.handleException(ErrorHandler.java:85) > at org.apache.olingo.server.core.OData4HttpHandler.process(OData4HttpHandler.java:70) > at org.teiid.olingo.web.ODataServlet.service(ODataServlet.java:50) [teiid-olingo-8.12.5.redhat-2.jar:8.12.5.redhat-2] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) [jboss-servlet-api_3.0_spec-1.0.2.Final-redhat-2.jar:1.0.2.Final-redhat-2] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:295) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1] > at org.teiid.olingo.web.ODataFilter.doFilter(ODataFilter.java:194) [teiid-olingo-8.12.5.redhat-2.jar:8.12.5.redhat-2] > at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1] > at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1] > at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:231) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1] > at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:149) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1] > at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:512) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1] > at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:169) [jboss-as-web-7.5.4.Final-redhat-4.jar:7.5.4.Final-redhat-4] > at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:150) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1] > at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:97) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1] > at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:102) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1] > at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:344) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1] > at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:854) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1] > at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:653) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1] > at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:926) [jbossweb-7.5.11.Final-redhat-1.jar:7.5.11.Final-redhat-1] > at java.lang.Thread.run(Thread.java:744) [rt.jar:1.8.0-internal] > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues March 2016