[JBoss JIRA] (ISPN-4163) CacheAuthorizationTest.testAllCombinations always fails on JDK8
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4163?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4163:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1173645|https://bugzilla.redhat.com/show_bug.cgi?id=1173645] from MODIFIED to ON_QA
> CacheAuthorizationTest.testAllCombinations always fails on JDK8
> ---------------------------------------------------------------
>
> Key: ISPN-4163
> URL: https://issues.jboss.org/browse/ISPN-4163
> Project: Infinispan
> Issue Type: Bug
> Components: Security, Test Suite - Core
> Affects Versions: 7.0.0.Alpha1
> Reporter: Dan Berindei
> Assignee: Tristan Tarrant
> Labels: testsuite_stability
> Fix For: 7.0.0.Alpha5
>
>
> JDK8 added some new default methods to ConcurrentMap, and SecureCacheTestDriver doesn't cover them. This actually raises the question of whether we could provide our own implementations while still keeping compatibility with JDK6...
> {noformat}
> java.lang.Exception: Class org.infinispan.security.SecureCacheTestDriver needs to declare a method with the following signature: void testReplaceAll_BiFunction(SecureCache<String, String> cache) {}
> at org.infinispan.security.CacheAuthorizationTest.testAllCombinations(CacheAuthorizationTest.java:158)
> Caused by: java.lang.NoSuchMethodException: org.infinispan.security.SecureCacheTestDriver.testReplaceAll_BiFunction(org.infinispan.security.SecureCache)
> at java.lang.Class.getMethod(Class.java:1773)
> at org.infinispan.security.CacheAuthorizationTest.testAllCombinations(CacheAuthorizationTest.java:109) ... 20 more
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (ISPN-5062) Cross site state transfer - incorrect status of push operation
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5062?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5062:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1172034|https://bugzilla.redhat.com/show_bug.cgi?id=1172034] from MODIFIED to ON_QA
> Cross site state transfer - incorrect status of push operation
> ---------------------------------------------------------------
>
> Key: ISPN-5062
> URL: https://issues.jboss.org/browse/ISPN-5062
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 7.1.0.Alpha1
> Reporter: Matej Čimbora
> Assignee: Pedro Ruivo
> Fix For: 7.1.0.Beta1, 7.1.0.Final
>
>
> Status of push operation remains at value "CANCELLED" after the push operation was cancelled and reinvoked (even if state transfer is currently in progress) - "SENDING" value is expected. Otherwise works as expected (after the state transfer completes, status is switched to "OK").
> - Sites LON (lonCache) - main, BRN (brnCache) - backup
> Consider the following scenario:
> [standalone@localhost:9999 distributed-cache=lonCache] site --push BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --cancelpush BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=CANCELED
> [standalone@localhost:9999 distributed-cache=lonCache] site --push BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=CANCELED
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=OK
> Expected behavior:
> [standalone@localhost:9999 distributed-cache=lonCache] site --push BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --cancelpush BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=CANCELED
> [standalone@localhost:9999 distributed-cache=lonCache] site --push BRN
> ok
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=SENDING
> [standalone@localhost:9999 distributed-cache=lonCache] site --pushstatus
> BRN=OK
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (ISPN-4884) Deployment scanner should be enabled to allow filter/converter jar deployment
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4884?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4884:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1156397|https://bugzilla.redhat.com/show_bug.cgi?id=1156397] from MODIFIED to ON_QA
> Deployment scanner should be enabled to allow filter/converter jar deployment
> -----------------------------------------------------------------------------
>
> Key: ISPN-4884
> URL: https://issues.jboss.org/browse/ISPN-4884
> Project: Infinispan
> Issue Type: Enhancement
> Components: Server
> Affects Versions: 7.0.0.CR2
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Priority: Critical
> Fix For: 7.0.0.Final
>
>
> When we want to copy JARS and deploy it on JDG server in standalone/clustered.xml is no deployment-scanner element defined. It should be added when server is built
> Steps to Reproduce:
> 1. cp filter-converter.jar infinispan-server-7.0.0.CR2/standalone/deployments/
> 2. look at console output of server
> 3. check if there is no output from deployment scanner
> Current results: not output from deployment scanner, because it is not enabled
> Expected results: we should see following output in console log
> JBAS015012: Started FileSystemDeploymentService for directory /home/infinispan-server-7.0.0.CR2/standalone/deployments
> JBAS015876: Starting deployment of "filter-converter.jar" (runtime-name: "filter-converter.jar")
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (ISPN-5059) JGroups subsystem doesn't support Vault
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5059?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5059:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1172038|https://bugzilla.redhat.com/show_bug.cgi?id=1172038] from MODIFIED to ON_QA
> JGroups subsystem doesn't support Vault
> ---------------------------------------
>
> Key: ISPN-5059
> URL: https://issues.jboss.org/browse/ISPN-5059
> Project: Infinispan
> Issue Type: Bug
> Components: Security, Server
> Affects Versions: 7.0.2.Final
> Reporter: Vojtech Juranek
> Assignee: Tristan Tarrant
> Fix For: 7.1.0.Beta1, 7.1.0.Final
>
>
> JGroups subsystem doesn't support passwords encrypted in Vault. E.g. when running [EncryptProtocolIT|https://github.com/infinispan/infinispan/blob/master/se...] with following configuration:
> {noformat}
> <protocol type="ENCRYPT">
> <property name="key_store_name">${jboss.server.config.dir}/server_jceks.keystore</property>
> <property name="store_password">${VAULT::keystore::password::1}</property>
> <property name="alias">memcached</property>
> </protocol>
> {noformat}
> i.e. it uses Vault-encrypted password for keystore, it fails with:
> {noformat}
> groups.channel.clustered: java.lang.Exception: Unable to load keystore infinispan/server/integration/testsuite/target/server/node2/standalone/configuration/server_jceks.keystore: java.io.IOException: Keystore was tampered with, or password was incorrect
> at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:74)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_55]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_55]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_55]
> Caused by: java.lang.Exception: Unable to load keystore infinispan/server/integration/testsuite/target/server/node2/standalone/configuration/server_jceks.keystore: java.io.IOException: Keystore was tampered with, or password was incorrect
> at org.jgroups.protocols.ENCRYPT.initConfiguredKey(ENCRYPT.java:309)
> at org.jgroups.protocols.ENCRYPT.init(ENCRYPT.java:250)
> at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:860)
> at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:481)
> at org.jgroups.JChannel.init(JChannel.java:848)
> at org.jgroups.JChannel.<init>(JChannel.java:159)
> at org.jboss.as.clustering.jgroups.JChannelFactory.createChannel(JChannelFactory.java:87)
> at org.jboss.as.clustering.jgroups.subsystem.ChannelService.start(ChannelService.java:69)
> {noformat}
> Vault record for {{keystore::password}} exists:
> {noformat}
> Task: Verify whether a secured attribute exists
> Enter Vault Block:keystore
> Enter Attribute Name:password
> A value exists for (keystore, password)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (ISPN-5104) Infinite loop in TransactionAwareCloseableIterator when iterating through cache...
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5104?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5104:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1176910|https://bugzilla.redhat.com/show_bug.cgi?id=1176910] from MODIFIED to ON_QA
> Infinite loop in TransactionAwareCloseableIterator when iterating through cache...
> ----------------------------------------------------------------------------------
>
> Key: ISPN-5104
> URL: https://issues.jboss.org/browse/ISPN-5104
> Project: Infinispan
> Issue Type: Bug
> Components: Transactions
> Affects Versions: 7.0.2.Final
> Reporter: Christian Niessner
> Assignee: William Burns
> Fix For: 7.1.0.Beta1, 7.0.3.Final
>
>
> Hi,
> i have some testing code that iterates through a cache and validates all data in this cache for consistency.
> The reduced code is:
> TransactionManager tm = cache.getAdvancedCache().getTransactionManager();
> tm.begin();
> try {
> for (Entry<Object,Object> entry : metadataCache.entrySet()) {
> // validation code omitted...
> }
> } finally {
> tm.commit();
> }
> In some circumstances the iteration starts returning the same Entry every time. I stepped into the code and the value is returned from:
> https://github.com/infinispan/infinispan/blob/master/core/src/main/java/o...
> This code block is commented with:
> "// We do a last check to make sure no additional values were added to our context while iterating"
> And for me it seems that the value returned here never gets added to the "seenContextKeys" Set and so the iterator is always returning the same key.
> Maybe a simple "seenContextKeys.add(lookedUpEntry.getKey())" next to Line 70 would fix this issue. Maybe even a 'break' could make sense here because is there the need to walk through the entire list if we have found a candidate?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (ISPN-4867) HotRodRemoteCacheIT(localmode-udp).testCustomEvents random failures
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4867?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4867:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1156310|https://bugzilla.redhat.com/show_bug.cgi?id=1156310] from MODIFIED to ON_QA
> HotRodRemoteCacheIT(localmode-udp).testCustomEvents random failures
> -------------------------------------------------------------------
>
> Key: ISPN-4867
> URL: https://issues.jboss.org/browse/ISPN-4867
> Project: Infinispan
> Issue Type: Bug
> Components: Server, Test Suite - Server
> Affects Versions: 7.0.0.CR1
> Reporter: Dan Berindei
> Assignee: Galder Zamarreño
> Priority: Blocker
> Labels: testsuite_stability
> Fix For: 7.0.0.Final
>
>
> {noformat}
> org.infinispan.client.hotrod.exceptions.HotRodClientException: org.infinispan.commons.CacheException: java.lang.NoClassDefFoundError: org/infinispan/server/test/client/hotrod/HotRodCustomMarshallerEventIT$Id
> at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:284)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:86)
> at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:72)
> at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56)
> at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:50)
> at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:30)
> at org.infinispan.client.hotrod.impl.operations.PutOperation.executeOperation(PutOperation.java:19)
> at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:50)
> at org.infinispan.client.hotrod.impl.RemoteCacheImpl.put(RemoteCacheImpl.java:237)
> at org.infinispan.client.hotrod.impl.RemoteCacheSupport.put(RemoteCacheSupport.java:79)
> at org.infinispan.server.test.client.hotrod.AbstractRemoteCacheIT.testCustomEvents(AbstractRemoteCacheIT.java:855)
> {noformat}
> Tests {{testCustomEventsDynamic}}, {{testEventFilteringDynamic}}, {{testEventFilteringStatic}} fail with the same error message.
> Failing since http://ci.infinispan.org/viewLog.html?buildTypeId=bt8&buildId=12713
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (ISPN-5091) BaseStoreTest.testPurgeExpired fails randomly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-5091?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-5091:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1174745|https://bugzilla.redhat.com/show_bug.cgi?id=1174745] from MODIFIED to ON_QA
> BaseStoreTest.testPurgeExpired fails randomly
> ---------------------------------------------
>
> Key: ISPN-5091
> URL: https://issues.jboss.org/browse/ISPN-5091
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 7.1.0.Alpha1
> Reporter: Jiří Holuša
> Assignee: Jiří Holuša
>
> On some DB (like DB2, Oracle11gR1, ...) BaseStoreTest.testPurgeExpired sometimes fails on assertion error.
> Investigated and found out that these stores don't insert all the entries in time before lifespan runs out and after that, there's a "contains" check which fails.
> Resolution is to move the "contains" checking right after insertion and adjust slightly the lifespan and idle values, so the cache store can manage to insert entry in time. The goal is to stabilize the testsuite.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months
[JBoss JIRA] (ISPN-4499) Prevent shadowing user-defined jgroups configuration file
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4499?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4499:
-----------------------------------------------
Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1115555|https://bugzilla.redhat.com/show_bug.cgi?id=1115555] from MODIFIED to ON_QA
> Prevent shadowing user-defined jgroups configuration file
> ---------------------------------------------------------
>
> Key: ISPN-4499
> URL: https://issues.jboss.org/browse/ISPN-4499
> Project: Infinispan
> Issue Type: Enhancement
> Components: Configuration
> Affects Versions: 7.0.0.Alpha4
> Reporter: Martin Gencur
> Assignee: Martin Gencur
> Fix For: 7.0.0.Alpha5
>
>
> When users create their own JGroups configuration file and name it the same way as default configuration files (jgroups-udp.xml / jgroups-tcp-xml / jgroups-ec2.xml), they might not be visible to the user application as they're shadowed by the default configuration files.
> Proposed solution:
> * place current jgroups configuration files into META-INF/configs folder (this folder doesn't have to have an obscure name such as "_internal" because of the following two points which complement the solution)
> * define order in which the config files are read by class loader (i.e. first scan user application, then path under META-INF/configs)
> * when Infinispan is started, log the path to the configuration file used, e.g.:
> {code}
> 2014-06-12 06:45:02,871 [thread-name] INFO [package-name] Using JGroups configuration file 'jar:META-INF/example_configurations/jgroups/udp.xml'
> 2014-06-12 06:45:02,871 [thread-name] INFO [package-name] Using JGroups configuration file 'file:/app_home/config/jgroups-udp.xml'
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 4 months