[JBoss JIRA] Created: (ISPN-1220) Add classloader hooks to cache listener events
by Paul Ferraro (JIRA)
Add classloader hooks to cache listener events
----------------------------------------------
Key: ISPN-1220
URL: https://issues.jboss.org/browse/ISPN-1220
Project: Infinispan
Issue Type: Enhancement
Components: Listeners
Affects Versions: 5.0.0.CR7
Reporter: Paul Ferraro
Assignee: Manik Surtani
This issue seeks to extend the classloading api changes made in ISPN-1096 to the Event API. Currently, cache listener events do not allow a classloader to be specified to perform any necessary deserialization triggered by the getKey(), getValue() methods. Can the event api be enhanced such that calls to getKey(), getValue() use a specific classloader?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years
[JBoss JIRA] (ISPN-1568) Clustered Query fail when hibernate search not fully initialized
by Mathieu Lachance (Created) (JIRA)
Clustered Query fail when hibernate search not fully initialized
----------------------------------------------------------------
Key: ISPN-1568
URL: https://issues.jboss.org/browse/ISPN-1568
Project: Infinispan
Issue Type: Bug
Components: Querying, RPC
Affects Versions: 5.1.0.BETA5
Reporter: Mathieu Lachance
Assignee: Sanne Grinovero
Hi,
I'm running into this issue when doing a clustered query in distribution mode :
org.infinispan.CacheException: org.hibernate.search.SearchException: Not a mapped entity (don't forget to add @Indexed): class com.XXX.Client
at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:166)
at org.infinispan.remoting.rpc.RpcManagerImpl.invokeRemotely(RpcManagerImpl.java:181)
at org.infinispan.query.clustered.ClusteredQueryInvoker.broadcast(ClusteredQueryInvoker.java:113)
at org.infinispan.query.clustered.ClusteredCacheQueryImpl.broadcastQuery(ClusteredCacheQueryImpl.java:115)
at org.infinispan.query.clustered.ClusteredCacheQueryImpl.iterator(ClusteredCacheQueryImpl.java:90)
at org.infinispan.query.impl.CacheQueryImpl.iterator(CacheQueryImpl.java:129)
at org.infinispan.query.clustered.ClusteredCacheQueryImpl.list(ClusteredCacheQueryImpl.java:133)
at com.XXX.DistributedCache.cacheQueryList(DistributedCache.java:313)
at com.XXX.DistributedCache.cacheQueryList(DistributedCache.java:274)
at com.XXX.ClientCache.getClientsByServerId(ClientCache.java:127)
at com.XXX.ClientManager.getClientsByServerId(ClientManager.java:157)
at com.XXX$PingClient.run(PlayerBll.java:890)
at java.util.TimerThread.mainLoop(Timer.java:512)
at java.util.TimerThread.run(Timer.java:462)
Caused by: org.hibernate.search.SearchException: Not a mapped entity (don't forget to add @Indexed): class com.XXX.Client
at org.hibernate.search.query.engine.impl.HSQueryImpl.buildSearcher(HSQueryImpl.java:549)
at org.hibernate.search.query.engine.impl.HSQueryImpl.buildSearcher(HSQueryImpl.java:493)
at org.hibernate.search.query.engine.impl.HSQueryImpl.queryDocumentExtractor(HSQueryImpl.java:292)
at org.infinispan.query.clustered.commandworkers.CQCreateEagerQuery.perform(CQCreateEagerQuery.java:44)
at org.infinispan.query.clustered.ClusteredQueryCommand.perform(ClusteredQueryCommand.java:135)
at org.infinispan.query.clustered.ClusteredQueryCommand.perform(ClusteredQueryCommand.java:129)
at org.infinispan.remoting.InboundInvocationHandlerImpl.handleInternal(InboundInvocationHandlerImpl.java:170)
at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithWaitForBlocks(InboundInvocationHandlerImpl.java:179)
at org.infinispan.remoting.InboundInvocationHandlerImpl.handleWithRetry(InboundInvocationHandlerImpl.java:208)
at org.infinispan.remoting.InboundInvocationHandlerImpl.handle(InboundInvocationHandlerImpl.java:156)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.executeCommand(CommandAwareRpcDispatcher.java:162)
at org.infinispan.remoting.transport.jgroups.CommandAwareRpcDispatcher.handle(CommandAwareRpcDispatcher.java:141)
at org.jgroups.blocks.RequestCorrelator.handleRequest(RequestCorrelator.java:447)
at org.jgroups.blocks.RequestCorrelator.receiveMessage(RequestCorrelator.java:354)
at org.jgroups.blocks.RequestCorrelator.receive(RequestCorrelator.java:230)
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:556)
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:418)
at org.jgroups.protocols.pbcast.GMS.up(GMS.java:881)
at org.jgroups.protocols.pbcast.StreamingStateTransfer.up(StreamingStateTransfer.java:262)
at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:244)
at org.jgroups.protocols.UNICAST.up(UNICAST.java:332)
at org.jgroups.protocols.pbcast.NAKACK.handleMessage(NAKACK.java:700)
at org.jgroups.protocols.pbcast.NAKACK.up(NAKACK.java:561)
at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:140)
at org.jgroups.protocols.FD.up(FD.java:273)
at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:284)
at org.jgroups.protocols.MERGE2.up(MERGE2.java:205)
at org.jgroups.protocols.Discovery.up(Discovery.java:354)
at org.jgroups.protocols.TP.passMessageUp(TP.java:1174)
at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1709)
at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1691)
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:662)
With the use of the following
cache configuration :
<infinispan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:infinispan:config:5.1 http://www.infinispan.org/schemas/infinispan-config-5.1.xsd"
xmlns="urn:infinispan:config:5.1">
<global>
<transport clusterName="XXX-cluster" machineId="XXX" siteId="XXX" rackId="XXX" distributedSyncTimeout="15000">
<properties>
<property name="configurationFile" value="jgroups-jdbc-ping.xml" />
</properties>
</transport>
</global>
<default>
<transaction
cacheStopTimeout="30000"
transactionManagerLookupClass="org.infinispan.transaction.lookup.DummyTransactionManagerLookup"
lockingMode="PESSIMISTIC"
useSynchronization="true"
transactionMode="TRANSACTIONAL"
syncCommitPhase="true"
syncRollbackPhase="false"
>
<recovery enabled="false" />
</transaction>
<clustering mode="local" />
<indexing enabled="true" indexLocalOnly="true">
<properties>
<property name="hibernate.search.default.directory_provider" value="ram" />
</properties>
</indexing>
</default>
<namedCache name="XXX-Client">
<transaction
cacheStopTimeout="30000"
transactionManagerLookupClass="org.infinispan.transaction.lookup.DummyTransactionManagerLookup"
lockingMode="PESSIMISTIC"
useSynchronization="true"
transactionMode="TRANSACTIONAL"
syncCommitPhase="true"
syncRollbackPhase="false"
>
<recovery enabled="false" />
</transaction>
<invocationBatching enabled="false" />
<loaders passivation="false" />
<clustering mode="distribution" >
<sync replTimeout="15000" />
<stateRetrieval
timeout="240000"
retryWaitTimeIncreaseFactor="2"
numRetries="5"
maxNonProgressingLogWrites="100"
fetchInMemoryState="false"
logFlushTimeout="60000"
alwaysProvideInMemoryState="false"
/>
</clustering>
<storeAsBinary enabled="false" storeValuesAsBinary="true" storeKeysAsBinary="true" />
<deadlockDetection enabled="true" spinDuration="100" />
<eviction strategy="NONE" threadPolicy="PIGGYBACK" maxEntries="-1" />
<jmxStatistics enabled="true" />
<locking writeSkewCheck="false" lockAcquisitionTimeout="10000" isolationLevel="READ_COMMITTED" useLockStriping="false" concurrencyLevel="32" />
<expiration wakeUpInterval="60000" lifespan="-1" maxIdle="3000000" />
</namedCache>
</infinispan>
and jgroups configuration :
<config xmlns="urn:org:jgroups"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:org:jgroups file:schema/JGroups-3.0.xsd">
<TCP
bind_port="7800"
loopback="true"
port_range="30"
recv_buf_size="20000000"
send_buf_size="640000"
discard_incompatible_packets="true"
max_bundle_size="64000"
max_bundle_timeout="30"
enable_bundling="true"
use_send_queues="true"
sock_conn_timeout="300"
enable_diagnostics="false"
thread_pool.enabled="true"
thread_pool.min_threads="2"
thread_pool.max_threads="30"
thread_pool.keep_alive_time="5000"
thread_pool.queue_enabled="false"
thread_pool.queue_max_size="100"
thread_pool.rejection_policy="Discard"
oob_thread_pool.enabled="true"
oob_thread_pool.min_threads="2"
oob_thread_pool.max_threads="30"
oob_thread_pool.keep_alive_time="5000"
oob_thread_pool.queue_enabled="false"
oob_thread_pool.queue_max_size="100"
oob_thread_pool.rejection_policy="Discard"
/>
<JDBC_PING
connection_url="jdbc:jtds:sqlserver://XXX;databaseName=XXX"
connection_username="XXX"
connection_password="XXX"
connection_driver="net.sourceforge.jtds.jdbcx.JtdsDataSource"
initialize_sql=""
/>
<MERGE2 max_interval="30000"
min_interval="10000"/>
<FD_SOCK/>
<FD timeout="3000" max_tries="3"/>
<VERIFY_SUSPECT timeout="1500"/>
<pbcast.NAKACK
use_mcast_xmit="false"
retransmit_timeout="300,600,1200,2400,4800"
discard_delivered_msgs="false"/>
<UNICAST timeout="300,600,1200"/>
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
max_bytes="400000"/>
<pbcast.STATE />
<pbcast.GMS print_local_addr="false" join_timeout="7000" view_bundling="true"/>
<UFC max_credits="2000000" min_threshold="0.10"/>
<MFC max_credits="2000000" min_threshold="0.10"/>
<FRAG2 frag_size="60000"/>
</config>
Tough my entity is well annotated.
Here's the steps to reproduce :
1. boot node A completly.
2. boot node B, make all caches start (DefaultCacheManager::startCaches(...)), then breakpoint just after.
3. on node A, do a clustered query.
4. node A fail because node b has not been fully initialized.
Here's how I do my query :
private CacheQuery getClusteredNonClusteredQuery(Query query)
{
CacheQuery cacheQuery;
if (useClusteredQuery)
{
cacheQuery = searchManager.getClusteredQuery(query, cacheValueClass);
}
else
{
cacheQuery = searchManager.getQuery(query, cacheValueClass);
}
return cacheQuery;
}
I've tried also without supplying any "cacheValueClass" without any success.
One ugly "workaround" I've found is, to as soon as possible in the application, to force the local insertion and removal of one dummy key and value to force initialization of the search manager like :
cache.getAdvancedCache().withFlags(Flag.CACHE_MODE_LOCAL).put("XXX", new Client("XXX");
cache.getAdvancedCache().withFlags(Flag.CACHE_MODE_LOCAL).remove("XXX");
Tough this technique won't still garanty me that any clustered query will occur before.
I think the issue this might as well be related to issue : ISPN-627 Provision to get Cache from CacheManager.
Any idea or workaround ? Do you think by just adding a try catch and return an empty list could "fix" the problem ?
Thanks a lot,
--
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
[JBoss JIRA] (ISPN-1990) Preload sets the versions to null (repeatable read + write skew)
by Pedro Ruivo (JIRA)
Pedro Ruivo created ISPN-1990:
---------------------------------
Summary: Preload sets the versions to null (repeatable read + write skew)
Key: ISPN-1990
URL: https://issues.jboss.org/browse/ISPN-1990
Project: Infinispan
Issue Type: Bug
Components: Loaders and Stores
Environment: Java 6 (64bits)
Infinispan 5.2.0-SNAPSHOT
MacOS
Reporter: Pedro Ruivo
Assignee: Manik Surtani
I think I've spotted a issue when I use repeatable read with write skew check and I preload the cache.
I've made a test case to reproduce the bug. It can be found here [1].
The problem is that each keys preloaded is put in the container with version = null. When I try to commit a transaction, I get this exception:
java.lang.IllegalStateException: Entries cannot have null versions!
at
org.infinispan.container.entries.ClusteredRepeatableReadEntry.performWriteSkewCheck(ClusteredRepeatableReadEntry.java:44)
at
org.infinispan.transaction.WriteSkewHelper.performWriteSkewCheckAndReturnNewVersions(WriteSkewHelper.java:81)
at
org.infinispan.interceptors.locking.ClusteringDependentLogic$AllNodesLogic.createNewVersionsAndCheckForWriteSkews(ClusteringDependentLogic.java:133)
at
org.infinispan.interceptors.VersionedEntryWrappingInterceptor.visitPrepareCommand(VersionedEntryWrappingInterceptor.java:64)
I think that all info is in the test case, but if you need something let
me know.
Cheers,
Pedro
[1]
https://github.com/pruivo/infinispan/blob/issue_1/core/src/test/java/org/...
--
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
[JBoss JIRA] (ISPN-2240) Per-key lock container leads to superfluous TimeoutExceptions on concurrent access to same key
by Robert Stupp (JIRA)
Robert Stupp created ISPN-2240:
----------------------------------
Summary: Per-key lock container leads to superfluous TimeoutExceptions on concurrent access to same key
Key: ISPN-2240
URL: https://issues.jboss.org/browse/ISPN-2240
Project: Infinispan
Issue Type: Bug
Components: Locking and Concurrency
Affects Versions: 5.1.6.FINAL
Reporter: Robert Stupp
Assignee: Mircea Markus
Attachments: somehow.zip
Hi,
I've encountered a lot of TimeoutExceptions just running a load test against an infinispan cluster.
I tracked down the reason and found out, that the code in org.infinispan.util.concurrent.locks.containers.AbstractPerEntryLockContainer#releaseLock() causes these superfluous TimeoutExceptions.
A small test case (which just prints out timeouts, too late timeouts and "paints" a lot of dots to the console - more dots/second on the console means better throughput ;-)
In a short test I extended the class ReentrantPerEntryLockContainer and changed the implementation of releaseLock() as follows:
{noformat}
public void releaseLock(Object lockOwner, Object key) {
ReentrantLock l = locks.get(key);
if (l != null) {
if (!l.isHeldByCurrentThread())
throw new IllegalStateException("Lock for [" + key + "] not held by current thread " + Thread.currentThread());
while (l.isHeldByCurrentThread())
unlock(l, lockOwner);
if (!l.hasQueuedThreads())
locks.remove(key);
}
else
throw new IllegalStateException("No lock for [" + key + ']');
}
{noformat}
The main improvement is that locks are not removed from the concurrent map as long as other threads are waiting on that lock.
If the lock is removed from the map while other threads are waiting for it, they may run into timeouts and force TimeoutExceptions to the client.
The above methods "paints more dots per second" - means: it gives a better throughput for concurrent accesses to the same key.
The re-implemented method should also fix some replication timeout exceptions.
Please, please add this to 5.1.7, if possible.
--
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
12 years
[JBoss JIRA] (ISPN-2205) Design HotRod protocol version 1.2
by Dan Berindei (JIRA)
Dan Berindei created ISPN-2205:
----------------------------------
Summary: Design HotRod protocol version 1.2
Key: ISPN-2205
URL: https://issues.jboss.org/browse/ISPN-2205
Project: Infinispan
Issue Type: Task
Components: Cache Server
Affects Versions: 5.2.0.ALPHA2
Reporter: Dan Berindei
Assignee: Dan Berindei
Priority: Critical
Fix For: 5.2.0.FINAL
The consistent hash representation is changing in 5.2, and we need to modify the HotRod protocol to incorporate those changes. We preserved compatibility with 1.0/1.1 clients with a workaround on the server, but is not as efficient as it could be.
The new version could also incorporate fixes for older issues like ISPN-1293.
--
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
[JBoss JIRA] (ISPN-2192) Allow using Distributed Execution against any cache (not just clustered caches)
by Randall Hauch (JIRA)
Randall Hauch created ISPN-2192:
-----------------------------------
Summary: Allow using Distributed Execution against any cache (not just clustered caches)
Key: ISPN-2192
URL: https://issues.jboss.org/browse/ISPN-2192
Project: Infinispan
Issue Type: Enhancement
Affects Versions: 5.1.2.FINAL
Reporter: Randall Hauch
Assignee: Manik Surtani
Priority: Critical
It is often desirable to process all entries in a cache, and there is no reliable and consistent way to do that for any cache.
If a cache is clustered, then map-reduce can be used (although IIUC it currently doesn't guarantee to process non-materialized entries for caches that have a cache store) and distributed execution can be used (IIUC this will be called for all keys owned by the cluster node). However, neither of these work on local caches.
If a cache is local and there is no cache store, then apparently {{keySet()}} does work and allows a client to iterate over the keys in the local cache. However, if the local cache is configured to have a cache store, then the {{keySet()}} method will return only the keys for the materialized entries and does not return all of the keys in the cache. Of course, if a local cache does have a cache store, then its possible to obtain the keys using {{CacheLoader.loadAllKeys(...)}} (obviously this is probably not something a client should do).
In short, it should be possible to use Distributed Execution against any cache, regardless of its configuration. (Ideally, it would be possible for Map-Reduce to also be used against any cache.)
--
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
[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
12 years