June 2011 - infinispan-issues - Jboss List Archives

[JBoss JIRA] Created: (ISPN-1179) Preloading the cache leads to duplicate (multiple) results from queries

by juergen roberg (JIRA)

Preloading the cache leads to duplicate (multiple) results from queries ----------------------------------------------------------------------- Key: ISPN-1179 URL: https://issues.jboss.org/browse/ISPN-1179 Project: Infinispan Issue Type: Bug Components: Loaders and Stores, Querying Affects Versions: 5.0.0.CR3 Reporter: juergen roberg Assignee: Manik Surtani Duplicate (multiple) results from queries. We are using Infinispan 5.0.0.CR3 and our cache has a JdbcStringBasedCacheStore loader with preload="true". When reaching the QueryInterceptor (see StackTrace below) entry.isCreated() returns true. ReadCommittedEntry(a44130){ key=0eebcb5b-d581-49ec-8e49-565a8f134b4c, value={objectID=0eebcb5b-d581-49ec-8e49-565a8f134b4c, street=Street 66}, oldValue=null, isCreated=true, isChanged=true, isRemoved=false, isValid=true } so the QueryInterceptor adds the entry to the index again instead of just updating the index. public Object visitPutKeyValueCommand(InvocationContext ctx, PutKeyValueCommand command) throws Throwable { // This method will get the put() calls on the cache and then send them into Lucene once it's successful. // do the actual put first. Object toReturn = invokeNextInterceptor(ctx, command); if (shouldModifyIndexes(ctx)) { // First making a check to see if the key is already in the cache or not. If it isn't we can add the key no problem, // otherwise we need to be updating the indexes as opposed to simply adding to the indexes. Object key = command.getKey(); Object value = extractValue(command.getValue()); updateKnownTypesIfNeeded( value ); CacheEntry entry = ctx.lookupEntry(key); // New entry so we will add it to the indexes. if(entry.isCreated()) { log.debug("Entry is created"); >>>> addToIndexes(value, extractValue(key)); } else{ // This means that the entry is just modified so we need to update the indexes and not add to them. log.debug("Entry is changed"); updateIndexes(value, extractValue(key)); } } return toReturn; } Thread [main] (Suspended) LocalQueryInterceptor(QueryInterceptor).visitPutKeyValueCommand(InvocationContext, PutKeyValueCommand) line: 98 PutKeyValueCommand.acceptVisitor(InvocationContext, Visitor) line: 77 LockingInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, VisitableCommand) line: 119 LockingInterceptor.visitPutKeyValueCommand(InvocationContext, PutKeyValueCommand) line: 294 PutKeyValueCommand.acceptVisitor(InvocationContext, Visitor) line: 77 CacheStoreInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, VisitableCommand) line: 119 CacheStoreInterceptor.visitPutKeyValueCommand(InvocationContext, PutKeyValueCommand) line: 204 PutKeyValueCommand.acceptVisitor(InvocationContext, Visitor) line: 77 CacheLoaderInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, VisitableCommand) line: 119 CacheLoaderInterceptor.visitPutKeyValueCommand(InvocationContext, PutKeyValueCommand) line: 82 PutKeyValueCommand.acceptVisitor(InvocationContext, Visitor) line: 77 NotificationInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, VisitableCommand) line: 119 NotificationInterceptor(CommandInterceptor).handleDefault(InvocationContext, VisitableCommand) line: 133 NotificationInterceptor(AbstractVisitor).visitPutKeyValueCommand(InvocationContext, PutKeyValueCommand) line: 60 PutKeyValueCommand.acceptVisitor(InvocationContext, Visitor) line: 77 TxInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, VisitableCommand) line: 119 TxInterceptor.enlistWriteAndInvokeNext(InvocationContext, WriteCommand) line: 204 TxInterceptor.visitPutKeyValueCommand(InvocationContext, PutKeyValueCommand) line: 152 PutKeyValueCommand.acceptVisitor(InvocationContext, Visitor) line: 77 InvocationContextInterceptor(CommandInterceptor).invokeNextInterceptor(InvocationContext, VisitableCommand) line: 119 InvocationContextInterceptor.handleAll(InvocationContext, VisitableCommand) line: 96 InvocationContextInterceptor.handleDefault(InvocationContext, VisitableCommand) line: 63 InvocationContextInterceptor(AbstractVisitor).visitPutKeyValueCommand(InvocationContext, PutKeyValueCommand) line: 60 PutKeyValueCommand.acceptVisitor(InvocationContext, Visitor) line: 77 InterceptorChain.invoke(InvocationContext, VisitableCommand) line: 274 CacheDelegate<K,V>.put(K, V, long, TimeUnit, long, TimeUnit) line: 505 CacheLoaderManagerImpl.preload() line: 160 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: not available DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: not available Method.invoke(Object, Object...) line: not available ReflectionUtil.invokeAccessibly(Object, Method, Object[]) line: 172 AbstractComponentRegistry$PrioritizedMethod.invoke() line: 908 ComponentRegistry(AbstractComponentRegistry).internalStart() line: 706 ComponentRegistry(AbstractComponentRegistry).start() line: 608 ComponentRegistry.start() line: 179 CacheDelegate<K,V>.start() line: 362 DefaultCacheManager.createCache(String) line: 548 DefaultCacheManager.getCache(String) line: 445 Main.main(String[]) line: 45 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

3
4
0 / 0

[JBoss JIRA] Created: (ISPN-1162) Duplicate command ID check should include user defined ones too

by Galder Zamarreño (JIRA)

Duplicate command ID check should include user defined ones too --------------------------------------------------------------- Key: ISPN-1162 URL: https://issues.jboss.org/browse/ISPN-1162 Project: Infinispan Issue Type: Bug Affects Versions: 5.0.0.CR4 Reporter: Galder Zamarreño Assignee: Manik Surtani Fix For: 5.0.0.CR5 Infinispan does not take into account user-defined command Ids when checking for duplicate ids. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

2
8
0 / 0

[JBoss JIRA] Created: (ISPN-1182) Failure after TimeoutException during the restart of HotRod Server

by Jacek Gerbszt (JIRA)

Failure after TimeoutException during the restart of HotRod Server ------------------------------------------------------------------ Key: ISPN-1182 URL: https://issues.jboss.org/browse/ISPN-1182 Project: Infinispan Issue Type: Bug Components: Cache Server Affects Versions: 5.0.0.CR4 Reporter: Jacek Gerbszt Assignee: Manik Surtani Sometimes during restart of 3 or more HotRod nodes from 25-node cluster, I receive replication timeout exception, after which the node is unusable. The timeout comes from replacing the view in HotrodServer.addSelfToTopologyView. If 3 nodes try to replace the same element in cache at the same time, it's not a big surprise, that they fall into some kind of deadlock, which is properly recognized and broken after the timeout. But unfortunately the breaking exception is not handled and stops the HotRodServer start procedure. I suggest to catch it in addSelfToTopologyView like this: var updated = false try { updated = topologyCache.replace("view", currentView, newView) } catch { case e: TimeoutException => logUnableToReplaceView } This time the exception will not be thrown from the containing closure and updateTopologyView method will have the chance to replace the view again. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

4
14
0 / 0

[JBoss JIRA] Created: (ISPN-1184) Provide more meaningful messages for EOFException

by Galder Zamarreño (JIRA)

Provide more meaningful messages for EOFException ------------------------------------------------- Key: ISPN-1184 URL: https://issues.jboss.org/browse/ISPN-1184 Project: Infinispan Issue Type: Enhancement Components: Marshalling, State transfer Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.0.0.CR7 During state transfer and any other streaming functionality, the sender could prematurely die without sending all the bytes. This generally results on the receiver side throwing: {code}2011-06-09 15:32:18,092 ERROR [JGroupsTransport] (Incoming-1,Infinispan-Cluster,NodeB-32230) ISPN00096: Caught while requesting or applying state org.infinispan.statetransfer.StateTransferException: java.io.EOFException: Read past end of file at org.infinispan.statetransfer.StateTransferManagerImpl.applyState(StateTransferManagerImpl.java:333){code} This can be a bit misleading for users, so the exception should be laundered into something that's more meaningful. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

2
4
0 / 0

[JBoss JIRA] Created: (ISPN-1187) Some parameters inconsistent with loggin pattern

by Sanne Grinovero (JIRA)

Some parameters inconsistent with loggin pattern ------------------------------------------------ Key: ISPN-1187 URL: https://issues.jboss.org/browse/ISPN-1187 Project: Infinispan Issue Type: Bug Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Minor Two issues in the logging templates being inconsistent with the number of parameters being passed: Format specifier 's' Parameter count does not match for format 'Could not register object with name: %s (%s)'. Required: 2 Provided: 1 Format specifier 's' Parameter count does not match for format 'Found WebSphere TransactionManager factory class [%s], but couldn't invoke its static 'getTransactionManager' method'. Required: 1 Provided: 0 detected via LOGTOOL-20 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

2
3
0 / 0

[JBoss JIRA] Created: (ISPN-1160) fetchInMemoryState doesn't work without FLUSH protocol for udp

by William Burns (JIRA)

fetchInMemoryState doesn't work without FLUSH protocol for udp -------------------------------------------------------------- Key: ISPN-1160 URL: https://issues.jboss.org/browse/ISPN-1160 Project: Infinispan Issue Type: Bug Affects Versions: 5.0.0.CR4 Reporter: William Burns Assignee: Manik Surtani I was testing with a replicated cache in infinispan. And in an attempt to try it in 5.0CR4 I have found that I cannot use a replicated or invalidating cache (async or sync) that has fetchInMemoryState set to true unless I have FLUSH protocol provided with udp. I was able to reproduce this using the distributed jgroups-udp.xml file, which has FLUSH removed. When I tried with jgroups-tcp.xml it works without the FLUSH protocol as expected. I have attached the test java file that is only using infinispan and is very basic that reproduces it every time I try. I also will attach the log file from both the coordinator and the joining peer that shows this issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

5
18
0 / 0

[JBoss JIRA] Created: (ISPN-1012) With L1 disabled a new node join may result some entries are not invalidated for non-owner in DIST mode

by Changgeng Li (JIRA)

With L1 disabled a new node join may result some entries are not invalidated for non-owner in DIST mode ------------------------------------------------------------------------------------------------------- Key: ISPN-1012 URL: https://issues.jboss.org/browse/ISPN-1012 Project: Infinispan Issue Type: Bug Affects Versions: 4.2.1.FINAL Reporter: Changgeng Li Assignee: Manik Surtani I have a test case that have 30,000 entries in cache in dist mode with number of owner set to 2 and L1 is disabled. A new node join the cluster, then the total number of entries in all cache is larger than 60,000. Even worse, after I execute cache.clear() on all caches in the cluster, there are still lots of entries left. The attached unit test can reproduce this issue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

5
13
0 / 0

[JBoss JIRA] Created: (ISPN-1188) config schema - isolationLevel attribute allows unsupported isolation modes

by Michal Linhard (JIRA)

config schema - isolationLevel attribute allows unsupported isolation modes --------------------------------------------------------------------------- Key: ISPN-1188 URL: https://issues.jboss.org/browse/ISPN-1188 Project: Infinispan Issue Type: Bug Components: Configuration Affects Versions: 5.0.0.CR5 Reporter: Michal Linhard Assignee: Manik Surtani The configuration schema, attribute infinispan.configuration.locking.isolationLevel allows picking of two unsupported isolation levels READ_UNCOMMITTED SERIALIZABLE We don't even warn when such isolation type is used - in the code we use tests like: useReadCommitted = configuration.getIsolationLevel() == IsolationLevel.READ_COMMITTED; useRepeatableRead = configuration.getIsolationLevel() == IsolationLevel.REPEATABLE_READ; shouldn't we remove these from schema to avoid confusion ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

2
2
0 / 0

[JBoss JIRA] Created: (ISPN-979) FileCacheStore should use fsync() when writing to disk

by Manik Surtani (JIRA)

FileCacheStore should use fsync() when writing to disk ------------------------------------------------------ Key: ISPN-979 URL: https://issues.jboss.org/browse/ISPN-979 Project: Infinispan Issue Type: Feature Request Components: Loaders and Stores Affects Versions: 4.2.0.Final Reporter: Manik Surtani Assignee: Manik Surtani Fix For: 4.2.1.FINAL This would be an optional flag, offering one of 3 modes (no sync, periodic sync - e.g., every second - and sync per write). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

3
18
0 / 0

[JBoss JIRA] Created: (ISPN-1183) java.lang.NullPointerException deploying REST server in AS7

by Galder Zamarreño (JIRA)

java.lang.NullPointerException deploying REST server in AS7 ----------------------------------------------------------- Key: ISPN-1183 URL: https://issues.jboss.org/browse/ISPN-1183 Project: Infinispan Issue Type: Bug Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 5.0.0.CR6 {code}15:12:25,527 ERROR [org.apache.catalina.core.ContainerBase.[jboss.web].[localhost].[/infinispan]] (MSC service thread 1-4) Servlet /infinispan threw load() exception: java.lang.NullPointerException at org.infinispan.config.GlobalConfiguration$GlobalJmxStatisticsType.getMBeanServerLookupInstance(GlobalConfiguration.java:1645) [infinispan-core-5.0.0-SNAPSHOT.jar:] at org.infinispan.config.GlobalConfiguration.getMBeanServerLookupInstance(GlobalConfiguration.java:245) [infinispan-core-5.0.0-SNAPSHOT.jar:] at org.infinispan.jmx.JmxUtil.lookupMBeanServer(JmxUtil.java:55) [infinispan-core-5.0.0-SNAPSHOT.jar:] at org.infinispan.jmx.AbstractJmxRegistration.registerMBeans(AbstractJmxRegistration.java:50) [infinispan-core-5.0.0-SNAPSHOT.jar:] at org.infinispan.jmx.CacheManagerJmxRegistration.start(CacheManagerJmxRegistration.java:62) [infinispan-core-5.0.0-SNAPSHOT.jar:] at org.infinispan.manager.DefaultCacheManager.start(DefaultCacheManager.java:572) [infinispan-core-5.0.0-SNAPSHOT.jar:] at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:269) [infinispan-core-5.0.0-SNAPSHOT.jar:] at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:238) [infinispan-core-5.0.0-SNAPSHOT.jar:] at org.infinispan.rest.StartupListener.init(StartupListener.scala:59) [classes:] at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1202) [jbossweb-7.0.0.CR2.jar:7.0.0.Beta4-SNAPSHOT] at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1102) [jbossweb-7.0.0.CR2.jar:7.0.0.Beta4-SNAPSHOT] at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:3631) [jbossweb-7.0.0.CR2.jar:7.0.0.Beta4-SNAPSHOT] at org.apache.catalina.core.StandardContext.start(StandardContext.java:3840) [jbossweb-7.0.0.CR2.jar:7.0.0.Beta4-SNAPSHOT] at org.jboss.as.web.deployment.WebDeploymentService.start(WebDeploymentService.java:70) [jboss-as-web-7.0.0.Beta4-SNAPSHOT.jar:7.0.0.Beta4-SNAPSHOT] at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1675) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24] at java.lang.Thread.run(Thread.java:680) [:1.6.0_24]{code} This is related to ISPN-1096 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 6 months

2
9
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2011