[JBoss JIRA] (TEIID-2638) CLI Scripts are incorrectly referencing the cache within the cache container, should reference cache container
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-2638?page=com.atlassian.jira.plugin... ]
Van Halbert commented on TEIID-2638:
------------------------------------
server has an issue when the caches are assigned the cache names,not the container names. The following error is seen with current CLI scripts:
[Server:server-two] JBAS014775: New missing/unsatisfied dependencies:
[Server:server-two] service jboss.infinispan.preparedplan (missing) dependents: [service jboss.teiid.infinispan-pp-cache-factory]
[Server:server-two] service jboss.infinispan.preparedplan.preparedplan (missing) dependents: [service jboss.teiid.cache.prepared-plan]
[Server:server-two] service jboss.infinispan.resultset-repl (missing) dependents: [service jboss.teiid.infinispan-rs-cache-factory]
[Server:server-two] service jboss.infinispan.resultset-repl.resultset (missing) dependents: [service jboss.teiid.cache.resultset]
[Server:server-two] service jboss.infinispan.resultset-repl.resultset-repl (missing) dependents: [service jboss.teiid.cache.resultset]
[Server:server-two]
[Server:server-two] 11:06:28,817 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: JBoss EAP 6.1.0.GA (AS 7.2.0.Final-redhat-8) started (with errors) in 7222ms - Started 196 of 338 services (13 services failed or missing dependencies, 128 services are passive or on-demand)
which do not appear when those changes are mode.
> CLI Scripts are incorrectly referencing the cache within the cache container, should reference cache container
> --------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-2638
> URL: https://issues.jboss.org/browse/TEIID-2638
> Project: Teiid
> Issue Type: Bug
> Components: Build/Kits
> Affects Versions: 8.4, 8.4.1
> Reporter: Van Halbert
> Assignee: Van Halbert
> Fix For: 8.4.1, 8.5
>
>
> The domain and standalone cli scripts need to have the following lines corrected:
> /profile=ha/subsystem=teiid:add(async-thread-pool=teiid-async, distributed-cache-jgroups-stack=udp, resultset-cache-infinispan-container=resultset-repl, preparedplan-cache-infinispan-container=preparedplan, policy-decider-module=org.jboss.teiid)
> /subsystem=teiid:add(async-thread-pool=teiid-async, resultset-cache-infinispan-container=resultset, preparedplan-cache-infinispan-container=preparedplan, policy-decider-module=org.jboss.teiid)
> so that the cache containers map to teiid-cache, and not the cache within the container. This isn't seen in the standalone-teiid.xml, cause those settings to do point to the "teiid" cache container.
--
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, 4 months
[JBoss JIRA] (TEIID-2638) CLI Scripts are incorrectly referencing the cache within the cache container, should reference cache container
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2638?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2638.
-----------------------------------
Fix Version/s: 8.4.1
8.5
Resolution: Done
> CLI Scripts are incorrectly referencing the cache within the cache container, should reference cache container
> --------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-2638
> URL: https://issues.jboss.org/browse/TEIID-2638
> Project: Teiid
> Issue Type: Bug
> Components: Build/Kits
> Affects Versions: 8.4, 8.4.1
> Reporter: Van Halbert
> Assignee: Van Halbert
> Fix For: 8.4.1, 8.5
>
>
> The domain and standalone cli scripts need to have the following lines corrected:
> /profile=ha/subsystem=teiid:add(async-thread-pool=teiid-async, distributed-cache-jgroups-stack=udp, resultset-cache-infinispan-container=resultset-repl, preparedplan-cache-infinispan-container=preparedplan, policy-decider-module=org.jboss.teiid)
> /subsystem=teiid:add(async-thread-pool=teiid-async, resultset-cache-infinispan-container=resultset, preparedplan-cache-infinispan-container=preparedplan, policy-decider-module=org.jboss.teiid)
> so that the cache containers map to teiid-cache, and not the cache within the container. This isn't seen in the standalone-teiid.xml, cause those settings to do point to the "teiid" cache container.
--
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, 4 months
[JBoss JIRA] (TEIID-2638) CLI Scripts are incorrectly referencing the cache within the cache container, should reference cache container
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2638?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2638:
-------------------------------------
for HA add,
resultset-cache-name=resultset-repl
then we should be good
> CLI Scripts are incorrectly referencing the cache within the cache container, should reference cache container
> --------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-2638
> URL: https://issues.jboss.org/browse/TEIID-2638
> Project: Teiid
> Issue Type: Bug
> Components: Build/Kits
> Affects Versions: 8.4, 8.4.1
> Reporter: Van Halbert
> Assignee: Van Halbert
>
> The domain and standalone cli scripts need to have the following lines corrected:
> /profile=ha/subsystem=teiid:add(async-thread-pool=teiid-async, distributed-cache-jgroups-stack=udp, resultset-cache-infinispan-container=resultset-repl, preparedplan-cache-infinispan-container=preparedplan, policy-decider-module=org.jboss.teiid)
> /subsystem=teiid:add(async-thread-pool=teiid-async, resultset-cache-infinispan-container=resultset, preparedplan-cache-infinispan-container=preparedplan, policy-decider-module=org.jboss.teiid)
> so that the cache containers map to teiid-cache, and not the cache within the container. This isn't seen in the standalone-teiid.xml, cause those settings to do point to the "teiid" cache container.
--
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, 4 months
[JBoss JIRA] (TEIID-2638) CLI Scripts are incorrectly referencing the cache within the cache container, should reference cache container
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2638?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2638:
-------------------------------------
hmm.. good point may be not. Just the replication resultset cache name is not default in that case
> CLI Scripts are incorrectly referencing the cache within the cache container, should reference cache container
> --------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-2638
> URL: https://issues.jboss.org/browse/TEIID-2638
> Project: Teiid
> Issue Type: Bug
> Components: Build/Kits
> Affects Versions: 8.4, 8.4.1
> Reporter: Van Halbert
> Assignee: Van Halbert
>
> The domain and standalone cli scripts need to have the following lines corrected:
> /profile=ha/subsystem=teiid:add(async-thread-pool=teiid-async, distributed-cache-jgroups-stack=udp, resultset-cache-infinispan-container=resultset-repl, preparedplan-cache-infinispan-container=preparedplan, policy-decider-module=org.jboss.teiid)
> /subsystem=teiid:add(async-thread-pool=teiid-async, resultset-cache-infinispan-container=resultset, preparedplan-cache-infinispan-container=preparedplan, policy-decider-module=org.jboss.teiid)
> so that the cache containers map to teiid-cache, and not the cache within the container. This isn't seen in the standalone-teiid.xml, cause those settings to do point to the "teiid" cache container.
--
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, 4 months
[JBoss JIRA] (TEIID-2638) CLI Scripts are incorrectly referencing the cache within the cache container, should reference cache container
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2638?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2638:
---------------------------------------
Ramesh since we use those cache names by default in TeiidAdd, is there a reason that they need to be in the cli script as well?
> CLI Scripts are incorrectly referencing the cache within the cache container, should reference cache container
> --------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-2638
> URL: https://issues.jboss.org/browse/TEIID-2638
> Project: Teiid
> Issue Type: Bug
> Components: Build/Kits
> Affects Versions: 8.4, 8.4.1
> Reporter: Van Halbert
> Assignee: Van Halbert
>
> The domain and standalone cli scripts need to have the following lines corrected:
> /profile=ha/subsystem=teiid:add(async-thread-pool=teiid-async, distributed-cache-jgroups-stack=udp, resultset-cache-infinispan-container=resultset-repl, preparedplan-cache-infinispan-container=preparedplan, policy-decider-module=org.jboss.teiid)
> /subsystem=teiid:add(async-thread-pool=teiid-async, resultset-cache-infinispan-container=resultset, preparedplan-cache-infinispan-container=preparedplan, policy-decider-module=org.jboss.teiid)
> so that the cache containers map to teiid-cache, and not the cache within the container. This isn't seen in the standalone-teiid.xml, cause those settings to do point to the "teiid" cache container.
--
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, 4 months
[JBoss JIRA] (TEIID-2636) Stream corruption errors when doing big query
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2636?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2636.
-----------------------------------
Resolution: Done
The problem should have been caught early, but our exception from serialization was getting swallowed as if it were due to a concurrent modification. Corrected the exception handling, updated the logging, and switched the textline logic to use a proper array.
> Stream corruption errors when doing big query
> ---------------------------------------------
>
> Key: TEIID-2636
> URL: https://issues.jboss.org/browse/TEIID-2636
> Project: Teiid
> Issue Type: Bug
> Affects Versions: 8.4
> Environment: Teiid 8.5 Beta2 Running in JBoss EAP 6.1 on RHEL6
> Java 7 openjdk
> Reporter: Graeme Gillies
> Assignee: Steven Hawkins
> Fix For: 8.4.1, 8.5
>
> Attachments: server.log
>
>
> Hi,
> When performing the following big query against a virtual db we have setup in this environment, we get an error
> The query is
> {noformat}
> SELECT
> bugs.bug_id, classification.name, bugs.cf_internal_whiteboard,
> dev_cond_nak_grouped."value", partner_grouped."value",
> bugs.cf_last_closed, bugs.bug_severity, bugs.cf_qa_whiteboard,
> bugs.short_desc, qe_cond_nak_grouped."value", bugs.priority,
> bugs.version, bugs.cf_pm_score, bugs.bug_status, product.name,
> blocks_grouped.blocked, qa_contact.login_name, reporter.login_name,
> component.name, flag_grouped.flag_full, bugs.delta_ts,
> dependson_grouped.dependson, verified_grouped."value",
> bugs.creation_ts, bugs.cf_devel_whiteboard, keyword_grouped.name,
> target_release_grouped."value", bugs.target_milestone, assigned_to.login_name,
> bugs.resolution
> FROM Bugzilla_raw.bugs
> LEFT JOIN Bugzilla_raw.products ON products.id = bugs.product_id
> LEFT JOIN Bugzilla_raw.classifications classification ON classification.id = products.classification_id
> LEFT JOIN (SELECT bugs.bug_id, TEXTAGG(FOR(dev_cond_nak."value")) AS "value" FROM Bugzilla_raw.bugs JOIN Bugzilla_raw.bug_cf_conditional_nak dev_cond_nak ON dev_cond_nak.bug_id = bugs.bug_id GROUP BY bugs.bug_id) dev_cond_nak_grouped ON bugs.bug_id = dev_cond_nak_grouped.bug_id
> LEFT JOIN (SELECT bugs.bug_id, TEXTAGG(FOR(partner."value")) AS "value" FROM Bugzilla_raw.bugs JOIN Bugzilla_raw.bug_cf_partner partner ON partner.bug_id = bugs.bug_id GROUP BY bugs.bug_id) partner_grouped ON bugs.bug_id = partner_grouped.bug_id
> LEFT JOIN (SELECT bugs.bug_id, TEXTAGG(FOR(qe_cond_nak."value")) AS "value" FROM Bugzilla_raw.bugs JOIN Bugzilla_raw.bug_cf_qe_conditional_nak qe_cond_nak ON qe_cond_nak.bug_id = bugs.bug_id GROUP BY bugs.bug_id) qe_cond_nak_grouped ON bugs.bug_id = qe_cond_nak_grouped.bug_id
> LEFT JOIN Bugzilla_raw.products product ON product.id = bugs.product_id LEFT JOIN (SELECT bugs.bug_id, TEXTAGG(FOR(blocks.blocked)) AS blocked FROM Bugzilla_raw.bugs JOIN Bugzilla_raw.dependencies blocks ON blocks.dependson = bugs.bug_id GROUP BY bugs.bug_id) blocks_grouped ON bugs.bug_id = blocks_grouped.bug_id
> LEFT JOIN Bugzilla_raw.profiles qa_contact ON qa_contact.userid = bugs.qa_contact LEFT JOIN Bugzilla_raw.profiles reporter ON reporter.userid = bugs.reporter LEFT JOIN Bugzilla_raw.components component ON component.id = bugs.component_id LEFT JOIN ( SELECT flags.bug_id, TEXTAGG(FOR(concat(ft.name, flags.status))) AS flag_full FROM Bugzilla_raw.flags
> LEFT JOIN Bugzilla_raw.flagtypes ft ON ft.id = flags.type_id GROUP BY flags.bug_id) flag_grouped ON bugs.bug_id = flag_grouped.bug_id
> LEFT JOIN (SELECT bugs.bug_id, TEXTAGG(FOR(dependson.dependson)) AS dependson FROM Bugzilla_raw.bugs JOIN Bugzilla_raw.dependencies dependson ON dependson.blocked = bugs.bug_id GROUP BY bugs.bug_id) dependson_grouped ON bugs.bug_id = dependson_grouped.bug_id
> LEFT JOIN (SELECT bugs.bug_id, TEXTAGG(FOR(verified."value")) AS "value" FROM Bugzilla_raw.bugs JOIN Bugzilla_raw.bug_cf_verified verified ON verified.bug_id = bugs.bug_id GROUP BY bugs.bug_id) verified_grouped ON bugs.bug_id = verified_grouped.bug_id
> LEFT JOIN ( SELECT keywords.bug_id, TEXTAGG(FOR(kw.name)) AS name FROM Bugzilla_raw.keywords LEFT JOIN Bugzilla_raw.keyworddefs kw ON kw.id = keywords.keywordid GROUP BY keywords.bug_id) keyword_grouped ON bugs.bug_id = keyword_grouped.bug_id
> LEFT JOIN (SELECT bugs.bug_id, TEXTAGG(FOR(target_release."value")) AS "value" FROM Bugzilla_raw.bugs JOIN Bugzilla_raw.bugs_release target_release ON target_release.bug_id = bugs.bug_id GROUP BY bugs.bug_id) target_release_grouped ON bugs.bug_id = target_release_grouped.bug_id
> LEFT JOIN Bugzilla_raw.profiles assigned_to ON assigned_to.userid = bugs.assigned_to
> WHERE bugs.bug_id > 990410 OR bugs.delta_ts > parseTimestamp('2013-07-31 06:57:31 +0000', 'yyyy-MM-dd HH:mm:ss z')
> LIMIT 0,1000000
> {noformat}
> The error the client sees is
> ERROR: TEIID30048 Error reading 24,668
> DETAIL: org.teiid.jdbc.TeiidSQLException: TEIID30048 Error reading 24,668
> This is using the Postgresql ODBC interface or the JDBC interface
> The errors in the log file are quite long so I will attach the whole log file.
> Regards,
> Graeme
--
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, 4 months
[JBoss JIRA] (TEIID-2638) CLI Scripts are incorrectly referencing the cache within the cache container, should reference cache container
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-2638?page=com.atlassian.jira.plugin... ]
Ramesh Reddy commented on TEIID-2638:
-------------------------------------
Those are still in-correct. It should be
resultset-cache-infinispan-container=teiid-cache, resultset-cache-name=resultset, preparedplan-cache-infinispan-container=teiid-cache, preparedplan-cache-name= preparedplan
and for HA
resultset-cache-infinispan-container=teiid-cache, resultset-cache-name=resultset-repl, preparedplan-cache-infinispan-container=teiid-cache, preparedplan-cache-name= preparedplan
Pull submitted is wrong
> CLI Scripts are incorrectly referencing the cache within the cache container, should reference cache container
> --------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-2638
> URL: https://issues.jboss.org/browse/TEIID-2638
> Project: Teiid
> Issue Type: Bug
> Components: Build/Kits
> Affects Versions: 8.4, 8.4.1
> Reporter: Van Halbert
> Assignee: Van Halbert
>
> The domain and standalone cli scripts need to have the following lines corrected:
> /profile=ha/subsystem=teiid:add(async-thread-pool=teiid-async, distributed-cache-jgroups-stack=udp, resultset-cache-infinispan-container=resultset-repl, preparedplan-cache-infinispan-container=preparedplan, policy-decider-module=org.jboss.teiid)
> /subsystem=teiid:add(async-thread-pool=teiid-async, resultset-cache-infinispan-container=resultset, preparedplan-cache-infinispan-container=preparedplan, policy-decider-module=org.jboss.teiid)
> so that the cache containers map to teiid-cache, and not the cache within the container. This isn't seen in the standalone-teiid.xml, cause those settings to do point to the "teiid" cache container.
--
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, 4 months
[JBoss JIRA] (TEIID-2638) CLI Scripts are incorrectly referencing the cache within the cache container, should reference cache container
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-2638?page=com.atlassian.jira.plugin... ]
Work on TEIID-2638 stopped by Van Halbert.
> CLI Scripts are incorrectly referencing the cache within the cache container, should reference cache container
> --------------------------------------------------------------------------------------------------------------
>
> Key: TEIID-2638
> URL: https://issues.jboss.org/browse/TEIID-2638
> Project: Teiid
> Issue Type: Bug
> Components: Build/Kits
> Affects Versions: 8.4, 8.4.1
> Reporter: Van Halbert
> Assignee: Van Halbert
>
> The domain and standalone cli scripts need to have the following lines corrected:
> /profile=ha/subsystem=teiid:add(async-thread-pool=teiid-async, distributed-cache-jgroups-stack=udp, resultset-cache-infinispan-container=resultset-repl, preparedplan-cache-infinispan-container=preparedplan, policy-decider-module=org.jboss.teiid)
> /subsystem=teiid:add(async-thread-pool=teiid-async, resultset-cache-infinispan-container=resultset, preparedplan-cache-infinispan-container=preparedplan, policy-decider-module=org.jboss.teiid)
> so that the cache containers map to teiid-cache, and not the cache within the container. This isn't seen in the standalone-teiid.xml, cause those settings to do point to the "teiid" cache container.
--
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, 4 months
[JBoss JIRA] (TEIID-2475) The RelationalNode.collectNodeStats is only subtracting out the last node
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2475?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2475.
-----------------------------------
Fix Version/s: 8.4.1
8.5
(was: 8.4)
(was: 7.7.8)
Resolution: Done
Changed from reporting "node process time" to "node next batch process time".
The "cumulative node process time" overlaps for child nodes - since it starts when a batch is first fetched and the blocked exception may be caught. So it is generally not possible to compute just the "node process time", we do know however that the child next batch times do not overlap, so we can somewhat accurately report just the "node next batch process time".
Another issue seen but not addressed is that nodes that directly return a tuple buffer (such as a full sort) will not report any node stats as getNextBatch is never consulted. I'm not sure what should be done in these case as we don't wont to needlessly iterate over the batches.
> The RelationalNode.collectNodeStats is only subtracting out the last node
> -------------------------------------------------------------------------
>
> Key: TEIID-2475
> URL: https://issues.jboss.org/browse/TEIID-2475
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 6.0.0
> Reporter: Debbie Steigner
> Assignee: Steven Hawkins
> Fix For: 8.4.1, 8.5
>
> Attachments: Query_Plan.txt
>
>
> The "Node Cumulative Next Batch Process Time" Statistic
> If you have a look at the explain plan (attached). Following the definition,
> the JoinNode Node Cumulative Next Batch Process Time: 565471. So, it is the summation of AccessNode (Node Process Time: 892860) + DependentAccessNode (Node Process Time: 439) + JoinNode (Node Process Time: 2203120). The summation does not agree.
> The RelationalNode.collectNodeStats looks wrong (it's effectively only subtracting out the last node)
--
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, 4 months
[JBoss JIRA] (TEIID-2637) Catching exceptions in BatchIterator.more masks problems
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2637?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-2637.
-----------------------------------
Resolution: Done
Allowing the iterator to throw component exceptions and prevented the possibility of throwing a processing exception. Also cleaned up the synchronization at the datatiertuplesource layer since inappropriate behavior was seen there after the batchiterator caused processing beyond when the the nodes were valid.
> Catching exceptions in BatchIterator.more masks problems
> --------------------------------------------------------
>
> Key: TEIID-2637
> URL: https://issues.jboss.org/browse/TEIID-2637
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Affects Versions: 7.4
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Fix For: 8.4.1, 8.5
>
>
> Depending upon the exception caught, the use of the iterator will be against nodes in an invalid state and lead to other errors.
--
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, 4 months