November 2019 - infinispan-issues

[JBoss JIRA] (ISPN-10887) GlobalJmxStatisticsConfiguration.allowDuplicateDomains is not implemented atomically and can fail frequently

by Nistor Adrian (Jira)

Nistor Adrian created ISPN-10887: ------------------------------------ Summary: GlobalJmxStatisticsConfiguration.allowDuplicateDomains is not implemented atomically and can fail frequently Key: ISPN-10887 URL: https://issues.jboss.org/browse/ISPN-10887 Project: Infinispan Issue Type: Bug Components: JMX, reporting and management Affects Versions: 10.0.0.Final Reporter: Nistor Adrian Assignee: Nistor Adrian The feature is supposed to allow detection of an already occupied jmx domain and generate a new unique one by adding an increasing number suffix. The implementation polls the MBeanServer registry using queryNames until a free domain is found. The unique domain generation and the registration of the first MBean to occupy it is not atomic, so multiple CacheManagers starting up concurrently can mistakenly pick up the same domain. This can be fixed by making it atomic, by not using queryNames and instead directly registering the first bean, retrying if InstanceAlreadyExistsException. The first bean has to be picked identically by all cache managers. We'll pick first the cache manager itself and register the other components afterwards. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10863) java.lang.IllegalAccessException logged by PropertyFormatter

by Nistor Adrian (Jira)

[ https://issues.jboss.org/browse/ISPN-10863?page=com.atlassian.jira.plugin... ] Nistor Adrian updated ISPN-10863: --------------------------------- Fix Version/s: 10.0.2.Final > java.lang.IllegalAccessException logged by PropertyFormatter > ------------------------------------------------------------- > > Key: ISPN-10863 > URL: https://issues.jboss.org/browse/ISPN-10863 > Project: Infinispan > Issue Type: Bug > Components: Configuration > Affects Versions: 10.0.0.Final > Reporter: Nistor Adrian > Assignee: Nistor Adrian > Priority: Major > Fix For: 10.1.0.Beta1, 10.0.2.Final > > > This is a benign issue being logged by AccessibleObject when PropertyFormatter attempts to accesses via reflection some config methods that are not accessible. JmxStatsFunctionalTest is one good example, and it's not failing because of this. > {code} > java.lang.IllegalAccessException: class org.infinispan.configuration.format.PropertyFormatter cannot access a member of class org.infinispan.configuration.cache.AuthorizationConfiguration with modifiers "static final" > at java.base/jdk.internal.reflect.Reflection.newIllegalAccessException(Reflection.java:361) > at java.base/java.lang.reflect.AccessibleObject.checkAccess(AccessibleObject.java:591) > at java.base/java.lang.reflect.Method.invoke(Method.java:558) > at org.infinispan.configuration.format.PropertyFormatter.reflect(PropertyFormatter.java:101) > at org.infinispan.configuration.format.PropertyFormatter.reflect(PropertyFormatter.java:110) > at org.infinispan.configuration.format.PropertyFormatter.reflect(PropertyFormatter.java:101) > at org.infinispan.configuration.format.PropertyFormatter.reflect(PropertyFormatter.java:101) > at org.infinispan.configuration.format.PropertyFormatter.format(PropertyFormatter.java:131) > at org.infinispan.cache.impl.AbstractDelegatingCache.getConfigurationAsProperties(AbstractDelegatingCache.java:616) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at org.infinispan.jmx.ResourceDMBean$InvokableSetterBasedMBeanAttributeInfo.invoke(ResourceDMBean.java:378) > at org.infinispan.jmx.ResourceDMBean.getNamedAttribute(ResourceDMBean.java:289) > at org.infinispan.jmx.ResourceDMBean.getAttribute(ResourceDMBean.java:172) > at java.management/com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getAttribute(DefaultMBeanServerInterceptor.java:641) > at java.management/com.sun.jmx.mbeanserver.JmxMBeanServer.getAttribute(JmxMBeanServer.java:678) > at org.infinispan.jmx.JmxStatsFunctionalTest.testConfigurationProperties(JmxStatsFunctionalTest.java:307) > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10886) Server side objects implementing Serializable causes serialization errors

by Gustavo Fernandes (Jira)

Gustavo Fernandes created ISPN-10886: ---------------------------------------- Summary: Server side objects implementing Serializable causes serialization errors Key: ISPN-10886 URL: https://issues.jboss.org/browse/ISPN-10886 Project: Infinispan Issue Type: Bug Components: Server Affects Versions: 10.0.1.Final, 10.0.0.Final Reporter: Gustavo Fernandes This changed between 10.0.0.CR3 and 10.0.1.Final: filters/converters/entities deployed on the server that implements Serializable don't work any more: although JBoss Marshaller is in the classpath and the Hot Rod client users Jboss marshaller, it tries to use protostream to replicate commands involving those objects The workaround it to annotate all of them with @SerializeWith and write Externalizers -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10885) REST Reindex action

by Tristan Tarrant (Jira)

Tristan Tarrant created ISPN-10885: -------------------------------------- Summary: REST Reindex action Key: ISPN-10885 URL: https://issues.jboss.org/browse/ISPN-10885 Project: Infinispan Issue Type: Feature Request Components: Remote Querying, REST Affects Versions: 10.0.1.Final Reporter: Tristan Tarrant Assignee: Gustavo Fernandes Fix For: 10.1.0.Final The Cache rest resource should implement a /rest/v2/caches/{cacheName}?action=reindex&mode=[sync|async] The method should return a 200 OK for sync and 202 Accepted for async reindex. It should also not initiate a new reindexing if one is running already and return 409 Conflict. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10883) [REST] Simultaneous call to stop don't stop the servers

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/ISPN-10883?page=com.atlassian.jira.plugin... ] Gustavo Fernandes updated ISPN-10883: ------------------------------------- Description: This was observed in a cluster of 3 servers in the same machine, listening on ports 11222, 11322, 11422. A script would call stop on each of the server individually: http://localhost:11222/rest/v2/server?action=stop http://localhost:11322/rest/v2/server?action=stop http://localhost:11422/rest/v2/server?action=stop All the commands return code 200 but the servers are not stopped, the processes are still alive. This is a regression from 10.0.0.CR3 where those ops were working correctly. was: This was observed in a cluster of 3 servers in the same machine, listening on ports 11222, 11322, 11422. A script would call stop on each of the server individually: http://localhost:11222/rest/v2/server?action=stop http://localhost:11322/rest/v2/server?action=stop http://localhost:11422/rest/v2/server?action=stop All the commands return code 200 but the servers are not stopped, the processes are still alive. > [REST] Simultaneous call to stop don't stop the servers > ------------------------------------------------------- > > Key: ISPN-10883 > URL: https://issues.jboss.org/browse/ISPN-10883 > Project: Infinispan > Issue Type: Bug > Components: REST, Server > Affects Versions: 10.0.0.Final, 10.0.1.Final > Reporter: Gustavo Fernandes > Assignee: Tristan Tarrant > Priority: Major > > This was observed in a cluster of 3 servers in the same machine, listening on ports 11222, 11322, 11422. A script would call stop on each of the server individually: > http://localhost:11222/rest/v2/server?action=stop > http://localhost:11322/rest/v2/server?action=stop > http://localhost:11422/rest/v2/server?action=stop > All the commands return code 200 but the servers are not stopped, the processes are still alive. > This is a regression from 10.0.0.CR3 where those ops were working correctly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10883) [REST] Simultaneous call to stop don't stop the servers

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/ISPN-10883?page=com.atlassian.jira.plugin... ] Gustavo Fernandes updated ISPN-10883: ------------------------------------- Affects Version/s: 10.0.1.Final 10.0.0.Final > [REST] Simultaneous call to stop don't stop the servers > ------------------------------------------------------- > > Key: ISPN-10883 > URL: https://issues.jboss.org/browse/ISPN-10883 > Project: Infinispan > Issue Type: Bug > Components: REST, Server > Affects Versions: 10.0.0.Final, 10.0.1.Final > Reporter: Gustavo Fernandes > Assignee: Tristan Tarrant > Priority: Major > > This was observed in a cluster of 3 servers in the same machine, listening on ports 11222, 11322, 11422. A script would call stop on each of the server individually: > http://localhost:11222/rest/v2/server?action=stop > http://localhost:11322/rest/v2/server?action=stop > http://localhost:11422/rest/v2/server?action=stop > All the commands return code 200 but the servers are not stopped, the processes are still alive. > This is a regression from 10.0.0.CR3 where those ops were working correctly. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10883) [REST] Simultaneous call to stop don't stop the servers

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/ISPN-10883?page=com.atlassian.jira.plugin... ] Gustavo Fernandes reassigned ISPN-10883: ---------------------------------------- Assignee: Tristan Tarrant > [REST] Simultaneous call to stop don't stop the servers > ------------------------------------------------------- > > Key: ISPN-10883 > URL: https://issues.jboss.org/browse/ISPN-10883 > Project: Infinispan > Issue Type: Bug > Components: REST, Server > Affects Versions: 10.0.0.Final, 10.0.1.Final > Reporter: Gustavo Fernandes > Assignee: Tristan Tarrant > Priority: Major > > This was observed in a cluster of 3 servers in the same machine, listening on ports 11222, 11322, 11422. A script would call stop on each of the server individually: > http://localhost:11222/rest/v2/server?action=stop > http://localhost:11322/rest/v2/server?action=stop > http://localhost:11422/rest/v2/server?action=stop > All the commands return code 200 but the servers are not stopped, the processes are still alive. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-10883) [REST] Simultaneous call to stop don't stop the servers

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/ISPN-10883?page=com.atlassian.jira.plugin... ] Gustavo Fernandes updated ISPN-10883: ------------------------------------- Summary: [REST] Simultaneous call to stop don't stop the servers (was: [REST] Simulataneous call to stop don't stop the servers) > [REST] Simultaneous call to stop don't stop the servers > ------------------------------------------------------- > > Key: ISPN-10883 > URL: https://issues.jboss.org/browse/ISPN-10883 > Project: Infinispan > Issue Type: Bug > Components: REST, Server > Reporter: Gustavo Fernandes > Priority: Major > > This was observed in a cluster of 3 servers in the same machine, listening on ports 11222, 11322, 11422. A script would call stop on each of the server individually: > http://localhost:11222/rest/v2/server?action=stop > http://localhost:11322/rest/v2/server?action=stop > http://localhost:11422/rest/v2/server?action=stop > All the commands return code 200 but the servers are not stopped, the processes are still alive. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9620) Rolling Upgrade Marshaller Changes

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/ISPN-9620?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes edited comment on ISPN-9620 at 11/4/19 2:40 AM: ------------------------------------------------------------------ "Protocol buffers should be utilised as the wire/storage format, with protostream providing the implementation." Is about a core-scoped rolling upgrade? Or related to the current Rolling Upgrade that happens over hot rod? For the current procedure, a server can store data in any format: JBoss marshalled, UTF-8, protostream, octect-stream, etc. When migrating data from a cluster to another, it all happens via Hot Rod with "raw" data, that is, data is iterated in the source cluster and stored in the new cluster in the same format, so it does not make sense to use the same marshaller between two clusters was (Author: gustavonalle): "Protocol buffers should be utilised as the wire/storage format, with protostream providing the implementation." Not sure I understand this, as a server can store data in any format: JBoss marshalled, UTF-8, protostream, octect-stream, etc. When migrating data from a cluster to another via Rolling Upgrade, it all happens via Hot Rod with "raw" data, that is, data is iterated in the source cluster and stored in the new cluster in the same format > Rolling Upgrade Marshaller Changes > ---------------------------------- > > Key: ISPN-9620 > URL: https://issues.jboss.org/browse/ISPN-9620 > Project: Infinispan > Issue Type: Enhancement > Components: Core, Loaders and Stores > Affects Versions: 9.4.0.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.1.0.Final > > > In order to allow for compatibility between infinispan versions it is necessary for us to utilise a marshalling implementation at both the cluster (internal node-to-node communication) and persistence layer that is strictly defined but allows for future changes. This is necessary in order to facilitate both rolling and start/stop upgrades. Protocol buffers should be utilised as the wire/storage format, with protostream providing the implementation. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-9620) Rolling Upgrade Marshaller Changes

by Gustavo Fernandes (Jira)

[ https://issues.jboss.org/browse/ISPN-9620?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes edited comment on ISPN-9620 at 11/4/19 2:34 AM: ------------------------------------------------------------------ "Protocol buffers should be utilised as the wire/storage format, with protostream providing the implementation." Not sure I understand this, as a server can store data in any format: JBoss marshalled, UTF-8, protostream, octect-stream, etc. When migrating data from a cluster to another via Rolling Upgrade, it all happens via Hot Rod with "raw" data, that is, data is iterated in the source cluster and stored in the new cluster in the same format was (Author: gustavonalle): "Protocol buffers should be utilised as the wire/storage format, with protostream providing the implementation." Not sure I understand this, as a server can store data in any format: JBoss marshalled, UTF-8, protostream, octect-stream, etc. When migrating data from a cluster to another via Rolling Upgrade, it all happens via Hot Rod with "raw" data, that is, data is iterated in the source cluster and stored in the new cluster in the same format as its stored. > Rolling Upgrade Marshaller Changes > ---------------------------------- > > Key: ISPN-9620 > URL: https://issues.jboss.org/browse/ISPN-9620 > Project: Infinispan > Issue Type: Enhancement > Components: Core, Loaders and Stores > Affects Versions: 9.4.0.Final > Reporter: Ryan Emerson > Assignee: Ryan Emerson > Priority: Major > Fix For: 10.1.0.Final > > > In order to allow for compatibility between infinispan versions it is necessary for us to utilise a marshalling implementation at both the cluster (internal node-to-node communication) and persistence layer that is strictly defined but allows for future changes. This is necessary in order to facilitate both rolling and start/stop upgrades. Protocol buffers should be utilised as the wire/storage format, with protostream providing the implementation. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 2 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues November 2019