November 2011 - infinispan-issues

[JBoss JIRA] (ISPN-1583) AbstractDelegatingAdvancedCache with(ClassLoader), withFlags(Flag...) logic is broken

by Paul Ferraro (Created) (JIRA)

AbstractDelegatingAdvancedCache with(ClassLoader), withFlags(Flag...) logic is broken ------------------------------------------------------------------------------------- Key: ISPN-1583 URL: https://issues.jboss.org/browse/ISPN-1583 Project: Infinispan Issue Type: Bug Components: Core API Affects Versions: 5.1.0.BETA5 Reporter: Paul Ferraro Assignee: Manik Surtani Priority: Critical When the withFlags(...) logic was modified to use a DecoratedCache instead of thread-local storage, any caches already decorated with the AbstractDelegatingAdvancedCache(...) broke. Take the following code: AdvancedCache<K, V> baseCache; AdvancedCache<K, V> customCache = new AbstractDelegatingAdvancedCache<K, V>(baseCache) { public void clear() { // custom clear logic } }; customCache.withFlags(Flag.CACHE_MODE_LOCAL).clear(); In the above statement, the flag is not applied. The call to withFlags(...) returns a reference to customCache, and the reference to DecoratedCache containing the flags is lost to garbage collection. In the case of with(ClassLoader) we have the opposite problem. customCache.with(customClassLoader).clear(); In the above statement, the native clear() method is invoked instead of my custom clear() method. with(ClassLoader) returns a reference to DecoratedCache. The clear() method then operates on baseCache, instead of decoratedCache. -- 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

7
10
0 / 0

[JBoss JIRA] Created: (ISPN-928) Interceptor that allows invocations only when cluster is formed of N nodes

by Galder Zamarreño (JIRA)

Interceptor that allows invocations only when cluster is formed of N nodes -------------------------------------------------------------------------- Key: ISPN-928 URL: https://issues.jboss.org/browse/ISPN-928 Project: Infinispan Issue Type: Feature Request Components: Configuration, RPC Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.0.0.BETA1, 5.0.0.Final Following from https://github.com/pmuir/infinispan-examples/commit/f5d090092fa7b3660025b... It'd be great to have an configurable StrictCluster interceptor in Infinispan which would basically make all invocations wait until the cluster of N nodes has been formed. I think it'd be a great addition and would allow clients to verify whether the cluster actually forms without the need to verify whether data replicates...etc. In principle, the configuration would be at the CacheManager, i.e.: <transport strictNumMembers="4"... /> However, it could also be useful to configure it at the cache level. So, could maybe want to do this: I want cache X to allow invocations the moment I have 2 nodes (in spite of the cluster being formed of 4 noes), whereas I want cache Y to allow invocations once I have 3 nodes. Apart from an strict number of nodes, you could have a minimum number of nodes: allow invocations once I have 4 or more nodes. The strict value could still be useful to make sure intrusive machines don't get into the cluster, i.e. I expect 4 nodes in the cluster and if I have 5, something is wrong. I think it's an interesting concept that would get rid of cluster validation code in examples and RadarGun. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

1
4
0 / 0

[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

7
16
0 / 0

[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

9
11
0 / 0

[JBoss JIRA] Created: (ISPN-1410) Supporting rolling upgrades of a live cluster

by Sanne Grinovero (JIRA)

Supporting rolling upgrades of a live cluster --------------------------------------------- Key: ISPN-1410 URL: https://issues.jboss.org/browse/ISPN-1410 Project: Infinispan Issue Type: Feature Request Reporter: Sanne Grinovero Assignee: Manik Surtani Fix For: 5.1.0.BETA2 This is an umbrella issue for several pieces need to make sure people will be able to perform a rolling upgrade. After the depending issues are solved we should add specific tests to perform this. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years

3
10
0 / 0

[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

4
9
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

4
19
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] 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] Created: (ISPN-1271) Consistent Hash externalizer loses grouping configuration

by Dan Berindei (JIRA)

Consistent Hash externalizer loses grouping configuration --------------------------------------------------------- Key: ISPN-1271 URL: https://issues.jboss.org/browse/ISPN-1271 Project: Infinispan Issue Type: Bug Components: Marshalling Affects Versions: 5.0.0.CR8 Reporter: Dan Berindei Assignee: Pete Muir -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 1 month

6
13
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2011