[JBoss JIRA] (TEIID-5620) Provide flattened jmx metrics
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5620?page=com.atlassian.jira.plugin... ]
Steven Hawkins updated TEIID-5620:
----------------------------------
Fix Version/s: 12.1
> Provide flattened jmx metrics
> -----------------------------
>
> Key: TEIID-5620
> URL: https://issues.jboss.org/browse/TEIID-5620
> Project: Teiid
> Issue Type: Quality Risk
> Components: Server
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 12.1
>
>
> Providing JMX metrics via jolokia to Prometheus does not work well with complex types. We are providing several metric sets - engine stats, worker pool stats, requests, etc. as beans which needs to be flattened. Simple parameters are ok to the metrics methods, but simple results are required.
> We need to make sure that at least statistics are available on:
> * number of plans waiting to be processed - this will be a primary metric for determining horizontal scale out
> * amount /%of buffer memory used - this will be a primary metric for determining if pods need to be allocated with more memory/disk
> Ideally alerting could be available on percent utilization - but we could also add a metric such as out of disk count to provide a hard count of exceptional conditions.
> It's assumed that cpu utilization will be monitored from the pod itself - which will be a primary metric for determining if pods should be allocated with more cpu resources.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (TEIID-5619) Provide tables representing admin information
by Steven Hawkins (Jira)
Steven Hawkins created TEIID-5619:
-------------------------------------
Summary: Provide tables representing admin information
Key: TEIID-5619
URL: https://issues.jboss.org/browse/TEIID-5619
Project: Teiid
Issue Type: Quality Risk
Components: Query Engine
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 12.1
Information provided over the admin api about sessions, requests, transactions, etc. should also be available via system tables.
Similarly many of the admin operations could be provided as system procedures - kill session, flush cache, etc.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (TEIID-5617) Insert command complete for pg/odbc is incorrect
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5617?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-5617.
-----------------------------------
Resolution: Done
Updated the logic to add the 0 oid for the insert command complete. At some point later we can investigate if it makes sense to determine a pseudo oid for returning generated keys.
> Insert command complete for pg/odbc is incorrect
> ------------------------------------------------
>
> Key: TEIID-5617
> URL: https://issues.jboss.org/browse/TEIID-5617
> Project: Teiid
> Issue Type: Bug
> Components: ODBC
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 12.1, 11.2.2, 12.0.1
>
>
> The message format for insert command complete is INSERT oid rows, but we are sending INSERT rows. Depending upon the client, such as using a newer JDBC driver, that will cause an exception on the client side.
> {code}
> java.lang.StringIndexOutOfBoundsException: String index out of range: -1
> at java.lang.String.substring(String.java:1967)
> at org.postgresql.core.v3.QueryExecutorImpl.interpretCommandStatus(QueryExecutorImpl.java:2528)
> at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2134)
> at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:300)
> at org.postgresql.core.v3.ExtendedQueryExecutorImpl.execute(ExtendedQueryExecutorImpl.java:88)
> at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:428)
> at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:354)
> at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:169)
> at org.postgresql.jdbc.PgPreparedStatement.executeQuery(PgPreparedStatement.java:117)
> at org.teiid.transport.TestODBCSocketTransport.testPreparedNull(TestODBCSocketTransport.java:299)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
> at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:538)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:760)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:460)
> at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:206)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (TEIID-5618) clientHostName always reported as localhost via JDBC connection
by Debbie Steigner (Jira)
Debbie Steigner created TEIID-5618:
--------------------------------------
Summary: clientHostName always reported as localhost via JDBC connection
Key: TEIID-5618
URL: https://issues.jboss.org/browse/TEIID-5618
Project: Teiid
Issue Type: Bug
Components: Server
Affects Versions: 8.12.16.6_4
Reporter: Debbie Steigner
Assignee: Steven Hawkins
VDB session information in the Management Console and logs shows localhost for Client Host Name with a JDBC connection.
Client Host Name: localhost
Client Hardware Address: 4CBB58502284
IP Address:
Security Domain: teiid-security
In the server.log with org.teiid set to TRACE it displays below for session:
DEBUG [org.teiid.SECURITY] (New I/O worker #2) Logon successful, created session: sessionid=DW9hzUw5P1ob; userName=teiidUser@teiid-security; vdbName=deb_pg; vdbVersion=2; createdTime=Thu Jan 17 08:15:44 CST 2019; applicationName=JDBC; clientHostName=localhost; clientHardwareAddress=4CBB58502284; IPAddress=192.168.x.x; securityDomain=teiid-security; lastPingTime=Thu Jan 17 08:15:44 CST 2019
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (TEIID-5617) Insert command complete for pg/odbc is incorrect
by Steven Hawkins (Jira)
Steven Hawkins created TEIID-5617:
-------------------------------------
Summary: Insert command complete for pg/odbc is incorrect
Key: TEIID-5617
URL: https://issues.jboss.org/browse/TEIID-5617
Project: Teiid
Issue Type: Bug
Components: ODBC
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 12.1, 11.2.2, 12.0.1
The message format for insert command complete is INSERT oid rows, but we are sending INSERT rows. Depending upon the client, such as using a newer JDBC driver, that will cause an exception on the client side.
{code}
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1967)
at org.postgresql.core.v3.QueryExecutorImpl.interpretCommandStatus(QueryExecutorImpl.java:2528)
at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2134)
at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:300)
at org.postgresql.core.v3.ExtendedQueryExecutorImpl.execute(ExtendedQueryExecutorImpl.java:88)
at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:428)
at org.postgresql.jdbc.PgStatement.execute(PgStatement.java:354)
at org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(PgPreparedStatement.java:169)
at org.postgresql.jdbc.PgPreparedStatement.executeQuery(PgPreparedStatement.java:117)
at org.teiid.transport.TestODBCSocketTransport.testPreparedNull(TestODBCSocketTransport.java:299)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:86)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:538)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:760)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:206)
{code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (TEIID-5614) Teiid Spring Boot - Enable Spring Actuator and non OData requests
by Ramesh Reddy (Jira)
[ https://issues.jboss.org/browse/TEIID-5614?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-5614:
-------------------------------------
Looks like it is little quirky than I originally thought. In Actuator 1.x, the API at root context plus, Teiid used servlets to develop the OData API so that can code reuse from WildFly side. Here I suspect Actuator is using Spring MVC. I will able to redirect any servlet-based calls but when not a Spring MVC based requests. Maybe I just need to leave it there for now, until we move up to Spring 2 and/or port OData stuff to Spring.
> Teiid Spring Boot - Enable Spring Actuator and non OData requests
> -----------------------------------------------------------------
>
> Key: TEIID-5614
> URL: https://issues.jboss.org/browse/TEIID-5614
> Project: Teiid
> Issue Type: Feature Request
> Reporter: Tamar Meron
> Assignee: Ramesh Reddy
> Priority: Major
>
> While working with Teiid spring boot starter in my spring boot app I encountered an issue when trying to access spring actuator endpoints.
> I have "server.context-path: /api/odata" in my bootstrap.yml configuration.
> Then, accessing <my-server-url>/api/odata/health returns an error since I don't have a table named "health":
> {code}
> <error xmlns="http://docs.oasis-open.org/odata/ns/metadata">
> <code>null</code>
> <message>
> Cannot find EntitySet, Singleton, ActionImport or FunctionImport with name 'health'.
> </message>
> </error>
> {code}
> I need to "split" the context for OData endpoints and for the rest endpoints which are not OData endpoints.
> I saw that Olingo has a support for that ("org.apache.olingo.odata2.path.split" property).
> (didn't find any documentation for that "split" for OData version 4)
> https://olingo.apache.org/doc/odata2/tutorials/Olingo_Tutorial_Advanced_S...
> Maybe this feature is useful also for requests which are not OData Protocol requests(and not only for Spring actuator endpoints..)
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (TEIID-5615) Error when binding NULL to nullable parameter in a prepared statement with PDO PostgreSQL ODBC client
by Steven Hawkins (Jira)
[ https://issues.jboss.org/browse/TEIID-5615?page=com.atlassian.jira.plugin... ]
Work on TEIID-5615 started by Steven Hawkins.
---------------------------------------------
> Error when binding NULL to nullable parameter in a prepared statement with PDO PostgreSQL ODBC client
> -----------------------------------------------------------------------------------------------------
>
> Key: TEIID-5615
> URL: https://issues.jboss.org/browse/TEIID-5615
> Project: Teiid
> Issue Type: Bug
> Components: ODBC
> Affects Versions: 11.0, 11.2
> Environment: All infrastructure is Dockerized on Windows 64bit (see below)
> WildFly Full 11.0.0.Final (WildFly Core 3.0.8.Final)
> Teiid Engine 11.2.0
> DatabaseProductVersion=11.1 (Debian 11.1-1.pgdg90+1)
> PostgreSQL JDBC Driver=42.2.5
> PDO Driver for PostgreSQL (from phpinfo())
> PostgreSQL(libpq) Version: 9.6.10
> Module version: 7.1.26
> Reporter: George Ushakov
> Assignee: Steven Hawkins
> Priority: Major
>
> On Teiid 11.0 (and probably later versions, as well) running in a WildFly there is a problem when binding to a NULLABLE parameter in a prepared statement with NULL value when running against a PostgreSQL source from a PDO (PHP) ODBC client.
> PDO calls causing the error are related to [PDOStatement::bindValue|https://secure.php.net/manual/en/pdostatement.bin...]
> and [PDOStatement::bindParam|https://secure.php.net/manual/en/pdostatement.bin...].
> It occurs exclusively when the client is trying to bind a NULL value (corresponding to a NULLABLE column in a table) to the prepared statement using PDO::PARAM_NULL type.
> Example PHP code
> {code:php}
> $dbh = new PDO('pgsql:host=<teiid_host>;port=35432;dbname=<vdb_name>;user=<teiid_user>;password=<teiid_password>');
> $stmt = $dbh->prepare("INSERT INTO foobar (id, optional) VALUES(?, ?)");
> $stmt->bindValue(1, 1);
> $stmt->bindValue(2, null, PDO::PARAM_NULL);
> $stmt->execute();
> {code}
> Exception thrown is
> Caused by: java.lang.NegativeArraySizeException
> at org.teiid.transport.PgFrontendProtocol.createByteArray(PgFrontendProtocol.java:328)
> at org.teiid.transport.PgFrontendProtocol.buildBind(PgFrontendProtocol.java:266)
> at org.teiid.transport.PgFrontendProtocol.createRequestMessage(PgFrontendProtocol.java:153)
> at org.teiid.transport.PgFrontendProtocol.decode(PgFrontendProtocol.java:133)
> at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411)
> ... 15 more
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months
[JBoss JIRA] (TEIID-5615) Error when binding NULL to nullable parameter in a prepared statement with PDO PostgreSQL ODBC client
by George Ushakov (Jira)
George Ushakov created TEIID-5615:
-------------------------------------
Summary: Error when binding NULL to nullable parameter in a prepared statement with PDO PostgreSQL ODBC client
Key: TEIID-5615
URL: https://issues.jboss.org/browse/TEIID-5615
Project: Teiid
Issue Type: Bug
Components: ODBC
Affects Versions: 11.2, 11.0
Environment: All infrastructure is Dockerized on Windows 64bit (see below)
WildFly Full 11.0.0.Final (WildFly Core 3.0.8.Final)
Teiid Engine 11.2.0
DatabaseProductVersion=11.1 (Debian 11.1-1.pgdg90+1)
PostgreSQL JDBC Driver=42.2.5
PDO Driver for PostgreSQL (from phpinfo())
PostgreSQL(libpq) Version: 9.6.10
Module version: 7.1.26
Reporter: George Ushakov
Assignee: Steven Hawkins
On Teiid 11.0 (and probably later versions, as well) running in a WildFly there is a problem when binding to a NULLABLE parameter in a prepared statement with NULL value when running against a PostgreSQL source from a PDO (PHP) ODBC client.
PDO calls causing the error are related to [PDOStatement::bindValue|https://secure.php.net/manual/en/pdostatement.bin...]
and [PDOStatement::bindParam|https://secure.php.net/manual/en/pdostatement.bin...].
It occurs exclusively when the client is trying to bind a NULL value (corresponding to a NULLABLE column in a table) to the prepared statement using PDO::PARAM_NULL type.
Example PHP code
{code:php}
$dbh = new PDO('pgsql:host=<teiid_host>;port=35432;dbname=<vdb_name>;user=<teiid_user>;password=<teiid_password>');
$stmt = $dbh->prepare("INSERT INTO foobar (id, optional) VALUES(?, ?)");
$stmt->bindValue(1, 1);
$stmt->bindValue(2, null, PDO::PARAM_NULL);
$stmt->execute();
{code}
Exception thrown is
Caused by: java.lang.NegativeArraySizeException
at org.teiid.transport.PgFrontendProtocol.createByteArray(PgFrontendProtocol.java:328)
at org.teiid.transport.PgFrontendProtocol.buildBind(PgFrontendProtocol.java:266)
at org.teiid.transport.PgFrontendProtocol.createRequestMessage(PgFrontendProtocol.java:153)
at org.teiid.transport.PgFrontendProtocol.decode(PgFrontendProtocol.java:133)
at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411)
... 15 more
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
5 years, 5 months