[JBoss JIRA] Created: (TEIID-1453) Possible load-balancing issue in Teiid
by Boris Belovic (JIRA)
Possible load-balancing issue in Teiid
--------------------------------------
Key: TEIID-1453
URL: https://issues.jboss.org/browse/TEIID-1453
Project: Teiid
Issue Type: Bug
Affects Versions: 7.1.1
Reporter: Boris Belovic
Assignee: Steven Hawkins
I have 2 SOA-P servers clustered, both with Teiid installed.
node1 has property org.teiid.sockets.maxCachedInstances set to 2
node2 has property org.teiid.sockets.maxCachedInstances set to 16
There is a web app deployed on node1 which starts consuming connections from Teiid datasource. When all connections from node1 are used, the app should get a connection from second node. But instead , I have got following exception:
16:06:59,341 ERROR [STDERR] org.jboss.util.NestedSQLException: Unable to get managed connection for TEIID-DS; - nested throwable: (javax.resource.ResourceException: Unable to get managed connection for TEIID-DS)
16:06:59,342 ERROR [STDERR] at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:95)
16:06:59,342 ERROR [STDERR] at org.jboss.soa.clustering.teiid.LoadBalancingServlet.getDatasourceConnection(Unknown Source)
16:06:59,342 ERROR [STDERR] at org.jboss.soa.clustering.teiid.LoadBalancingServlet.doGet(Unknown Source)
16:06:59,342 ERROR [STDERR] at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
16:06:59,342 ERROR [STDERR] at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
16:06:59,342 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
16:06:59,342 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
16:06:59,342 ERROR [STDERR] at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
16:06:59,342 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
16:06:59,342 ERROR [STDERR] at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
16:06:59,342 ERROR [STDERR] at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
16:06:59,342 ERROR [STDERR] at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
16:06:59,342 ERROR [STDERR] at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:183)
16:06:59,342 ERROR [STDERR] at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:95)
16:06:59,342 ERROR [STDERR] at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
16:06:59,342 ERROR [STDERR] at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
16:06:59,342 ERROR [STDERR] at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
16:06:59,342 ERROR [STDERR] at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
16:06:59,342 ERROR [STDERR] at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
16:06:59,342 ERROR [STDERR] at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
16:06:59,342 ERROR [STDERR] at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
16:06:59,342 ERROR [STDERR] at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
16:06:59,342 ERROR [STDERR] at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
16:06:59,342 ERROR [STDERR] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:451)
16:06:59,342 ERROR [STDERR] at java.lang.Thread.run(Thread.java:619)
16:06:59,342 ERROR [STDERR] Caused by: javax.resource.ResourceException: Unable to get managed connection for TEIID-DS
16:06:59,342 ERROR [STDERR] at org.jboss.resource.connectionmanager.BaseConnectionManager2.getManagedConnection(BaseConnectionManager2.java:441)
16:06:59,342 ERROR [STDERR] at org.jboss.resource.connectionmanager.TxConnectionManager.getManagedConnection(TxConnectionManager.java:424)
16:06:59,343 ERROR [STDERR] at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:496)
16:06:59,343 ERROR [STDERR] at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:941)
16:06:59,343 ERROR [STDERR] at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:89)
16:06:59,343 ERROR [STDERR] ... 24 more
16:06:59,343 ERROR [STDERR] Caused by: javax.resource.ResourceException: No ManagedConnections available within configured blocking timeout ( 30000 [ms] )
16:06:59,343 ERROR [STDERR] at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.getConnection(InternalManagedConnectionPool.java:311)
16:06:59,343 ERROR [STDERR] at org.jboss.resource.connectionmanager.JBossManagedConnectionPool$BasePool.getConnection(JBossManagedConnectionPool.java:690)
16:06:59,343 ERROR [STDERR] at org.jboss.resource.connectionmanager.BaseConnectionManager2.getManagedConnection(BaseConnectionManager2.java:404)
16:06:59,343 ERROR [STDERR] ... 28 more
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (TEIID-1335) Customer requesting the ability to make query planner always create dependent joins.
by Debbie Steigner (JIRA)
Customer requesting the ability to make query planner always create dependent joins.
------------------------------------------------------------------------------------
Key: TEIID-1335
URL: https://jira.jboss.org/browse/TEIID-1335
Project: Teiid
Issue Type: Feature Request
Components: Server
Reporter: Debbie Steigner
Assignee: Steven Hawkins
Nike is finding that the query planner often chooses to use a non-dependent join plan, even when cost statistics have been gathered on all source systems and a dependent plan would perform much better.
I've showed them how to use option makedep to force a dependent join scenario. However, it requires careful analysis of each query to setup the proper makedep parameters, and may not be feasible when working with hibernate as the client.
Thus, they ask: is there any way to tell the query planner to always use dependent join for every join, no matter what.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (TEIID-1324) Deploy JOPR Plugin on JON/RHQ
by Cristiano Nicolai (JIRA)
Deploy JOPR Plugin on JON/RHQ
-----------------------------
Key: TEIID-1324
URL: https://jira.jboss.org/browse/TEIID-1324
Project: Teiid
Issue Type: Bug
Components: Jopr Plugin
Affects Versions: 7.2
Environment: Jboss EAP 5.1, JON 2.4, jon-plugin-pack-eap-2.4.0.GA
Reporter: Cristiano Nicolai
Assignee: Steven Hawkins
When deploying Teiid JOPR plugin on JON, when the agent try to run the plugin there are some missing classes.
Caused by: java.lang.NoClassDefFoundError: org/jboss/reflect/spi/TypeInfo
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
at java.lang.Class.getConstructor0(Class.java:2699)
at java.lang.Class.newInstance0(Class.java:326)
at java.lang.Class.newInstance(Class.java:308)
at org.jboss.metatype.plugins.values.MetaValueFactoryBuilder$1.run(MetaValueFactoryBuilder.java:71)
at org.jboss.metatype.plugins.values.MetaValueFactoryBuilder$1.run(MetaValueFactoryBuilder.java:46)
at java.security.AccessController.doPrivileged(Native Method)
at org.jboss.metatype.plugins.values.MetaValueFactoryBuilder.<clinit>(MetaValueFactoryBuilder.java:45)
at org.jboss.metatype.api.values.MetaValueFactory.<clinit>(MetaValueFactory.java:41)
at org.teiid.rhq.admin.DQPManagementView.<clinit>(DQPManagementView.java:68)
at org.teiid.rhq.plugin.VDBComponent.getAvailability(VDBComponent.java:139)
at sun.reflect.GeneratedMethodAccessor50.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.rhq.core.pc.inventory.ResourceContainer$ComponentInvocationThread.call(ResourceContainer.java:525)
... 5 more
Basically the missing jar is jboss-metatype.jar.
I tried some classloader configuration including the missing jar in teiid-console-7.2.0.Beta1.jar/lib, but as it has dependent classes (jboss-managed.jar) that are loaded in jboss-as-5 RHQ plugin I couldn't find any solution without changing the jboss-as-5 code. Probably some sync with RHQ guys is needed because jboss-managed.jar depends on jboss-metatype.jar.
My workaround for this was a code change in ApplicationServerDiscoveryComponent to include the required jar from the AS installation.
private static final List<String> CLIENT_JARS = Arrays.asList(
// NOTE: The jbossall-client.jar aggregates a whole bunch of other jars from the client dir via its
// MANIFEST.MF Class-Path.
"client/jbossall-client.jar",
"client/trove.jar",
"client/javassist.jar",
"common/lib/jboss-security-aspects.jar",
"lib/jboss-managed.jar",
"lib/jboss-metatype.jar",
"lib/jboss-reflect.jar",
"lib/jboss-dependency.jar"
);
Fixing this class dependency the plugin start to require some Teiid client classes and to solve this I just copy the teiid-7.2.0.Beta1-client.jar to teiid-console-7.2.0.Beta1.jar/lib and redeploy the plugin.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years
[JBoss JIRA] Created: (TEIID-1396) XML_PLAN output to server log too verbose for DEBUG level logging
by Paul Nittel (JIRA)
XML_PLAN output to server log too verbose for DEBUG level logging
-----------------------------------------------------------------
Key: TEIID-1396
URL: https://issues.jboss.org/browse/TEIID-1396
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
15 years
[JBoss JIRA] Created: (TEIID-1351) Replace translate criteria
by Steven Hawkins (JIRA)
Replace translate criteria
--------------------------
Key: TEIID-1351
URL: https://jira.jboss.org/browse/TEIID-1351
Project: Teiid
Issue Type: Feature Request
Components: Query Engine
Affects Versions: 7.3
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Priority: Critical
Fix For: 7.3
While we hardened the usage in 7.2, translate criteria has too many implied restrictions to reliably perform the update/delete the user query is specifying.
It would be better to rely on better default handling (especially pass-through) TEIID-1349 and to remove the current restrictions on virtual update, such as requiring scalar set clause values and no subquery evaluation TEIID-1276.
This change should not remove the possibility of using TRANSLATE CRITERIA/CREATE PROCEDURE, as it will not be removed until Teiid 8 or later.
Beyond the default handling, one possible construct is to provide the user with an cursor that contains the update (or delete) set with the corresponding updated values. Then leave it up to the user to iterate over the change set and process the changes. One drawback with this approach is that it may be hard to decipher from the view output rows how to apply the updates to constituent tables when the view transformation is a set or join and branch descriminators or additional primary keys are not projected. Of course those situations were already difficult to handle with translate criteria.
This will require coordinated designer changes.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
15 years