March 2017 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-7626) eventType is null when CacheEventConverter.convert() is called

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-7626?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-7626: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.0.0.Final Resolution: Done > eventType is null when CacheEventConverter.convert() is called > --------------------------------------------------------------- > > Key: ISPN-7626 > URL: https://issues.jboss.org/browse/ISPN-7626 > Project: Infinispan > Issue Type: Bug > Affects Versions: 9.0.0.CR3 > Reporter: Vittorio Rigamonti > Assignee: Vittorio Rigamonti > Fix For: 9.0.0.Final > > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7628) Administration console - the cluster status doesn't reflect "reload-required" state of its nodes

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-7628?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic commented on ISPN-7628: ------------------------------------------- [~ryanemerson] [~rmacor] We can expand cluster status options if needed. So far we had "STARTED", "STOPPED" and "DEGRADED". We can expand it to "STARTED", "RELOAD-REQUIRED", "RESTART-REQUIRED", "STOPPED" and "DEGRADED". The new statuses "RELOAD-REQUIRED" and "RESTART-REQUIRED" are turned on only if all cluster nodes are in those states. If for some reason not all nodes are in the same state we could use "DEGRADED". Thoughts? > Administration console - the cluster status doesn't reflect "reload-required" state of its nodes > ------------------------------------------------------------------------------------------------ > > Key: ISPN-7628 > URL: https://issues.jboss.org/browse/ISPN-7628 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 9.0.0.CR2 > Reporter: Roman Macor > Assignee: Vladimir Blagojevic > > The cluster has "Started" status even though all of its nodes have "reload-required" status. > Expected result: > The cluster status should also be "reload-required" > Another suggestion: > "Reload" action should be available from the cluster so that the user doesn't need to perform this action on individual nodes (there could be hundreds of them ) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7627) Add test to verify off heap and binary storage work with indexing

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7627?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-7627: ------------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Add test to verify off heap and binary storage work with indexing > ----------------------------------------------------------------- > > Key: ISPN-7627 > URL: https://issues.jboss.org/browse/ISPN-7627 > Project: Infinispan > Issue Type: Bug > Reporter: William Burns > Assignee: William Burns > Fix For: 9.0.0.Final > > > We should add some more tests to verify querying works properly with other storage types such as OFF_HEAP and BINARY. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7637) Administration console - minor issue in cache configuration

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-7637?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic reassigned ISPN-7637: ----------------------------------------- Assignee: Ryan Emerson > Administration console - minor issue in cache configuration > ----------------------------------------------------------- > > Key: ISPN-7637 > URL: https://issues.jboss.org/browse/ISPN-7637 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 9.0.0.CR2 > Reporter: Roman Macor > Assignee: Ryan Emerson > Priority: Minor > > The issue is that when the user opens one of the pop-up dialogs in cache configuration (e.g. cache store -> Write behind), doesn't change anything and clicks OK, make some other changes, there is an error pop up when they try to save changes. > Steps to reproduce: > Set up a file store: > Cache container -> cache -> configuration -> Store tab -> Select file store -> apply -> ok -> restart later > Make a change: > - Cache container -> cache -> configuration -> Store tab > - change an attribute e.g. Read Only > - click on write behind (Don't change anything) -> click OK (WORKAROUND: if we click Cancel here instead of OK, everything works fine) > - apply changes -> confirm > result: > Error pop-up: > {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:":{"Operation step-5":"WFLYCTL0201: Unknown attribute 'modified'"}} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7638) Observing non-final values on backup owner

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-7638?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-7638: ------------------------------ Labels: consistency (was: ) > Observing non-final values on backup owner > ------------------------------------------ > > Key: ISPN-7638 > URL: https://issues.jboss.org/browse/ISPN-7638 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Radim Vansa > Assignee: Radim Vansa > Labels: consistency > > Regardless of storing command invocations, reading value on backup owner in non-tx cache can always lead to publishing value that should not ever been in the cache: > 1. initial value is A > 2. T1 calls replace A -> B, backup stores this value, primary is delayed > 3. T2 reads value B > 4. T3 puts C, currently blocked at primary > 5. topology change, both T1 and T3 have to retry > 6. T3 retries and updates both primary and backup > 7. T1 retries and returns false, because the current value is C, not A > Therefore, B should have never been stored in the cache but it was observed there. > Recording the operation T1 on primary cannot help, because we would be in a similar situation if primary crashed and we had two backups - the backup that becomes primary might not have received the operation at all. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7638) Observing non-final values on backup owner

by Radim Vansa (JIRA)

Radim Vansa created ISPN-7638: --------------------------------- Summary: Observing non-final values on backup owner Key: ISPN-7638 URL: https://issues.jboss.org/browse/ISPN-7638 Project: Infinispan Issue Type: Bug Components: Core Reporter: Radim Vansa Assignee: Radim Vansa Regardless of storing command invocations, reading value on backup owner in non-tx cache can always lead to publishing value that should not ever been in the cache: 1. initial value is A 2. T1 calls replace A -> B, backup stores this value, primary is delayed 3. T2 reads value B 4. T3 puts C, currently blocked at primary 5. topology change, both T1 and T3 have to retry 6. T3 retries and updates both primary and backup 7. T1 retries and returns false, because the current value is C, not A Therefore, B should have never been stored in the cache but it was observed there. Recording the operation T1 on primary cannot help, because we would be in a similar situation if primary crashed and we had two backups - the backup that becomes primary might not have received the operation at all. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7637) Administration console - minor issue in cache configuration

by Roman Macor (JIRA)

Roman Macor created ISPN-7637: --------------------------------- Summary: Administration console - minor issue in cache configuration Key: ISPN-7637 URL: https://issues.jboss.org/browse/ISPN-7637 Project: Infinispan Issue Type: Bug Components: JMX, reporting and management Affects Versions: 9.0.0.CR2 Reporter: Roman Macor Priority: Minor The issue is that when the user opens one of the pop-up dialogs in cache configuration (e.g. cache store -> Write behind), doesn't change anything and clicks OK, make some other changes, there is an error pop up when they try to save changes. Steps to reproduce: Set up a file store: Cache container -> cache -> configuration -> Store tab -> Select file store -> apply -> ok -> restart later Make a change: - Cache container -> cache -> configuration -> Store tab - change an attribute e.g. Read Only - click on write behind (Don't change anything) -> click OK (WORKAROUND: if we click Cancel here instead of OK, everything works fine) - apply changes -> confirm result: Error pop-up: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:":{"Operation step-5":"WFLYCTL0201: Unknown attribute 'modified'"}} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7572) Infinispan initialization via DirectoryProvider can't use any CacheStore or other extensions

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7572?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-7572: ------------------------------------ Status: Resolved (was: Pull Request Sent) Resolution: Done > Infinispan initialization via DirectoryProvider can't use any CacheStore or other extensions > -------------------------------------------------------------------------------------------- > > Key: ISPN-7572 > URL: https://issues.jboss.org/browse/ISPN-7572 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores, Lucene Directory, WildFly modules > Affects Versions: 9.0.0.CR2, 8.2.6.Final > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Critical > Fix For: 9.0.0.Final, 8.2.7.Final > > > When the Infinispan CacheManager is bootstrapped via Hibernate Search, the Infinispan modules are not necessarily visible to the deployment classpath (the TCCL). > In this case if the configuration file refers to any extension such as a {{CacheStore}}, Infinispan will fail to start as it doesn't depend on the modules of its extensions. > This will cause puzzling errors such as : > {{ISPN000327: Cannot find a parser for element 'string-keyed-jdbc-store' in namespace 'urn:infinispan:config:store:jdbc:8.0'. Check that your configuration is up-to date for this version of Infinispan.}} > For the record, the fact that the configuration parser expects to use the TCCL is an old problem which I've highlighted already in the past: > Explicit classloader support during parsing was introduced in 2013: > - http://lists.jboss.org/pipermail/infinispan-dev/2013-April/012590.html > Then removed again in 2014: > - http://lists.jboss.org/pipermail/infinispan-dev/2014-May/014952.html > I asked for improvements and hoped for someone to take ownership: > - http://lists.jboss.org/pipermail/infinispan-dev/2014-October/015549.html > In this last email I explained what Hibernate Search would do, in lack of better alternatives..and so we did. > Finally, this component of Hibernate Search code was transferred to the Infinispan repository so luckily we can change both components as you see most fit; the only requirement is to not expect the Hibernate users to have Infinispan on their TCCL. > My proposal is simple: the Infinispan-core module should have an optional dependency to its extensions, including at least all supported CacheStore implementations so that people can use them. > In fact, I expected them to do as it feels natural to have a graph edge towards extension points to be able to load them. > But [~NadirX] doesn't like that, so assigning the issue to him ;-) > Alternative ideas: > * allow people to mention module names explicitly in the Infinispan configuration? > * have a module which bootstraps the CacheManager, depending explicitly on all extensions, and register it over JNDI > I favour the second option, especially as it came up before as a dire pratical need for many other situations. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7572) Infinispan initialization via DirectoryProvider can't use any CacheStore or other extensions

by Gustavo Fernandes (JIRA)

[ https://issues.jboss.org/browse/ISPN-7572?page=com.atlassian.jira.plugin.... ] Gustavo Fernandes updated ISPN-7572: ------------------------------------ Fix Version/s: (was: 8.2.7.Final) > Infinispan initialization via DirectoryProvider can't use any CacheStore or other extensions > -------------------------------------------------------------------------------------------- > > Key: ISPN-7572 > URL: https://issues.jboss.org/browse/ISPN-7572 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores, Lucene Directory, WildFly modules > Affects Versions: 9.0.0.CR2, 8.2.6.Final > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Critical > Fix For: 9.0.0.Final > > > When the Infinispan CacheManager is bootstrapped via Hibernate Search, the Infinispan modules are not necessarily visible to the deployment classpath (the TCCL). > In this case if the configuration file refers to any extension such as a {{CacheStore}}, Infinispan will fail to start as it doesn't depend on the modules of its extensions. > This will cause puzzling errors such as : > {{ISPN000327: Cannot find a parser for element 'string-keyed-jdbc-store' in namespace 'urn:infinispan:config:store:jdbc:8.0'. Check that your configuration is up-to date for this version of Infinispan.}} > For the record, the fact that the configuration parser expects to use the TCCL is an old problem which I've highlighted already in the past: > Explicit classloader support during parsing was introduced in 2013: > - http://lists.jboss.org/pipermail/infinispan-dev/2013-April/012590.html > Then removed again in 2014: > - http://lists.jboss.org/pipermail/infinispan-dev/2014-May/014952.html > I asked for improvements and hoped for someone to take ownership: > - http://lists.jboss.org/pipermail/infinispan-dev/2014-October/015549.html > In this last email I explained what Hibernate Search would do, in lack of better alternatives..and so we did. > Finally, this component of Hibernate Search code was transferred to the Infinispan repository so luckily we can change both components as you see most fit; the only requirement is to not expect the Hibernate users to have Infinispan on their TCCL. > My proposal is simple: the Infinispan-core module should have an optional dependency to its extensions, including at least all supported CacheStore implementations so that people can use them. > In fact, I expected them to do as it feels natural to have a graph edge towards extension points to be able to load them. > But [~NadirX] doesn't like that, so assigning the issue to him ;-) > Alternative ideas: > * allow people to mention module names explicitly in the Infinispan configuration? > * have a module which bootstraps the CacheManager, depending explicitly on all extensions, and register it over JNDI > I favour the second option, especially as it came up before as a dire pratical need for many other situations. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

[JBoss JIRA] (ISPN-7636) HR 2.6 decoder misreads add client listener command

by Vojtech Juranek (JIRA)

[ https://issues.jboss.org/browse/ISPN-7636?page=com.atlassian.jira.plugin.... ] Vojtech Juranek updated ISPN-7636: ---------------------------------- Status: Open (was: New) > HR 2.6 decoder misreads add client listener command > --------------------------------------------------- > > Key: ISPN-7636 > URL: https://issues.jboss.org/browse/ISPN-7636 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols > Affects Versions: 9.0.0.CR2 > Reporter: Vojtech Juranek > Assignee: Vojtech Juranek > Priority: Critical > > HR 2.6 decoder misreads add client listener command, expecting more input form client, which results in hanged HR client, waiting for response from server: > {noformat} > java.lang.Thread.State: RUNNABLE > at sun.nio.ch.Net.poll(Native Method) > at sun.nio.ch.SocketChannelImpl.poll(SocketChannelImpl.java:954) > - locked <0x00000000d6ea7db0> (a java.lang.Object) > at sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:204) > - locked <0x00000000d6ea7da0> (a java.lang.Object) > at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103) > - locked <0x00000000d6ea80d0> (a sun.nio.ch.SocketAdaptor$SocketInputStream) > at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) > at java.io.BufferedInputStream.read(BufferedInputStream.java:265) > - locked <0x00000000d6ea7f30> (a java.io.BufferedInputStream) > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.readByte(TcpTransport.java:220) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readMagic(Codec20.java:325) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeaderOrEvent(Codec20.java:225) > at org.infinispan.client.hotrod.impl.operations.AddClientListenerOperation.executeOperation(AddClientListenerOperation.java:97) > at org.infinispan.client.hotrod.impl.operations.AddClientListenerOperation.executeOperation(AddClientListenerOperation.java:27) > at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:56) > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.addClientListener(RemoteCacheImpl.java:439) > {noformat} > Can be easily reproduced with many tests from HR client testsuite (e.g. {{ClusterInvalidatedNearCacheTest}}) - tests just hangs -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues March 2017