[JBoss JIRA] (TEIID-3105) Can we add allowDuplicateDomains in Infinispan global configuration
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3105?page=com.atlassian.jira.plugin... ]
Kylin Soong closed TEIID-3105.
------------------------------
Resolution: Done
I close this issue due to the git pull request has been merged
> Can we add allowDuplicateDomains in Infinispan global configuration
> -------------------------------------------------------------------
>
> Key: TEIID-3105
> URL: https://issues.jboss.org/browse/TEIID-3105
> Project: Teiid
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Embedded
> Affects Versions: 8.9
> Environment: Teiid Embedded with Infinispan local cache
> Reporter: Kylin Soong
> Assignee: Kylin Soong
> Fix For: 8.9
>
>
> I have run Teiid Embedded on top of Infinispan local cache meet the the following exception:
> org.infinispan.jmx.JmxDomainConflictException: Domain already registered org.infinispan when trying to register: type=CacheManager,name="DefaultCacheManager"
> The "DefaultCacheManager" be register to MBeanServer 2 times cause the issue:
> 1. EmbeddedServer load infinispan cache via [1], this cause "DefaultCacheManager" register to MBean Server
> 2. Infinispan Translator connection load VDB refrred cache, this also cause "DefaultCacheManager" register again
> If we add allowDuplicateDomains in Infinispan configuration [1], this will avoid the issue.
> [1] https://github.com/teiid/teiid/blob/master/runtime/src/main/resources/inf...
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 6 months
[JBoss JIRA] (TEIID-2615) Teiid 8.5 TEIID30238 Duplicate key on #MAT_PG_CATALOG.MATPG_RELATT
by Cristiano Nicolai (JIRA)
[ https://issues.jboss.org/browse/TEIID-2615?page=com.atlassian.jira.plugin... ]
Cristiano Nicolai commented on TEIID-2615:
------------------------------------------
Hi Steven,
Thanks for investigating this problem, here is the ddl for all three problematic tables, they all contains a column with the same name as the table. As far as the VDB goes, there is not much about it, we're using a dynamic model the exposes the entire db from Beaker.
{code:sql}
CREATE TABLE `osmajor` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`osmajor` varchar(255) DEFAULT NULL,
`alias` varchar(25) DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `osmajor` (`osmajor`),
UNIQUE KEY `alias` (`alias`)
) ENGINE=InnoDB AUTO_INCREMENT=3876 DEFAULT CHARSET=utf8$$
CREATE TABLE `device_class` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`device_class` varchar(24) NOT NULL,
`description` text,
PRIMARY KEY (`id`),
UNIQUE KEY `device_class` (`device_class`)
) ENGINE=InnoDB AUTO_INCREMENT=614 DEFAULT CHARSET=utf8$$
CREATE TABLE `arch` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`arch` varchar(20) DEFAULT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `arch` (`arch`)
) ENGINE=InnoDB AUTO_INCREMENT=10 DEFAULT CHARSET=utf8$$
{code}
> Teiid 8.5 TEIID30238 Duplicate key on #MAT_PG_CATALOG.MATPG_RELATT
> ------------------------------------------------------------------
>
> Key: TEIID-2615
> URL: https://issues.jboss.org/browse/TEIID-2615
> Project: Teiid
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Query Engine
> Affects Versions: 8.2
> Environment: Teiid 8.5 from git master, running on jboss eap 6.1 using java 7 openjdk
> Reporter: Graeme Gillies
> Assignee: Steven Hawkins
> Fix For: 8.4.1, 8.5
>
>
> Hi,
> We are deploying a few dynamic vbs into our teiid environment and when we've deployed current versions of teiid from git master, we get the following error
> {noformat}
> 09:44:31,467 ERROR [org.teiid.PROCESSOR.MATVIEWS] (New I/O worker #1) TEIID30015 Failed to load materialized view table #MAT_PG_CATALOG.MATPG_RELATT.: org.teiid.core.TeiidProcessingException: TEIID30238 Duplicate key on #MAT_PG_CATALOG.MATPG_RELATT
> at org.teiid.query.tempdata.TempTable.insertTuple(TempTable.java:788) [teiid-engine-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.query.tempdata.TempTable.access$500(TempTable.java:83) [teiid-engine-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.query.tempdata.TempTable$InsertUpdateProcessor.tuplePassed(TempTable.java:150) [teiid-engine-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.query.tempdata.TempTable$UpdateProcessor.process(TempTable.java:257) [teiid-engine-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.query.tempdata.TempTable$InsertUpdateProcessor.process(TempTable.java:102) [teiid-engine-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.query.tempdata.TempTable.insert(TempTable.java:682) [teiid-engine-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.query.tempdata.TempTableDataManager$7.createTupleSource(TempTableDataManager.java:627) [teiid-engine-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.query.tempdata.TempTableDataManager$ProxyTupleSource.nextTuple(TempTableDataManager.java:106) [teiid-engine-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.query.tempdata.TempTableDataManager$4.load(TempTableDataManager.java:526) [teiid-engine-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.query.tempdata.TempTableDataManager$4.createTupleSource(TempTableDataManager.java:497) [teiid-engine-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.query.tempdata.TempTableDataManager$ProxyTupleSource.nextTuple(TempTableDataManager.java:106) [teiid-engine-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.relational.AccessNode.nextBatchDirect(AccessNode.java:376) [teiid-engine-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.relational.RelationalNode.nextBatch(RelationalNode.java:278) [teiid-engine-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.relational.RelationalPlan.nextBatch(RelationalPlan.java:136) [teiid-engine-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.QueryProcessor.nextBatchDirect(QueryProcessor.java:151) [teiid-engine-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.QueryProcessor.nextBatch(QueryProcessor.java:114) [teiid-engine-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.query.processor.BatchCollector.collectTuples(BatchCollector.java:153) [teiid-engine-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.dqp.internal.process.RequestWorkItem.processMore(RequestWorkItem.java:435) [teiid-engine-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.dqp.internal.process.RequestWorkItem.process(RequestWorkItem.java:320) [teiid-engine-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.dqp.internal.process.AbstractWorkItem.run(AbstractWorkItem.java:51) [teiid-engine-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.dqp.internal.process.RequestWorkItem.run(RequestWorkItem.java:248) [teiid-engine-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.dqp.internal.process.DQPCore.executeRequest(DQPCore.java:307) [teiid-engine-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at sun.reflect.GeneratedMethodAccessor53.invoke(Unknown Source) [:1.7.0_25]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> at org.teiid.logging.LogManager$LoggingProxy.invoke(LogManager.java:121) [teiid-api-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.jboss.TransportService$3.invoke(TransportService.java:254) [teiid-jboss-integration-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at com.sun.proxy.$Proxy20.executeRequest(Unknown Source)
> at sun.reflect.GeneratedMethodAccessor53.invoke(Unknown Source) [:1.7.0_25]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> at org.teiid.transport.LocalServerConnection$1$1.call(LocalServerConnection.java:135) [teiid-runtime-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:269) [teiid-engine-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:253) [teiid-engine-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.transport.LocalServerConnection$1.invoke(LocalServerConnection.java:133) [teiid-runtime-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at com.sun.proxy.$Proxy20.executeRequest(Unknown Source)
> at sun.reflect.GeneratedMethodAccessor53.invoke(Unknown Source) [:1.7.0_25]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> at org.teiid.transport.LocalServerConnection$1$1.call(LocalServerConnection.java:135) [teiid-runtime-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [rt.jar:1.7.0_25]
> at java.util.concurrent.FutureTask.run(FutureTask.java:166) [rt.jar:1.7.0_25]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:269) [teiid-engine-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.dqp.internal.process.DQPWorkContext.runInContext(DQPWorkContext.java:253) [teiid-engine-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.transport.LocalServerConnection$1.invoke(LocalServerConnection.java:133) [teiid-runtime-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at com.sun.proxy.$Proxy20.executeRequest(Unknown Source)
> at org.teiid.jdbc.StatementImpl.execute(StatementImpl.java:633) [teiid-client-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.jdbc.StatementImpl.executeSql(StatementImpl.java:509) [teiid-client-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.jdbc.PreparedStatementImpl.executeQuery(PreparedStatementImpl.java:258) [teiid-client-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.odbc.ODBCServerRemoteImpl.getPgColInfo(ODBCServerRemoteImpl.java:1012) [teiid-runtime-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.odbc.ODBCServerRemoteImpl.prepare(ODBCServerRemoteImpl.java:432) [teiid-runtime-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at sun.reflect.GeneratedMethodAccessor112.invoke(Unknown Source) [:1.7.0_25]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.7.0_25]
> at java.lang.reflect.Method.invoke(Method.java:606) [rt.jar:1.7.0_25]
> at org.teiid.transport.ODBCClientInstance.processMessage(ODBCClientInstance.java:127) [teiid-runtime-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.transport.ODBCClientInstance.receivedMessage(ODBCClientInstance.java:116) [teiid-runtime-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.teiid.transport.SSLAwareChannelHandler.messageReceived(SSLAwareChannelHandler.java:201) [teiid-runtime-8.5.0.Beta2-SNAPSHOT.jar:8.5.0.Beta2-SNAPSHOT]
> at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:88) [netty.jar:3.6.2.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:560) [netty.jar:3.6.2.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:787) [netty.jar:3.6.2.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296) [netty.jar:3.6.2.Final-redhat-1]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:462) [netty.jar:3.6.2.Final-redhat-1]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:443) [netty.jar:3.6.2.Final-redhat-1]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303) [netty.jar:3.6.2.Final-redhat-1]
> at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty.jar:3.6.2.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:560) [netty.jar:3.6.2.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:787) [netty.jar:3.6.2.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:296) [netty.jar:3.6.2.Final-redhat-1]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.unfoldAndFireMessageReceived(FrameDecoder.java:462) [netty.jar:3.6.2.Final-redhat-1]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.callDecode(FrameDecoder.java:443) [netty.jar:3.6.2.Final-redhat-1]
> at org.jboss.netty.handler.codec.frame.FrameDecoder.messageReceived(FrameDecoder.java:303) [netty.jar:3.6.2.Final-redhat-1]
> at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:70) [netty.jar:3.6.2.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:560) [netty.jar:3.6.2.Final-redhat-1]
> at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:555) [netty.jar:3.6.2.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:268) [netty.jar:3.6.2.Final-redhat-1]
> at org.jboss.netty.channel.Channels.fireMessageReceived(Channels.java:255) [netty.jar:3.6.2.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:88) [netty.jar:3.6.2.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:107) [netty.jar:3.6.2.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:312) [netty.jar:3.6.2.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:88) [netty.jar:3.6.2.Final-redhat-1]
> at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) [netty.jar:3.6.2.Final-redhat-1]
> at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) [netty.jar:3.6.2.Final-redhat-1]
> at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) [netty.jar:3.6.2.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> {noformat}
> When we try and run queries against it. Sometimes it happens once and goes away, other times it happens over and over.
> I can supply the vdbs themselves if needed to help debug.
> Regards,
> Graeme
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 6 months
[JBoss JIRA] (TEIID-3106) BufferManager Cleaner consuming 90% of total CPU time
by Mark Addleman (JIRA)
[ https://issues.jboss.org/browse/TEIID-3106?page=com.atlassian.jira.plugin... ]
Mark Addleman commented on TEIID-3106:
--------------------------------------
Sure. We'll add the appropriate logging.
> BufferManager Cleaner consuming 90% of total CPU time
> -----------------------------------------------------
>
> Key: TEIID-3106
> URL: https://issues.jboss.org/browse/TEIID-3106
> Project: Teiid
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Query Engine
> Affects Versions: 8.7
> Environment: zOS
> Reporter: Devesh Mishra
> Assignee: Steven Hawkins
> Labels: teiid-engine
> Attachments: BufferManagerImpl.java
>
>
> BufferManager Cleaner thread is consuming almost all of the CPU utilized by the jboss process. Thread dump shows following information.
> 3XMTHREADINFO "BufferManager Cleaner" J9VMThread:0x0000004C41CFEB00, j9thread_t:0x0000004C52B85AE0, java/lang/Thread:0x000000481C036E20, state:CW, prio=5
> 3XMJAVALTHREAD (java/lang/Thread getId:0x76, isDaemon:true)
> 3XMTHREADINFO1 (native thread ID:0x3AEC2600, native priority:0x5, native policy:UNKNOWN)
> 3XMHEAPALLOC Heap bytes allocated since last GC cycle=2609184 (0x27D020)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACE at java/util/concurrent/ConcurrentSkipListMap.doRemove(ConcurrentSkipListMap.java:1070(Compiled Code))
> 4XESTACKTRACE at java/util/concurrent/ConcurrentSkipListMap.remove(ConcurrentSkipListMap.java:1659(Compiled Code))
> 4XESTACKTRACE at org/teiid/common/buffer/impl/LrfuEvictionQueue.remove(LrfuEvictionQueue.java:60(Compiled Code))
> 4XESTACKTRACE at org/teiid/common/buffer/impl/BufferManagerImpl.doEvictions(BufferManagerImpl.java:854(Compiled Code))
> 5XESTACKTRACE (entered lock: org/teiid/common/buffer/CacheEntry@0x00000048393C2598, entry count: 1)
> 4XESTACKTRACE at org/teiid/common/buffer/impl/BufferManagerImpl$Cleaner.run(BufferManagerImpl.java:108)
> 4XESTACKTRACE at java/util/TimerThread.mainLoop(Timer.java:555)
> 4XESTACKTRACE at java/util/TimerThread.run(Timer.java:505)
> When we added log statements around the BufferManagerImpl.doEvictions() it loops through the remove and firstEntry loop.
> Forum discussion link : https://community.jboss.org/message/901792
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 6 months
[JBoss JIRA] (TEIID-3106) BufferManager Cleaner consuming 90% of total CPU time
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3106?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3106:
---------------------------------------
Would it be possible as well to see if/when overflow could have been introduced in the CacheKeys - for example a debug line if the last access or the ordering value is less than 0?
> BufferManager Cleaner consuming 90% of total CPU time
> -----------------------------------------------------
>
> Key: TEIID-3106
> URL: https://issues.jboss.org/browse/TEIID-3106
> Project: Teiid
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Query Engine
> Affects Versions: 8.7
> Environment: zOS
> Reporter: Devesh Mishra
> Assignee: Steven Hawkins
> Labels: teiid-engine
> Attachments: BufferManagerImpl.java
>
>
> BufferManager Cleaner thread is consuming almost all of the CPU utilized by the jboss process. Thread dump shows following information.
> 3XMTHREADINFO "BufferManager Cleaner" J9VMThread:0x0000004C41CFEB00, j9thread_t:0x0000004C52B85AE0, java/lang/Thread:0x000000481C036E20, state:CW, prio=5
> 3XMJAVALTHREAD (java/lang/Thread getId:0x76, isDaemon:true)
> 3XMTHREADINFO1 (native thread ID:0x3AEC2600, native priority:0x5, native policy:UNKNOWN)
> 3XMHEAPALLOC Heap bytes allocated since last GC cycle=2609184 (0x27D020)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACE at java/util/concurrent/ConcurrentSkipListMap.doRemove(ConcurrentSkipListMap.java:1070(Compiled Code))
> 4XESTACKTRACE at java/util/concurrent/ConcurrentSkipListMap.remove(ConcurrentSkipListMap.java:1659(Compiled Code))
> 4XESTACKTRACE at org/teiid/common/buffer/impl/LrfuEvictionQueue.remove(LrfuEvictionQueue.java:60(Compiled Code))
> 4XESTACKTRACE at org/teiid/common/buffer/impl/BufferManagerImpl.doEvictions(BufferManagerImpl.java:854(Compiled Code))
> 5XESTACKTRACE (entered lock: org/teiid/common/buffer/CacheEntry@0x00000048393C2598, entry count: 1)
> 4XESTACKTRACE at org/teiid/common/buffer/impl/BufferManagerImpl$Cleaner.run(BufferManagerImpl.java:108)
> 4XESTACKTRACE at java/util/TimerThread.mainLoop(Timer.java:555)
> 4XESTACKTRACE at java/util/TimerThread.run(Timer.java:505)
> When we added log statements around the BufferManagerImpl.doEvictions() it loops through the remove and firstEntry loop.
> Forum discussion link : https://community.jboss.org/message/901792
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 6 months
[JBoss JIRA] (TEIID-3106) BufferManager Cleaner consuming 90% of total CPU time
by Mark Addleman (JIRA)
[ https://issues.jboss.org/browse/TEIID-3106?page=com.atlassian.jira.plugin... ]
Mark Addleman commented on TEIID-3106:
--------------------------------------
Thanks Steve. We'll gather more logs tonight during our testing window.
> BufferManager Cleaner consuming 90% of total CPU time
> -----------------------------------------------------
>
> Key: TEIID-3106
> URL: https://issues.jboss.org/browse/TEIID-3106
> Project: Teiid
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Query Engine
> Affects Versions: 8.7
> Environment: zOS
> Reporter: Devesh Mishra
> Assignee: Steven Hawkins
> Labels: teiid-engine
> Attachments: BufferManagerImpl.java
>
>
> BufferManager Cleaner thread is consuming almost all of the CPU utilized by the jboss process. Thread dump shows following information.
> 3XMTHREADINFO "BufferManager Cleaner" J9VMThread:0x0000004C41CFEB00, j9thread_t:0x0000004C52B85AE0, java/lang/Thread:0x000000481C036E20, state:CW, prio=5
> 3XMJAVALTHREAD (java/lang/Thread getId:0x76, isDaemon:true)
> 3XMTHREADINFO1 (native thread ID:0x3AEC2600, native priority:0x5, native policy:UNKNOWN)
> 3XMHEAPALLOC Heap bytes allocated since last GC cycle=2609184 (0x27D020)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACE at java/util/concurrent/ConcurrentSkipListMap.doRemove(ConcurrentSkipListMap.java:1070(Compiled Code))
> 4XESTACKTRACE at java/util/concurrent/ConcurrentSkipListMap.remove(ConcurrentSkipListMap.java:1659(Compiled Code))
> 4XESTACKTRACE at org/teiid/common/buffer/impl/LrfuEvictionQueue.remove(LrfuEvictionQueue.java:60(Compiled Code))
> 4XESTACKTRACE at org/teiid/common/buffer/impl/BufferManagerImpl.doEvictions(BufferManagerImpl.java:854(Compiled Code))
> 5XESTACKTRACE (entered lock: org/teiid/common/buffer/CacheEntry@0x00000048393C2598, entry count: 1)
> 4XESTACKTRACE at org/teiid/common/buffer/impl/BufferManagerImpl$Cleaner.run(BufferManagerImpl.java:108)
> 4XESTACKTRACE at java/util/TimerThread.mainLoop(Timer.java:555)
> 4XESTACKTRACE at java/util/TimerThread.run(Timer.java:505)
> When we added log statements around the BufferManagerImpl.doEvictions() it loops through the remove and firstEntry loop.
> Forum discussion link : https://community.jboss.org/message/901792
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 6 months
[JBoss JIRA] (TEIID-3106) BufferManager Cleaner consuming 90% of total CPU time
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3106?page=com.atlassian.jira.plugin... ]
Steven Hawkins edited comment on TEIID-3106 at 9/1/14 6:10 PM:
---------------------------------------------------------------
Devesh, it would probably be best to collect cpu stats from a profiling run rather than looking for a spike and a thread dump, unless the spike is sustained for a substantial period of time. The stack that is being shown there unfortunately doesn't help clarify what you might be seeing. Do you have additional log entries indicating what may be occurring?
Yes Mark that should be an equals check rather than equality.
was (Author: shawkins):
Devesh, it would probably be best to collect cpu stats from a profiling run rather than looking for a spike and a thread dump, unless the spike is sustained for a substantial period of time. The stack that is being shown there unfortunately doesn't help clarify what you might be seeing. Do you have additional log entries indicating what may be occuring?
Mark, I'm not sure what you mean. Which comparison are you referring to?
> BufferManager Cleaner consuming 90% of total CPU time
> -----------------------------------------------------
>
> Key: TEIID-3106
> URL: https://issues.jboss.org/browse/TEIID-3106
> Project: Teiid
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Query Engine
> Affects Versions: 8.7
> Environment: zOS
> Reporter: Devesh Mishra
> Assignee: Steven Hawkins
> Labels: teiid-engine
> Attachments: BufferManagerImpl.java
>
>
> BufferManager Cleaner thread is consuming almost all of the CPU utilized by the jboss process. Thread dump shows following information.
> 3XMTHREADINFO "BufferManager Cleaner" J9VMThread:0x0000004C41CFEB00, j9thread_t:0x0000004C52B85AE0, java/lang/Thread:0x000000481C036E20, state:CW, prio=5
> 3XMJAVALTHREAD (java/lang/Thread getId:0x76, isDaemon:true)
> 3XMTHREADINFO1 (native thread ID:0x3AEC2600, native priority:0x5, native policy:UNKNOWN)
> 3XMHEAPALLOC Heap bytes allocated since last GC cycle=2609184 (0x27D020)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACE at java/util/concurrent/ConcurrentSkipListMap.doRemove(ConcurrentSkipListMap.java:1070(Compiled Code))
> 4XESTACKTRACE at java/util/concurrent/ConcurrentSkipListMap.remove(ConcurrentSkipListMap.java:1659(Compiled Code))
> 4XESTACKTRACE at org/teiid/common/buffer/impl/LrfuEvictionQueue.remove(LrfuEvictionQueue.java:60(Compiled Code))
> 4XESTACKTRACE at org/teiid/common/buffer/impl/BufferManagerImpl.doEvictions(BufferManagerImpl.java:854(Compiled Code))
> 5XESTACKTRACE (entered lock: org/teiid/common/buffer/CacheEntry@0x00000048393C2598, entry count: 1)
> 4XESTACKTRACE at org/teiid/common/buffer/impl/BufferManagerImpl$Cleaner.run(BufferManagerImpl.java:108)
> 4XESTACKTRACE at java/util/TimerThread.mainLoop(Timer.java:555)
> 4XESTACKTRACE at java/util/TimerThread.run(Timer.java:505)
> When we added log statements around the BufferManagerImpl.doEvictions() it loops through the remove and firstEntry loop.
> Forum discussion link : https://community.jboss.org/message/901792
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 6 months
[JBoss JIRA] (TEIID-3106) BufferManager Cleaner consuming 90% of total CPU time
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3106?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-3106:
---------------------------------------
Devesh, it would probably be best to collect cpu stats from a profiling run rather than looking for a spike and a thread dump, unless the spike is sustained for a substantial period of time. The stack that is being shown there unfortunately doesn't help clarify what you might be seeing. Do you have additional log entries indicating what may be occuring?
Mark, I'm not sure what you mean. Which comparison are you referring to?
> BufferManager Cleaner consuming 90% of total CPU time
> -----------------------------------------------------
>
> Key: TEIID-3106
> URL: https://issues.jboss.org/browse/TEIID-3106
> Project: Teiid
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Query Engine
> Affects Versions: 8.7
> Environment: zOS
> Reporter: Devesh Mishra
> Assignee: Steven Hawkins
> Labels: teiid-engine
> Attachments: BufferManagerImpl.java
>
>
> BufferManager Cleaner thread is consuming almost all of the CPU utilized by the jboss process. Thread dump shows following information.
> 3XMTHREADINFO "BufferManager Cleaner" J9VMThread:0x0000004C41CFEB00, j9thread_t:0x0000004C52B85AE0, java/lang/Thread:0x000000481C036E20, state:CW, prio=5
> 3XMJAVALTHREAD (java/lang/Thread getId:0x76, isDaemon:true)
> 3XMTHREADINFO1 (native thread ID:0x3AEC2600, native priority:0x5, native policy:UNKNOWN)
> 3XMHEAPALLOC Heap bytes allocated since last GC cycle=2609184 (0x27D020)
> 3XMTHREADINFO3 Java callstack:
> 4XESTACKTRACE at java/util/concurrent/ConcurrentSkipListMap.doRemove(ConcurrentSkipListMap.java:1070(Compiled Code))
> 4XESTACKTRACE at java/util/concurrent/ConcurrentSkipListMap.remove(ConcurrentSkipListMap.java:1659(Compiled Code))
> 4XESTACKTRACE at org/teiid/common/buffer/impl/LrfuEvictionQueue.remove(LrfuEvictionQueue.java:60(Compiled Code))
> 4XESTACKTRACE at org/teiid/common/buffer/impl/BufferManagerImpl.doEvictions(BufferManagerImpl.java:854(Compiled Code))
> 5XESTACKTRACE (entered lock: org/teiid/common/buffer/CacheEntry@0x00000048393C2598, entry count: 1)
> 4XESTACKTRACE at org/teiid/common/buffer/impl/BufferManagerImpl$Cleaner.run(BufferManagerImpl.java:108)
> 4XESTACKTRACE at java/util/TimerThread.mainLoop(Timer.java:555)
> 4XESTACKTRACE at java/util/TimerThread.run(Timer.java:505)
> When we added log statements around the BufferManagerImpl.doEvictions() it loops through the remove and firstEntry loop.
> Forum discussion link : https://community.jboss.org/message/901792
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 6 months
[JBoss JIRA] (TEIID-3105) Can we add allowDuplicateDomains in Infinispan global configuration
by Kylin Soong (JIRA)
[ https://issues.jboss.org/browse/TEIID-3105?page=com.atlassian.jira.plugin... ]
Kylin Soong updated TEIID-3105:
-------------------------------
Fix Version/s: 8.9
Git Pull Request: https://github.com/teiid/teiid/pull/311
Affects Version/s: 8.9
(was: 9.x)
> Can we add allowDuplicateDomains in Infinispan global configuration
> -------------------------------------------------------------------
>
> Key: TEIID-3105
> URL: https://issues.jboss.org/browse/TEIID-3105
> Project: Teiid
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Embedded
> Affects Versions: 8.9
> Environment: Teiid Embedded with Infinispan local cache
> Reporter: Kylin Soong
> Assignee: Kylin Soong
> Fix For: 8.9
>
>
> I have run Teiid Embedded on top of Infinispan local cache meet the the following exception:
> org.infinispan.jmx.JmxDomainConflictException: Domain already registered org.infinispan when trying to register: type=CacheManager,name="DefaultCacheManager"
> The "DefaultCacheManager" be register to MBeanServer 2 times cause the issue:
> 1. EmbeddedServer load infinispan cache via [1], this cause "DefaultCacheManager" register to MBean Server
> 2. Infinispan Translator connection load VDB refrred cache, this also cause "DefaultCacheManager" register again
> If we add allowDuplicateDomains in Infinispan configuration [1], this will avoid the issue.
> [1] https://github.com/teiid/teiid/blob/master/runtime/src/main/resources/inf...
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
10 years, 6 months