[JBoss JIRA] (ISPN-1345) Dirty reads may occurs on mutable objects
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-1345?page=com.atlassian.jira.plugin.... ]
Mircea Markus resolved ISPN-1345.
---------------------------------
Resolution: Rejected
storeAsBinary should solve the issue. It should be up to the user to clone the objects added to the cache.
> Dirty reads may occurs on mutable objects
> -----------------------------------------
>
> Key: ISPN-1345
> URL: https://issues.jboss.org/browse/ISPN-1345
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 5.0.0.FINAL
> Environment: Windows Java 1.6.0_26
> Reporter: Christophe Labouisse
> Assignee: Manik Surtani
> Priority: Critical
> Fix For: 5.3.0.Final
>
>
> In local mode, I create a cache like this:
> {code}
> cacheManager = new DefaultCacheManager();
> cacheManager.getDefaultConfiguration().fluent().storeAsBinary().transaction().cacheStopTimeout(5000);
> final Configuration config = new Configuration().fluent().transactionManagerLookup(this.tmLookup).locking()
> .isolationLevel(IsolationLevel.READ_COMMITED).build();
> this.cacheManager.defineConfiguration("Gruik", config);
> this.cache = this.cacheManager.getCache("Gruik");
> {code}
> When retrieving data using {{cache.get(_key_)}} I find out that Infinispan returns the object instance actually stored in the cache datastore. This is OK when the inserted objects are immutable but fails to achieve isolation when using mutable objects.
> For instance on a simple Pojo with a {{get/setValue}}.
> ||Step||Reader||Writer||
> |1|Starts transaction| |
> |2|{{value = cache.get(KEY);}}| |
> |3|{{System.out.println(value.getValue());}} Prints 42| |
> |4| |Starts transaction|
> |5| |{{value = cache.get(KEY);}} Same instance than step 2|
> |6| |{{value.setValue(666); // Prepare update}}|
> |7|{{System.out.println(value.getValue());}} Prints 666 !| |
> |8|{{value = cache.get(KEY);}} Same instance than step 2| |
> |9| |{{cache.put(KEY,value);}}|
> |10| |Commits transaction|
> |11|{{value = cache.get(KEY);}} Same instance than step 2| |
> |12|{{System.out.println(value.getValue());}} Prints 666| |
> |13|Commits transaction| |
> According to the READ_COMMITTED specification, the value printed on step 7 should be 42 as the change to 666 is not committed yet.
--
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, 1 month
[JBoss JIRA] (ISPN-1319) topology changes makes entire cluster inconsistent
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-1319?page=com.atlassian.jira.plugin.... ]
Mircea Markus resolved ISPN-1319.
---------------------------------
Resolution: Out of Date
should work in 5.2.
> topology changes makes entire cluster inconsistent
> --------------------------------------------------
>
> Key: ISPN-1319
> URL: https://issues.jboss.org/browse/ISPN-1319
> Project: Infinispan
> Issue Type: Bug
> Components: Distributed Cache
> Affects Versions: 5.0.0.FINAL
> Environment: linux / devel environment / 1.6.0_26
> Reporter: Jan Slezak
> Assignee: Manik Surtani
> Priority: Blocker
>
> Invoke timeout exception in replicated or distributed environment (the issue occurred in both) during topology change on producer node - after that the data may end up in inconsistent state on other nodes (in my case n+1 entities on some of the nodes). I tried that with many TM / ISPN configurations in sync mode using DummyTransactionManagerLookup. Same behavior using invocation batching ...
> example xml:
> <infinispan
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="urn:infinispan:config:5.0 http://www.infinispan.org/schemas/infinispan-config-5.0.xsd"
> xmlns="urn:infinispan:config:5.0">
> <global>
> <transport clusterName="ifprotocluster"/>
> </global>
> <default>
> <clustering mode="distribution">
> <l1 enabled="false"/>
> <hash numOwners="100" rehashRpcTimeout="120000" />
> <sync/>
> </clustering>
> <transaction
> transactionManagerLookupClass="org.infinispan.transaction.lookup.DummyTransactionManagerLookup"
> syncRollbackPhase="true"
> syncCommitPhase="true"
> useEagerLocking="true"
> />
> </default>
> </infinispan>
--
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, 1 month
[JBoss JIRA] (ISPN-2853) Asymmetric Transactional Clustered Cache causes NullPointerExceptions on non Clustered members
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-2853?page=com.atlassian.jira.plugin.... ]
William Burns commented on ISPN-2853:
-------------------------------------
Unfortunately it doesn't just pollute the logs. If you take a closer look at the trace from the clustered member, which is trying to do a put it actually causes a RuntimeException to be thrown which in the case of my example actually killed the thread.
{quote}
Exception in thread "main" org.infinispan.remoting.RemoteException: ISPN000217: Received exception from wburns-43310, see cause for remote stack trace
at org.infinispan.remoting.transport.AbstractTransport.checkResponse(AbstractTransport.java:72)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.processSingleCall(CommandAwareRpcDispatcher.java:310)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:179)
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:515)
at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:169)
{quote}
Thus in our configuration we had to disable the usage of asymmetric clusters else we can never update the caches.
> Asymmetric Transactional Clustered Cache causes NullPointerExceptions on non Clustered members
> ----------------------------------------------------------------------------------------------
>
> Key: ISPN-2853
> URL: https://issues.jboss.org/browse/ISPN-2853
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.1.6.FINAL
> Reporter: William Burns
> Assignee: Adrian Nistor
> Priority: Minor
> Labels: onboard
> Fix For: 5.3.0.Final
>
> Attachments: Asymmetric.java
>
>
> We utilize Asymmetric clusters to prevent some unneeded communication between members that don't need to participate in the cluster cache. This works fine for the cache updates to not be sent to that node. However, I noticed that if you have this cache be transactional as well, then members that aren't clustered for this cache will get transaction prepare and commit messages which cause NullPointerExceptions since they don't have remote transactions configured for these nodes.
> Here is a sample test case that shows the error that is found.
> {code}
> 15164 [OOB-3,wburns-45269] TRACE org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher - Attempting to execute command: TxCompletionNotificationCommand{ xid=null, internalId=0, gtx=GlobalTransaction:<wburns-1521>:1:local, cacheName=asymmetric} [sender=wburns-1521]
> 15164 [OOB-3,wburns-45269] TRACE org.infinispan.remoting.InboundInvocationHandlerImpl - Calling perform() on TxCompletionNotificationCommand{ xid=null, internalId=0, gtx=GlobalTransaction:<wburns-1521>:1:local, cacheName=asymmetric}
> 15164 [OOB-3,wburns-45269] TRACE org.infinispan.commands.remote.recovery.TxCompletionNotificationCommand - Processing completed transaction GlobalTransaction:<wburns-1521>:1:local
> 15164 [OOB-3,wburns-45269] TRACE org.infinispan.remoting.InboundInvocationHandlerImpl - Exception executing command
> java.lang.NullPointerException
> at org.infinispan.transaction.TransactionTable.removeRemoteTransaction(TransactionTable.java:340)
> at org.infinispan.commands.remote.recovery.TxCompletionNotificationCommand.perform(TxCompletionNotificationCommand.java:92)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:127)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithWaitForBlocks(InboundInvocationHandlerImpl.java:136)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithRetry(InboundInvocationHandlerImpl.java:162)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:114)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:226)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:203)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:456)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:363)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:238)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:601)
> at org.jgroups.JChannel.up(JChannel.java:716)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1026)
> at org.jgroups.protocols.RSVP.up(RSVP.java:192)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:889)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
> at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:759)
> at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:365)
> at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:602)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:177)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
> at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
> at org.jgroups.protocols.Discovery.up(Discovery.java:359)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1180)
> at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1728)
> at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1710)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> 15167 [OOB-3,wburns-45269] TRACE org.infinispan.remoting.InboundInvocationHandlerImpl - Unable to execute command, got invalid response ExceptionResponse
> 20170 [OOB-3,wburns-45269] TRACE org.infinispan.marshall.jboss.AbstractJBossMarshaller - Start unmarshaller after retrieving marshaller from thread local
> 20170 [OOB-3,wburns-45269] TRACE org.infinispan.marshall.VersionAwareMarshaller - Read version 510
> 20171 [OOB-3,wburns-45269] TRACE org.infinispan.marshall.jboss.AbstractJBossMarshaller - Start unmarshaller after retrieving marshaller from factory
> 20171 [OOB-3,wburns-45269] TRACE org.infinispan.marshall.VersionAwareMarshaller - Read version 510
> 20171 [OOB-3,wburns-45269] TRACE org.infinispan.marshall.jboss.AbstractJBossMarshaller - Stop unmarshaller
> 20171 [OOB-3,wburns-45269] TRACE org.infinispan.marshall.jboss.AbstractJBossMarshaller - Stop unmarshaller
> 20171 [OOB-3,wburns-45269] TRACE org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher - Attempting to execute command: TxCompletionNotificationCommand{ xid=null, internalId=0, gtx=GlobalTransaction:<wburns-1521>:2:local, cacheName=asymmetric} [sender=wburns-1521]
> 20171 [OOB-3,wburns-45269] TRACE org.infinispan.remoting.InboundInvocationHandlerImpl - Calling perform() on TxCompletionNotificationCommand{ xid=null, internalId=0, gtx=GlobalTransaction:<wburns-1521>:2:local, cacheName=asymmetric}
> 20171 [OOB-3,wburns-45269] TRACE org.infinispan.commands.remote.recovery.TxCompletionNotificationCommand - Processing completed transaction GlobalTransaction:<wburns-1521>:2:local
> 20171 [OOB-3,wburns-45269] TRACE org.infinispan.remoting.InboundInvocationHandlerImpl - Exception executing command
> java.lang.NullPointerException
> at org.infinispan.transaction.TransactionTable.removeRemoteTransaction(TransactionTable.java:340)
> at org.infinispan.commands.remote.recovery.TxCompletionNotificationCommand.perform(TxCompletionNotificationCommand.java:92)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:127)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithWaitForBlocks(InboundInvocationHandlerImpl.java:136)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithRetry(InboundInvocationHandlerImpl.java:162)
> at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:114)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:226)
> at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:203)
> at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:456)
> at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:363)
> at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:238)
> at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:601)
> at org.jgroups.JChannel.up(JChannel.java:716)
> at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1026)
> at org.jgroups.protocols.RSVP.up(RSVP.java:192)
> at org.jgroups.protocols.FRAG2.up(FRAG2.java:181)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:418)
> at org.jgroups.protocols.FlowControl.up(FlowControl.java:400)
> at org.jgroups.protocols.pbcast.GMS.up(GMS.java:889)
> at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
> at org.jgroups.protocols.UNICAST2.handleDataReceived(UNICAST2.java:759)
> at org.jgroups.protocols.UNICAST2.up(UNICAST2.java:365)
> at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:602)
> at org.jgroups.protocols.FD_ALL.up(FD_ALL.java:177)
> at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:288)
> at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
> at org.jgroups.protocols.Discovery.up(Discovery.java:359)
> at org.jgroups.protocols.TP.passMessageUp(TP.java:1180)
> at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1728)
> at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1710)
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> at java.lang.Thread.run(Unknown Source)
> 20173 [OOB-3,wburns-45269] TRACE org.infinispan.remoting.InboundInvocationHandlerImpl - Unable to execute command, got invalid response ExceptionResponse
> {code}
> As a side note, these NPE appear to not be propagated to the client, since they are sent with a response mode of GET_NONE. However we have a site that will every once in a while get the NPE sent back to the updating member which then causes a CacheException to occur forcing the original nodes transaction to be rolled back forcing a retry of the operation.
--
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, 1 month
[JBoss JIRA] (ISPN-3081) Logging produces strange beginning of lines
by Michal Linhard (JIRA)
[ https://issues.jboss.org/browse/ISPN-3081?page=com.atlassian.jira.plugin.... ]
Michal Linhard commented on ISPN-3081:
--------------------------------------
seems like the problem is only in few first logged lines:
{code}
JAVA_OPTS already set in environment; overriding default settings with values: -Djava.managed.server.id=p3MXeYznB29SpGQJ -server -Xms256m -Xmx256m -XX:MaxPermSize=128m -XX:MaxDirectMemorySize=64m -XX:+UseLargePages -Dsun.nio.ch.bugLevel= -Djava.net.preferIPv4Stack=true -XX:NewRatio=3 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -Dorg.jboss.qa.threadpoolwatchdog.output=/home/mlinhard/dev/projects/perf/smartfrog/smartfrog/tpstats/node01.csv
=========================================================================
JBoss Bootstrap Environment
JBOSS_HOME: /home/mlinhard/dev/projects/perf/smartfrog/smartfrog/servers/node01
JAVA: /home/mlinhard/dev/software/jdk1.6.0_37/bin/java
JAVA_OPTS: -Djava.managed.server.id=p3MXeYznB29SpGQJ -server -Xms256m -Xmx256m -XX:MaxPermSize=128m -XX:MaxDirectMemorySize=64m -XX:+UseLargePages -Dsun.nio.ch.bugLevel= -Djava.net.preferIPv4Stack=true -XX:NewRatio=3 -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -Dorg.jboss.qa.threadpoolwatchdog.output=/home/mlinhard/dev/projects/perf/smartfrog/smartfrog/tpstats/node01.csv
=========================================================================
Java HotSpot(TM) Server VM warning: Failed to reserve shared memory (errno = 22).
[0m14:03:31,945 INFO [org.jboss.modules] (main) JBoss Modules version 1.2.0.CR1
[0m[0m14:03:32,331 INFO [org.jboss.msc] (main) JBoss MSC version 1.0.4.GA
[0m[0m14:03:32,602 INFO [org.jboss.as] (MSC service thread 1-3) JBAS015899: JBoss Infinispan Server 5.3.0-SNAPSHOT (AS 7.2.0.Final) starting
[0m[33m14:03:34,794 WARN [org.jboss.as.server] (Controller Boot Thread) JBAS015883: No security realm defined for native management service; all access will be unrestricted.
[0m[0m14:03:34,799 INFO [org.xnio] (MSC service thread 1-3) XNIO Version 3.0.7.GA
[0m[0m14:03:34,825 INFO [org.xnio.nio] (MSC service thread 1-3) XNIO NIO Implementation Version 3.0.7.GA
[0m[0m14:03:34,862 INFO [org.jboss.remoting] (MSC service thread 1-3) JBoss Remoting version 3.2.14.GA
[0m14:03:34,957 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 15) JBAS010280: Activating Infinispan subsystem.
14:03:34,963 INFO [org.jboss.as.clustering.jgroups] (ServerService Thread Pool -- 16) JBAS010260: Activating JGroups subsystem.
14:03:35,021 INFO [org.jboss.as.naming] (ServerService Thread Pool -- 19) JBAS011800: Activating Naming Subsystem
14:03:35,037 INFO [org.jboss.as.security] (ServerService Thread Pool -- 22) JBAS013171: Activating Security Subsystem
14:03:35,145 INFO [org.jboss.as.security] (MSC service thread 1-1) JBAS013170: Current PicketBox version=4.0.15.Final
14:03:35,208 INFO [org.jboss.as.naming] (MSC service thread 1-3) JBAS011802: Starting Naming Service
14:03:35,219 INFO [org.jboss.as.remoting] (MSC service thread 1-4) JBAS017100: Listening on 192.168.11.101:9999
14:03:35,220 INFO [org.jboss.as.remoting] (MSC service thread 1-2) JBAS017100: Listening on 192.168.11.101:4447
14:03:35,231 INFO [org.jboss.as.connector.logging] (MSC service thread 1-2) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.15.Final)
14:03:35,782 WARN [org.jgroups.stack.Configurator] (MSC service thread 1-3) [JGRP00014] TP.enable_bundling has been deprecated: will be ignored as bundling is on by default
14:03:37,024 INFO [org.infinispan.server.endpoint] (MSC service thread 1-2) JDGS010000: HotRodServer starting
14:03:37,028 INFO [org.infinispan.server.endpoint] (MSC service thread 1-2) JDGS010001: HotRodServer listening on 192.168.11.101:11222
14:03:37,311 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000078: Starting JGroups Channel
14:03:37,326 WARN [org.jgroups.protocols.UDP] (MSC service thread 1-3) [JGRP00015] the send buffer of socket DatagramSocket was set to 640KB, but the OS only allocated 180.22KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
14:03:37,327 WARN [org.jgroups.protocols.UDP] (MSC service thread 1-3) [JGRP00015] the receive buffer of socket DatagramSocket was set to 20MB, but the OS only allocated 180.22KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
14:03:37,327 WARN [org.jgroups.protocols.UDP] (MSC service thread 1-3) [JGRP00015] the send buffer of socket MulticastSocket was set to 640KB, but the OS only allocated 180.22KB. This might lead to performance problems. Please set your max send buffer in the OS correctly (e.g. net.core.wmem_max on Linux)
14:03:37,328 WARN [org.jgroups.protocols.UDP] (MSC service thread 1-3) [JGRP00015] the receive buffer of socket MulticastSocket was set to 25MB, but the OS only allocated 180.22KB. This might lead to performance problems. Please set your max receive buffer in the OS correctly (e.g. net.core.rmem_max on Linux)
14:03:37,331 INFO [stdout] (MSC service thread 1-3)
14:03:37,331 INFO [stdout] (MSC service thread 1-3) -------------------------------------------------------------------
14:03:37,331 INFO [stdout] (MSC service thread 1-3) GMS: address=node01/default, cluster=default, physical address=192.168.11.101:55200
14:03:37,331 INFO [stdout] (MSC service thread 1-3) -------------------------------------------------------------------
14:03:40,972 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000094: Received new cluster view: [node02/default|1] [node02/default, node01/default]
14:03:41,135 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-3) ISPN000079: Cache local address is node01/default, physical addresses are [192.168.11.101:55200]
14:03:41,139 INFO [org.infinispan.factories.GlobalComponentRegistry] (MSC service thread 1-3) ISPN000128: Infinispan version: Infinispan 'Tactical Nuclear Penguin' 5.3.0-SNAPSHOT
14:03:41,310 INFO [org.infinispan.jmx.CacheJmxRegistration] (MSC service thread 1-3) ISPN000031: MBeans were successfully registered to the platform MBean server.
14:03:41,503 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-3) JBAS010281: Started testCache cache from default container
14:03:41,647 INFO [org.infinispan.jmx.CacheJmxRegistration] (MSC service thread 1-2) ISPN000031: MBeans were successfully registered to the platform MBean server.
14:03:41,702 INFO [org.jboss.as.clustering.infinispan] (MSC service thread 1-2) JBAS010281: Started ___hotRodTopologyCache cache from default container
14:03:41,873 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss Infinispan Server 5.3.0-SNAPSHOT (AS 7.2.0.Final) started in 10819ms - Started 80 of 107 services (27 services are passive or on-demand)
{code}
> Logging produces strange beginning of lines
> -------------------------------------------
>
> Key: ISPN-3081
> URL: https://issues.jboss.org/browse/ISPN-3081
> Project: Infinispan
> Issue Type: Bug
> Components: Server
> Affects Versions: 5.3.0.Alpha1
> Reporter: Michal Linhard
> Assignee: Tristan Tarrant
>
> This is what I get on the console when running infinispan-server-5.3.0-SNAPSHOT
> {code}
> [0m06:38:12,718 INFO [org.jboss.modules] (main) JBoss Modules version 1.2.0.CR1
> [0m[0m06:38:13,282 INFO [org.jboss.msc] (main) JBoss MSC version 1.0.4.GA
> [0m[0m06:38:13,486 INFO [org.jboss.as] (MSC service thread 1-7) JBAS015899: JBoss Infinispan Server 5.3.0-SNAPSHOT (AS 7.2.0.Final) starting
> [0m[31m06:38:14,687 ERROR [org.jboss.as.server] (Controller Boot Thread) JBAS015956: Caught exception during boot: org.jboss.as.controller.persistence.ConfigurationPersistenceException: JBAS014676: Failed to parse configuration
> ..
> {code}
> configuration:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-perf-cs-client-s...
> whole logs:
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jdg-perf-cs-client-s...
--
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, 1 month
[JBoss JIRA] (ISPN-3010) Cache GET operation retrieves a Class instance instead of expected type
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3010?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3010:
--------------------------------
Priority: Major (was: Critical)
> Cache GET operation retrieves a Class instance instead of expected type
> -----------------------------------------------------------------------
>
> Key: ISPN-3010
> URL: https://issues.jboss.org/browse/ISPN-3010
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.5.Final
> Reporter: Sanne Grinovero
> Assignee: Mircea Markus
> Labels: stable_embedded_query
> Fix For: 5.3.0.Beta2
>
>
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/hibernate-search-mast...
> {quote}
> Error Message
> HSEARCH000103: Unable to initialize IndexManager emails
> Stacktrace
> org.hibernate.search.SearchException: HSEARCH000103: Unable to initialize IndexManager emails
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:230)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.buildEntityIndexBinding(IndexManagerHolder.java:102)
> at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:414)
> at org.hibernate.search.spi.SearchFactoryBuilder.buildNewSearchFactory(SearchFactoryBuilder.java:222)
> at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:146)
> at org.hibernate.search.event.impl.FullTextIndexEventListener.initialize(FullTextIndexEventListener.java:130)
> at org.hibernate.search.hcore.impl.HibernateSearchIntegrator.integrate(HibernateSearchIntegrator.java:83)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:303)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1750)
> at org.hibernate.search.test.util.FullTextSessionBuilder.build(FullTextSessionBuilder.java:182)
> at org.hibernate.search.infinispan.StoredIndexTest.startNode(StoredIndexTest.java:121)
> at org.hibernate.search.infinispan.StoredIndexTest.testRestartingNode(StoredIndexTest.java:53)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Caused by: java.lang.ClassCastException: java.lang.Class cannot be cast to [B
> at org.infinispan.lucene.SingleChunkIndexInput.<init>(SingleChunkIndexInput.java:49)
> at org.infinispan.lucene.InfinispanDirectory.openInput(InfinispanDirectory.java:290)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:620)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:554)
> at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:359)
> at org.apache.lucene.index.IndexReader.indexExists(IndexReader.java:1099)
> at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:155)
> at org.hibernate.search.infinispan.impl.InfinispanDirectoryProvider.start(InfinispanDirectoryProvider.java:103)
> at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:104)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:227)
> ... 42 more
> {quote}
--
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, 1 month
[JBoss JIRA] (ISPN-3010) Cache GET operation retrieves a Class instance instead of expected type
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3010?page=com.atlassian.jira.plugin.... ]
Mircea Markus commented on ISPN-3010:
-------------------------------------
reducing the prio as this is a window only failure.
> Cache GET operation retrieves a Class instance instead of expected type
> -----------------------------------------------------------------------
>
> Key: ISPN-3010
> URL: https://issues.jboss.org/browse/ISPN-3010
> Project: Infinispan
> Issue Type: Bug
> Affects Versions: 5.2.5.Final
> Reporter: Sanne Grinovero
> Assignee: Mircea Markus
> Labels: stable_embedded_query
> Fix For: 5.3.0.Beta2
>
>
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/hibernate-search-mast...
> {quote}
> Error Message
> HSEARCH000103: Unable to initialize IndexManager emails
> Stacktrace
> org.hibernate.search.SearchException: HSEARCH000103: Unable to initialize IndexManager emails
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:230)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.buildEntityIndexBinding(IndexManagerHolder.java:102)
> at org.hibernate.search.spi.SearchFactoryBuilder.initDocumentBuilders(SearchFactoryBuilder.java:414)
> at org.hibernate.search.spi.SearchFactoryBuilder.buildNewSearchFactory(SearchFactoryBuilder.java:222)
> at org.hibernate.search.spi.SearchFactoryBuilder.buildSearchFactory(SearchFactoryBuilder.java:146)
> at org.hibernate.search.event.impl.FullTextIndexEventListener.initialize(FullTextIndexEventListener.java:130)
> at org.hibernate.search.hcore.impl.HibernateSearchIntegrator.integrate(HibernateSearchIntegrator.java:83)
> at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:303)
> at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1750)
> at org.hibernate.search.test.util.FullTextSessionBuilder.build(FullTextSessionBuilder.java:182)
> at org.hibernate.search.infinispan.StoredIndexTest.startNode(StoredIndexTest.java:121)
> at org.hibernate.search.infinispan.StoredIndexTest.testRestartingNode(StoredIndexTest.java:53)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:41)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
> at org.junit.runners.BlockJUnit4ClassRunner.runNotIgnored(BlockJUnit4ClassRunner.java:79)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:71)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:49)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
> at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:31)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:236)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:134)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:113)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
> at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
> at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:103)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:74)
> Caused by: java.lang.ClassCastException: java.lang.Class cannot be cast to [B
> at org.infinispan.lucene.SingleChunkIndexInput.<init>(SingleChunkIndexInput.java:49)
> at org.infinispan.lucene.InfinispanDirectory.openInput(InfinispanDirectory.java:290)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:620)
> at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:554)
> at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:359)
> at org.apache.lucene.index.IndexReader.indexExists(IndexReader.java:1099)
> at org.hibernate.search.store.impl.DirectoryProviderHelper.initializeIndexIfNeeded(DirectoryProviderHelper.java:155)
> at org.hibernate.search.infinispan.impl.InfinispanDirectoryProvider.start(InfinispanDirectoryProvider.java:103)
> at org.hibernate.search.indexes.impl.DirectoryBasedIndexManager.initialize(DirectoryBasedIndexManager.java:104)
> at org.hibernate.search.indexes.impl.IndexManagerHolder.createIndexManager(IndexManagerHolder.java:227)
> ... 42 more
> {quote}
--
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, 1 month
[JBoss JIRA] (ISPN-3051) Allow configuring the number of segments per node
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3051?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3051:
--------------------------------
Description:
This should allow for the following use cases:
- a node to take more load
- a node to take no load
A simple way for specifying this would be to configure a load factor per node, e.g. more powerful machine would be 2*x and that would mean that it would take twice the load of an "ordinary" machine in the cluster.
was:
Some clusters requires to use embedded caches to distributed its data. In the current state, Infinispan does not allow to access this kind of clusters without being a full member of the cluster, 'sharing' memory space and CPU time.
The requested feature is to allow remote/client cache members in an embedded configuration (like the hotrod _RemoteCache_)
*SUGGESTION*
* *For the data:* Exclude marked/flagged hash spaces (nodes) from the consistent hash function.
* *For remote execution:* is up to you guys ...
> Allow configuring the number of segments per node
> -------------------------------------------------
>
> Key: ISPN-3051
> URL: https://issues.jboss.org/browse/ISPN-3051
> Project: Infinispan
> Issue Type: Feature Request
> Components: Distributed Cache
> Reporter: Guillermo GARCIA OCHOA
> Assignee: Dan Berindei
>
> This should allow for the following use cases:
> - a node to take more load
> - a node to take no load
> A simple way for specifying this would be to configure a load factor per node, e.g. more powerful machine would be 2*x and that would mean that it would take twice the load of an "ordinary" machine in the cluster.
--
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, 1 month
[JBoss JIRA] (ISPN-3051) Allow configuring the number of segments per node
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3051?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3051:
--------------------------------
Summary: Allow configuring the number of segments per node (was: Allow embedded caches with no local storage (remote/client for embedded caches))
> Allow configuring the number of segments per node
> -------------------------------------------------
>
> Key: ISPN-3051
> URL: https://issues.jboss.org/browse/ISPN-3051
> Project: Infinispan
> Issue Type: Feature Request
> Components: Distributed Cache
> Reporter: Guillermo GARCIA OCHOA
> Assignee: Mircea Markus
>
> Some clusters requires to use embedded caches to distributed its data. In the current state, Infinispan does not allow to access this kind of clusters without being a full member of the cluster, 'sharing' memory space and CPU time.
> The requested feature is to allow remote/client cache members in an embedded configuration (like the hotrod _RemoteCache_)
> *SUGGESTION*
> * *For the data:* Exclude marked/flagged hash spaces (nodes) from the consistent hash function.
> * *For remote execution:* is up to you guys ...
--
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, 1 month
[JBoss JIRA] (ISPN-3051) Allow configuring the number of segments per node
by Mircea Markus (JIRA)
[ https://issues.jboss.org/browse/ISPN-3051?page=com.atlassian.jira.plugin.... ]
Mircea Markus updated ISPN-3051:
--------------------------------
Assignee: Dan Berindei (was: Mircea Markus)
> Allow configuring the number of segments per node
> -------------------------------------------------
>
> Key: ISPN-3051
> URL: https://issues.jboss.org/browse/ISPN-3051
> Project: Infinispan
> Issue Type: Feature Request
> Components: Distributed Cache
> Reporter: Guillermo GARCIA OCHOA
> Assignee: Dan Berindei
>
> Some clusters requires to use embedded caches to distributed its data. In the current state, Infinispan does not allow to access this kind of clusters without being a full member of the cluster, 'sharing' memory space and CPU time.
> The requested feature is to allow remote/client cache members in an embedded configuration (like the hotrod _RemoteCache_)
> *SUGGESTION*
> * *For the data:* Exclude marked/flagged hash spaces (nodes) from the consistent hash function.
> * *For remote execution:* is up to you guys ...
--
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, 1 month