[JBoss JIRA] Updated: (TEIID-1397) XML_PLAN output to server log too verbose for DEBUG level logging
by Van Halbert (JIRA)
[ https://issues.jboss.org/browse/TEIID-1397?page=com.atlassian.jira.plugin... ]
Van Halbert updated TEIID-1397:
-------------------------------
Summary: XML_PLAN output to server log too verbose for DEBUG level logging (was: CLONE - )
> XML_PLAN output to server log too verbose for DEBUG level logging
> -----------------------------------------------------------------
>
> Key: TEIID-1397
> URL: https://issues.jboss.org/browse/TEIID-1397
> Project: Teiid
> Issue Type: Bug
> Components: EDS
> Affects Versions: 5.1.0.ER5
> Environment: RHEL 5, SOA-P 5.1 ER5, JBDS 4.0 Beta2 (H33)
> Reporter: Paul Nittel
> Assignee: Steven Hawkins
>
> I was executing the E2E Staging Table test script and executed a query of the XML document from Designer. It took a long time--longer than I'd anticipated--so I looked at the server log to see what had happened. Turns out the server log had grown to 1.2GB in roughly 10 minutes. Checking the log (carefully!) I found XML_PLAN entries accounted for 8,759,795 lines of the 10,267,566 line log file. A sample of the entries look like:
> 2010-12-14 10:01:47,612 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) [showState] currentObject: shows
> 2010-12-14 10:01:47,612 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) [showState] currentObject.getNillableDescriptor(): null
> 2010-12-14 10:01:47,612 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) [showState] workingElements: [programId, programName, rating]
> 2010-12-14 10:01:47,613 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) [showState] currentParent.getParent(): ResultSet
> 2010-12-14 10:01:47,613 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) Executing instruction NEXT TVDOC.TVGUIDEROOTALL.MAPPINGCLASSES.SHOWS_1
> 2010-12-14 10:01:47,613 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) NEXT TVDOC.TVGUIDEROOTALL.MAPPINGCLASSES.SHOWS_1
> 2010-12-14 10:01:47,613 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) Processor Environment popped program w/ recursion count 0 ; 2 programs left.
> 2010-12-14 10:01:47,613 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) Executing instruction LOOP TVDOC.TVGUIDEROOTALL.MAPPINGCLASSES.SHOWS_1
> 2010-12-14 10:01:47,613 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) WHILE repeating for result set: TVDOC.TVGUIDEROOTALL.MAPPINGCLASSES.SHOWS_1 , block program: PROGRAM size 7
> 2010-12-14 10:01:47,613 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) Pushed non-recursive program w/ recursion count 0
> 2010-12-14 10:01:47,613 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) Executing instruction ELEM shows (namespaces )
> 2010-12-14 10:01:47,613 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599)
> [showState] State Vars at: addElement(2) - TOP
> 2010-12-14 10:01:47,613 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) [showState] currentParent: producer
> 2010-12-14 10:01:47,613 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) [showState] currentObject: shows
> 2010-12-14 10:01:47,613 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) [showState] currentObject.getNillableDescriptor(): null
> Speaking with Ramesh, he suggests possibly moving this type of output to TRACE.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] Created: (TEIID-1397) CLONE -
by Van Halbert (JIRA)
CLONE -
--------
Key: TEIID-1397
URL: https://issues.jboss.org/browse/TEIID-1397
Project: Teiid
Issue Type: Bug
Components: Query Engine
Affects Versions: 7.1.1
Environment: RHEL 5, SOA-P 5.1 ER5, JBDS 4.0 Beta2 (H33)
Reporter: Paul Nittel
Assignee: Steven Hawkins
I was executing the E2E Staging Table test script and executed a query of the XML document from Designer. It took a long time--longer than I'd anticipated--so I looked at the server log to see what had happened. Turns out the server log had grown to 1.2GB in roughly 10 minutes. Checking the log (carefully!) I found XML_PLAN entries accounted for 8,759,795 lines of the 10,267,566 line log file. A sample of the entries look like:
2010-12-14 10:01:47,612 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) [showState] currentObject: shows
2010-12-14 10:01:47,612 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) [showState] currentObject.getNillableDescriptor(): null
2010-12-14 10:01:47,612 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) [showState] workingElements: [programId, programName, rating]
2010-12-14 10:01:47,613 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) [showState] currentParent.getParent(): ResultSet
2010-12-14 10:01:47,613 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) Executing instruction NEXT TVDOC.TVGUIDEROOTALL.MAPPINGCLASSES.SHOWS_1
2010-12-14 10:01:47,613 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) NEXT TVDOC.TVGUIDEROOTALL.MAPPINGCLASSES.SHOWS_1
2010-12-14 10:01:47,613 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) Processor Environment popped program w/ recursion count 0 ; 2 programs left.
2010-12-14 10:01:47,613 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) Executing instruction LOOP TVDOC.TVGUIDEROOTALL.MAPPINGCLASSES.SHOWS_1
2010-12-14 10:01:47,613 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) WHILE repeating for result set: TVDOC.TVGUIDEROOTALL.MAPPINGCLASSES.SHOWS_1 , block program: PROGRAM size 7
2010-12-14 10:01:47,613 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) Pushed non-recursive program w/ recursion count 0
2010-12-14 10:01:47,613 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) Executing instruction ELEM shows (namespaces )
2010-12-14 10:01:47,613 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599)
[showState] State Vars at: addElement(2) - TOP
2010-12-14 10:01:47,613 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) [showState] currentParent: producer
2010-12-14 10:01:47,613 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) [showState] currentObject: shows
2010-12-14 10:01:47,613 DEBUG [org.teiid.PROCESSOR.XML_PLAN] (Worker28_QueryProcessorQueue599) [showState] currentObject.getNillableDescriptor(): null
Speaking with Ramesh, he suggests possibly moving this type of output to TRACE.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] Resolved: (TEIID-1389) Add additional detection for conflicting criteria to help optimize query plan
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-1389?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-1389.
-----------------------------------
Fix Version/s: 7.3
Resolution: Done
Added optimization in the rewriter for in, is null, and comparison criteria. It is not exhaustive. It tends to only examine situations involving constants (e.g. x in (1,2), x < 5, etc.) and only when the predicates are conjuncts. So the example in this issues using 'OR' would be optimized. It should instead be entered as an IN predicate.
> Add additional detection for conflicting criteria to help optimize query plan
> -----------------------------------------------------------------------------
>
> Key: TEIID-1389
> URL: https://issues.jboss.org/browse/TEIID-1389
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Affects Versions: 6.0.0
> Reporter: Marc Shirley
> Assignee: Steven Hawkins
> Fix For: 7.3
>
>
> Add additional detection for conflicting criteria such as "(column1=1 OR column1=2) AND column1=3". The attempted use case was a case of a UNION that was using the column as a measure of selecting a specific datasource, with each query joined by the UNION having a specific set of column1 values (such as "column1=1 OR column1=2"). In the case of the end user application submitting criteria such as "column1=3", the query planner should prune any branches of the UNION with a conflicting set of values for column1. It would also be helpful if other operators such as <, >, <>, IN, etc. could be accounted for.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] Updated: (TEIID-1392) Memory leak in Teiid
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-1392?page=com.atlassian.jira.plugin... ]
Ramesh Reddy updated TEIID-1392:
--------------------------------
Fix Version/s: 7.1.1
> Memory leak in Teiid
> --------------------
>
> Key: TEIID-1392
> URL: https://issues.jboss.org/browse/TEIID-1392
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 7.1.1
> Reporter: Pavel Macik
> Assignee: Ramesh Reddy
> Priority: Blocker
> Fix For: 7.1.1
>
> Attachments: 510ER5-eds_long_select_100t-overview.jps, eds-qs.zip
>
>
> To reproduce:
> 1.) unzip eds-qs.zip into ${SOA-P}/jboss-as/samples/quickstarts/ directory
> 2.) copy/move ${EDS-QS}/build.properties-example to ${EDS-QS}/build.properties
> 3.) the QS deploys a VDB with 2 Oracle10g datasources (you can configure (via build.properties) both to the same DB instance)
> 4.) start the server up
> 5.) using JDBC with following configuration send following SQL:
> JDBC:
> - URL: jdbc:teiid:perf@mm://${soa-p bind address}:31000
> - driver: org.teiid.jdbc.TeiidDriver
> - username/password: according to ${SOA-P}/jboss-as/server/${profile}/conf/props/teiid-security-users.properties
> SQL:
> select * from perf.long.persons where person_id < 100
> With server max heap set to 3G the GC caused by the leak affects the server after cca 150k iterations
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] Assigned: (TEIID-1392) Memory leak in Teiid
by Ramesh Reddy (JIRA)
[ https://issues.jboss.org/browse/TEIID-1392?page=com.atlassian.jira.plugin... ]
Ramesh Reddy reassigned TEIID-1392:
-----------------------------------
Assignee: Ramesh Reddy (was: Van Halbert)
> Memory leak in Teiid
> --------------------
>
> Key: TEIID-1392
> URL: https://issues.jboss.org/browse/TEIID-1392
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 7.1.1
> Reporter: Pavel Macik
> Assignee: Ramesh Reddy
> Priority: Blocker
> Attachments: 510ER5-eds_long_select_100t-overview.jps, eds-qs.zip
>
>
> To reproduce:
> 1.) unzip eds-qs.zip into ${SOA-P}/jboss-as/samples/quickstarts/ directory
> 2.) copy/move ${EDS-QS}/build.properties-example to ${EDS-QS}/build.properties
> 3.) the QS deploys a VDB with 2 Oracle10g datasources (you can configure (via build.properties) both to the same DB instance)
> 4.) start the server up
> 5.) using JDBC with following configuration send following SQL:
> JDBC:
> - URL: jdbc:teiid:perf@mm://${soa-p bind address}:31000
> - driver: org.teiid.jdbc.TeiidDriver
> - username/password: according to ${SOA-P}/jboss-as/server/${profile}/conf/props/teiid-security-users.properties
> SQL:
> select * from perf.long.persons where person_id < 100
> With server max heap set to 3G the GC caused by the leak affects the server after cca 150k iterations
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] Resolved: (TEIID-1391) Changes to the use of SSL when connecting with the Teiid Driver are ignored after a successful connection
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-1391?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-1391.
-----------------------------------
Assignee: Steven Hawkins (was: John Doyle)
Fix Version/s: 7.1.1
7.3
Resolution: Done
updated the hostinfo object to compare based upon ssl sooner
> Changes to the use of SSL when connecting with the Teiid Driver are ignored after a successful connection
> ---------------------------------------------------------------------------------------------------------
>
> Key: TEIID-1391
> URL: https://issues.jboss.org/browse/TEIID-1391
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Driver
> Affects Versions: 7.1.1
> Reporter: John Verhaeg
> Assignee: Steven Hawkins
> Fix For: 7.1.1, 7.3
>
>
> This might be a bit hard to follow, but...
> I tried to execute a Teiid VDB from the Teiid Designer perspective, which asks me to create a Teiid connection profile, which displays the Teiid driver properties dialog. Not knowing whether the server I was using was configured for SSL, I went ahead and selected the SSL option and hit Test. It failed (as expected). I then unchecked that checkbox, retested, and the test ping succeeded. But then I re-checked the box and tried once more. It succeeded again (Huh?). I then hit Finish, and got a failure message after being transferred to the DTP perspective. Seeing the connection profile in the Data Source Explorer, I opened its context menu, which showed an option to disconnect (implying it was still in a connected state). I disconnected and then tried to reconnect. Again, that worked. Opening the connection's profile and changing its SSL setting has no effect after that. Only if I completely remove the connection and recreate it can I see the SSL option fail again, but only until I turn it off and get the connection to succeed. Thereafter the setting seems to once again be ignored.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] Assigned: (TEIID-1391) Changes to the use of SSL when connecting with the Teiid Driver are ignored after a successful connection
by John Doyle (JIRA)
[ https://issues.jboss.org/browse/TEIID-1391?page=com.atlassian.jira.plugin... ]
John Doyle reassigned TEIID-1391:
---------------------------------
Assignee: John Doyle
> Changes to the use of SSL when connecting with the Teiid Driver are ignored after a successful connection
> ---------------------------------------------------------------------------------------------------------
>
> Key: TEIID-1391
> URL: https://issues.jboss.org/browse/TEIID-1391
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Driver
> Affects Versions: 7.1.1
> Reporter: John Verhaeg
> Assignee: John Doyle
>
> This might be a bit hard to follow, but...
> I tried to execute a Teiid VDB from the Teiid Designer perspective, which asks me to create a Teiid connection profile, which displays the Teiid driver properties dialog. Not knowing whether the server I was using was configured for SSL, I went ahead and selected the SSL option and hit Test. It failed (as expected). I then unchecked that checkbox, retested, and the test ping succeeded. But then I re-checked the box and tried once more. It succeeded again (Huh?). I then hit Finish, and got a failure message after being transferred to the DTP perspective. Seeing the connection profile in the Data Source Explorer, I opened its context menu, which showed an option to disconnect (implying it was still in a connected state). I disconnected and then tried to reconnect. Again, that worked. Opening the connection's profile and changing its SSL setting has no effect after that. Only if I completely remove the connection and recreate it can I see the SSL option fail again, but only until I turn it off and get the connection to succeed. Thereafter the setting seems to once again be ignored.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] Created: (TEIID-1393) Appears to be a limit of only one functional SalesForce connector in Teiid at a time.
by Van Halbert (JIRA)
Appears to be a limit of only one functional SalesForce connector in Teiid at a time.
-------------------------------------------------------------------------------------
Key: TEIID-1393
URL: https://issues.jboss.org/browse/TEIID-1393
Project: Teiid
Issue Type: Bug
Components: Salesforce Connector
Affects Versions: 7.1.1
Environment: Teiid 7.1.1 in EDS ER5, JBDS Beta2, RHEL 5.1
Reporter: John Doyle
Assignee: John Doyle
Priority: Blocker
Fix For: 7.1.1
It appears they only one SalesForce connector can be run at a time. If you preview a model from Designer and there are no SF connections in Teiid, it works. When you create a DS for the VDB and deploy, the VDB cannot get connections from SalesForce. If you delete the preview VDB and Datasource, then the deployed VDB begins working.
I originally suspected that the problem might be that we are running out of connections; SalesForce limits you to 5 simultaneous connections per username/password. But I deployed the two DataSources with different credentials, and the result did not change. Need to investigate more.
Think that we do need to default the SF DS to a pool of 1 and then doc that it should be bumped to 5 for production. The current default is 10, and that should never be. Even 5 will exhaust the limit with just a preview connection.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[JBoss JIRA] Commented: (TEIID-1392) Memory leak in Teiid
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-1392?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-1392:
---------------------------------------
Can you provide the JDBC that was being used?
> Memory leak in Teiid
> --------------------
>
> Key: TEIID-1392
> URL: https://issues.jboss.org/browse/TEIID-1392
> Project: Teiid
> Issue Type: Bug
> Components: Server
> Affects Versions: 7.1.1
> Reporter: Pavel Macik
> Assignee: Van Halbert
> Priority: Blocker
> Attachments: 510ER5-eds_long_select_100t-overview.jps, eds-qs.zip
>
>
> To reproduce:
> 1.) unzip eds-qs.zip into ${SOA-P}/jboss-as/samples/quickstarts/ directory
> 2.) copy/move ${EDS-QS}/build.properties-example to ${EDS-QS}/build.properties
> 3.) the QS deploys a VDB with 2 Oracle10g datasources (you can configure (via build.properties) both to the same DB instance)
> 4.) start the server up
> 5.) using JDBC with following configuration send following SQL:
> JDBC:
> - URL: jdbc:teiid:perf@mm://${soa-p bind address}:31000
> - driver: org.teiid.jdbc.TeiidDriver
> - username/password: according to ${SOA-P}/jboss-as/server/${profile}/conf/props/teiid-security-users.properties
> SQL:
> select * from perf.long.persons where person_id < 100
> With server max heap set to 3G the GC caused by the leak affects the server after cca 150k iterations
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months