January 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6116) query-dsl module shoud use jboss-logging

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6116?page=com.atlassian.jira.plugin.... ] Work on ISPN-6116 started by Adrian Nistor. ------------------------------------------- > query-dsl module shoud use jboss-logging > ---------------------------------------- > > Key: ISPN-6116 > URL: https://issues.jboss.org/browse/ISPN-6116 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.1.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.2.0.Beta1, 8.2.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6116) query-dsl module shoud use jboss-logging

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-6116: ----------------------------------- Summary: query-dsl module shoud use jboss-logging Key: ISPN-6116 URL: https://issues.jboss.org/browse/ISPN-6116 Project: Infinispan Issue Type: Bug Affects Versions: 8.1.0.Final Reporter: Adrian Nistor Assignee: Adrian Nistor Fix For: 8.2.0.Beta1, 8.2.0.Final -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6116) query-dsl module shoud use jboss-logging

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6116?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-6116: -------------------------------- Status: Open (was: New) > query-dsl module shoud use jboss-logging > ---------------------------------------- > > Key: ISPN-6116 > URL: https://issues.jboss.org/browse/ISPN-6116 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.1.0.Final > Reporter: Adrian Nistor > Assignee: Adrian Nistor > Fix For: 8.2.0.Beta1, 8.2.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6115) org.infinispan.tasks.logging.Log uses conflicting logging ids

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6115?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-6115: -------------------------------- Affects Version/s: 8.1.0.Final (was: 8.0.2.Final) > org.infinispan.tasks.logging.Log uses conflicting logging ids > ------------------------------------------------------------- > > Key: ISPN-6115 > URL: https://issues.jboss.org/browse/ISPN-6115 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.1.0.Final > Reporter: Adrian Nistor > Assignee: Tristan Tarrant > Fix For: 8.2.0.Beta1 > > > org.infinispan.tasks.logging.Log uses range 22001 to 23000, same as org.infinispan.persistence.rest.logging.Log. > The next free range is 24001-25000 (considering all modules in the ispn tree). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6115) org.infinispan.tasks.logging.Log uses conflicting logging ids

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6115?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-6115: -------------------------------- Status: Open (was: New) > org.infinispan.tasks.logging.Log uses conflicting logging ids > ------------------------------------------------------------- > > Key: ISPN-6115 > URL: https://issues.jboss.org/browse/ISPN-6115 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.0.2.Final > Reporter: Adrian Nistor > Assignee: Tristan Tarrant > Fix For: 8.2.0.Beta1 > > > org.infinispan.tasks.logging.Log uses range 22001 to 23000, same as org.infinispan.persistence.rest.logging.Log. > The next free range is 24001-25000 (considering all modules in the ispn tree). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6115) org.infinispan.tasks.logging.Log uses conflicting logging ids

by Adrian Nistor (JIRA)

Adrian Nistor created ISPN-6115: ----------------------------------- Summary: org.infinispan.tasks.logging.Log uses conflicting logging ids Key: ISPN-6115 URL: https://issues.jboss.org/browse/ISPN-6115 Project: Infinispan Issue Type: Bug Affects Versions: 8.0.2.Final Reporter: Adrian Nistor Assignee: Tristan Tarrant Fix For: 8.2.0.Beta1 org.infinispan.tasks.logging.Log uses range 22001 to 23000, same as org.infinispan.persistence.rest.logging.Log. The next free range is 24001-25000 (considering all modules in the ispn tree). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6061) Cache Enum.values()

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6061?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6061: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 8.2.0.Final Resolution: Done > Cache Enum.values() > ------------------- > > Key: ISPN-6061 > URL: https://issues.jboss.org/browse/ISPN-6061 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 8.0.2.Final > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 8.2.0.Beta1, 8.2.0.Final > > > For safety reason, Enum.values() clones the values array in each invocation. Although the cloning is fast, it creates a lot of garbage (as it is used in every Enum unmarshalling). Cache it avoids cloning it every time. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[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: ------------------------------------ The [{{socket()}} man page|http://linux.die.net/man/7/socket] says about {{SO_REUSEADDR}} "For AF_INET sockets this means that a socket may bind, except when there is an active listening socket bound to the address." So 2 sockets can bind to the same port, as long as only one of them calls {{listen()}} and becomes an _active listening socket_ (i.e. a _server socket_). In Java, {{ServerSocket}} only has a {{bind()}} method, which suggests that it atomically binds to the port and listens to it. But in fact this is not atomic, and it's entirely possible to fail in the {{listen()}} system call. When that happens, {{ServerSocket.bind()}} throws a {{SocketException}} (as opposed to a {{BindException}}, if the failure happens in the {{bind()}} system call). The {{ServerSocket}} then becomes invalid, because its corresponding OS socket if bound to a port, but it can't accept connections, and calling {{ServerSocket.bind()}} again will fail - this time with a {{BindException}}. > 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.Beta1 > > > 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)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6095) TransportStackConfigurationIT fails since the upgrade to JGroups 3.6.7.Final

by Tristan Tarrant (JIRA)

[ https://issues.jboss.org/browse/ISPN-6095?page=com.atlassian.jira.plugin.... ] Tristan Tarrant updated ISPN-6095: ---------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 8.2.0.Final Resolution: Done > TransportStackConfigurationIT fails since the upgrade to JGroups 3.6.7.Final > ---------------------------------------------------------------------------- > > Key: ISPN-6095 > URL: https://issues.jboss.org/browse/ISPN-6095 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Server > Affects Versions: 8.1.0.Final > Reporter: Dan Berindei > Assignee: Dan Berindei > Fix For: 8.2.0.Beta1, 8.2.0.Final > > > JGroups changed the default rejection policy to {{abort}} with JGRP-1965, but TransportStackConfigurationIT still assumes it's {{discard}}. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5920) Displaying caches in management console doesn't detect XSite replication correctly

by Jiří Holuša (JIRA)

[ https://issues.jboss.org/browse/ISPN-5920?page=com.atlassian.jira.plugin.... ] Jiří Holuša commented on ISPN-5920: ----------------------------------- Hi [~vblagojevic], I see this JIRA resolved, but I'm still experiencing the issue described. Using snapshots of both server and mgmt console. > Displaying caches in management console doesn't detect XSite replication correctly > ---------------------------------------------------------------------------------- > > Key: ISPN-5920 > URL: https://issues.jboss.org/browse/ISPN-5920 > Project: Infinispan > Issue Type: Bug > Components: Console > Affects Versions: 8.1.0.Alpha2 > Reporter: Jiří Holuša > Assignee: Vladimir Blagojevic > Fix For: 8.2.0.Beta1, 8.2.0.Final > > > Page "Caches" tab -> click on certain cache container: list of caches in that container is shown. > Having cache configured e.g. line this: > {code} > <distributed-cache name="memcachedCache" ...> > <backups> > <backup site="BRN" strategy="SYNC"/> > </backups> > </distributed-cache> > {code} > In the UI, when I click Trait > Remote backup filter, the cache is not shown in the results. Truth is that I don't actually have the BRN site running, however, when I look through the jconsole to MBean, the XSiteAdmin bean is there and I'm able to call operations on it, e.g. pushState (of course fails, because I don't have the site there). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 4 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues January 2016