[JBoss JIRA] (ISPN-6099) ConcurrentJoinTest random failures
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-6099?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-6099:
------------------------------------
[~belaban] looks like {{SO_REUSEADDR = false}} won't work for our test suite. The point-to-point connections linger for too long and prevent new server sockets from being opened on the same ports, to the point where a port range of {{100}} is not enough, and we get the same {{BindException}} as in the description (only for hundreds of tests, instead of a single one).
Note that when you test a snapshot, you must publish the jar to your local M2 repository with {{mvn install}}, {{ant publish-local}} (or even {{ant publish-local -Dm2-location=$HOME/.m2/repository}}) won't work. Because of [IVY-1476|https://issues.apache.org/jira/browse/IVY-1476], the snapshot published by Ivy doesn't use a unique version number, and Maven 3 will prefer to download a jar with a unique version from a remote repository and use that, regardless of how old that jar is compared to the Ivy snapshot.
> ConcurrentJoinTest random failures
> ----------------------------------
>
> Key: ISPN-6099
> URL: https://issues.jboss.org/browse/ISPN-6099
> Project: Infinispan
> Issue Type: Bug
> Components: Test Suite - Core
> Affects Versions: 8.1.0.Final
> Environment: java version "1.8.0_60"
> Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
> Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 8.2.0.CR1
>
> Attachments: main.cpp
>
>
> Since the switch to {{TCP_NIO2}} in the test suite, I've been seeing random failures in {{ConcurrentJoinTest}} and other tests that attempt to start multiple channels in parallel (e.g. {{StateTransferFunctionalTest}} and its subclasses).
> Normally JGroups only reports a {{java.net.BindException: No available port to bind to in range [8000 .. 8099]}}, but I have modified {{org.jgroups.util.Util.createServerSocket()}} to report the cause exception and I got this:
> {noformat}
> java.net.BindException: No available port to bind to in range [8000 .. 8099]
> at org.jgroups.util.Util.createServerSocketChannel(Util.java:3077) ~[jgroups-3.6.7.Final.jar:3.6.7.Final]
> at org.jgroups.blocks.cs.NioServer.<init>(NioServer.java:86) ~[jgroups-3.6.7.Final.jar:3.6.7.Final]
> at org.jgroups.protocols.TCP_NIO2.start(TCP_NIO2.java:97) ~[jgroups-3.6.7.Final.jar:3.6.7.Final]
> at org.jgroups.stack.ProtocolStack.startStack(ProtocolStack.java:966) ~[jgroups-3.6.7.Final.jar:3.6.7.Final]
> at org.jgroups.JChannel.startStack(JChannel.java:890) ~[jgroups-3.6.7.Final.jar:3.6.7.Final]
> at org.jgroups.JChannel._preConnect(JChannel.java:553) ~[jgroups-3.6.7.Final.jar:3.6.7.Final]
> at org.jgroups.JChannel.connect(JChannel.java:288) ~[jgroups-3.6.7.Final.jar:3.6.7.Final]
> at org.jgroups.JChannel.connect(JChannel.java:279) ~[jgroups-3.6.7.Final.jar:3.6.7.Final]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:199) ~[classes/:?]
> at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:190) ~[classes/:?]
> at sun.reflect.GeneratedMethodAccessor129.invoke(Unknown Source) ~[?:?]
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_60]
> at java.lang.reflect.Method.invoke(Method.java:497) ~[?:1.8.0_60]
> at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:168) ~[infinispan-commons-8.2.0-SNAPSHOT.jar:8.2.0-SNAPSHOT]
> at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:870) ~[classes/:?]
> at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:639) ~[classes/:?]
> at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:628) ~[classes/:?]
> at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:531) ~[classes/:?]
> at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:229) ~[classes/:?]
> ... 11 more
> Caused by: java.net.SocketException: Invalid argument
> at sun.nio.ch.Net.bind0(Native Method) ~[?:1.8.0_60]
> at sun.nio.ch.Net.bind(Net.java:433) ~[?:1.8.0_60]
> at sun.nio.ch.Net.bind(Net.java:425) ~[?:1.8.0_60]
> at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) ~[?:1.8.0_60]
> at java.nio.channels.ServerSocketChannel.bind(ServerSocketChannel.java:157) ~[?:1.8.0_60]
> at org.jgroups.util.Util.createServerSocketChannel(Util.java:3072) ~[jgroups-3.6.7.Final.jar:3.6.7.Final]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 1 month
[JBoss JIRA] (ISPN-6189) Enhance the REST Server to optionally return the value in put and remove calls
by Alan Field (JIRA)
Alan Field created ISPN-6189:
--------------------------------
Summary: Enhance the REST Server to optionally return the value in put and remove calls
Key: ISPN-6189
URL: https://issues.jboss.org/browse/ISPN-6189
Project: Infinispan
Issue Type: Feature Request
Components: Remote Protocols
Affects Versions: 8.1.1.Final
Reporter: Alan Field
Currently the PUT and DELETE methods in the server do not return the previous value when executed. There should be a way to execute these methods and return the previous value, so that a getAndPut and getAndRemove behavior could be implemented. This behavior could be achieved by using a custom header, the cache-control header or the accept header. The default behavior would remain the same. The behavior of the POST method would also remain the same as it is already very similar to a putIfAbsent call.
Not sure there are any HTTP standards for this, and I'm also not sure if any other key-value stores implement this.
https://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
http://tools.ietf.org/html/rfc7231#section-4.3
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ISPN-6188) DMR Script management ops
by Tristan Tarrant (JIRA)
Tristan Tarrant created ISPN-6188:
-------------------------------------
Summary: DMR Script management ops
Key: ISPN-6188
URL: https://issues.jboss.org/browse/ISPN-6188
Project: Infinispan
Issue Type: Sub-task
Components: Server
Reporter: Tristan Tarrant
Assignee: Tristan Tarrant
Fix For: 8.2.0.CR1
Add the following script management ops to the DMR:
* script-add(name=name, code=code)
* script-remove(name=name)
* script-cat(name=name)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ISPN-6125) JMX attribute evictions is always zero in Statistics and ClusterCacheStats MBeans
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-6125?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-6125:
--------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> JMX attribute evictions is always zero in Statistics and ClusterCacheStats MBeans
> ----------------------------------------------------------------------------------
>
> Key: ISPN-6125
> URL: https://issues.jboss.org/browse/ISPN-6125
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Eviction
> Affects Versions: 8.1.1.Final
> Reporter: Martin Vrabel
> Assignee: Martin Gencur
> Fix For: 8.2.0.CR1, 8.1.2.Final
>
>
> Description of problem:
> Eviction is working because numberOfEntries never exceeds maxEntries. But "evictions" attribute displays always 0 in JMX.
> How reproducible:
> Always.
> Actual results:
> evictions is always 0.
> Expected results:
> evictions should be the count of evicted entries.
> Additional info:
> This issue found in both of server and library modes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ISPN-6125) JMX attribute evictions is always zero in Statistics and ClusterCacheStats MBeans
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-6125?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-6125:
--------------------------------
Fix Version/s: 8.1.2.Final
> JMX attribute evictions is always zero in Statistics and ClusterCacheStats MBeans
> ----------------------------------------------------------------------------------
>
> Key: ISPN-6125
> URL: https://issues.jboss.org/browse/ISPN-6125
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Eviction
> Affects Versions: 8.1.1.Final
> Reporter: Martin Vrabel
> Assignee: Martin Gencur
> Fix For: 8.2.0.CR1, 8.1.2.Final
>
>
> Description of problem:
> Eviction is working because numberOfEntries never exceeds maxEntries. But "evictions" attribute displays always 0 in JMX.
> How reproducible:
> Always.
> Actual results:
> evictions is always 0.
> Expected results:
> evictions should be the count of evicted entries.
> Additional info:
> This issue found in both of server and library modes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ISPN-6125) JMX attribute evictions is always zero in Statistics and ClusterCacheStats MBeans
by William Burns (JIRA)
[ https://issues.jboss.org/browse/ISPN-6125?page=com.atlassian.jira.plugin.... ]
William Burns updated ISPN-6125:
--------------------------------
Fix Version/s: 8.2.0.CR1
> JMX attribute evictions is always zero in Statistics and ClusterCacheStats MBeans
> ----------------------------------------------------------------------------------
>
> Key: ISPN-6125
> URL: https://issues.jboss.org/browse/ISPN-6125
> Project: Infinispan
> Issue Type: Bug
> Components: Core, Eviction
> Affects Versions: 8.1.1.Final
> Reporter: Martin Vrabel
> Assignee: Martin Gencur
> Fix For: 8.2.0.CR1
>
>
> Description of problem:
> Eviction is working because numberOfEntries never exceeds maxEntries. But "evictions" attribute displays always 0 in JMX.
> How reproducible:
> Always.
> Actual results:
> evictions is always 0.
> Expected results:
> evictions should be the count of evicted entries.
> Additional info:
> This issue found in both of server and library modes.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ISPN-5965) Add a new mode (READ ONLY) for Partition Handling
by Dan Berindei (JIRA)
[ https://issues.jboss.org/browse/ISPN-5965?page=com.atlassian.jira.plugin.... ]
Dan Berindei commented on ISPN-5965:
------------------------------------
My feeling is that the cluster would spend too much time in read-only mode, as it would have to enter after any node crashes. But I guess the option could be useful if the cache is mostly static and the application can tolerate stale data (as the cache could stay in read-only mode for a very long time).
> Add a new mode (READ ONLY) for Partition Handling
> -------------------------------------------------
>
> Key: ISPN-5965
> URL: https://issues.jboss.org/browse/ISPN-5965
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Reporter: Wolf-Dieter Fink
> Labels: partition_handling
>
> Without any PartitionHandling it is not possible to ensure the consistency of the cache.
> With PH enabled it depends whether the remaining partition has the majority or at least all owners for a particular key to be able to access the key.
> In some cases the prefered behaviour is to keep every entry readable but prevent from any change to keep consistency.
> So there should be a configuration option for the partition handling to switch all instances to READ_ONLY instead of AVAILABLE/DEGRADED.
> In this case each get will return the current value but each put will be rejected with a AvailabilityException
> This prevents from any rebalancing if one partition contains a majority and stay available.
> But in case of a real instance crash it might need a human interaction to set the state back to AVAILABLE as the node will never come back to the cluster.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (ISPN-5965) Add a new mode (READ ONLY) for Partition Handling
by Wolf-Dieter Fink (JIRA)
[ https://issues.jboss.org/browse/ISPN-5965?page=com.atlassian.jira.plugin.... ]
Wolf-Dieter Fink closed ISPN-5965.
----------------------------------
Resolution: Duplicate Issue
> Add a new mode (READ ONLY) for Partition Handling
> -------------------------------------------------
>
> Key: ISPN-5965
> URL: https://issues.jboss.org/browse/ISPN-5965
> Project: Infinispan
> Issue Type: Feature Request
> Components: Core
> Reporter: Wolf-Dieter Fink
> Labels: partition_handling
>
> Without any PartitionHandling it is not possible to ensure the consistency of the cache.
> With PH enabled it depends whether the remaining partition has the majority or at least all owners for a particular key to be able to access the key.
> In some cases the prefered behaviour is to keep every entry readable but prevent from any change to keep consistency.
> So there should be a configuration option for the partition handling to switch all instances to READ_ONLY instead of AVAILABLE/DEGRADED.
> In this case each get will return the current value but each put will be rejected with a AvailabilityException
> This prevents from any rebalancing if one partition contains a majority and stay available.
> But in case of a real instance crash it might need a human interaction to set the state back to AVAILABLE as the node will never come back to the cluster.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months