[JBoss JIRA] (TEIID-5962) Teiid locks many threads when Salesforce is disconnected
by Renat Eskenin (Jira)
[ https://issues.redhat.com/browse/TEIID-5962?page=com.atlassian.jira.plugi... ]
Renat Eskenin commented on TEIID-5962:
--------------------------------------
And I think that behavior need to improve. You can try to look at Netflix Hystrix as example of this logic.
> Teiid locks many threads when Salesforce is disconnected
> --------------------------------------------------------
>
> Key: TEIID-5962
> URL: https://issues.redhat.com/browse/TEIID-5962
> Project: Teiid
> Issue Type: Bug
> Components: Salesforce Connector
> Affects Versions: 12.3.1
> Reporter: Renat Eskenin
> Assignee: Steven Hawkins
> Priority: Major
> Attachments: Снимок экрана от 2020-05-31 11-09-10.png
>
>
> We had two incidents in our experimental service with teiid spring boot app. When Salesforce is down to 20min and service with teiid trying to call SQL from Salesforce we have many threads in tomcat server (in spring boot app). Then when 200 threads is activated service do not reply to requests because is "max threads" in tomcat of service.
> Why teiid do not send response as "Salesforce is down - error" or connection timeout?
> Micro schema:
> HTTP Requests to REST api -> Teiid spring boot app -> {broken 20min}Salesforce
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (TEIID-5962) Teiid locks many threads when Salesforce is disconnected
by Renat Eskenin (Jira)
[ https://issues.redhat.com/browse/TEIID-5962?page=com.atlassian.jira.plugi... ]
Renat Eskenin edited comment on TEIID-5962 at 6/4/20 4:02 AM:
--------------------------------------------------------------
I set this properties, tnx. If we get new errors with this service, I will write about it. As I know in Salesforce maximal timeout (on server side) is 120s, so default values for this properties will be as Salesforce. It is not checked information, but admins told to me about it.
was (Author: i3draven):
I set this properties, tnx. If we get new errors with this service, I will write about it. As I know in Salesforce maximal timeout (on server side) is 120s, so default values for this properties will be as Salesforce.
> Teiid locks many threads when Salesforce is disconnected
> --------------------------------------------------------
>
> Key: TEIID-5962
> URL: https://issues.redhat.com/browse/TEIID-5962
> Project: Teiid
> Issue Type: Bug
> Components: Salesforce Connector
> Affects Versions: 12.3.1
> Reporter: Renat Eskenin
> Assignee: Steven Hawkins
> Priority: Major
> Attachments: Снимок экрана от 2020-05-31 11-09-10.png
>
>
> We had two incidents in our experimental service with teiid spring boot app. When Salesforce is down to 20min and service with teiid trying to call SQL from Salesforce we have many threads in tomcat server (in spring boot app). Then when 200 threads is activated service do not reply to requests because is "max threads" in tomcat of service.
> Why teiid do not send response as "Salesforce is down - error" or connection timeout?
> Micro schema:
> HTTP Requests to REST api -> Teiid spring boot app -> {broken 20min}Salesforce
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (TEIID-5962) Teiid locks many threads when Salesforce is disconnected
by Renat Eskenin (Jira)
[ https://issues.redhat.com/browse/TEIID-5962?page=com.atlassian.jira.plugi... ]
Renat Eskenin commented on TEIID-5962:
--------------------------------------
I set this properties, tnx. If we get new errors with this service, I will write about it. As I know in Salesforce maximal timeout (on server side) is 120s, so default values for this properties will be as Salesforce.
> Teiid locks many threads when Salesforce is disconnected
> --------------------------------------------------------
>
> Key: TEIID-5962
> URL: https://issues.redhat.com/browse/TEIID-5962
> Project: Teiid
> Issue Type: Bug
> Components: Salesforce Connector
> Affects Versions: 12.3.1
> Reporter: Renat Eskenin
> Assignee: Steven Hawkins
> Priority: Major
> Attachments: Снимок экрана от 2020-05-31 11-09-10.png
>
>
> We had two incidents in our experimental service with teiid spring boot app. When Salesforce is down to 20min and service with teiid trying to call SQL from Salesforce we have many threads in tomcat server (in spring boot app). Then when 200 threads is activated service do not reply to requests because is "max threads" in tomcat of service.
> Why teiid do not send response as "Salesforce is down - error" or connection timeout?
> Micro schema:
> HTTP Requests to REST api -> Teiid spring boot app -> {broken 20min}Salesforce
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (TEIIDSB-180) Define expectations for runtime metadata
by Ramesh Reddy (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-180?page=com.atlassian.jira.plug... ]
Ramesh Reddy commented on TEIIDSB-180:
--------------------------------------
TEIIDSB-207 will start for #1, not for metadata but as a starting point where we can instantiate Teiid instance from where we can foresee retrieving the metadata.
> Define expectations for runtime metadata
> ----------------------------------------
>
> Key: TEIIDSB-180
> URL: https://issues.redhat.com/browse/TEIIDSB-180
> Project: Teiid Spring Boot
> Issue Type: Feature Request
> Components: documentation
> Reporter: Steven Hawkins
> Assignee: Ramesh Reddy
> Priority: Major
>
> At a high level there are potentially three modes for our ddl:
> 1. Interactive - there was some work toward this, but it needed to only be a "developer mode" as it would reload the vdb on each metadata change. There is a lot about the transactionality of DDL updates that our current simplistic metadata model does not support, which makes this hard to fully implement. We haven't talked about this much in relation to Teiid Spring Boot, but ideally there should be a way for developers to test incremental changes without full rebuilds.
> 2. Dynamic - the term is a bit dated, but this refers to any vdb that performs import from a metadata repository that has runtime dependencies. By design this allows for a simple vdb definition and options for caching or re-importing on reload. In a container environment metadata caching no longer makes sense unless we use a volume. Depending upon your viewpoint allowing for runtime import of metadata is potentially a point of mutability that is also not needed in a container environment.
> 3. Static - much like our old .index designer vdbs there are benefits to having the full metadata already available to the vdb/image. There is a lot of work that we do lazily at runtime that can be moved to an earlier phase - primarily generating the rest and odata layers, but it would also include the pg system table materializations. For Teiid Spring Boot or usage in containers in general what this would look like is a build phase for the vdb such that it could obtain appropriate metadata and initialize as much as possible statically (eventually for quarkus vm snapshotting). The only metadata that would not be fresh potentially would be the costing metadata - however that is problematic as is and will eventually need a progressive optimization strategy employing a persistent store.
> As of now we are currently focused just on #2. As we look toward operators, we should start thinking about #3.
> #1 would come into play if/when we start looking at local development options using vs code.
> We can treat this issue as an epic and a place to centralize discussion.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (TEIIDSB-191) Build annotation based ExternalSource for JDBC sources
by Ramesh Reddy (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-191?page=com.atlassian.jira.plug... ]
Ramesh Reddy resolved TEIIDSB-191.
----------------------------------
Resolution: Duplicate Issue
Duplicate of TEIIDSB-197
> Build annotation based ExternalSource for JDBC sources
> ------------------------------------------------------
>
> Key: TEIIDSB-191
> URL: https://issues.redhat.com/browse/TEIIDSB-191
> Project: Teiid Spring Boot
> Issue Type: Enhancement
> Components: core
> Reporter: Ramesh Reddy
> Priority: Major
>
> All the JDBC based sources need to be converted to individual projects such that dependencies can be captured correctly and these also fall into the naming convention like other "spring-data-xxxx" sources.
> Then we can consider removing the external json file in the Operator to solely depend on the naming convention even for JDBC.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (TEIIDSB-207) Generate a Teiid Spring Boot project from given YAML based CR file
by Ramesh Reddy (Jira)
[ https://issues.redhat.com/browse/TEIIDSB-207?page=com.atlassian.jira.plug... ]
Ramesh Reddy updated TEIIDSB-207:
---------------------------------
Fix Version/s: 1.6.0
> Generate a Teiid Spring Boot project from given YAML based CR file
> ------------------------------------------------------------------
>
> Key: TEIIDSB-207
> URL: https://issues.redhat.com/browse/TEIIDSB-207
> Project: Teiid Spring Boot
> Issue Type: Feature Request
> Components: tools
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Priority: Major
> Fix For: 1.6.0
>
> Original Estimate: 3 days
> Remaining Estimate: 3 days
>
> Extend the "vdb-codegen" plugin to generate a full Teiid Spring Boot project based on the VDB defined in YAML CR.
> Currently the plugin already generates the `Application.java` and `DataSource.java` from a given DDL file, but when YAML file is supplied it should also generate the `pom.xml` and `application.properties` to be self-standing full TSB project as in this example https://github.com/teiid/teiid-spring-boot/tree/master/samples/vdb
> The intent behind is to use this for the local building of the project for testing with VSCode Plugin. Based on how this works out, could also be used in Operator work flow.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months
[JBoss JIRA] (TEIID-5936) create an s3 file source
by Steven Hawkins (Jira)
[ https://issues.redhat.com/browse/TEIID-5936?page=com.atlassian.jira.plugi... ]
Steven Hawkins updated TEIID-5936:
----------------------------------
Description:
The existing s3 support is implemented as a translator / ws source combo. We instead need this to be just a source to allow for translators to utilize it (excel, parquet, avro).
As an alternative to our existing support we should evaluate utilizing the sdk rather than providing our own processing logic. More than likely this will be a quicker path to things like s3 select support. However ceph seems to lag in s3 support (see TEIID-5935 and no s3 select support) so we'd have to compensate, make the metadata and/or the capabilities specific to the connection type.
was:As an alternative to our existing support we should evaluate utilizing the sdk rather than providing our own processing logic. More than likely this will be a quicker path to things like s3 select support. However ceph seems to lag in s3 support (see TEIID-5935 and no s3 select support) so we'd have to compensate, make the metadata and/or the capabilities specific to the connection type.
Summary: create an s3 file source (was: evaluate aws sdk for java for s3 support)
> create an s3 file source
> -------------------------
>
> Key: TEIID-5936
> URL: https://issues.redhat.com/browse/TEIID-5936
> Project: Teiid
> Issue Type: Feature Request
> Components: Misc. Connectors
> Reporter: Steven Hawkins
> Assignee: Steven Hawkins
> Priority: Major
> Fix For: 15.0
>
>
> The existing s3 support is implemented as a translator / ws source combo. We instead need this to be just a source to allow for translators to utilize it (excel, parquet, avro).
> As an alternative to our existing support we should evaluate utilizing the sdk rather than providing our own processing logic. More than likely this will be a quicker path to things like s3 select support. However ceph seems to lag in s3 support (see TEIID-5935 and no s3 select support) so we'd have to compensate, make the metadata and/or the capabilities specific to the connection type.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years, 6 months