[JBoss JIRA] (TEIIDSB-171) Add an opentracing example
by Steven Hawkins (Jira)
Steven Hawkins created TEIIDSB-171:
--------------------------------------
Summary: Add an opentracing example
Key: TEIIDSB-171
URL: https://issues.redhat.com/browse/TEIIDSB-171
Project: Teiid Spring Boot
Issue Type: Task
Components: OpenShift
Reporter: Steven Hawkins
Assignee: Ramesh Reddy
Fix For: 1.4.0
Provide an example demonstrating end-to-end opentracing.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (TEIID-5906) Occasional test failure
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5906?focusedWorklogId=12450203&pag... ]
Steven Hawkins logged work on TEIID-5906:
-----------------------------------------
Author: Steven Hawkins
Created on: 17/Feb/20 10:04 AM
Start Date: 17/Feb/20 10:04 AM
Worklog Time Spent: 30 minutes
Issue Time Tracking
-------------------
Remaining Estimate: 4 hours, 30 minutes (was: 5 hours)
Time Spent: 1 hour, 30 minutes (was: 1 hour)
Worklog Id: (was: 12450203)
> Occasional test failure
> -----------------------
>
> Key: TEIID-5906
> URL: https://issues.redhat.com/browse/TEIID-5906
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 13.1
>
> Original Estimate: 6 hours
> Time Spent: 1 hour, 30 minutes
> Remaining Estimate: 4 hours, 30 minutes
>
> TestWithClauseProcessing.testWithImplicitIndexing fails occasionally. Locally I have reproduced this after ~700 runs of the test.
> I'm not sure at this point what is introducing the non-determinism. I'll check if we need a better bound or if there is something deeper failing.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (TEIID-5906) Occasional test failure
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5906?page=com.atlassian.jira.plugi... ]
Steven Hawkins resolved TEIID-5906.
-----------------------------------
Resolution: Done
Simply upped the bound to 600000 for the test failure. Locally failure rates were stable at about 1 every 700 runs with the 500000 bound. In over 4000 runs, I never hit 600000. So the conclusion is that it's probably some fluctuation with gc activity that causes the higher read count. Note that without the implicit index there are over 1200000 reads at a baseline.
> Occasional test failure
> -----------------------
>
> Key: TEIID-5906
> URL: https://issues.redhat.com/browse/TEIID-5906
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 13.1
>
> Original Estimate: 6 hours
> Time Spent: 1 hour
> Remaining Estimate: 5 hours
>
> TestWithClauseProcessing.testWithImplicitIndexing fails occasionally. Locally I have reproduced this after ~700 runs of the test.
> I'm not sure at this point what is introducing the non-determinism. I'll check if we need a better bound or if there is something deeper failing.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (TEIID-5906) Occasional test failure
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5906?page=com.atlassian.jira.plugi... ]
Steven Hawkins updated TEIID-5906:
----------------------------------
Fix Version/s: 13.1
(was: 13.x)
> Occasional test failure
> -----------------------
>
> Key: TEIID-5906
> URL: https://issues.redhat.com/browse/TEIID-5906
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 13.1
>
> Original Estimate: 6 hours
> Time Spent: 1 hour
> Remaining Estimate: 5 hours
>
> TestWithClauseProcessing.testWithImplicitIndexing fails occasionally. Locally I have reproduced this after ~700 runs of the test.
> I'm not sure at this point what is introducing the non-determinism. I'll check if we need a better bound or if there is something deeper failing.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (TEIIDSB-147) Caching and materialization changes for JDG / OpenShift
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-147?focusedWorklogId=12450202&pa... ]
Steven Hawkins logged work on TEIIDSB-147:
------------------------------------------
Author: Steven Hawkins
Created on: 17/Feb/20 8:11 AM
Start Date: 17/Feb/20 8:11 AM
Worklog Time Spent: 1 hour
Issue Time Tracking
-------------------
Time Spent: 3 hours (was: 2 hours)
Worklog Id: (was: 12450202)
> Caching and materialization changes for JDG / OpenShift
> -------------------------------------------------------
>
> Key: TEIIDSB-147
> URL: https://issues.redhat.com/browse/TEIIDSB-147
> Project: Teiid Spring Boot
> Issue Type: Enhancement
> Components: core, OpenShift
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 1.4.0
>
> Time Spent: 3 hours
> Remaining Estimate: 0 minutes
>
> Started this as a higher level issue in Teiid Spring Boot rather than core Teiid since the work won't align well to Teiid 13.1, but some things may need addressed there as well.
> Things break down roughly into:
> * Single-pod support
> ** Define the expectations for how we'll be configured to hit a JDG instance - will it be a user exercise to create if it doesn't exist, will we need to create, will the be a crd strategy for creation, and will it be multi-tenet? There is also the issue / assumption of cache sharing based upon vdb name - is that sufficient for now?
> ** validate external materialization to JDG likely using a transactional upsert strategy to avoid issues like TEIID-5436
> * Multi-pod support
> ** everything from single-pod support
> ** Result set caching needs to directly write batches / results to JDG rather than relying upon on demand replication.
> ** requires replacing the logic that detect failed materialization loads
> ** internal materialization replacement needs to based upon something more like external materialization, but that can be seen as a next step that is turnkey internal materialization to JDG (little to no user setup required)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (TEIIDSB-147) Caching and materialization changes for JDG / OpenShift
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-147?page=com.atlassian.jira.plug... ]
Steven Hawkins resolved TEIIDSB-147.
------------------------------------
Resolution: Done
Marking the initial issue as resolved since the functionality in it's most basic form works.
There are 3 follow on issues, linked above:
- better handling for ispn credentials
- multi-pod support
- automation of internal materialization to jdg
> Caching and materialization changes for JDG / OpenShift
> -------------------------------------------------------
>
> Key: TEIIDSB-147
> URL: https://issues.redhat.com/browse/TEIIDSB-147
> Project: Teiid Spring Boot
> Issue Type: Enhancement
> Components: core, OpenShift
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Critical
> Fix For: 1.4.0
>
> Time Spent: 2 hours
> Remaining Estimate: 0 minutes
>
> Started this as a higher level issue in Teiid Spring Boot rather than core Teiid since the work won't align well to Teiid 13.1, but some things may need addressed there as well.
> Things break down roughly into:
> * Single-pod support
> ** Define the expectations for how we'll be configured to hit a JDG instance - will it be a user exercise to create if it doesn't exist, will we need to create, will the be a crd strategy for creation, and will it be multi-tenet? There is also the issue / assumption of cache sharing based upon vdb name - is that sufficient for now?
> ** validate external materialization to JDG likely using a transactional upsert strategy to avoid issues like TEIID-5436
> * Multi-pod support
> ** everything from single-pod support
> ** Result set caching needs to directly write batches / results to JDG rather than relying upon on demand replication.
> ** requires replacing the logic that detect failed materialization loads
> ** internal materialization replacement needs to based upon something more like external materialization, but that can be seen as a next step that is turnkey internal materialization to JDG (little to no user setup required)
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months
[JBoss JIRA] (TEIID-5906) Occasional test failure
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5906?page=com.atlassian.jira.plugi... ]
Steven Hawkins updated TEIID-5906:
----------------------------------
Original Estimate: 6 hours
Remaining Estimate: 6 hours
> Occasional test failure
> -----------------------
>
> Key: TEIID-5906
> URL: https://issues.redhat.com/browse/TEIID-5906
> Project: Teiid
> Issue Type: Bug
> Components: Query Engine
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 13.x
>
> Original Estimate: 6 hours
> Remaining Estimate: 6 hours
>
> TestWithClauseProcessing.testWithImplicitIndexing fails occasionally. Locally I have reproduced this after ~700 runs of the test.
> I'm not sure at this point what is introducing the non-determinism. I'll check if we need a better bound or if there is something deeper failing.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 11 months