March 2014 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-2879) Add more Resource Management

by Jeremy Phuah (JIRA)

[ https://issues.jboss.org/browse/TEIID-2879?page=com.atlassian.jira.plugin... ] Jeremy Phuah commented on TEIID-2879: ------------------------------------- There should be a way for us prioritise the transactions or queries as well. Some sort of queuing mechanism with priority or the ability to route priority transactions to a different Teiid instance would be great. > Add more Resource Management > ---------------------------- > > Key: TEIID-2879 > URL: https://issues.jboss.org/browse/TEIID-2879 > Project: Teiid > Issue Type: Feature Request > Reporter: Rick Wagner > Assignee: Steven Hawkins > > To protect the system sometimes we may need to throttle the queries to ensure it does not exhaust all the existing resources on the server. Resource management is the key to play this role of monitoring and throttling queries. Oracle products offer such a feature for managing the consumption of resources. We have quite a number of (Teiid) profiles running on a big box and we want to ensure no silly queires are hogging on to all the resources and consequently causing issue to others. > Ability to throttle the query by restricting query that uses > 1) Too much CPU > 2) Too much java heap > 3) Long running query -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2863) Allow both gssapi and username/password authentication on the same transport

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-2863?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-2863: ------------------------------------- I should have said two login-modules above, not two security-domains. Ignore the fact for now, whether they are in two separate or stacked in one. >> but not case 1, here the preference is set by user. >How is the preference set by the user? I was talking about case 2, where the preference is set using the "user" property >I don't think that a fallback mechanism makes sense, since the notion of the authentication type may depend upon >the user name. That tells me that you think it should work as Case 2. even if we ignore the fact how the preference is set whether using "user" or not. I am not saying we do not want to use the "user" property, but acknowledge the fact that this is the way we want to do it. > Allow both gssapi and username/password authentication on the same transport > ---------------------------------------------------------------------------- > > Key: TEIID-2863 > URL: https://issues.jboss.org/browse/TEIID-2863 > Project: Teiid > Issue Type: Enhancement > Components: Server > Reporter: Steven Hawkins > Assignee: Steven Hawkins > > With GSSAPI support enabled, username/password support on the same transport is effectively disabled. JDBC/ODBC should ideally support both on the same transport. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2863) Allow both gssapi and username/password authentication on the same transport

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2863?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2863: --------------------------------------- > Let's say Teiid server configured is with two security-domains one USERPWD and GSS. I'm still not quite understanding why two security domains are needed. Also in practice aren't we talking about a scenario here where they want to support sso with kerberos and also username/password authentication to kerberos? > but not case 1, here the preference is set by user. How is the preference set by the user? > But from what I understand Cristinio's usecase he is looking for case 1. I don't think that a fallback mechanism makes sense, since the notion of the authentication type may depend upon the user name. > Allow both gssapi and username/password authentication on the same transport > ---------------------------------------------------------------------------- > > Key: TEIID-2863 > URL: https://issues.jboss.org/browse/TEIID-2863 > Project: Teiid > Issue Type: Enhancement > Components: Server > Reporter: Steven Hawkins > Assignee: Steven Hawkins > > With GSSAPI support enabled, username/password support on the same transport is effectively disabled. JDBC/ODBC should ideally support both on the same transport. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2863) Allow both gssapi and username/password authentication on the same transport

by Ramesh Reddy (JIRA)

[ https://issues.jboss.org/browse/TEIID-2863?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-2863: ------------------------------------- There are two different scenarios. Let's say Teiid server configured is with two security-domains one USERPWD and GSS. case 1) User defined as preference auth type GSS, then they tried to login, if they fail, do that automatically fallback to USERPWD? case 2) User defined as preference auth type is GSS, if failed then auth process throws a login exception. so in, case 2, we can handle similarly in jdbc/odbc based on "user" name pattern suggestion, but not case 1, here the preference is set by user. case 1, we can handle in jdbc but not sure there is path for odbc, as odbc needs to notify user what auth mechanism it is going follow through and stick to it. But from what I understand Cristinio's usecase he is looking for case 1. > Allow both gssapi and username/password authentication on the same transport > ---------------------------------------------------------------------------- > > Key: TEIID-2863 > URL: https://issues.jboss.org/browse/TEIID-2863 > Project: Teiid > Issue Type: Enhancement > Components: Server > Reporter: Steven Hawkins > Assignee: Steven Hawkins > > With GSSAPI support enabled, username/password support on the same transport is effectively disabled. JDBC/ODBC should ideally support both on the same transport. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-994) Unable to execute Oracle pipelined table function as procedure

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-994?page=com.atlassian.jira.plugin.... ] Steven Hawkins commented on TEIID-994: -------------------------------------- I should add that the native-query property using the TABLE keyword is only appropriate for a function returning a table type. If a ref cursor is being returned, then the native-query needs to be "SELECT func(params...) FROM DUAL" and the procedure needs to be modeled with a return parameter with a native type of REF CURSOR. > Unable to execute Oracle pipelined table function as procedure > -------------------------------------------------------------- > > Key: TEIID-994 > URL: https://issues.jboss.org/browse/TEIID-994 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors, Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.7, Open To Community > > > Oracle pipelined table functions (can be used in Oracle queries as TABLE(...)) that can be put in the FROM clause and used as if they were tables although they are really procedures. We found that we imported this table function, although didn't get it quite right - the result set was wrong, which may just be a deficiency of the JDBC import metadata. We were able to map the proc to a table and execute but when we did we got a PL/SQL error from the db. > Because this is a proc, we are executing it as a CallableStatement down in the JDBC connector which apparently does not work with DataDirect. I'm not sure how we can detect and do something different but seems like we need to have some metadata (procedure name in source?) that can tell us that this proc needs to be run differently and have the Oracle JDBC Connector deal with this properly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-994) Unable to execute Oracle pipelined table function as procedure

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-994?page=com.atlassian.jira.plugin.... ] Steven Hawkins commented on TEIID-994: -------------------------------------- Basic support for this should be available based upon TEIID-2644 If the pipelined function is modeled as a procedure with a native-query property of the form "SELECT * FROM TABLE(func(params...))", that will work for a single call - although the parameter substitution does not yet work for varags. The follow-ons to the basic support are: Is pushdown support needed so that the pipelined function can be pushed as part of a larger query - this is possible, but it does require some additional metadata and translator supports. Is chaining of pipelined functions needed? This is not very easy for us to implement yet as it requires the notion of a cursor type that is not yet exposed in our type system. > Unable to execute Oracle pipelined table function as procedure > -------------------------------------------------------------- > > Key: TEIID-994 > URL: https://issues.jboss.org/browse/TEIID-994 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors, Query Engine > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.7, Open To Community > > > Oracle pipelined table functions (can be used in Oracle queries as TABLE(...)) that can be put in the FROM clause and used as if they were tables although they are really procedures. We found that we imported this table function, although didn't get it quite right - the result set was wrong, which may just be a deficiency of the JDBC import metadata. We were able to map the proc to a table and execute but when we did we got a PL/SQL error from the db. > Because this is a proc, we are executing it as a CallableStatement down in the JDBC connector which apparently does not work with DataDirect. I'm not sure how we can detect and do something different but seems like we need to have some metadata (procedure name in source?) that can tell us that this proc needs to be run differently and have the Oracle JDBC Connector deal with this properly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2761) Enable/disable transport per model/view/virtual procedure

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2761?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2761: --------------------------------------- This will likely evolve based upon TEIID-2863 and it currently is required that the transport specifies the vdb's security-domain in it's list of security domains. We may need to revisit that later if we want to encapsulate that more. > Enable/disable transport per model/view/virtual procedure > --------------------------------------------------------- > > Key: TEIID-2761 > URL: https://issues.jboss.org/browse/TEIID-2761 > Project: Teiid > Issue Type: Feature Request > Components: Server > Affects Versions: 8.5 > Reporter: Patrick Deenen > Assignee: Steven Hawkins > Fix For: 8.7 > > > It would be nice to be able to enable and disable access to models, tables, views or (virtual) procedures for a specific transport (JDBC, ODBC, OData, REST, Web services). > One may want to have access to virtual procedures only by Odata for example. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2863) Allow both gssapi and username/password authentication on the same transport

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2863?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2863: --------------------------------------- > In stacking model, it security-domains are tried to login sequentially one after other. Suppose we want to do kerberos or file logins, if I have a security domain with the kerberos login module first and marked as optional (with the storepass option enabled) as below: {code} <login-module code="Kerberos" flag="optional"> <module-option name="storeKey">true</module-option> <module-option name="storePass">true</module-option> <module-option name="useKeyTab">true</module-option> <module-option name="principal">demo(a)EXAMPLE.COM</module-option> <module-option name="keyTab">path/to/krb5.keytab</module-option> <module-option name="doNotPrompt">true</module-option> <module-option name="debug">false</module-option> </login-module> <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required"> <module-option name="password-stacking" value="useFirstPass"/> <module-option name="usersProperties" value="${jboss.server.config.dir}/teiid-security-users.properties"/> <module-option name="rolesProperties" value="${jboss.server.config.dir}/teiid-security-roles.properties"/> </login-module> </authentication> {code} Then if we authenticate into kerberos, then useFirstPass option will allow us to pick up the roles from the roles file. Otherwise the security-domain will use file authentication. What this is hopefully getting at is that the auth type ideally should be associated with the vdb/user - and not with the security domain. > So the question is which one we want to support? I'm not sure what you mean. I would like the ODBC/JDBC approach to be the same (or at least similar) if possible, so given a vdb/user the server should make a determination of what auth type to use, then log the user into the security domain associated with the vdb using that auth type. > Allow both gssapi and username/password authentication on the same transport > ---------------------------------------------------------------------------- > > Key: TEIID-2863 > URL: https://issues.jboss.org/browse/TEIID-2863 > Project: Teiid > Issue Type: Enhancement > Components: Server > Reporter: Steven Hawkins > Assignee: Steven Hawkins > > With GSSAPI support enabled, username/password support on the same transport is effectively disabled. JDBC/ODBC should ideally support both on the same transport. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2883) Support ParAccel as a data source

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2883?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-2883: ---------------------------------- Assignee: (was: Steven Hawkins) Fix Version/s: 8.8 Open To Community > Support ParAccel as a data source > --------------------------------- > > Key: TEIID-2883 > URL: https://issues.jboss.org/browse/TEIID-2883 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Reporter: Van Halbert > Fix For: 8.8, Open To Community > > > Support ParAccel as a data source -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2884) Support for Amazon Elastic MapReduce

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2884?page=com.atlassian.jira.plugin... ] Steven Hawkins updated TEIID-2884: ---------------------------------- Assignee: (was: Steven Hawkins) Fix Version/s: 8.8 Open To Community > Support for Amazon Elastic MapReduce > ------------------------------------ > > Key: TEIID-2884 > URL: https://issues.jboss.org/browse/TEIID-2884 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Reporter: Van Halbert > Fix For: 8.8, Open To Community > > > Amazon Elastic MapReduce > from http://en.wikipedia.org/wiki/Amazon_Elastic_MapReduce#Amazon_Elastic_MapR... > Elastic MapReduce (EMR)was introduced by Amazon in April 2009. Provisioning of the Hadoop cluster, running and terminating jobs, and handling data transfer between EC2 and S3 are automated by Elastic MapReduce. Apache Hive, which is built on top of Hadoop for providing data warehouse services, is also offered in Elastic MapReduce. > ... > In June 2012, premium options for EMR were added that replace ordinary Hadoop with MapR's M3 and M5 versions. These options provide additional capabilities over and above what the default EMR offering provides. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

10 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues March 2014