February 2016 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-3137) Change infinispan-cache translator to support JDG 6 and no longer support pre 6.0 infinispan

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3137?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3137: ------------------------------------------------ Filip Elias <felias(a)redhat.com> changed the Status of [bug 1150327|https://bugzilla.redhat.com/show_bug.cgi?id=1150327] from VERIFIED to CLOSED > Change infinispan-cache translator to support JDG 6 and no longer support pre 6.0 infinispan > -------------------------------------------------------------------------------------------- > > Key: TEIID-3137 > URL: https://issues.jboss.org/browse/TEIID-3137 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Affects Versions: 8.7.1, 8.9 > Reporter: Van Halbert > Assignee: Van Halbert > Fix For: 8.7.1, 8.10 > > > Change the infinispan-cache translator to support JDG 6 using library mode. Also, remove support for infinispan v.5. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3643) VDB based kerberos authentication does not work with ODBC

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3643?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3643: ------------------------------------------------ Filip Elias <felias(a)redhat.com> changed the Status of [bug 1254532|https://bugzilla.redhat.com/show_bug.cgi?id=1254532] from VERIFIED to CLOSED > VDB based kerberos authentication does not work with ODBC > --------------------------------------------------------- > > Key: TEIID-3643 > URL: https://issues.jboss.org/browse/TEIID-3643 > Project: Teiid > Issue Type: Bug > Components: Server > Affects Versions: 8.7.1.6_2 > Reporter: Juraj Duráni > Assignee: Steven Hawkins > Fix For: 8.12, 8.11.3, 8.7.2.6_2, 8.7.6 > > > I have a VDB configured to use GSS authentication. Both, JDBC and ODBC ports are configured to use default "teiid-security" security domain. Accessing the VDB through JDBC works fine, but ODBC throws exception [1], [2]. If the ODBC port is configured to use GSS authentication, connection is successful. > [1] > isql -v krb > [08001][unixODBC]could not connect to server: Spojenie odmietnut > Is the server running on host "localhost" (::1) and accepting > TCP/IP connections on port 35432? > ERROR: TEIID40055 Wrong logon method is being used. Server is not set up for Kerberos based authentication. > DETAIL: org.teiid.jdbc.TeiidSQLException: TEIID40055 Wrong logon method is being used. Server is not set up for Kerberos based authentication. > [ISQL]ERROR: Could not SQLConnect > [2] > 11:49:56,470 ERROR [org.teiid.ODBC] (New I/O worker #3) TEIID40015 Unexpected error occurred: org.teiid.client.security.LogonException: TEIID40055 Wrong logon method is being used. Server is not set up for Kerberos based authentication. > at org.teiid.transport.LogonImpl.neogitiateGssLogin(LogonImpl.java:168) [teiid-runtime-8.7.1.6_2-redhat-4.jar:8.7.1.6_2-redhat-4] > at org.teiid.odbc.ODBCServerRemoteImpl.logon(ODBCServerRemoteImpl.java:237) [teiid-runtime-8.7.1.6_2-redhat-4.jar:8.7.1.6_2-redhat-4] > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_40] > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_40] > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_40] > at java.lang.reflect.Method.invoke(Method.java:497) [rt.jar:1.8.0_40] > at org.teiid.transport.ODBCClientInstance.processMessage(ODBCClientInstance.java:127) [teiid-runtime-8.7.1.6_2-redhat-4.jar:8.7.1.6_2-redhat-4] > at org.teiid.transport.ODBCClientInstance.receivedMessage(ODBCClientInstance.java:116) [teiid-runtime-8.7.1.6_2-redhat-4.jar:8.7.1.6_2-redhat-4] > at org.teiid.transport.SSLAwareChannelHandler.messageReceived(SSLAwareChannelHandler.java:211) [teiid-runtime-8.7.1.6_2-redhat-4.jar:8.7.1.6_2-redhat-4] > at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1] > at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1] > at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:791) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1] > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1] > at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:462) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1] > at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:443) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1] > at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1] > at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1] > at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:564) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1] > at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:559) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1] > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1] > at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1] > at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1] > at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:109) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1] > at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:328) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1] > at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:90) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1] > at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1] > at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1] > at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty-3.6.10.Final-redhat-1.jar:3.6.10.Final-redhat-1] > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_40] > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_40] > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_40] -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3245) Database Logging: Problems with Microsoft

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3245?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3245: ------------------------------------------------ Filip Elias <felias(a)redhat.com> changed the Status of [bug 1118470|https://bugzilla.redhat.com/show_bug.cgi?id=1118470] from VERIFIED to CLOSED > Database Logging: Problems with Microsoft > ------------------------------------------ > > Key: TEIID-3245 > URL: https://issues.jboss.org/browse/TEIID-3245 > Project: Teiid > Issue Type: Bug > Components: Server > Affects Versions: 8.7.1 > Reporter: Van Halbert > Assignee: Ramesh Reddy > Fix For: 8.7.1 > > > Still getting error with mssql driver and sql server 2012. > The error messages look similar, but one: > [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool -- 55) Incorrect syntax near the keyword 'rowcount'. > is present. > While the prior issue > 14:46:56,858 ERROR [org.hibernate.tool.hbm2ddl.SchemaExport] (ServerService Thread Pool – 57) Incorrect syntax near the keyword 'plan'. > was solved. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3359) Allow more control over odata layer caching

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3359?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3359: ------------------------------------------------ Filip Elias <felias(a)redhat.com> changed the Status of [bug 1227333|https://bugzilla.redhat.com/show_bug.cgi?id=1227333] from VERIFIED to CLOSED > Allow more control over odata layer caching > ------------------------------------------- > > Key: TEIID-3359 > URL: https://issues.jboss.org/browse/TEIID-3359 > Project: Teiid > Issue Type: Enhancement > Components: OData > Affects Versions: 8.7 > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Labels: Alpha1 > Fix For: 8.7.1.6_2, 8.11 > > > The caching is always performed at a user level and for each query. Consumers may need to localize the caching affect only to paging results and scope only to that interaction, rather than for all users. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3404) Teiid DatabaseAppender JPA perisist Command log consume high CPU

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3404?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3404: ------------------------------------------------ Filip Elias <felias(a)redhat.com> changed the Status of [bug 1192173|https://bugzilla.redhat.com/show_bug.cgi?id=1192173] from VERIFIED to CLOSED > Teiid DatabaseAppender JPA perisist Command log consume high CPU > ---------------------------------------------------------------- > > Key: TEIID-3404 > URL: https://issues.jboss.org/browse/TEIID-3404 > Project: Teiid > Issue Type: Bug > Components: Tools > Affects Versions: 8.7.1 > Environment: * DV 6.1 > * dynamicvdb-datafederation quickstart > Reporter: Kylin Soong > Assignee: Kylin Soong > Fix For: 8.7.2 > > > I have 4 - 5 concurrent client query to Portfolio VDB, this cause log DatabaseAppender JPA perisist Command log thread consume high CPU. In my test, one log threads always swallow high CPU, if the concurrent client query more than 10, it swallow 100% cpu. > [1] have detailed reproduce steps, including thread dumps. > [1] https://github.com/kylinsoong/teiid-samples/tree/master/command-logging-h... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3164) Second connection to VDB through Kerberos authentication ends with exception

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3164?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3164: ------------------------------------------------ Filip Elias <felias(a)redhat.com> changed the Status of [bug 1151027|https://bugzilla.redhat.com/show_bug.cgi?id=1151027] from VERIFIED to CLOSED > Second connection to VDB through Kerberos authentication ends with exception > ---------------------------------------------------------------------------- > > Key: TEIID-3164 > URL: https://issues.jboss.org/browse/TEIID-3164 > Project: Teiid > Issue Type: Bug > Affects Versions: 8.7.1 > Environment: OS: fedora20 > arch: x86_64 > java: sun 1.7 > kdc: on localhost > Reporter: Juraj Duráni > Assignee: Ramesh Reddy > Fix For: 8.7.1, 8.9 > > Attachments: krb.zip > > > Second (third,forth,...) conection to VDB through Kerberos ends with exception: > javax.security.auth.login.LoginException: TEIID50103 Wrong Response returned from EXAMPLE.COM security domain; Expecting a Kerberoes response -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2981) Add an OData query parameter that caches the resultset

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-2981?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-2981: ------------------------------------------------ Filip Elias <felias(a)redhat.com> changed the Status of [bug 1242029|https://bugzilla.redhat.com/show_bug.cgi?id=1242029] from VERIFIED to CLOSED > Add an OData query parameter that caches the resultset > ------------------------------------------------------ > > Key: TEIID-2981 > URL: https://issues.jboss.org/browse/TEIID-2981 > Project: Teiid > Issue Type: Feature Request > Components: OData > Affects Versions: 8.7 > Reporter: John Muller > Assignee: Steven Hawkins > Priority: Minor > Labels: Caching > Fix For: 8.8, 8.7.5 > > > The Teiid caching guide indicates that the /*+ cache */ SQL hint is neccessary in order to cache results [1] . We would like two features added to the OData support: (1) to have a query parameter that basically injects the hint into the SQL statement run against the VDB and (2) a configuration setting that turns on OData resultset caching for all result sets smaller than some size (perhaps 256 as the default) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3487) preparedstatement leaks in odbc

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3487?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3487: ------------------------------------------------ Filip Elias <felias(a)redhat.com> changed the Status of [bug 1227330|https://bugzilla.redhat.com/show_bug.cgi?id=1227330] from VERIFIED to CLOSED > preparedstatement leaks in odbc > ------------------------------- > > Key: TEIID-3487 > URL: https://issues.jboss.org/browse/TEIID-3487 > Project: Teiid > Issue Type: Bug > Components: ODBC > Affects Versions: 8.4 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.7.1.6_2, 8.11 > > > There are several places where preparedstatements are being created and never closed by the odbc logic. And since we don't have garbage collection based cleanup, this can lead to a build up on the statementimpl. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3279) SOLR: Error when date, time or timestamp literal is in where clause

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3279?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3279: ------------------------------------------------ Filip Elias <felias(a)redhat.com> changed the Status of [bug 1180107|https://bugzilla.redhat.com/show_bug.cgi?id=1180107] from VERIFIED to CLOSED > SOLR: Error when date,time or timestamp literal is in where clause > ------------------------------------------------------------------ > > Key: TEIID-3279 > URL: https://issues.jboss.org/browse/TEIID-3279 > Project: Teiid > Issue Type: Bug > Components: Connector API > Affects Versions: 8.7 > Reporter: Filip Elias > Assignee: Ramesh Reddy > Fix For: 8.7.1.6_2, 8.11 > > > Query fails when time,date or timestamp literal is used in where clause. > Examples: > Query: > {code}select intkey from smalla where timevalue = '11:30:20'{code} > Error: > {code} > '11:30:20'org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Invalid Date String:'11-30-20' > at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:491) > {code} > Query: > {code}select intkey from smalla where datevalue = '2002-02-02'{code} > Error: > {code} > org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Invalid Date String:'11-30-20' > at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:491) > {code} > Query: > {code}select intkey from smalla where timestampvalue = '2000-01-01 00:00:04'{code} > Error: > {code} org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Invalid Date String:'2000-01-01T00-00-04' > at org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:491) > {code} > SOLR supports only timestamps (YYYY-mm-ddThh:mm:ssZ) so date and time types should be converted into timestamp before a query is send to SOLR. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3274) Change archetypes to create independent projects

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3274?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3274: ------------------------------------------------ Filip Elias <felias(a)redhat.com> changed the Status of [bug 1178658|https://bugzilla.redhat.com/show_bug.cgi?id=1178658] from VERIFIED to CLOSED > Change archetypes to create independent projects > ------------------------------------------------ > > Key: TEIID-3274 > URL: https://issues.jboss.org/browse/TEIID-3274 > Project: Teiid > Issue Type: Enhancement > Components: Tools > Affects Versions: 8.7.1 > Reporter: Van Halbert > Assignee: Van Halbert > Fix For: 8.7.1 > > > The current archetypes were developed with the mindset of generating projects that are part of the Teiid build. However, they need to be changed so that they are generating projects that are independent, that can stand on their own without requiring Teiid jar's. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues February 2016