[JBoss JIRA] (ISPN-6147) Provide option to invalidate on commit
by Tristan Tarrant (JIRA)
[ https://issues.jboss.org/browse/ISPN-6147?page=com.atlassian.jira.plugin.... ]
Tristan Tarrant updated ISPN-6147:
----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> Provide option to invalidate on commit
> --------------------------------------
>
> Key: ISPN-6147
> URL: https://issues.jboss.org/browse/ISPN-6147
> Project: Infinispan
> Issue Type: Enhancement
> Components: Transactions
> Affects Versions: 5.2.14.Final
> Reporter: Galder Zamarreño
> Assignee: Galder Zamarreño
> Fix For: 5.2.15.Final
>
>
> For 5.2.x, provide an option to enable invalidation messages to be sent at commit time. This issue is related to ISPN-5876 where we changed the default behaviour to send invalidation messages at commit time. This created issues in the 5.2.x branch and instead it was decided that the fix should be reverted and instead provide an option to change the default behaviour to invalidate at commit time controlled by a system property.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ISPN-6186) Public CommandAwareRpcDispatcher method signatures reference non-public classes
by Paul Ferraro (JIRA)
Paul Ferraro created ISPN-6186:
----------------------------------
Summary: Public CommandAwareRpcDispatcher method signatures reference non-public classes
Key: ISPN-6186
URL: https://issues.jboss.org/browse/ISPN-6186
Project: Infinispan
Issue Type: Bug
Components: Core
Affects Versions: 8.1.1.Final, 8.2.0.Beta1
Reporter: Paul Ferraro
The public CommandAwareRpcDispatcher.invokeRemoteCommands(...) method returns a RspListFuture which is a package protected class. Likewise, the invokeRemoteCommand(...) method returns a SingleResponseFuture, which is also package protected. While this is legal, it is sloppy, as a non-package class can neither invoke these methods or override them.
These methods should either be package protected - or the visibility of the return types be made public - otherwise, they cannot be overridden.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ISPN-6183) Initial state transfer fails with unexpected timeout
by Vladimir Dzhuvinov (JIRA)
[ https://issues.jboss.org/browse/ISPN-6183?page=com.atlassian.jira.plugin.... ]
Vladimir Dzhuvinov updated ISPN-6183:
-------------------------------------
Description:
Hi guys,
I would like to report a somewhat odd issue with initial state transfer. It was observed in two instances - an Infinispan 7.2.5 cluster with 2 nodes and an Infinispan 7.2.5 cluster with 6 nodes. The two clusters had been running for 2 weeks, the smaller for dev purposes with very light load - about a dozen cached objects. Upon adding an extra node an initial state transfer exception was encountered with both clusters, after about 4 minutes which is the default timeout setting for such situations. Several attempts were made to add a new node, incl. one with increased timeout (10 mins), but state transfer would still not complete, and throw an exception:
{code:java}
"message": "Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl",
"name": "org.infinispan.commons.CacheException",
"cause": {
"commonElementCount": 25,
"localizedMessage": "Initial state transfer timed out for cache authzStore.codeMap on ip-10-180-242-223-40643",
"message": "Initial state transfer timed out for cache authzStore.codeMap on ip-10-180-242-223-40643",
"name": "org.infinispan.commons.CacheException",
"extendedStackTrace": [
{
"class": "org.infinispan.statetransfer.StateTransferManagerImpl",
"method": "waitForInitialStateTransferToComplete",
"file": "StateTransferManagerImpl.java",
"line": 222,
"exact": false,
"location": "StateTransferManagerImpl.class",
"version": "?"
},
{code}
The JMX console reported "stateTransferInProgress=true" and "joinComplete=true".
The original clusters where then shut down and started again together with the new node, after which the clusters were successfully formed.
Attached is the exception stack trace and the JGroups config (based on the stock S3 ping).
was:
Hi guys,
I would like to report a somewhat odd issue with initial state transfer. It was observed in two instances - an Infinispan 7.2.5 cluster with 2 nodes and an Infinispan 7.2.5 cluster with 6 nodes. The two clusters have been running for about a month, the smaller for dev purposes with very light load - about a dozen cached objects. Upon adding an extra node an initial state transfer exception was encountered with both clusters, after about 4 minutes which is the default timeout setting for such situations. Several attempts were made to add a new node, incl. one with increased timeout (10 mins), but state transfer would still not complete, and throw an exception:
{code:java}
"message": "Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl",
"name": "org.infinispan.commons.CacheException",
"cause": {
"commonElementCount": 25,
"localizedMessage": "Initial state transfer timed out for cache authzStore.codeMap on ip-10-180-242-223-40643",
"message": "Initial state transfer timed out for cache authzStore.codeMap on ip-10-180-242-223-40643",
"name": "org.infinispan.commons.CacheException",
"extendedStackTrace": [
{
"class": "org.infinispan.statetransfer.StateTransferManagerImpl",
"method": "waitForInitialStateTransferToComplete",
"file": "StateTransferManagerImpl.java",
"line": 222,
"exact": false,
"location": "StateTransferManagerImpl.class",
"version": "?"
},
{code}
The JMX console reported "stateTransferInProgress=true" and "joinComplete=true".
The original clusters where then shut down and started again together with the new node, after which the clusters were successfully formed.
Attached is the exception stack trace and the JGroups config (based on the stock S3 ping).
> Initial state transfer fails with unexpected timeout
> ----------------------------------------------------
>
> Key: ISPN-6183
> URL: https://issues.jboss.org/browse/ISPN-6183
> Project: Infinispan
> Issue Type: Bug
> Components: State Transfer
> Affects Versions: 7.2.5.Final
> Environment: Java 7 on AWS EC2
> Reporter: Vladimir Dzhuvinov
> Attachments: default-jgroups-s3ping.xml, state-transfer-timeout-stack-trace.txt
>
>
> Hi guys,
> I would like to report a somewhat odd issue with initial state transfer. It was observed in two instances - an Infinispan 7.2.5 cluster with 2 nodes and an Infinispan 7.2.5 cluster with 6 nodes. The two clusters had been running for 2 weeks, the smaller for dev purposes with very light load - about a dozen cached objects. Upon adding an extra node an initial state transfer exception was encountered with both clusters, after about 4 minutes which is the default timeout setting for such situations. Several attempts were made to add a new node, incl. one with increased timeout (10 mins), but state transfer would still not complete, and throw an exception:
> {code:java}
> "message": "Unable to invoke method public void org.infinispan.statetransfer.StateTransferManagerImpl.waitForInitialStateTransferToComplete() throws java.lang.Exception on object of type StateTransferManagerImpl",
> "name": "org.infinispan.commons.CacheException",
> "cause": {
> "commonElementCount": 25,
> "localizedMessage": "Initial state transfer timed out for cache authzStore.codeMap on ip-10-180-242-223-40643",
> "message": "Initial state transfer timed out for cache authzStore.codeMap on ip-10-180-242-223-40643",
> "name": "org.infinispan.commons.CacheException",
> "extendedStackTrace": [
> {
> "class": "org.infinispan.statetransfer.StateTransferManagerImpl",
> "method": "waitForInitialStateTransferToComplete",
> "file": "StateTransferManagerImpl.java",
> "line": 222,
> "exact": false,
> "location": "StateTransferManagerImpl.class",
> "version": "?"
> },
> {code}
> The JMX console reported "stateTransferInProgress=true" and "joinComplete=true".
> The original clusters where then shut down and started again together with the new node, after which the clusters were successfully formed.
> Attached is the exception stack trace and the JGroups config (based on the stock S3 ping).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ISPN-6185) Allow task execution/listing from DMR
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-6185:
-------------------------------------
Summary: Allow task execution/listing from DMR
Key: ISPN-6185
URL: https://issues.jboss.org/browse/ISPN-6185
Project: Infinispan
Issue Type: Sub-task
Components: Server
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 8.2.0.CR1
Expose a series of commands on a cache container in the server to be able to:
* list available tasks
* list running tasks
* execute a task
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ISPN-6182) Scala blueprint generator prevent successfull builds of the core module on JDK 1.9
by Martin Gencur (JIRA)
[ https://issues.jboss.org/browse/ISPN-6182?page=com.atlassian.jira.plugin.... ]
Martin Gencur commented on ISPN-6182:
-------------------------------------
Sanne. The blueprint is generated for other modules too. Not just core. This is now fixed because I changed that to use Java. What do you mean by "we still have the issue of Scala blueprints" ? There's still a problem with Scala in HotRod modules but that is not due to blueprint generation. That's just because HotRod is written in Scala.
> Scala blueprint generator prevent successfull builds of the core module on JDK 1.9
> ----------------------------------------------------------------------------------
>
> Key: ISPN-6182
> URL: https://issues.jboss.org/browse/ISPN-6182
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 8.1.1.Final
> Reporter: Martin Gencur
> Assignee: Martin Gencur
> Fix For: 8.2.0.CR1
>
>
> On JDK 1.9 the build of some modules fails with:
> error: scala.reflect.internal.MissingRequirementError: object java.lang.Object in compiler mirror not found.
> at scala.reflect.internal.MissingRequirementError$.signal(MissingRequirementError.scala:17)
> at scala.reflect.internal.MissingRequirementError$.notFound(MissingRequirementError.scala:18)
> at scala.reflect.internal.Mirrors$RootsBase.getModuleOrClass(Mirrors.scala:53)
> at scala.reflect.internal.Mirrors$RootsBase.getModuleOrClass(Mirrors.scala:45)
> at scala.reflect.internal.Mirrors$RootsBase.getModuleOrClass(Mirrors.scala:45)
> at scala.reflect.internal.Mirrors$RootsBase.getModuleOrClass(Mirrors.scala:66)
> at scala.reflect.internal.Mirrors$RootsBase.getClassByName(Mirrors.scala:102)
> at scala.reflect.internal.Mirrors$RootsBase.getRequiredClass(Mirrors.scala:105)
> at scala.reflect.internal.Definitions$DefinitionsClass.ObjectClass$lzycompute(Definitions.scala:257)
> at scala.reflect.internal.Definitions$DefinitionsClass.ObjectClass(Definitions.scala:257)
> at scala.reflect.internal.Definitions$DefinitionsClass.init(Definitions.scala:1387)
> at scala.tools.nsc.Global$Run.<init>(Global.scala:1053)
> at scala.tools.nsc.Driver.doCompile(Driver.scala:31)
> at scala.tools.nsc.MainClass.doCompile(Main.scala:23)
> at scala.tools.nsc.Driver.process(Driver.scala:51)
> at scala.tools.nsc.Driver.main(Driver.scala:64)
> at scala.tools.nsc.Main.main(Main.scala)
> The underlying problem is https://issues.scala-lang.org/browse/SI-9103 which means that Scala does not work on JDK 1.9 yet.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ISPN-6182) Scala blueprint generator prevent successfull builds of the core module on JDK 1.9
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-6182?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero updated ISPN-6182:
----------------------------------
Summary: Scala blueprint generator prevent successfull builds of the core module on JDK 1.9 (was: Scala blueprint generator does not work on JDK 1.9)
> Scala blueprint generator prevent successfull builds of the core module on JDK 1.9
> ----------------------------------------------------------------------------------
>
> Key: ISPN-6182
> URL: https://issues.jboss.org/browse/ISPN-6182
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 8.1.1.Final
> Reporter: Martin Gencur
> Assignee: Martin Gencur
> Fix For: 8.2.0.CR1
>
>
> On JDK 1.9 the build of some modules fails with:
> error: scala.reflect.internal.MissingRequirementError: object java.lang.Object in compiler mirror not found.
> at scala.reflect.internal.MissingRequirementError$.signal(MissingRequirementError.scala:17)
> at scala.reflect.internal.MissingRequirementError$.notFound(MissingRequirementError.scala:18)
> at scala.reflect.internal.Mirrors$RootsBase.getModuleOrClass(Mirrors.scala:53)
> at scala.reflect.internal.Mirrors$RootsBase.getModuleOrClass(Mirrors.scala:45)
> at scala.reflect.internal.Mirrors$RootsBase.getModuleOrClass(Mirrors.scala:45)
> at scala.reflect.internal.Mirrors$RootsBase.getModuleOrClass(Mirrors.scala:66)
> at scala.reflect.internal.Mirrors$RootsBase.getClassByName(Mirrors.scala:102)
> at scala.reflect.internal.Mirrors$RootsBase.getRequiredClass(Mirrors.scala:105)
> at scala.reflect.internal.Definitions$DefinitionsClass.ObjectClass$lzycompute(Definitions.scala:257)
> at scala.reflect.internal.Definitions$DefinitionsClass.ObjectClass(Definitions.scala:257)
> at scala.reflect.internal.Definitions$DefinitionsClass.init(Definitions.scala:1387)
> at scala.tools.nsc.Global$Run.<init>(Global.scala:1053)
> at scala.tools.nsc.Driver.doCompile(Driver.scala:31)
> at scala.tools.nsc.MainClass.doCompile(Main.scala:23)
> at scala.tools.nsc.Driver.process(Driver.scala:51)
> at scala.tools.nsc.Driver.main(Driver.scala:64)
> at scala.tools.nsc.Main.main(Main.scala)
> The underlying problem is https://issues.scala-lang.org/browse/SI-9103 which means that Scala does not work on JDK 1.9 yet.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months
[JBoss JIRA] (ISPN-6182) Scala blueprint generator prevent successfull builds of the core module on JDK 1.9
by Sanne Grinovero (JIRA)
[ https://issues.jboss.org/browse/ISPN-6182?page=com.atlassian.jira.plugin.... ]
Sanne Grinovero commented on ISPN-6182:
---------------------------------------
I've renamed the issue description as we still have the issue of Scala blueprints not working on JDK9, but at least now we can build infinispan-core.
> Scala blueprint generator prevent successfull builds of the core module on JDK 1.9
> ----------------------------------------------------------------------------------
>
> Key: ISPN-6182
> URL: https://issues.jboss.org/browse/ISPN-6182
> Project: Infinispan
> Issue Type: Bug
> Components: Build process
> Affects Versions: 8.1.1.Final
> Reporter: Martin Gencur
> Assignee: Martin Gencur
> Fix For: 8.2.0.CR1
>
>
> On JDK 1.9 the build of some modules fails with:
> error: scala.reflect.internal.MissingRequirementError: object java.lang.Object in compiler mirror not found.
> at scala.reflect.internal.MissingRequirementError$.signal(MissingRequirementError.scala:17)
> at scala.reflect.internal.MissingRequirementError$.notFound(MissingRequirementError.scala:18)
> at scala.reflect.internal.Mirrors$RootsBase.getModuleOrClass(Mirrors.scala:53)
> at scala.reflect.internal.Mirrors$RootsBase.getModuleOrClass(Mirrors.scala:45)
> at scala.reflect.internal.Mirrors$RootsBase.getModuleOrClass(Mirrors.scala:45)
> at scala.reflect.internal.Mirrors$RootsBase.getModuleOrClass(Mirrors.scala:66)
> at scala.reflect.internal.Mirrors$RootsBase.getClassByName(Mirrors.scala:102)
> at scala.reflect.internal.Mirrors$RootsBase.getRequiredClass(Mirrors.scala:105)
> at scala.reflect.internal.Definitions$DefinitionsClass.ObjectClass$lzycompute(Definitions.scala:257)
> at scala.reflect.internal.Definitions$DefinitionsClass.ObjectClass(Definitions.scala:257)
> at scala.reflect.internal.Definitions$DefinitionsClass.init(Definitions.scala:1387)
> at scala.tools.nsc.Global$Run.<init>(Global.scala:1053)
> at scala.tools.nsc.Driver.doCompile(Driver.scala:31)
> at scala.tools.nsc.MainClass.doCompile(Main.scala:23)
> at scala.tools.nsc.Driver.process(Driver.scala:51)
> at scala.tools.nsc.Driver.main(Driver.scala:64)
> at scala.tools.nsc.Main.main(Main.scala)
> The underlying problem is https://issues.scala-lang.org/browse/SI-9103 which means that Scala does not work on JDK 1.9 yet.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 8 months