December 2015 - teiid-issues - Jboss List Archives

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

by Johnathon Lee (JIRA)

[ https://issues.jboss.org/browse/TEIID-3643?page=com.atlassian.jira.plugin... ] Johnathon Lee updated TEIID-3643: --------------------------------- Fix Version/s: 8.7.6 > 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, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3757) OData V2: $top doesn't work with virtual procedures

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3757?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3757: ------------------------------------------------ jolee(a)redhat.com changed the Status of [bug 1272211|https://bugzilla.redhat.com/show_bug.cgi?id=1272211] from NEW to MODIFIED > OData V2: $top doesn't work with virtual procedures > --------------------------------------------------- > > Key: TEIID-3757 > URL: https://issues.jboss.org/browse/TEIID-3757 > Project: Teiid > Issue Type: Bug > Components: OData > Affects Versions: 8.7.1.6_2 > Reporter: Debbie Steigner > Assignee: Ramesh Reddy > Fix For: 8.12.1 > > Attachments: odat.vdb > > > When using OData to query a virtual procedure with a input parameter $top gets ignored: > http://127.0.0.1:8080/odata/odat/proctest?string_in='30'&$top=5 > Returns all the rows. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3831) For results set caching there should scope metadata for source tables/procedures

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3831?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-3831. ----------------------------------- Fix Version/s: 8.13 8.12.3 (was: 8.12.x) Resolution: Done Added to 8.12.x since it may be needed there, but will leverage this more in 9.0. The one thing that isn't very good is that re-using the Scope enum means you can set Scope.NONE - which is no different than Scope.SESSION. This is noted in the java docs. The docs for 9.0 have been updated as well. > For results set caching there should scope metadata for source tables/procedures > -------------------------------------------------------------------------------- > > Key: TEIID-3831 > URL: https://issues.jboss.org/browse/TEIID-3831 > Project: Teiid > Issue Type: Feature Request > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.13, 8.12.3 > > > Functions have optional metadata to convey their determinism, which affects the caching scope. However we don't have extension metadata or per execution metadata around source queries (there is a scope field on a cache directive, but that only applies to source level caching). We should provide a general mechanism so that users aren't required to manually override the result set cache scope. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3436) OData V2: Add array type support to the odata translator

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3436?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-3436: ---------------------------------- Fix Version/s: 8.13 > OData V2: Add array type support to the odata translator > -------------------------------------------------------- > > Key: TEIID-3436 > URL: https://issues.jboss.org/browse/TEIID-3436 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Reporter: Steven Hawkins > Assignee: Ramesh Reddy > Fix For: 8.12.1, 8.13 > > > Arrays of basic types in odata responses should be convertible into a runtime array type. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3851) foreign temp additional extension properties not accessible in QMI

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3851?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-3851. ----------------------------------- Resolution: Done Added the unwrapping to the original metadata id. > foreign temp additional extension properties not accessible in QMI > ------------------------------------------------------------------ > > Key: TEIID-3851 > URL: https://issues.jboss.org/browse/TEIID-3851 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.13, 8.12.3 > > > The original metadata id is not consulted when checking extension metadata properties, so anything that isn't transferred to a proper metadata property is lost to the engine (but is accessible to the translator as it will have access to the actual metadata object). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3850) Source caching with the cache directive can be at the wrong scope

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3850?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-3850. ----------------------------------- Resolution: Done Added the missing breaks in the case statement. > Source caching with the cache directive can be at the wrong scope > ----------------------------------------------------------------- > > Key: TEIID-3850 > URL: https://issues.jboss.org/browse/TEIID-3850 > Project: Teiid > Issue Type: Bug > Components: Query Engine > Affects Versions: 8.4 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.13, 8.12.3 > > > Source caching with the cache directive can be at the wrong scope since the conversion from the cache directive to the determinism level lacks break statements. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3739) Dynamic VDB that imports another VDB does not get redeployed if the imported VDB is redeployed

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/TEIID-3739?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on TEIID-3739: ------------------------------------------------ jolee(a)redhat.com changed the Status of [bug 1268308|https://bugzilla.redhat.com/show_bug.cgi?id=1268308] from NEW to MODIFIED > Dynamic VDB that imports another VDB does not get redeployed if the imported VDB is redeployed > ---------------------------------------------------------------------------------------------- > > Key: TEIID-3739 > URL: https://issues.jboss.org/browse/TEIID-3739 > Project: Teiid > Issue Type: Bug > Components: Server > Affects Versions: 8.7.1.6_2 > Reporter: Debbie Steigner > Assignee: Steven Hawkins > Fix For: 8.12, 8.11.5, 8.7.2.6_2, 8.7.6 > > Attachments: dynovdb1-vdb.xml, dynovdb2-vdb.xml > > > When using a Dynamic VDB that imports another VDB it isn't redeployed if the imported VDB is redeployed. You can in the log it undeploys the top VDB and the imported VDB but only redeploys the imported one. The top VDB then doesn't exist until it's redeployed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3851) foreign temp additional extension properties not accessible in QMI

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-3851: ------------------------------------- Summary: foreign temp additional extension properties not accessible in QMI Key: TEIID-3851 URL: https://issues.jboss.org/browse/TEIID-3851 Project: Teiid Issue Type: Bug Components: Query Engine Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 8.13, 8.12.3 The original metadata id is not consulted when checking extension metadata properties, so anything that isn't transferred to a proper metadata property is lost to the engine (but is accessible to the translator as it will have access to the actual metadata object). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3850) Source caching with the cache directive can be at the wrong scope

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-3850: ------------------------------------- Summary: Source caching with the cache directive can be at the wrong scope Key: TEIID-3850 URL: https://issues.jboss.org/browse/TEIID-3850 Project: Teiid Issue Type: Bug Components: Query Engine Affects Versions: 8.4 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 8.13, 8.12.3 Source caching with the cache directive can be at the wrong scope since the conversion from the cache directive to the determinism level lacks break statements. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

[JBoss JIRA] (TEIID-3849) Writes using Cassandra connector are very slow

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-3849?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-3849: ---------------------------------- Fix Version/s: 9.0 The translator currently does not support bulk/batched updates and yes just uses standard CQL to issue an INSERT/UPDATE/DELETE. So at the least we'll update the logic to support bulk updates and it looks like the batch logic is via BatchedStatement. The change to asynch would be useful to not tie up a Teiid thread. > Writes using Cassandra connector are very slow > ---------------------------------------------- > > Key: TEIID-3849 > URL: https://issues.jboss.org/browse/TEIID-3849 > Project: Teiid > Issue Type: Enhancement > Components: Misc. Connectors > Reporter: Pranav K > Assignee: Steven Hawkins > Fix For: 9.0 > > > The connector seems to execute the insert queries one by one rather than using batched approach, also the API used is the synchronous one instead of the future based async API [session.executeAsync()] > Cassandra writes are generally very fast, but it was noted in one scenario that on a single node Cassandra setup inserting a set 50k records and 3 columns took more than 25 mins. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 5 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues December 2015