[JBoss JIRA] (TEIID-5430) Closing Teiid JDBC connection is delayed 5 seconds
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/TEIID-5430?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration updated TEIID-5430:
-------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1607681
Bugzilla Update: Perform
> Closing Teiid JDBC connection is delayed 5 seconds
> --------------------------------------------------
>
> Key: TEIID-5430
> URL: https://issues.jboss.org/browse/TEIID-5430
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Driver
> Affects Versions: 8.12.13.6_4
> Reporter: Hiroki Daicho
> Assignee: Steven Hawkins
> Attachments: JDBCClient.java
>
>
> Teiid JDBC Driver waits 5 seconds during closing connection when the client can not reach teiid server.
> If many connections are pooling by the client as a Datasource, it takes more time the closing all connections.
> e.g. if the datasource has 50 connections, the close time would be 5 seconds * 50.
> [1] is the stacktrace whie the connection is closing with the delay.
> When closing connection, teiid JDBC waits server response by Future#get() with timeout of 5 seconds.
> So, it would be waiting for the time if the socket doesn't receive any response.
> [1] Stacktrace when the connection waits 5 seconds.
> {code}
> "main" #1 prio=5 os_prio=0 tid=0x00007f5b1c009000 nid=0x707b runnable [0x00007f5b238ac000]
> java.lang.Thread.State: RUNNABLE
> at java.net.SocketInputStream.socketRead0(Native Method)
> at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
> at java.net.SocketInputStream.read(SocketInputStream.java:171)
> at java.net.SocketInputStream.read(SocketInputStream.java:141)
> at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
> at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
> - locked <0x000000071c98cad0> (a org.teiid.core.util.AccessibleBufferedInputStream)
> at java.io.DataInputStream.readInt(DataInputStream.java:387)
> at org.teiid.netty.handler.codec.serialization.ObjectDecoderInputStream.readObjectOverride(ObjectDecoderInputStream.java:97)
> at java.io.ObjectInputStream.readObject(ObjectInputStream.java:416)
> at org.teiid.net.socket.OioOjbectChannelFactory$OioObjectChannel.read(OioOjbectChannelFactory.java:117)
> at org.teiid.net.socket.SocketServerInstanceImpl.read(SocketServerInstanceImpl.java:308)
> at org.teiid.net.socket.SocketServerInstanceImpl$RemoteInvocationHandler$1.get(SocketServerInstanceImpl.java:411)
> at org.teiid.net.socket.SocketServerConnection.logoff(SocketServerConnection.java:331)
> at org.teiid.net.socket.SocketServerConnection.close(SocketServerConnection.java:306)
> - locked <0x000000071c51bb48> (a org.teiid.net.socket.SocketServerConnection)
> at org.teiid.jdbc.ConnectionImpl.close(ConnectionImpl.java:282)
> at ClientMain.invoke(ClientMain.java:83)
> at ClientMain.main(ClientMain.java:30)
> {code}
> [2]
> https://github.com/teiid/teiid/blob/master/client/src/main/java/org/teiid...
> {code}
> private void logoff() {
> disconnect();
> try {
> //make a best effort to send the logoff
> Future<?> writeFuture = this.serverInstance.getService(ILogon.class).logoff();
> writeFuture.get(5000, TimeUnit.MILLISECONDS);
> } catch (Exception e) {
> //ignore
> }
> closeServerInstance();
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (TEIID-5430) Closing Teiid JDBC connection is delayed 5 seconds
by Hiroki Daicho (JIRA)
Hiroki Daicho created TEIID-5430:
------------------------------------
Summary: Closing Teiid JDBC connection is delayed 5 seconds
Key: TEIID-5430
URL: https://issues.jboss.org/browse/TEIID-5430
Project: Teiid
Issue Type: Bug
Components: JDBC Driver
Affects Versions: 8.12.13.6_4
Reporter: Hiroki Daicho
Assignee: Steven Hawkins
Attachments: JDBCClient.java
Teiid JDBC Driver waits 5 seconds during closing connection when the client can not reach teiid server.
If many connections are pooling by the client as a Datasource, it takes more time the closing all connections.
e.g. if the datasource has 50 connections, the close time would be 5 seconds * 50.
[1] is the stacktrace whie the connection is closing with the delay.
When closing connection, teiid JDBC waits server response by Future#get() with timeout of 5 seconds.
So, it would be waiting for the time if the socket doesn't receive any response.
[1] Stacktrace when the connection waits 5 seconds.
{code}
"main" #1 prio=5 os_prio=0 tid=0x00007f5b1c009000 nid=0x707b runnable [0x00007f5b238ac000]
java.lang.Thread.State: RUNNABLE
at java.net.SocketInputStream.socketRead0(Native Method)
at java.net.SocketInputStream.socketRead(SocketInputStream.java:116)
at java.net.SocketInputStream.read(SocketInputStream.java:171)
at java.net.SocketInputStream.read(SocketInputStream.java:141)
at java.io.BufferedInputStream.fill(BufferedInputStream.java:246)
at java.io.BufferedInputStream.read(BufferedInputStream.java:265)
- locked <0x000000071c98cad0> (a org.teiid.core.util.AccessibleBufferedInputStream)
at java.io.DataInputStream.readInt(DataInputStream.java:387)
at org.teiid.netty.handler.codec.serialization.ObjectDecoderInputStream.readObjectOverride(ObjectDecoderInputStream.java:97)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:416)
at org.teiid.net.socket.OioOjbectChannelFactory$OioObjectChannel.read(OioOjbectChannelFactory.java:117)
at org.teiid.net.socket.SocketServerInstanceImpl.read(SocketServerInstanceImpl.java:308)
at org.teiid.net.socket.SocketServerInstanceImpl$RemoteInvocationHandler$1.get(SocketServerInstanceImpl.java:411)
at org.teiid.net.socket.SocketServerConnection.logoff(SocketServerConnection.java:331)
at org.teiid.net.socket.SocketServerConnection.close(SocketServerConnection.java:306)
- locked <0x000000071c51bb48> (a org.teiid.net.socket.SocketServerConnection)
at org.teiid.jdbc.ConnectionImpl.close(ConnectionImpl.java:282)
at ClientMain.invoke(ClientMain.java:83)
at ClientMain.main(ClientMain.java:30)
{code}
[2]
https://github.com/teiid/teiid/blob/master/client/src/main/java/org/teiid...
{code}
private void logoff() {
disconnect();
try {
//make a best effort to send the logoff
Future<?> writeFuture = this.serverInstance.getService(ILogon.class).logoff();
writeFuture.get(5000, TimeUnit.MILLISECONDS);
} catch (Exception e) {
//ignore
}
closeServerInstance();
}
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (TEIID-5429) timestampadd(SQL_TSI_MONTH, 1, 31/03/2018)) results in ORA-01839: date not valid for month specified
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5429?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-5429.
-----------------------------------
Fix Version/s: 11.1
11.0.1
10.3.3
Resolution: Done
Switched to the add_months function instead.
> timestampadd(SQL_TSI_MONTH, 1, 31/03/2018)) results in ORA-01839: date not valid for month specified
> ----------------------------------------------------------------------------------------------------
>
> Key: TEIID-5429
> URL: https://issues.jboss.org/browse/TEIID-5429
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 11.x
> Reporter: Ivan Semenov
> Assignee: Steven Hawkins
> Fix For: 11.1, 11.0.1, 10.3.3
>
>
> There is a known problem with Oracle's intervals:
> {code:sql}
> select to_date('2018/03/31', 'yyyy/mm/dd') + (INTERVAL '1' MONTH(2)) from dual
> {code}
> results in {{ORA-01839: date not valid for month specified error}}
> As an alternative, ADD_MONTHS function could be used .
> {code:sql}
> select ADD_MONTHS(to_date('2018/03/31', 'yyyy/mm/dd'), 1) from dual
> {code}
> It is not defined in the functions spec how timestampadd with SQL_TSI_MONTH should behave in some cases but anyway no error should happen.
> Currently "interval" - inflicted Oracle errors are transmitted for timestampadd invocations.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (TEIID-5409) left join is reversed
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5409?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-5409:
---------------------------------------
Thanks Bram. We'll cut the fix releases a little earlier to get this out a little sooner.
> left join is reversed
> ---------------------
>
> Key: TEIID-5409
> URL: https://issues.jboss.org/browse/TEIID-5409
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 10.3.1, 10.3.2
> Reporter: Bram Gadeyne
> Assignee: Steven Hawkins
> Priority: Blocker
> Fix For: 11.1, 11.0.1, 10.3.3
>
> Attachments: plan_teiid_10.3.2.txt, plan_teiid_9.1.txt
>
>
> A query that is run on teiid 9.1 results in 56186 rows.
> The same query that is run on teiid 10.3.2 results in 5919 rows.
> It seems like the left join is reversed.
> I've attached both query plans.
> The queries are exactly the same. Note that on 9.1 we've prefixed table names with cos2_5_.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (TEIID-5427) Remove session/user scoped materialized views
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-5427?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-5427.
-----------------------------------
Resolution: Done
Removed the feature and updated the docs/release notes.
> Remove session/user scoped materialized views
> ---------------------------------------------
>
> Key: TEIID-5427
> URL: https://issues.jboss.org/browse/TEIID-5427
> Project: Teiid
> Issue Type: Task
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 11.1
>
>
> TEIID-2507 added session scoped materialized views - which are now not well aligned with any other materialization strategy. They have to be unmanaged and internal only. It would be best to completely remove the feature and recommend instead that users create global temporary tables instead.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months
[JBoss JIRA] (TEIID-5409) left join is reversed
by Bram Gadeyne (JIRA)
[ https://issues.jboss.org/browse/TEIID-5409?page=com.atlassian.jira.plugin... ]
Bram Gadeyne commented on TEIID-5409:
-------------------------------------
I've build the 10.3.3-SNAPSHOT an can confirm that the issue has been resolved.
> left join is reversed
> ---------------------
>
> Key: TEIID-5409
> URL: https://issues.jboss.org/browse/TEIID-5409
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 10.3.1, 10.3.2
> Reporter: Bram Gadeyne
> Assignee: Steven Hawkins
> Priority: Blocker
> Fix For: 11.1, 11.0.1, 10.3.3
>
> Attachments: plan_teiid_10.3.2.txt, plan_teiid_9.1.txt
>
>
> A query that is run on teiid 9.1 results in 56186 rows.
> The same query that is run on teiid 10.3.2 results in 5919 rows.
> It seems like the left join is reversed.
> I've attached both query plans.
> The queries are exactly the same. Note that on 9.1 we've prefixed table names with cos2_5_.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 5 months