[JBoss JIRA] Created: (ISPN-1293) Enable default lifespan/maxIdle values to be used by the Hot Rod server
by Galder Zamarreño (JIRA)
Enable default lifespan/maxIdle values to be used by the Hot Rod server
-----------------------------------------------------------------------
Key: ISPN-1293
URL: https://issues.jboss.org/browse/ISPN-1293
Project: Infinispan
Issue Type: Enhancement
Components: Cache Server
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 5.2.0.FINAL
Hot Rod clients should be able to tell the server that no lifespan/maxIdle value was given, and so that the server should use the default lifespan+maxIdle values set in configuration. This is not currently possible in v1 of the protocol and so requires a change of protocol.
This is the result of the investigation for ISPN-1285, and so when this is resolved:
1. Make sure you revert the javadoc added to ISPN-1285 to document the limitation
2. Enable and expand client/hotrod-client/src/test/java/org/infinispan/client/hotrod/ExpiryTest.java
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 9 months
[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
11 years, 9 months
[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"
/>
<!--
Network calls are synchronous.
-->
<sync replTimeout="20000"/>
</clustering>
<loaders
passivation="false"
shared="false"
preload="true">
<loader
class="org.infinispan.loaders.jdbc.stringbased.JdbcStringBasedCacheStore"
fetchPersistentState="true"
purgeOnStartup="false">
<!-- set to true for not first node in the cluster in testing/demo -->
<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>
<!--
<async enabled="false" />
-->
</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
11 years, 9 months
[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
11 years, 9 months
[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
11 years, 10 months