[JBoss JIRA] Created: (ISPN-1399) Jandex index file containing old removed classes
by Galder Zamarreño (JIRA)
Jandex index file containing old removed classes
------------------------------------------------
Key: ISPN-1399
URL: https://issues.jboss.org/browse/ISPN-1399
Project: Infinispan
Issue Type: Bug
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 5.1.0.BETA1
With ISPN-1194 in, running TransportSenderExceptionHandlingTest shows the following in the logs.
As a result of ISPN-1194, StateTransferManagerImpl has been removed but it's still being indexed.
Looking at infinispan-core-jandex.idx, StateTransferManagerImpl is still present but this is a file in the src/main/resources. Shouldn't this be generated?
We're not gonna remember to manually generate it when a component is removed :)
{code}2011-09-20 16:21:19,781 FATAL [AnnotatedMethodCache] (main) Caught exception scanning annotations on void org.infinispan.statetransfer.StateTransferManagerImpl.injectDependencies(org.infinispan.remoting.rpc.RpcManager, org.infinispan.AdvancedCache, org.infinispan.config.Configuration, org.infinispan.container.DataContainer, org.infinispan.loaders.CacheLoaderManager, org.infinispan.marshall.StreamingMarshaller, org.infinispan.transaction.TransactionLog, org.infinispan.interceptors.InterceptorChain, org.infinispan.context.InvocationContextContainer, org.infinispan.commands.CommandsFactory, org.infinispan.transaction.TransactionTable)
java.lang.ClassNotFoundException: org.infinispan.statetransfer.StateTransferManagerImpl
at java.net.URLClassLoader$1.run(URLClassLoader.java:202)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:190)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
at org.infinispan.util.reflect.CachedMethod.<init>(CachedMethod.java:52)
at org.infinispan.util.reflect.AnnotatedMethodCache.collectAndCacheMethodAnnotations(AnnotatedMethodCache.java:121)
at org.infinispan.util.reflect.AnnotatedMethodCache.<clinit>(AnnotatedMethodCache.java:86)
at org.infinispan.factories.AbstractComponentRegistry.addComponentDependencies(AbstractComponentRegistry.java:208)
at org.infinispan.factories.AbstractComponentRegistry.registerComponentInternal(AbstractComponentRegistry.java:192)
at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:154)
at org.infinispan.factories.AbstractComponentRegistry.registerComponent(AbstractComponentRegistry.java:149)
at org.infinispan.factories.AbstractComponentRegistry.registerDefaultClassLoader(AbstractComponentRegistry.java:439)
at org.infinispan.factories.GlobalComponentRegistry.<init>(GlobalComponentRegistry.java:93)
at org.infinispan.manager.DefaultCacheManager.<init>(DefaultCacheManager.java:223)
at org.infinispan.test.fwk.TestCacheManagerFactory.newDefaultCacheManager(TestCacheManagerFactory.java:376)
at org.infinispan.test.fwk.TestCacheManagerFactory.newDefaultCacheManager(TestCacheManagerFactory.java:73)
at org.infinispan.test.fwk.TestCacheManagerFactory.createClusteredCacheManager(TestCacheManagerFactory.java:171)
at org.infinispan.test.fwk.TestCacheManagerFactory.createClusteredCacheManager(TestCacheManagerFactory.java:151)
at org.infinispan.test.MultipleCacheManagersTest.addClusterEnabledCacheManager(MultipleCacheManagersTest.java:168)
at org.infinispan.test.MultipleCacheManagersTest.createClusteredCaches(MultipleCacheManagersTest.java:298)
at org.infinispan.test.MultipleCacheManagersTest.createClusteredCaches(MultipleCacheManagersTest.java:291)
at org.infinispan.remoting.TransportSenderExceptionHandlingTest.createCacheManagers(TransportSenderExceptionHandlingTest.java:52)
at org.infinispan.test.MultipleCacheManagersTest.callCreateCacheManagers(MultipleCacheManagersTest.java:89)
at org.infinispan.test.MultipleCacheManagersTest.createBeforeClass(MultipleCacheManagersTest.java:83)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:644)
at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:443)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:160)
at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:90)
at org.testng.internal.TestMethodWorker.invokeBeforeClassMethods(TestMethodWorker.java:183)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:115)
at org.testng.TestRunner.runWorkers(TestRunner.java:909)
at org.testng.TestRunner.privateRun(TestRunner.java:618)
at org.testng.TestRunner.run(TestRunner.java:499)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:332)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:327)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:299)
at org.testng.SuiteRunner.run(SuiteRunner.java:204)
at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:915)
at org.testng.TestNG.runSuitesLocally(TestNG.java:879)
at org.testng.TestNG.run(TestNG.java:787)
at org.testng.remote.RemoteTestNG.run(RemoteTestNG.java:73)
at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:101){code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] Created: (ISPN-385) Add idle timeout to memcached and hot rod servers.
by Galder Zamarreno (JIRA)
Add idle timeout to memcached and hot rod servers.
--------------------------------------------------
Key: ISPN-385
URL: https://jira.jboss.org/jira/browse/ISPN-385
Project: Infinispan
Issue Type: Task
Components: Cache Server
Reporter: Galder Zamarreno
Assignee: Galder Zamarreno
Fix For: 4.1.0.BETA1
Add an IdleStateHandler to memcached and hot rod servers so that idle connections can be closed automatically. This is necessary to handle error conditions such as cases where clients erroneously indicate the server that it needs to read 20 bytes but they only send 10 bytes. Without such handler, the server will carry on waiting for bytes forever. The handler will provide a defence mechanism for such cases.
The timeout will be configurable via the command line. Besides, clients wanting to do some connection pooling will require to configure this accordingly in the server. In other words, there's hardly any point in having servers configured with idle timeout of 30 seconds and clients closing connections after 60 seconds of idle time. These two should be aligned accordingly.
--
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, 4 months
[JBoss JIRA] Created: (ISPN-1370) 5.0.0.FINAL hangs in replication mode with 2 local nodes (works in 4.2.1.FINAL)
by Stuart Hughes (JIRA)
5.0.0.FINAL hangs in replication mode with 2 local nodes (works in 4.2.1.FINAL)
-------------------------------------------------------------------------------
Key: ISPN-1370
URL: https://issues.jboss.org/browse/ISPN-1370
Project: Infinispan
Issue Type: Bug
Components: Cache Server, Configuration
Affects Versions: 5.0.0.FINAL
Environment: Ubuntu 10.10 i686 (32bit)
Apache tomcat 6.0.28
java version "1.6.0_26" (Sun)
Maven 2.2.1
Reporter: Stuart Hughes
Assignee: Manik Surtani
Infinispan hangs when starting a second instance of a named cache in replication mode on the same host.
Program scenario:
Http servlet is used to cache pages using Infinispan
Web app started twice by Maven on different ports:
* mvn tomcat:run -Dmaven.tomcat.port=9090
* mvn tomcat:run -Dmaven.tomcat.port=9091
Infinispan XML config:
{code}
<?xml version="1.0" encoding="UTF-8"?>
<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/>
</global>
<default>
<clustering mode="repl">
</clustering>
</default>
<namedCache name="itemCache">
</namedCache>
<namedCache name="pageCache">
</namedCache>
</infinispan>
{code}
Code extract:
{code}
@Service
public class InfCachingService
implements ICachingService, ResourceLoaderAware {
private static final Logger logger = LoggerFactory.getLogger(InfCachingService.class);
private String configName = null;
protected Cache<Integer, ContentBase> itemCache;
protected Cache<String, PageCacheItem> pageCache;
@Value("${inf.config.file}")
void setConfig(String configName) {
this.configName = configName;
}
@Override
public void setResourceLoader(ResourceLoader resourceLoader) {
try {
String configFile = resourceLoader.getResource( configName ).getFile().getCanonicalPath();
createCaches(configFile);
} catch(Exception e) {
logger.error("Could not get resource file: "+ configName + " : " + e);
}
}
protected Boolean createCaches(String configFile) {
System.out.println("Creating infinispan CacheManager from XML config");
try {
DefaultCacheManager m = new DefaultCacheManager(configFile);
if ( pageCache != null ) {
throw new Exception("pageCache should not exists");
}
pageCache = m.getCache("pageCache");
System.out.println("pageCache created");
return true;
} catch(Exception e) {
logger.error("Could not create Caches:", e);
return false;
}
}
{code}
Log output on second jvm:
{code}
ISPN000088: Unable to use any JGroups configuration mechanisms provided in properties {}. Using default JGroups configuration!
New view accepted: [z200-59673|1] [z200-59673, z200-39342]
ISPN000094: Received new cluster view: [z200-59673|1] [z200-59673, z200-39342]
ISPN000079: Cache local address is z200-39342, physical addresses are [fe80:0:0:0:250:56ff:fec0:8:60576]
Waiting on view being accepted
ISPN000128: Infinispan version: Infinispan 'Pagoa' 5.0.0.CR8
Interceptor chain size: 6
Interceptor chain is:
>> org.infinispan.interceptors.InvocationContextInterceptor
>> org.infinispan.interceptors.TxInterceptor
>> org.infinispan.interceptors.NotificationInterceptor
>> org.infinispan.interceptors.LockingInterceptor
>> org.infinispan.interceptors.ReplicationInterceptor
>> org.infinispan.interceptors.CallInterceptor
Initiating state transfer process
ISPN000074: Trying to fetch state from z200-59673
New view accepted: MergeView::[z200-39342|3] [z200-39342, z200-59673], subgroups=[[z200-59673|2] [z200-59673], [z200-59673|1] [z200-39342]]
ISPN000093: Received new, MERGED cluster view: MergeView::[z200-39342|3] [z200-39342, z200-59673], subgroups=[[z200-59673|2] [z200-59673], [z200-59673|1] [z200-39342]]
{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] Created: (ISPN-1303) More FileCacheStore optimizations
by Robert Stupp (JIRA)
More FileCacheStore optimizations
---------------------------------
Key: ISPN-1303
URL: https://issues.jboss.org/browse/ISPN-1303
Project: Infinispan
Issue Type: Enhancement
Components: Loaders and Stores
Affects Versions: 5.0.0.CR8
Reporter: Robert Stupp
Assignee: Manik Surtani
Still some more optimizations
1. added a check to prohibit purge at all, if the whole cache store does not contain any expireable cache entry (works great with non-expireable cache entries - like Lucene indexes)
2. added some more configuration options for purge:
2.a. minimum time to wait between to purge runs
2.b. minimum time to wait after last update to a bucket before purge run
2.c. maximum time to wait after the last purge run
3. prohibit purge run, if no update occured
4. prohibit purge test (and execution), if bucket file did not change after last purge run
Will attach source code.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] Created: (ISPN-1331) Log something about auto discovered modules and extensions
by Sanne Grinovero (JIRA)
Log something about auto discovered modules and extensions
----------------------------------------------------------
Key: ISPN-1331
URL: https://issues.jboss.org/browse/ISPN-1331
Project: Infinispan
Issue Type: Feature Request
Reporter: Sanne Grinovero
Assignee: Manik Surtani
Fix For: 5.1.0.ALPHA1
It seems that when looking in the classpath for instances of _infinispan-module.properties_ files, nothing is logged. No idea why it's not loading an extension.
Also specific modules should log their registration happening:
_org.infinispan.tree.LifecycleCallbacks_ should mention that it's being enabled.
(when registration of such a module doesn't happen, people experience misleading errors)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] Created: (ISPN-1317) JGroupsDistSync.flushWaitGate appears to be left open
by Galder Zamarreño (JIRA)
JGroupsDistSync.flushWaitGate appears to be left open
-----------------------------------------------------
Key: ISPN-1317
URL: https://issues.jboss.org/browse/ISPN-1317
Project: Infinispan
Issue Type: Bug
Components: State transfer
Affects Versions: 5.0.0.FINAL
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Fix For: 5.1.0.ALPHA1, 5.1.0.FINAL
Logs in JBPAPP-6929 show:
{code}15:40:22,698 ERROR [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (STREAMING_STATE_TRANSFER-sender-1,default,michal-linhard-12702)
ISPN000095: Caught while responding to state transfer request: org.infinispan.statetransfer.StateTransferException: java.util.concurrent.TimeoutException: Timed out waiting for a cluster-wide sync to be acquired. (timeout = 60 seconds)
at org.infinispan.statetransfer.StateTransferManagerImpl.generateState(StateTransferManagerImpl.java:162) [infinispan-core-5.0.0-SNAPSHOT.jar:5.0.0-SNAPSHOT]
at org.infinispan.remoting.InboundInvocationHandlerImpl.generateState(InboundInvocationHandlerImpl.java:248) [infinispan-core-5.0.0-SNAPSHOT.jar:5.0.0-SNAPSHOT]
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.getState(JGroupsTransport.java:590) [infinispan-core-5.0.0-SNAPSHOT.jar:5.0.0-SNAPSHOT]
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.handleUpEvent(MessageDispatcher.java:690) [jgroups-2.12.1.Final.jar:]
at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:771) [jgroups-2.12.1.Final.jar:]
at org.jgroups.JChannel.up(JChannel.java:1484) [jgroups-2.12.1.Final.jar:]
at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1074) [jgroups-2.12.1.Final.jar:]
at org.jgroups.protocols.pbcast.FLUSH.up(FLUSH.java:477) [jgroups-2.12.1.Final.jar:]
at org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER$StateProviderHandler.process(STREAMING_STATE_TRANSFER.java:651) [jgroups-2.12.1.Final.jar:]
at org.jgroups.protocols.pbcast.STREAMING_STATE_TRANSFER$StateProviderThreadSpawner$1.run(STREAMING_STATE_TRANSFER.java:580) [jgroups-2.12.1.Final.jar:]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_25]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_25]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_25]
Caused by: java.util.concurrent.TimeoutException: Timed out waiting for a cluster-wide sync to be acquired. (timeout = 60 seconds)
at org.infinispan.remoting.transport.jgroups.JGroupsDistSync.blockUntilAcquired(JGroupsDistSync.java:62) [infinispan-core-5.0.0-SNAPSHOT.jar:5.0.0-SNAPSHOT]
at org.infinispan.statetransfer.StateTransferManagerImpl.generateTransactionLog(StateTransferManagerImpl.java:196) [infinispan-core-5.0.0-SNAPSHOT.jar:5.0.0-SNAPSHOT]
at org.infinispan.statetransfer.StateTransferManagerImpl.generateState(StateTransferManagerImpl.java:152) [infinispan-core-5.0.0-SNAPSHOT.jar:5.0.0-SNAPSHOT]
... 12 more{code}
Now, what's odd about this is that the JGroupsDistSync.flushWaitGate behind it is only acquired/released while state transfer control command is sent and the logs show that both the enabling(acquiring) and disabling(releasing) state transfer control commands where built:
{code}15:39:20,902 TRACE [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) dests=[michal-linhard-37465], command=StateTransferControlCommand{enabled=true}, mode=SYNCHRONOUS, timeout=480000
...
15:39:21,074 TRACE [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-4) dests=[michal-linhard-37465], command=StateTransferControlCommand{enabled=false}, mode=SYNCHRONOUS, timeout=480000{code}
There's no other references to StateTransferControlCommand, so how can it be that flushWaitGate is open?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] Created: (ISPN-1298) Configure fork=once so that TRACE logs can be gathered more easily
by Galder Zamarreño (JIRA)
Configure fork=once so that TRACE logs can be gathered more easily
------------------------------------------------------------------
Key: ISPN-1298
URL: https://issues.jboss.org/browse/ISPN-1298
Project: Infinispan
Issue Type: Enhancement
Components: Test Suite
Reporter: Galder Zamarreño
Assignee: Galder Zamarreño
Priority: Minor
Fix For: 5.2.0.FINAL
We currently run our testsuite with fork=none which causes us some small issues:
- First, we're exposed to whatever system properties Maven might use internally which could impact our build.
- Secondly, it makes it difficult to have per-project log4j settings that are not hardcoded in the source code.
So, what is suggested here is that we switch to fork=once so that each module's testsuite runs in a different JVM. The overhead of this is apparently pretty small (needs double checking).
In terms of logging, this potentially enables each module to have its own 'trace-enabling' profile pointing to its own TRACE enabled log4j file, making it quite easy for each module to define what TRACE is relevant for each. For example:
{code}
<project>
<profiles>
<profile>
<id>trace-tests</id>
<build>
<plugins>
<plugin>
<artifactId>maven-surefire-plugin</artifactId>
<configuration>
<systemPropertyVariables>
<log4j.configuration>${basedir}/src/test/trace/log4j.xml</log4j.configuration>
</systemPropertyVariables>
</configuration>
</plugin>
</plugins>
</build>
</profile>
</profiles>
</project>
{code}
This has another advantage which is allowing us to override the log output directory selectively which is handy in a CI environment such as CloudBees:
- First, set the logs location to be dependant on another system property, i.e.:
{code}location=${log4j.outputDirectory}/infinispan.log{code}
- And then, selectively change it:
{code}<systemPropertyVariables>
<log4j.configuration>${basedir}/src/test/trace/log4j.xml</log4j.configuration>
<log4j.outputDirectory>${project.build.directory}/test-logs</log4j.outputDirectory>
</systemPropertyVariables>{code}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months