April 2012 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-1884) expose hibernate search search factory statistics jmx

by Mathieu Lachance (JIRA)

Mathieu Lachance created ISPN-1884: -------------------------------------- Summary: expose hibernate search search factory statistics jmx Key: ISPN-1884 URL: https://issues.jboss.org/browse/ISPN-1884 Project: Infinispan Issue Type: Feature Request Components: JMX, reporting and management Affects Versions: 5.1.1.FINAL Reporter: Mathieu Lachance Assignee: Manik Surtani it is possible to add jmx hook to obtain Hibernate Search SearchFactory Statistics by using this property : <indexing enabled="true" indexLocalOnly="true"> <properties> <property name="hibernate.search.jmx_enabled" value="true" /> </properties> </indexing> tough this property does not allow multiple registration (one registration per cache). it would be nice to wrap the Statistics object from HibernateSearch into the actual cache object mbean. i guess the implementation could look like this : // get search factory statistics org.hibernate.search.stat.Statistics statistics = Search.getSearchManager(org.infinispan.Cache).getSearchFactory().getStatistics(); // wrap search factory statistics SearchFactoryStatisticMBean mbean = new SearchFactoryStatisticMBeanImpl(statistics); // expose mbean ManagementFactory.getPlatformMBeanServer().registerMBean(new ObjectName("..."), mbean); -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

6
15
0 / 0

[JBoss JIRA] Created: (ISPN-1174) Using an AsyncStore with passivating eviction creates a time window in which entries might not be found

by Sanne Grinovero (JIRA)

Using an AsyncStore with passivating eviction creates a time window in which entries might not be found ------------------------------------------------------------------------------------------------------- Key: ISPN-1174 URL: https://issues.jboss.org/browse/ISPN-1174 Project: Infinispan Issue Type: Bug Components: Eviction, Locking and Concurrency Affects Versions: 5.0.0.CR5 Reporter: Sanne Grinovero Assignee: Manik Surtani Fix For: 5.0.0.CR6 When loading from an AsyncStore we should check if the entry is not in process of being written to the underlying store (somewhere in the async queue), as at this point it was already removed from the container and if not yet written on the store it might not be found otherwise. See also http://infinispan.markmail.org/search/#query:%20from%3A%22Manik%20Surtani... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

4
19
0 / 0

[JBoss JIRA] (ISPN-1586) inconsistent cache data in replication cluster with local (not shared) cache store

by dex chen (Created) (JIRA)

inconsistent cache data in replication cluster with local (not shared) cache store ---------------------------------------------------------------------------------- Key: ISPN-1586 URL: https://issues.jboss.org/browse/ISPN-1586 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.0.0.FINAL Environment: ISPN 5.0.0. Final and ISPN 5.1 sanpshot Java 1.7 Linux Cent OS Reporter: dex chen Assignee: Manik Surtani I rerun my test (an embedded ISPN cluser) with ISPN 5.0.0. final and 5.1 Sanpshot code. It is configured in "replication", using local cache store, and preload=true, purgeOnStartup=false .. (see the whole config below). I will get the inconsistent data among the nodes in the following scenario: 1) start 2 node cluster 2) after the cluster is formed, add some data to the cache k1-->v1 k2-->v2 I will see the data replication working perfectly at this point. 3) bring node 2 down 4) delete entry k1-->v1 through node1 Note: At this point, on the local (persistent) cache store on the node2 have 2 entries. 5) start node2, and wait to join the cluster 6) after state merging, you will see now that node1 has 1 entry and nod2 has 2 entries. I am expecting that the data should be consistent across the cluster. Here is the infinispan config: <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="demoCluster" machineId="node1" rackId="r1" nodeName="dexlaptop" > <properties> <property name="configurationFile" value="./jgroups-tcp.xml" /> </properties> </transport> <globalJmxStatistics enabled="true"/> </global> <default> <locking isolationLevel="READ_COMMITTED" lockAcquisitionTimeout="20000" writeSkewCheck="false" concurrencyLevel="5000" useLockStriping="false" /> <jmxStatistics enabled="true"/> <clustering mode="replication"> <stateRetrieval timeout="240000" fetchInMemoryState="true" alwaysProvideInMemoryState="false" />  <sync replTimeout="20000"/> </clustering> <loaders passivation="false" shared="false" preload="true"> <loader class="org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore" fetchPersistentState="true" purgeOnStartup="false">  <properties> <property name="stringsTableNamePrefix" value="ISPN_STRING_TABLE"/> <property name="idColumnName" value="ID_COLUMN"/> <property name="dataColumnName" value="DATA_COLUMN"/> <property name="timestampColumnName" value="TIMESTAMP_COLUMN"/> <property name="timestampColumnType" value="BIGINT"/> <property name="connectionFactoryClass" value="org.infinispan.loaders.jdbc.connectionfactory.PooledConnectionFactory"/> <property name="connectionUrl" value="jdbc:h2:file:/var/tmp/h2cachestore;DB_CLOSE_DELAY=-1"/> <property name="userName" value="sa"/> <property name="driverClass" value="org.h2.Driver"/> <property name="idColumnType" value="VARCHAR(255)"/> <property name="dataColumnType" value="BINARY"/> <property name="dropTableOnExit" value="false"/> <property name="createTableOnStart" value="true"/> </properties>  </loader> </loaders> </default> </infinispan> Basically, current ISPN implementation in state transfer will result in data insistence among nodes in replication mode and each node has local cache store. I found code BaseStateTransferManagerImpl's applyState code does not remove stale data in the local cache store and result in inconsistent data when joins a cluster: Here is the code snipt of applyState(): public void applyState(Collection<InternalCacheEntry> state, Address sender, int viewId) throws InterruptedException { ..... for (InternalCacheEntry e : state) { InvocationContext ctx = icc.createInvocationContext(false, 1); // locking not necessary as during rehashing we block all transactions ctx.setFlags(CACHE_MODE_LOCAL, SKIP_CACHE_LOAD, SKIP_REMOTE_LOOKUP, SKIP_SHARED_CACHE_STORE, SKIP_LOCKING, SKIP_OWNERSHIP_CHECK); try { PutKeyValueCommand put = cf.buildPutKeyValueCommand(e.getKey(), e.getValue(), e.getLifespan(), e.getMaxIdle(), ctx.getFlags()); interceptorChain.invoke(ctx, put); } catch (Exception ee) { log.problemApplyingStateForKey(ee.getMessage(), e.getKey()); } } ... } As we can see that the code bascically try to add all data entryies got from the cluster (other node). Hence, it does not know any previous entries were deleted from the cluster which exist in its local cache store. This is exactly my test case (my confiuration is that each node has its own cache store and in replication mode). To fix this, we need to delete any entries from the local cache/cache store which no longer exist in the new state. I modified the above method by adding the following code before put loop, and it fixed the problem in my configuration: //Remove entries which no loger exist in the new state from local cache/cache store for (InternalCacheEntry ie: dataContainer.entrySet()) { if (!state.contains(ie)) { log.debug("Try to delete local store entry no loger exists in the new state: " + ie.getKey()); InvocationContext ctx = icc.createInvocationContext(false, 1); // locking not necessary as during rehashing we block all transactions ctx.setFlags(CACHE_MODE_LOCAL, SKIP_CACHE_LOAD, SKIP_REMOTE_LOOKUP, SKIP_SHARED_CACHE_STORE, SKIP_LOCKING, SKIP_OWNERSHIP_CHECK); try { RemoveCommand remove = cf.buildRemoveCommand(ie.getKey(), ie.getValue(), ctx.getFlags()); interceptorChain.invoke(ctx, remove); dataContainer.remove(ie.getKey()); } catch (Exception ee) { log.error("failed to delete local store entry", ee); } } } ... Obvious, the above "fix" is based on assumption/configure that dataContainer will have all local entries, i.e., preload=true, no enviction replication. The real fix, I think, we need delegate the syncState(state) to cache store impl, where we can check the configurations and do the right thing. For example, in the cache store impl, we can calculate the changes based on local data and new state, and apply the changes there. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

12
25
0 / 0

[JBoss JIRA] (ISPN-1830) L1: On topology changes we should propagate the key requestors information to the new owners

by Dan Berindei (JIRA)

Dan Berindei created ISPN-1830: ---------------------------------- Summary: L1: On topology changes we should propagate the key requestors information to the new owners Key: ISPN-1830 URL: https://issues.jboss.org/browse/ISPN-1830 Project: Infinispan Issue Type: Task Components: Distributed Cache Affects Versions: 5.1.0.FINAL Reporter: Dan Berindei Assignee: Manik Surtani Fix For: 5.2.0.FINAL I think we are losing information about where a key needs to be invalidated when a node changes from owner to non-owner (e.g. because another node joined): * We lose the list of requestors stored on this node. Even if all ClusteredGetCommands reached all the current owners (which we are about to change with ISPN-825), once all the current owners leave the new owners will not know about this node's old requestors. * We don't add ourselves as a requestor for the key on the new owners when we invalidate the entry and move it to L1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

2
13
0 / 0

[JBoss JIRA] (ISPN-1797) Implement MongoDB based cache store

by Andrew Pushkin (JIRA)

Andrew Pushkin created ISPN-1797: ------------------------------------ Summary: Implement MongoDB based cache store Key: ISPN-1797 URL: https://issues.jboss.org/browse/ISPN-1797 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores Affects Versions: 5.1.0.FINAL Reporter: Andrew Pushkin Assignee: Manik Surtani I have an implementation to submit if you are interested. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

7
17
0 / 0

[JBoss JIRA] Created: (ISPN-517) CacheStore impl based on LibIO, as per HornetQ's disk spooling

by Manik Surtani (JIRA)

CacheStore impl based on LibIO, as per HornetQ's disk spooling -------------------------------------------------------------- Key: ISPN-517 URL: https://jira.jboss.org/browse/ISPN-517 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores Reporter: Manik Surtani Fix For: 5.1.0.BETA1, 5.1.0.Final HornetQ uses Linux LibIO API to create a very fast and efficient disk spooling mechanism. Should look into the possibility of creating a CacheStore around this. -- 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

12 years, 1 month

5
11
0 / 0

[JBoss JIRA] (ISPN-1965) Some entries not available during view change

by Michal Linhard (JIRA)

Michal Linhard created ISPN-1965: ------------------------------------ Summary: Some entries not available during view change Key: ISPN-1965 URL: https://issues.jboss.org/browse/ISPN-1965 Project: Infinispan Issue Type: Bug Affects Versions: 5.1.3.FINAL Reporter: Michal Linhard Assignee: Manik Surtani In the 4 node, dist mode, num-owners=2, elasticity test http://www.qa.jboss.com/~mlinhard/hyperion/run44-elas-dist/ there is a cca 90 sec period of time where clients get null responses to GET requests on entries that should exist in the cache. first occurence: hyperion1139.log 05:31:01,202 286.409 last occurence: hyperion1135.log 05:32:45,441 390.648 total occurence count: (in all 19 driver nodes) 152241 (this doesn't mean it happens for 152K keys, because each key is retried after erroneous attempt) data doesn't seem to be lost, because these errors cease after a while and number of entries returns back to normal (see cache_entries.csv) this happens approximately in the period between node0001 is killed and cluster {node0002 - node0004} is formed (and shortly after). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

3
23
0 / 0

[JBoss JIRA] (ISPN-1954) Wrong ServerWorker thread name in Hot rod server

by Michal Linhard (JIRA)

Michal Linhard created ISPN-1954: ------------------------------------ Summary: Wrong ServerWorker thread name in Hot rod server Key: ISPN-1954 URL: https://issues.jboss.org/browse/ISPN-1954 Project: Infinispan Issue Type: Bug Components: Cache Server Reporter: Michal Linhard Assignee: Galder Zamarreño Priority: Minor When debugging/profiling EDG, we're seeing HotRod server calls being executed by MemcachedServerWorker threads. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

4
18
0 / 0

[JBoss JIRA] Created: (ISPN-143) Security needs to be considered

by Manik Surtani (JIRA)

Security needs to be considered ------------------------------- Key: ISPN-143 URL: https://jira.jboss.org/jira/browse/ISPN-143 Project: Infinispan Issue Type: Feature Request Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.1.0.CR1, 4.1.0.GA We need to consider security for Infinispan. Storing state on the cloud only makes sense if the data can be secured. Both encryption and authentication need to be considered, and all levels (wire protocol, cache store, public API, server module, etc) need to be taken in to consideration. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

3
6
0 / 0

[JBoss JIRA] (ISPN-1996) Failed to prepare view exceptions

by dex chen (JIRA)

dex chen created ISPN-1996: ------------------------------ Summary: Failed to prepare view exceptions Key: ISPN-1996 URL: https://issues.jboss.org/browse/ISPN-1996 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.1.3.FINAL Environment: ISPN 5.1.3.Final; Java 7; Cent OS 3-node cluster in replication mode using jgroups-tcp config. Reporter: dex chen Assignee: Manik Surtani I saw lot (re-curring) cache view exceptions (below) when I start up a 3 node cluster. I am running ISPN 5.1.3 final with replication mode, and jgroup-tcp config. In this case, I start first 2 nodes first, and later try to join the 3rd node. ======================================= 2012-04-10/12:13:45.714/MDT [CacheViewInstaller-3,portal1.net-1609] ERROR org.infinispan.cacheviews.CacheViewsManagerImpl[263] - ISPN000172: Failed to prepare view CacheView{viewId=832, members=[portal1.net-1609, portal2.net-11982]} for cache ispn-cipherkey, rolling back to view CacheView{viewId=831, members=[portal1.net-1609]} java.util.concurrent.ExecutionException: org.infinispan.CacheException: java.lang.IllegalStateException: Cannot prepare new view CacheView{viewId=832, members=[portal1.net-1609, portal2.net-11982]} on cache ispn-cipherkey, we have already committed view CacheView{viewId=844, members=[]} at java.util.concurrent.FutureTask$Sync.innerGet(FutureTask.java:262) at java.util.concurrent.FutureTask.get(FutureTask.java:119) at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterPrepareView(CacheViewsManagerImpl.java:318) at org.infinispan.cacheviews.CacheViewsManagerImpl.clusterInstallView(CacheViewsManagerImpl.java:249) at org.infinispan.cacheviews.CacheViewsManagerImpl$ViewInstallationTask.call(CacheViewsManagerImpl.java:875) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) Caused by: org.infinispan.CacheException: java.lang.IllegalStateException: Cannot prepare new view CacheView{viewId=832, members=[portal1.net-1609, portal2.net-11982]} on cache ispn-cipherkey, we have already committed view CacheView{viewId=844, members=[]} at org.infinispan.util.Util.rewrapAsCacheException(Util.java:524) at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.invokeRemoteCommand(CommandAwareRpcDispatcher.java:172) at org.infinispan.remoting.transport.jgroups.JGroupsTransport.invokeRemotely(JGroupsTransport.java:488) at org.infinispan.cacheviews.CacheViewsManagerImpl$2.call(CacheViewsManagerImpl.java:302) at org.infinispan.cacheviews.CacheViewsManagerImpl$2.call(CacheViewsManagerImpl.java:299) ... 5 more Caused by: java.lang.IllegalStateException: Cannot prepare new view CacheView{viewId=832, members=[portal1.net-1609, portal2.net-11982]} on cache ispn-cipherkey, we have already committed view CacheView{viewId=844, members=[]} at org.infinispan.cacheviews.CacheViewInfo.prepareView(CacheViewInfo.java:107) at org.infinispan.cacheviews.CacheViewsManagerImpl.handlePrepareView(CacheViewsManagerImpl.java:481) at org.infinispan.commands.control.CacheViewControlCommand.perform(CacheViewControlCommand.java:125) at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:95) at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:221) at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:201) 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:543) at org.jgroups.JChannel.up(JChannel.java:716) at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1026) 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:882) 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:595) at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:143) at org.jgroups.protocols.FD.up(FD.java:273) at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:282) 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:1174) at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1722) at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1704) ... 3 more 2012-04-10/12:13:46.715/MDT -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 2 months

5
8
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues April 2012