[JBoss JIRA] (TEIID-4796) Support automatic pushdown of unsupported functions in JDBC connectors.
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-4796?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-4796:
---------------------------------------
Unfortunately this is more complicated than it seems. We need to be able to resolve the function to at least know the return type.
It's very straight-forward to add a source function to a source model.
Also depending upon the source the function may be listed by the DatabaseMetadata.getFunctions. It would be easier to enhance the importer to import functions from there.
> Support automatic pushdown of unsupported functions in JDBC connectors.
> -----------------------------------------------------------------------
>
> Key: TEIID-4796
> URL: https://issues.jboss.org/browse/TEIID-4796
> Project: Teiid
> Issue Type: Feature Request
> Components: JDBC Connector
> Affects Versions: 9.1.3
> Reporter: John Rodrigues
> Assignee: Steven Hawkins
>
> Please refer to this discussion for context: https://developer.jboss.org/message/969432
> It would be nice if Teiid could support automatic pushdown of unsupported functions for JDBC connectors.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-4782) Change framework to catch RutineException from translator/connector
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/TEIID-4782?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-4782:
---------------------------------
Fix Version/s: 8.12.10.6_3
> Change framework to catch RutineException from translator/connector
> -------------------------------------------------------------------
>
> Key: TEIID-4782
> URL: https://issues.jboss.org/browse/TEIID-4782
> Project: Teiid
> Issue Type: Sub-task
> Components: Query Engine
> Affects Versions: 9.3
> Reporter: Van Halbert
> Assignee: Ramesh Reddy
> Labels: Alpaha1
> Fix For: 9.3, 9.2.1, 9.1.4, 8.12.10.6_3
>
>
> Discussion:
> Generally the connector/engine logic should be responsible for handling whatever exception is thrown. For example ConnectorWorkItem and DataTeirTupleSource do intercept RuntimeExceptions, but rethrows them. We may want to instead convert them into Processing exceptions as the ConnectorWorkItem level.
> ----- Original Message -----
> > With Resource-adapters, the drivers to connect to some of these data sources
> > are not standard. And because of that, just like with JDG, its probable
> > that other drivers will be throwing unexpected exceptions when those data
> > sources are scaled up and down. I know the supporting of other RA data
> > sources is probably not real close, but would it be pro-active to look at
> > possible RA's and that may need to have try/catches added?
> >
> > Van
> >
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-4775) External materialization, after transaction timeout, LoadState continues to be LOADING
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/TEIID-4775?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-4775:
---------------------------------
Fix Version/s: 8.12.10.6_3
> External materialization, after transaction timeout, LoadState continues to be LOADING
> --------------------------------------------------------------------------------------
>
> Key: TEIID-4775
> URL: https://issues.jboss.org/browse/TEIID-4775
> Project: Teiid
> Issue Type: Sub-task
> Components: Server
> Affects Versions: 8.7
> Environment: * CentOs 7
> * Teiid 9.1.2
> * Wildfly 10
> Reporter: Pedro Inácio
> Assignee: Ramesh Reddy
> Labels: Alpha1
> Fix For: 9.3, 9.2.1, 9.1.4, 8.12.10.6_3
>
>
> For some unknown reason, sometimes a materialized view takes more time to finish the load/update than the one defined in transaction timeout (300 seconds is the default value, and we have configured 600 seconds to try to solve the problem).
> The transaction reaper will kill the update transaction. The _LoadState_ in _status_ table will be *LOADING*.
> Any subsequent try to update the view will fail, since the system reads the state as being *LOADING* even if the system is not currently updating it.
> Example log next.
> The update took too long (more than 10 minutes [defined transaction timeout]):
> {code:batch}
> 2017-02-17 16:10:44,487 INFO [org.teiid.COMMAND_LOG] (NIO6) gZueFR0aNjgi START USER COMMAND: startTime=2017-02-17 16:10:44.487 requestID=gZueFR0aNjgi.11 txID=null sessionID=gZueFR0aNjgi applicationName=JDBC principal=manel vdbName=CountryServiceListVDB vdbVersion=1 sql={call SYSADMIN.loadMatView(?, ?)}
> 2017-02-17 16:20:44,528 WARN [com.arjuna.ats.arjuna] (Transaction Reaper) ARJUNA012117: TransactionReaper::check timeout for TX 0:ffff0a080174:21ddbdf0:58a71a32:cb in state RUN
> 2017-02-17 16:20:44,564 WARN [com.arjuna.ats.arjuna] (Transaction Reaper Worker 0) ARJUNA012121: TransactionReaper::doCancellations worker Thread[Transaction Reaper Worker 0,5,main] successfully canceled TX 0:ffff0a080174:21ddbdf0:58a71a32:cb
> {code}
> Next I tried to update the view:
> {code:batch}
> 2017-02-17 16:29:21,272 INFO [org.teiid.COMMAND_LOG] (NIO2) E1xyKpChGKvC START USER COMMAND: startTime=2017-02-17 16:29:21.272 requestID=E1xyKpChGKvC.7 txID=null sessionID=E1xyKpChGKvC applicationName=JDBC principal=manel vdbName=CountryServiceListVDB vdbVersion=1 sql=EXECUTE SYSADMIN.loadMatView('CountryServiceListCalculatedRaw','country_service_list_calculated_raw')
> 2017-02-17 16:29:21,391 INFO [org.teiid.COMMAND_LOG] (Worker25_QueryProcessorQueue18136) E1xyKpChGKvC END USER COMMAND: endTime=2017-02-17 16:29:21.391 requestID=E1xyKpChGKvC.7 txID=null sessionID=E1xyKpChGKvC principal=manel vdbName=CountryServiceListVDB vdbVersion=1 finalRowCount=1
> {code}
> And nothing happened.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months
[JBoss JIRA] (TEIID-4778) External Materialization, When TTL is less than loading time, the scheduling is off
by Johnathon Lee (JIRA)
[ https://issues.jboss.org/browse/TEIID-4778?page=com.atlassian.jira.plugin... ]
Johnathon Lee updated TEIID-4778:
---------------------------------
Fix Version/s: 8.12.10.6_3
> External Materialization, When TTL is less than loading time, the scheduling is off
> -----------------------------------------------------------------------------------
>
> Key: TEIID-4778
> URL: https://issues.jboss.org/browse/TEIID-4778
> Project: Teiid
> Issue Type: Sub-task
> Components: Server
> Affects Versions: 8.7
> Reporter: Ramesh Reddy
> Assignee: Ramesh Reddy
> Labels: Alpha1
> Fix For: 9.3, 9.2.1, 9.1.4, 8.12.10.6_3
>
>
> During managed external mateiralization,
> 1) if the TTL specified is less than the amount of load time
> 2) Then, if other nodes check the status at "LOADING", and the elapsed time is calculated from the time on the {{Status}} table. Which when goes over the TTL, it will be a negative value
> 3) Then, the scheduling algorithm schedules the next check immediately, which will be exactly same as one before as it also checks from the last updated time. Thus going into a tight loop which consume all the resources spinning.
> Correct this to check that, the scheduler always schedules next check atleast a default time after the previous one, which is currently at a minute.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
7 years, 10 months