[JBoss JIRA] (TEIID-3164) Second connection to VDB through Kerberos authentication ends with exception
by Juraj Duráni (JIRA)
Juraj Duráni created TEIID-3164:
-----------------------------------
Summary: Second connection to VDB through Kerberos authentication ends with exception
Key: TEIID-3164
URL: https://issues.jboss.org/browse/TEIID-3164
Project: Teiid
Issue Type: Bug
Affects Versions: 8.7.1
Environment: OS: fedora20
arch: x86_64
java: sun 1.7
kdc: on localhost
Reporter: Juraj Duráni
Assignee: Steven Hawkins
Second (third,forth,...) conection to VDB through Kerberos ends with exception:
javax.security.auth.login.LoginException: TEIID50103 Wrong Response returned from EXAMPLE.COM security domain; Expecting a Kerberoes response
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (TEIID-3070) Netty worker threads cause system high cpu
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3070?page=com.atlassian.jira.plugin... ]
Kylin Soong edited comment on TEIID-3070 at 10/8/14 11:31 PM:
--------------------------------------------------------------
Hi Steven
I have talked with norman that seems netty 3.6.x have this issue(DV 6.0 use netty 3.6.6, DV 6.1 use netty 3.6.7), not sure other versions.
Teiid 8.7.x use bom to contorl netty version, as Bugzilla updates, the issue being handled in wildfly and EAP upstream, no changes are needed in teiid side.
Netty 3.6.10 has been released(https://github.com/netty/netty/releases/tag/netty-3.6.10.Final), for current master netty 8.9, I have tested update netty version to 3.6.10, but execute build failed(runtime unit test failed), do you think we need upgrate the netty version? if yes, I will do more investigation.
was (Author: kylin):
Hi Steven
I have talked with norman that seems netty 3.6.x have this issue(DV 6.0 use netty 3.6.6, DV 6.1 use netty 3.6.7), not sure other versions.
Teiid 8.7.x use bom to contorl netty version, as Bugzilla updates, the issue being handled in wildfly and EAP upstream, no changes are needed in teiid side.
Netty 3.6.10 has been released(https://github.com/netty/netty/releases/tag/netty-3.6.10.Final), for current master netty 8.9, I have tested update netty version to 3.6.10, but execute build failed, do you think we need upgrate the netty version? if yes, I will do more investigation.
> Netty worker threads cause system high cpu
> ------------------------------------------
>
> Key: TEIID-3070
> URL: https://issues.jboss.org/browse/TEIID-3070
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.7
> Environment: JDV 6.1.0.DR2
> JDV 6.0
> Reporter: Kylin Soong
> Assignee: Kylin Soong
>
> I have hit this issue many times in deploying a VDB to JDV, All CPU be used by netty worker threads:
> ~~~
> "New I/O worker #3" daemon prio=10 tid=0x00007fc71c0d2000 nid=0x320b runnable [0x00007fc7074f3000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87)
> - locked <0x00000000c42b4318> (a sun.nio.ch.Util$2)
> - locked <0x00000000c42b4328> (a java.util.Collections$UnmodifiableSet)
> - locked <0x00000000c42b42d0> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98)
> at org.jboss.netty.channel.socket.nio.SelectorUtil.select(SelectorUtil.java:64)
> ~~~
> Seems this is a exist netty issue, search "jboss netty high cpu" via google we can get lots of result.
> Below link have detailed depiction about this issue;
> https://github.com/kylinsoong/teiid-samples/tree/master/highcpu
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (TEIID-3070) Netty worker threads cause system high cpu
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3070?page=com.atlassian.jira.plugin... ]
Kylin Soong edited comment on TEIID-3070 at 10/8/14 11:30 PM:
--------------------------------------------------------------
Hi Steven
I have talked with norman that seems netty 3.6.x have this issue(DV 6.0 use netty 3.6.6, DV 6.1 use netty 3.6.7), not sure other versions.
Teiid 8.7.x use bom to contorl netty version, as Bugzilla updates, the issue being handled in wildfly and EAP upstream, no changes are needed in teiid side.
Netty 3.6.10 has been released(https://github.com/netty/netty/releases/tag/netty-3.6.10.Final), for current master netty 8.9, I have tested update netty version to 3.6.10, but execute build failed, do you think we need upgrate the netty version? if yes, I will do more investigation.
was (Author: kylin):
Hi Steven
I have talked with norman that seems netty 3.6.x have this issue(DV 6.0 use netty 3.6.6, DV 6.1 use netty 3.6.7), not sure other versions.
Teiid 8.7.x use bom to contorl netty version, as Bugzilla updates, the issue being handled in wildfly and EAP upstream, no changes are needed in teiid side.
Netty 3.6.10 has been released(https://github.com/netty/netty/releases/tag/netty-3.6.10.Final), for current master netty 8.9, I think we can update netty version to 3.6.10 directly.
> Netty worker threads cause system high cpu
> ------------------------------------------
>
> Key: TEIID-3070
> URL: https://issues.jboss.org/browse/TEIID-3070
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.7
> Environment: JDV 6.1.0.DR2
> JDV 6.0
> Reporter: Kylin Soong
> Assignee: Kylin Soong
>
> I have hit this issue many times in deploying a VDB to JDV, All CPU be used by netty worker threads:
> ~~~
> "New I/O worker #3" daemon prio=10 tid=0x00007fc71c0d2000 nid=0x320b runnable [0x00007fc7074f3000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87)
> - locked <0x00000000c42b4318> (a sun.nio.ch.Util$2)
> - locked <0x00000000c42b4328> (a java.util.Collections$UnmodifiableSet)
> - locked <0x00000000c42b42d0> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98)
> at org.jboss.netty.channel.socket.nio.SelectorUtil.select(SelectorUtil.java:64)
> ~~~
> Seems this is a exist netty issue, search "jboss netty high cpu" via google we can get lots of result.
> Below link have detailed depiction about this issue;
> https://github.com/kylinsoong/teiid-samples/tree/master/highcpu
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (TEIID-3070) Netty worker threads cause system high cpu
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3070?page=com.atlassian.jira.plugin... ]
Kylin Soong commented on TEIID-3070:
------------------------------------
Hi Steven
I have talked with norman that seems netty 3.6.x have this issue(DV 6.0 use netty 3.6.6, DV 6.1 use netty 3.6.7), not sure other versions.
Teiid 8.7.x use bom to contorl netty version, as Bugzilla updates, the issue being handled in wildfly and EAP upstream, no changes are needed in teiid side.
Netty 3.6.10 has been released(https://github.com/netty/netty/releases/tag/netty-3.6.10.Final), for current master netty 8.9, I think we can update netty version to 3.6.10 directly.
> Netty worker threads cause system high cpu
> ------------------------------------------
>
> Key: TEIID-3070
> URL: https://issues.jboss.org/browse/TEIID-3070
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.7
> Environment: JDV 6.1.0.DR2
> JDV 6.0
> Reporter: Kylin Soong
> Assignee: Kylin Soong
>
> I have hit this issue many times in deploying a VDB to JDV, All CPU be used by netty worker threads:
> ~~~
> "New I/O worker #3" daemon prio=10 tid=0x00007fc71c0d2000 nid=0x320b runnable [0x00007fc7074f3000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87)
> - locked <0x00000000c42b4318> (a sun.nio.ch.Util$2)
> - locked <0x00000000c42b4328> (a java.util.Collections$UnmodifiableSet)
> - locked <0x00000000c42b42d0> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98)
> at org.jboss.netty.channel.socket.nio.SelectorUtil.select(SelectorUtil.java:64)
> ~~~
> Seems this is a exist netty issue, search "jboss netty high cpu" via google we can get lots of result.
> Below link have detailed depiction about this issue;
> https://github.com/kylinsoong/teiid-samples/tree/master/highcpu
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (TEIID-3142) Vanilla Hive sorting issue
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3142?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3142:
---------------------------------------
There is also now TEIID-3156 that can be used to more selectively turn string sorting behavior. Just to double check, what is the ordering given by hive?
> Vanilla Hive sorting issue
> --------------------------
>
> Key: TEIID-3142
> URL: https://issues.jboss.org/browse/TEIID-3142
> Project: Teiid
> Issue Type: Feature Request
> Components: Misc. Connectors
> Affects Versions: 8.7.1
> Reporter: Filip Nguyen
> Assignee: Steven Hawkins
>
> It seems that Vanilla Apache Hive 0.13 sorts in a yet another different way than what we expect and also differently from Cloudera Imapla (another Hive flavor).
> SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA order by BQT1.SmallA.StringNum
> 1: -1
> 2: -10
> 3: -11
> 4: -12
> 5: -13
> 6: -14
> 7: -15
> 8: -16
> 9: -17
> 10: -18
> 11: -19
> 12: -2
> 13: -20
> 14: -21
> 15: -22
> 16: -24
> 17: -3
> 18: -4
> 19: -5
> 20: -6
> 21: -8
> 22: -9
> 23: 0
> 24: 1
> 25: 10
> 26: 11
> 27: 12
> 28: 13
> 29: 14
> 30: 15
> 31: 16
> 32: 17
> 33: 18
> 34: 19
> 35: 2
> 36: 20
> 37: 21
> 38: 22
> 39: 23
> 40: 24
> 41: 3
> 42: 4
> 43: 5
> 44: 6
> 45: 7
> 46: 8
> 47: null
> 48: null
> 49: null
> 50: null
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (TEIID-3134) Impala sorting Issue
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3134?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3134:
---------------------------------------
Just to double check, something that isn't show above is an order by clause? Is there an explicit ordering that you are comparing? From the link it looks like we should expect the source ordering to work as all data you are dealing with is ascii compatible.
> Impala sorting Issue
> --------------------
>
> Key: TEIID-3134
> URL: https://issues.jboss.org/browse/TEIID-3134
> Project: Teiid
> Issue Type: Bug
> Components: Misc. Connectors
> Affects Versions: 8.7.1
> Reporter: Van Halbert
>
> String sorting of impala is inconsistent with our expectations:
> Impala sorting
> ---------------------------
> SELECT BQT1.SmallA.StringNum FROM BQT1.SmallA
> Results
> 1: -1
> 2: -10
> 3: -11
> 4: -12
> 5: -13
> 6: -14
> 7: -15
> 8: -16
> 9: -17
> 10: -18
> 11: -19
> 12: -2
> 13: -20
> 14: -21
> 15: -22
> 16: -24
> 17: -3
> 18: -4
> 19: -5
> 20: -6
> 21: -8
> 22: -9
> 23: 0
> 24: 1
> 25: 10
> 26: 11
> 27: 12
> 28: 13
> 29: 14
> 30: 15
> 31: 16
> 32: 17
> 33: 18
> 34: 19
> 35: 2
> 36: 20
> 37: 21
> 38: 22
> 39: 23
> 40: 24
> 41: 3
> 42: 4
> 43: 5
> 44: 6
> 45: 7
> 46: 8
> 47: null
> 48: null
> 49: null
> 50: null
> Expected
> ---------------------------
> While we expect sorting to be consistent with other sources:
> 1: 0
> 2: 1
> 3: -1
> 4: 10
> 5: -10
> 6: 11
> 7: -11
> 8: 12
> 9: -12
> 10: 13
> 11: -13
> 12: 14
> 13: -14
> 14: 15
> 15: -15
> 16: 16
> 17: -16
> 18: 17
> 19: -17
> 20: 18
> 21: -18
> 22: 19
> 23: -19
> 24: 2
> 25: -2
> 26: 20
> 27: -20
> 28: 21
> 29: -21
> 30: 22
> 31: -22
> 32: 23
> 33: 24
> 34: -24
> 35: 3
> 36: -3
> 37: 4
> 38: -4
> 39: 5
> 40: -5
> 41: 6
> 42: -6
> 43: 7
> 44: 8
> 45: -8
> 46: -9
> 47: null
> 48: null
> 49: null
> 50: null
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (TEIID-3156) Provide a mechanism to turn off string sorting
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3156?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-3156.
-----------------------------------
Resolution: Done
Added the translator property collationLocale which if different than the system property org.teiid.collationLocale will inhibit the pushdown of order by string values for join processing and with the system property org.teiid.requireTeiidCollation set will inhibit any pushdown of a string ordering where the locales do not match.
> Provide a mechanism to turn off string sorting
> ----------------------------------------------
>
> Key: TEIID-3156
> URL: https://issues.jboss.org/browse/TEIID-3156
> Project: Teiid
> Issue Type: Feature Request
> Components: Misc. Connectors, Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.9
>
>
> Currently we don't have a fine grained mechanism to turn off source sorting of specifically string data. If a source is using a different collation for example and cannot be set on a session basis (that could be configured on the datasource) to an ansi/utf collation, then at least for join scenarios we have to process the sort in the engine. Optionally the user may wan the Teiid default collation enforced even for other sorts.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months
[JBoss JIRA] (TEIID-3070) Netty worker threads cause system high cpu
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3070?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3070:
---------------------------------------
Is there any indication of when a 3.6.10 netty will be released so that we can resolve this fully from the community side - and possibly add patching instructions to the download page?
> Netty worker threads cause system high cpu
> ------------------------------------------
>
> Key: TEIID-3070
> URL: https://issues.jboss.org/browse/TEIID-3070
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 8.7
> Environment: JDV 6.1.0.DR2
> JDV 6.0
> Reporter: Kylin Soong
> Assignee: Kylin Soong
>
> I have hit this issue many times in deploying a VDB to JDV, All CPU be used by netty worker threads:
> ~~~
> "New I/O worker #3" daemon prio=10 tid=0x00007fc71c0d2000 nid=0x320b runnable [0x00007fc7074f3000]
> java.lang.Thread.State: RUNNABLE
> at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
> at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:269)
> at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:79)
> at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87)
> - locked <0x00000000c42b4318> (a sun.nio.ch.Util$2)
> - locked <0x00000000c42b4328> (a java.util.Collections$UnmodifiableSet)
> - locked <0x00000000c42b42d0> (a sun.nio.ch.EPollSelectorImpl)
> at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98)
> at org.jboss.netty.channel.socket.nio.SelectorUtil.select(SelectorUtil.java:64)
> ~~~
> Seems this is a exist netty issue, search "jboss netty high cpu" via google we can get lots of result.
> Below link have detailed depiction about this issue;
> https://github.com/kylinsoong/teiid-samples/tree/master/highcpu
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
9 years, 8 months