[JBoss JIRA] (JBCACHE-1629) JBoss Cache will not compile tests with java 1.7
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/JBCACHE-1629?page=com.atlassian.jira.plug... ]
Mircea Markus commented on JBCACHE-1629:
----------------------------------------
JBossCache is no longer community-supported. We strongly advise switching to www.infinispan.org
> JBoss Cache will not compile tests with java 1.7
> ------------------------------------------------
>
> Key: JBCACHE-1629
> URL: https://issues.jboss.org/browse/JBCACHE-1629
> Project: JBoss Cache
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.2.9.GA
> Environment: Windows, RHEL
> Oracle jdk 1.7, IBM jdk 1.7, openjdk 1.7
> Reporter: Richard Janík
> Assignee: Manik Surtani
>
> I am unable to compile tests from JBoss Cache (mvn test, or mvn compile compiler:testCompile) with any 1.7 jdk:
> {code}
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:2.0.1:testCompile (default-testCompile) on project jbosscache-core: Compilation failure: Compilation failure:
> [ERROR] /home/rjanik/svn/jbosscache/3.2.11.GA/src/test/java/org/jboss/cache/loader/DataSourceIntegrationTest.java:[106,18] error: MockDataSource is not abstract and does not override abstract method getParentLogger() in CommonDataSource
> [ERROR] -> [Help 1]
> {code}
> I have tried this with 3.2.10.GA and 3.2.11.GA as well, but they are not listed among possible affected versions. Svn tags:
> https://anonsvn.jboss.org/repos/jbosscache/core/tags/3.2.10.GA/
> https://anonsvn.jboss.org/repos/jbosscache/core/tags/3.2.11.GA/
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
- 1
- 0
[JBoss JIRA] (JBCACHE-1599) Patch for JBCACHE-1592 --> "org.jboss.cache.lock.TimeoutException: Unable to acquire lock on Fqn is very frequently in cluster" potential Fix
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/JBCACHE-1599?page=com.atlassian.jira.plug... ]
Mircea Markus commented on JBCACHE-1599:
----------------------------------------
hi [~sopanpatel]
JBossCache is no longer supported for community. We strongly encourage all the users to move to Inifinispan - its successor.
> Patch for JBCACHE-1592 --> "org.jboss.cache.lock.TimeoutException: Unable to acquire lock on Fqn is very frequently in cluster" potential Fix
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBCACHE-1599
> URL: https://issues.jboss.org/browse/JBCACHE-1599
> Project: JBoss Cache
> Issue Type: Patch
> Security Level: Public(Everyone can see)
> Components: Locking
> Affects Versions: 3.2.5.GA
> Reporter: Christopher Ezell
> Assignee: Manik Surtani
> Fix For: 3.2.6.GA, 3.2.7.GA
>
> Attachments: MVCCLockingInterceptor.java.patch
>
>
> This is a potential fix for the Timeout Problem from BUG "JBCACHE-1592". This Patch fix The Problem by removing the line:
> "ctx.getOptionOverrides().setLockAcquisitionTimeout(0);" in the "org.jboss.cache.interceptors.MVCCLockingInterceptor.java" in line 202.
> This line set the Timeout to zero and deranges the System to gain a Lock.
> Removing this line prevents this.
> Patch is in the attached file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
- 1
- 0
[JBoss JIRA] (JBCACHE-1592) org.jboss.cache.lock.TimeoutException: Unable to acquire lock on Fqn is very frequently in cluster
by sopan patel (JIRA)
[ https://issues.jboss.org/browse/JBCACHE-1592?page=com.atlassian.jira.plug... ]
sopan patel commented on JBCACHE-1592:
--------------------------------------
Hi,
I am using Jboss cache 3.2.8.1 version. When i am restarting my DB(oracle 11g) and after that trying to fetch any data from Jboss cache then it was throwing below exception. I tried deleting "org.jboss.cache.interceptors.MVCCLockingInterceptor.java" in line 202." and check again but it didnt help me
Exception :
Got Exception in JbossCacheProcessor's store operation, even after retrying for ...21 times -
org.jboss.cache.lock.TimeoutException: Unable to acquire lock on Fqn [/jboss/ABCInfo-1] after [10000] milliseconds for requestor [Thread[thread-3,4,main]]! Lock held by [Thread[pool-flow.seda.ABC-mediation-notification-se-thread-46,5,]]
at org.jboss.cache.mvcc.MVCCNodeHelper.acquireLock(MVCCNodeHelper.java:159)
at org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:242)
at org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:186)
> org.jboss.cache.lock.TimeoutException: Unable to acquire lock on Fqn is very frequently in cluster
> --------------------------------------------------------------------------------------------------
>
> Key: JBCACHE-1592
> URL: https://issues.jboss.org/browse/JBCACHE-1592
> Project: JBoss Cache
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Locking
> Affects Versions: 3.2.5.GA
> Environment: windows os,cluster node in one machine.
> Reporter: l jw
> Assignee: Manik Surtani
> Priority: Blocker
>
> When used in cluster,the following exception is throw frequently:
> org.jboss.cache.lock.TimeoutException: Unable to acquire lock on Fqn [/courseClass/360/male] after [5000] milliseconds for requestor [GlobalTransaction:<172.18.73.162:3430>:1843]! Lock held by [GlobalTransaction:<172.18.73.162:3428>:6416]
> at org.jboss.cache.mvcc.MVCCNodeHelper.acquireLock(MVCCNodeHelper.java:159)
> at org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:217)
> at org.jboss.cache.mvcc.MVCCNodeHelper.wrapNodeForWriting(MVCCNodeHelper.java:186)
> at org.jboss.cache.interceptors.MVCCLockingInterceptor.handlePutKeyValueCommand(MVCCLockingInterceptor.java:101)
> at org.jboss.cache.interceptors.base.PrePostProcessingCommandInterceptor.visitPutKeyValueCommand(PrePostProcessingCommandInterceptor.java:88)
> at org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
> at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> at org.jboss.cache.interceptors.ReplicationInterceptor.handleCrudMethod(ReplicationInterceptor.java:150)
> at org.jboss.cache.interceptors.ReplicationInterceptor.visitPutKeyValueCommand(ReplicationInterceptor.java:107)
> at org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
> at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> at org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131)
> at org.jboss.cache.commands.AbstractVisitor.visitPutKeyValueCommand(AbstractVisitor.java:65)
> at org.jboss.cache.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:100)
> at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> at org.jboss.cache.interceptors.TxInterceptor.replayModifications(TxInterceptor.java:501)
> at org.jboss.cache.interceptors.TxInterceptor.handleRemotePrepare(TxInterceptor.java:388)
> at org.jboss.cache.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:134)
> at org.jboss.cache.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:68)
> at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> at org.jboss.cache.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:131)
> at org.jboss.cache.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:140)
> at org.jboss.cache.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:68)
> at org.jboss.cache.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:116)
> at org.jboss.cache.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:178)
> at org.jboss.cache.interceptors.InvocationContextInterceptor.visitPrepareCommand(InvocationContextInterceptor.java:106)
> at org.jboss.cache.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:68)
> at org.jboss.cache.interceptors.InterceptorChain.invokeRemote(InterceptorChain.java:316)
> at org.jboss.cache.commands.remote.ReplicateCommand.processSingleCommand(ReplicateCommand.java:139)
> at org.jboss.cache.commands.remote.ReplicateCommand.perform(ReplicateCommand.java:115)
> at org.jboss.cache.marshall.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:319)
> at org.jboss.cache.marshall.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:246)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:637)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:545)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:368)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:775)
> at org.jgroups.JChannel.up(JChannel.java:1336)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:454)
> at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:486)
> at org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER.up(STREAMING_STATE_TRANSFER.java:319)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:188)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:820)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:233)
> at org.jgroups.protocols.UNICAST.up(UNICAST.java:328)
> at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:895)
> at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:708)
> at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:167)
> at org.jgroups.protocols.FD.up(FD.java:284)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:307)
> at org.jgroups.protocols.MERGE2.up(MERGE2.java:144)
> at org.jgroups.protocols.Discovery.up(Discovery.java:264)
> at org.jgroups.protocols.PING.up(PING.java:273)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1273)
> at org.jgroups.protocols.TP.access$100(TP.java:49)
> at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1826)
> at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1805)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
> at java.lang.Thread.run(Thread.java:619)
> and following is my config:
> <jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:jboss:jbosscache-core:config:3.2">
> <locking isolationLevel="REPEATABLE_READ"
> lockParentForChildInsertRemove="false"
> lockAcquisitionTimeout="5000"
> nodeLockingScheme="mvcc"
> writeSkewCheck="true"
> useLockStriping="true"
> concurrencyLevel="10000"/>
> <clustering mode="replication" clusterName="JBossCache-cluster">
> <stateRetrieval timeout="5000" fetchInMemoryState="false" nonBlocking="false"/>
> <sync replTimeout="5000"/>
> <jgroupsConfig>
> <UDP discard_incompatible_packets="true" enable_bundling="false" enable_diagnostics="false" ip_ttl="2"
> loopback="false" max_bundle_size="64000" max_bundle_timeout="30" mcast_addr="224.0.0.1"
> mcast_port="45588" mcast_recv_buf_size="25000000" mcast_send_buf_size="640000"
> oob_thread_pool.enabled="true" oob_thread_pool.keep_alive_time="10000" oob_thread_pool.max_threads="4"
> oob_thread_pool.min_threads="1" oob_thread_pool.queue_enabled="true"
> oob_thread_pool.queue_max_size="10"
> oob_thread_pool.rejection_policy="Run" thread_naming_pattern="pl" thread_pool.enabled="true"
> thread_pool.keep_alive_time="30000" thread_pool.max_threads="25" thread_pool.min_threads="1"
> thread_pool.queue_enabled="true" thread_pool.queue_max_size="10" thread_pool.rejection_policy="Run"
> tos="8" ucast_recv_buf_size="20000000" ucast_send_buf_size="640000" use_concurrent_stack="true"
> use_incoming_packet_handler="true"/>
> <PING num_initial_members="3" timeout="2000"/>
> <MERGE2 max_interval="30000" min_interval="10000"/>
> <FD_SOCK/>
> <FD max_tries="5" shun="true" timeout="10000"/>
> <VERIFY_SUSPECT timeout="1500"/>
> <pbcast.NAKACK discard_delivered_msgs="true" gc_lag="0" retransmit_timeout="300,600,1200,2400,4800"
> use_mcast_xmit="false"/>
> <UNICAST timeout="300,600,1200,2400,3600"/>
> <pbcast.STABLE desired_avg_gossip="50000" max_bytes="400000" stability_delay="1000"/>
> <pbcast.GMS join_timeout="5000" print_local_addr="true" shun="false" view_ack_collection_timeout="5000"
> view_bundling="true"/>
> <FRAG2 frag_size="60000"/>
> <pbcast.STREAMING_STATE_TRANSFER/>
> <pbcast.FLUSH timeout="0"/>
> </jgroupsConfig>
> </clustering>
> </jbosscache>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
- 1
- 0
[JBoss JIRA] (JBCACHE-1599) Patch for JBCACHE-1592 --> "org.jboss.cache.lock.TimeoutException: Unable to acquire lock on Fqn is very frequently in cluster" potential Fix
by sopan patel (JIRA)
[ https://issues.jboss.org/browse/JBCACHE-1599?page=com.atlassian.jira.plug... ]
sopan patel commented on JBCACHE-1599:
--------------------------------------
Can somebody please comments on this ..it's little urgent
> Patch for JBCACHE-1592 --> "org.jboss.cache.lock.TimeoutException: Unable to acquire lock on Fqn is very frequently in cluster" potential Fix
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBCACHE-1599
> URL: https://issues.jboss.org/browse/JBCACHE-1599
> Project: JBoss Cache
> Issue Type: Patch
> Security Level: Public(Everyone can see)
> Components: Locking
> Affects Versions: 3.2.5.GA
> Reporter: Christopher Ezell
> Assignee: Manik Surtani
> Fix For: 3.2.6.GA, 3.2.7.GA
>
> Attachments: MVCCLockingInterceptor.java.patch
>
>
> This is a potential fix for the Timeout Problem from BUG "JBCACHE-1592". This Patch fix The Problem by removing the line:
> "ctx.getOptionOverrides().setLockAcquisitionTimeout(0);" in the "org.jboss.cache.interceptors.MVCCLockingInterceptor.java" in line 202.
> This line set the Timeout to zero and deranges the System to gain a Lock.
> Removing this line prevents this.
> Patch is in the attached file.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
- 1
- 0
- ← Newer
- 1
- Older →