[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)
7 years, 2 months
[JBoss JIRA] (TEIID-5620) Provide flattened jmx metrics
by Steven Hawkins (Jira)
Steven Hawkins created TEIID-5620:
-------------------------------------
Summary: 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
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)
7 years, 2 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)
7 years, 2 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)
7 years, 2 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)
7 years, 2 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)
7 years, 2 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)
7 years, 2 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)
7 years, 2 months