September 2013 - teiid-issues - Jboss List Archives

[JBoss JIRA] (TEIID-1311) Consider developing a connector/translator to Cassandra/Thrift

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-1311?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-1311: --------------------------------------- I should add that there is currently no separate cassandra-api module. The translator module is just a dependency of the resource adapter. This seems fine given their tightly coupled relationship. > Consider developing a connector/translator to Cassandra/Thrift > -------------------------------------------------------------- > > Key: TEIID-1311 > URL: https://issues.jboss.org/browse/TEIID-1311 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Affects Versions: 7.1 > Environment: Any > Reporter: Ken Johnson > Fix For: 8.6 > > > Apache Cassandra is starting to see uptake beyond the big name social network players. Has any thought been given to offering connectivity to Cassandra through Teiid? Perhaps this is through consuming the Thrift file as metadata 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-1311) Consider developing a connector/translator to Cassandra/Thrift

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-1311?page=com.atlassian.jira.plugin... ] Steven Hawkins reassigned TEIID-1311: ------------------------------------- Assignee: Steven Hawkins > Consider developing a connector/translator to Cassandra/Thrift > -------------------------------------------------------------- > > Key: TEIID-1311 > URL: https://issues.jboss.org/browse/TEIID-1311 > Project: Teiid > Issue Type: Feature Request > Components: Misc. Connectors > Affects Versions: 7.1 > Environment: Any > Reporter: Ken Johnson > Assignee: Steven Hawkins > Fix For: 8.6 > > > Apache Cassandra is starting to see uptake beyond the big name social network players. Has any thought been given to offering connectivity to Cassandra through Teiid? Perhaps this is through consuming the Thrift file as metadata 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2680) VDBService not properly detecting missing delegate

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2680?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-2680. ----------------------------------- Resolution: Done Corrected the check. > VDBService not properly detecting missing delegate > -------------------------------------------------- > > Key: TEIID-2680 > URL: https://issues.jboss.org/browse/TEIID-2680 > Project: Teiid > Issue Type: Bug > Components: Server > Affects Versions: 8.4.1, 8.5 > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.6 > > > This is a regression introduced by TEIID-2629. The getExecutionFactory check for setting the delegate is incorrect. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2680) VDBService not properly detecting missing delegate

by Steven Hawkins (JIRA)

Steven Hawkins created TEIID-2680: ------------------------------------- Summary: VDBService not properly detecting missing delegate Key: TEIID-2680 URL: https://issues.jboss.org/browse/TEIID-2680 Project: Teiid Issue Type: Bug Components: Server Affects Versions: 8.5, 8.4.1 Reporter: Steven Hawkins Assignee: Steven Hawkins Fix For: 8.6 This is a regression introduced by TEIID-2629. The getExecutionFactory check for setting the delegate is incorrect. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2679) future proof the client handshake client/server version

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2679?page=com.atlassian.jira.plugin... ] Steven Hawkins resolved TEIID-2679. ----------------------------------- Resolution: Done Updated the handshake object and all string comparisons to normalize the numerical version components to two digits. > future proof the client handshake client/server version > ------------------------------------------------------- > > Key: TEIID-2679 > URL: https://issues.jboss.org/browse/TEIID-2679 > Project: Teiid > Issue Type: Quality Risk > Components: Server > Reporter: Steven Hawkins > Assignee: Steven Hawkins > Fix For: 8.6 > > > Until the version logic in the DQPWorkContext, the version strings are being compared lexically which will have an issue with any version part greater than 9. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2676) Delay in DataNotAvailableException not honored when isForkable=false

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2676?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2676: --------------------------------------- To elaborate more on an analogy I'm alluding to is that a non-strict DNA is the moral equivalent of a java timed wait. If you do {code} synchroized(foo) { foo.wait(1000); } {code} you may wait 1000 ms, but there isn't a hard guarantee either way - you may be spuriously woken up early and you may due to other factors won't necessarily resume after exactly 1000 ms. So with the wait and the non-strict DNA it would be considered a best practice (or in the DNA case basically required given the number of wake-ups that can occur) to use some logic to ensure that the wait exit condition has been met: {code} synchronized(foo) { while (!done) { foo.wait(timeRemaining); } } {code} So if you don't strictly want to wait, then you should probably have translator logic that knows a little more about when it can/should resume. > Delay in DataNotAvailableException not honored when isForkable=false > -------------------------------------------------------------------- > > Key: TEIID-2676 > URL: https://issues.jboss.org/browse/TEIID-2676 > Project: Teiid > Issue Type: Bug > Reporter: Mark Addleman > Assignee: Steven Hawkins > Attachments: DelayNotHonored.java > > > It appears that when isForkable=false, the delay specified in DataNotFoundException is not honored. I have seen similar behavior even when isForkable=true but it's a Heisenbug: when I add logging, it goes away. It smells like a race condition. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2676) Delay in DataNotAvailableException not honored when isForkable=false

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2676?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2676: --------------------------------------- > Then I must not understand something. It's my understanding that since the execution is not reusable, a new instance is created when the command is reexecuted. This effectively resets the letExecutionContinue to false each time the command is (re)executed so I would expect a delay. Ah, I glanced and must have assumed that you were reusable. The issue here is still really one of strictness - more deeply it's an issue of how the client and source events interact with the processing state machine. The client will always proactively fetch the next batch after the first batch (of a single row) is delivered, it signals it wants more results. In the not forkable scenario, this is occurring with the state machine is in the executing state. The state machine will transition into "more work" as it's assumed this is generally an asynch process from execution and we don't know where we are at in the execution cycle - it's a purposeful simplification to keep the state machine unaware of whether the work event is related to results processing or from a source. Then when the translator throws a non-strict DNA it will be immediately handle since you are not forkable and the engine will see the "more work" state and immediately try to continue executing. When forkable, essentially the execution state machine is transitioning out of execution prior to processing the DNA, such that it will be interpreted the way you expect. So the best recommendation in general is to use a strict DNA to prevent any spurious wake up from triggering a processing that you don't expect. Otherwise we'd likely have to differentiate more between the "more work" events, which isn't appealing. > Further, I don't understand why the behavior should be different when forkable is true versus false. That represents that your plan (which is now asynch from the Execution) will transition into a different state by the time the DNA or results have been delivered, such that it more results are requested by the client > Delay in DataNotAvailableException not honored when isForkable=false > -------------------------------------------------------------------- > > Key: TEIID-2676 > URL: https://issues.jboss.org/browse/TEIID-2676 > Project: Teiid > Issue Type: Bug > Reporter: Mark Addleman > Assignee: Steven Hawkins > Attachments: DelayNotHonored.java > > > It appears that when isForkable=false, the delay specified in DataNotFoundException is not honored. I have seen similar behavior even when isForkable=true but it's a Heisenbug: when I add logging, it goes away. It smells like a race condition. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2676) Delay in DataNotAvailableException not honored when isForkable=false

by Mark Addleman (JIRA)

[ https://issues.jboss.org/browse/TEIID-2676?page=com.atlassian.jira.plugin... ] Mark Addleman commented on TEIID-2676: -------------------------------------- > Your code only produces an initial delay, as no DNA will be thrown after that. Then I must not understand something. It's my understanding that since the execution is not reusable, a new instance is created when the command is reexecuted. This effectively resets the letExecutionContinue to false each time the command is (re)executed so I would expect a delay. > Here again it may the the non-strict nature that is throwing things off. When any source reports that data is available the engine resumes the plan - but doesn't specifically know/care that it was data source x that's now ready Since there's only one execution in my test case, again, I would expect the delay on every execution, no? Further, I don't understand why the behavior should be different when forkable is true versus false. > Delay in DataNotAvailableException not honored when isForkable=false > -------------------------------------------------------------------- > > Key: TEIID-2676 > URL: https://issues.jboss.org/browse/TEIID-2676 > Project: Teiid > Issue Type: Bug > Reporter: Mark Addleman > Assignee: Steven Hawkins > Attachments: DelayNotHonored.java > > > It appears that when isForkable=false, the delay specified in DataNotFoundException is not honored. I have seen similar behavior even when isForkable=true but it's a Heisenbug: when I add logging, it goes away. It smells like a race condition. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2676) Delay in DataNotAvailableException not honored when isForkable=false

by Steven Hawkins (JIRA)

[ https://issues.jboss.org/browse/TEIID-2676?page=com.atlassian.jira.plugin... ] Steven Hawkins commented on TEIID-2676: --------------------------------------- > I get a barrage of "Row received" with no delay. I'm running an JDK "1.7.0_11-b21" on an 8 core laptop. Your code only produces an initial delay, as no DNA will be thrown after that. > I don't have time to come with a test case now but it seems the misbehavior is also tied to the complexity of the query - adding a join can trigger the bug regardless of the forkable setting. Here again it may the the non-strict nature that is throwing things off. When any source reports that data is available the engine resumes the plan - but doesn't specifically know/care that it was data source x that's now ready. Since it is restarting it will go through the default processing logic that can result in polls against all sources and without a strict DNA you won't see a pause. > Delay in DataNotAvailableException not honored when isForkable=false > -------------------------------------------------------------------- > > Key: TEIID-2676 > URL: https://issues.jboss.org/browse/TEIID-2676 > Project: Teiid > Issue Type: Bug > Reporter: Mark Addleman > Assignee: Steven Hawkins > Attachments: DelayNotHonored.java > > > It appears that when isForkable=false, the delay specified in DataNotFoundException is not honored. I have seen similar behavior even when isForkable=true but it's a Heisenbug: when I add logging, it goes away. It smells like a race condition. -- 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

11 years, 2 months

1
0
0 / 0

[JBoss JIRA] (TEIID-2676) Delay in DataNotAvailableException not honored when isForkable=false

by Mark Addleman (JIRA)

[ https://issues.jboss.org/browse/TEIID-2676?page=com.atlassian.jira.plugin... ] Mark Addleman commented on TEIID-2676: -------------------------------------- I get a barrage of "Row received" with no delay. I'm running an JDK "1.7.0_11-b21" on an 8 core laptop. Other observations: I tend to see this kind of behavior more with stored procedures than with tables, although with uploaded test case, I get the same behavior with both table and stored procedure. I don't have time to come with a test case now but it seems the misbehavior is also tied to the complexity of the query - adding a join can trigger the bug regardless of the forkable setting. > Delay in DataNotAvailableException not honored when isForkable=false > -------------------------------------------------------------------- > > Key: TEIID-2676 > URL: https://issues.jboss.org/browse/TEIID-2676 > Project: Teiid > Issue Type: Bug > Reporter: Mark Addleman > Assignee: Steven Hawkins > Attachments: DelayNotHonored.java > > > It appears that when isForkable=false, the delay specified in DataNotFoundException is not honored. I have seen similar behavior even when isForkable=true but it's a Heisenbug: when I add logging, it goes away. It smells like a race condition. -- 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

11 years, 2 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

teiid-issues September 2013