June 2016 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-6744) ClusterEvent doesn't implement CacheEntryExpired

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-6744?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-6744: -------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/4385 > ClusterEvent doesn't implement CacheEntryExpired > ------------------------------------------------ > > Key: ISPN-6744 > URL: https://issues.jboss.org/browse/ISPN-6744 > Project: Infinispan > Issue Type: Bug > Components: Expiration, Listeners > Reporter: William Burns > Assignee: William Burns > Fix For: 9.0.0.Alpha3, 9.0.0.Final > > > ClusterEvent needs to implement CacheEntryExpired or else it cannot be replicated as a cluster event in the event of an expiration not on a node where a cluster listener was registered. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (HRJS-20) Remove deprecated operations (getBulk*, getVersioned)

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/HRJS-20?page=com.atlassian.jira.plugin.sy... ] Galder Zamarreño resolved HRJS-20. ---------------------------------- Fix Version/s: 0.3.0 Resolution: Done > Remove deprecated operations (getBulk*, getVersioned) > ----------------------------------------------------- > > Key: HRJS-20 > URL: https://issues.jboss.org/browse/HRJS-20 > Project: Infinispan Javascript client > Issue Type: Task > Reporter: Galder Zamarreño > Fix For: 0.3.0 > > > Remove deprecated operations: getBulk*, getVersioned. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (HRJS-20) Remove deprecated operations (getBulk*, getVersioned)

by Galder Zamarreño (JIRA)

Galder Zamarreño created HRJS-20: ------------------------------------ Summary: Remove deprecated operations (getBulk*, getVersioned) Key: HRJS-20 URL: https://issues.jboss.org/browse/HRJS-20 Project: Infinispan Javascript client Issue Type: Task Reporter: Galder Zamarreño Remove deprecated operations: getBulk*, getVersioned. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (HRJS-16) Generate API docs for JS client

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/HRJS-16?page=com.atlassian.jira.plugin.sy... ] Galder Zamarreño resolved HRJS-16. ---------------------------------- Resolution: Done > Generate API docs for JS client > ------------------------------- > > Key: HRJS-16 > URL: https://issues.jboss.org/browse/HRJS-16 > Project: Infinispan Javascript client > Issue Type: Task > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 0.3.0 > > Attachments: screenshot-1.png > > > We should generate API documentation for the JS client so that it is clear which API is available. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6755) Functional API's metadata support is unusable when using CacheLoaders

by Krzysztof Sobolewski (JIRA)

[ https://issues.jboss.org/browse/ISPN-6755?page=com.atlassian.jira.plugin.... ] Krzysztof Sobolewski updated ISPN-6755: --------------------------------------- Git Pull Request: https://github.com/infinispan/infinispan/pull/4396 > Functional API's metadata support is unusable when using CacheLoaders > --------------------------------------------------------------------- > > Key: ISPN-6755 > URL: https://issues.jboss.org/browse/ISPN-6755 > Project: Infinispan > Issue Type: Bug > Components: Loaders and Stores > Affects Versions: 9.0.0.Alpha2 > Reporter: Krzysztof Sobolewski > > These are the meta parameters used by the Functional API. They are created and updated when we call EntryView.WriteEntryView.set(value, params...), but this is not the only source of these parameters. The other is the cache loaders: the return value of CacheLoader.load() is a MarshalledEntry that contains three values: the key, the value and the metadata. This is a place where the implementations will want to inject information like the lifetime (for expiration). The only way to do that currently is to create a custom implementation of the Metadata interface, but that won't work, partialy because the Functional API is unfinished in these darker, dustier corners. So when we call MetaParam.Lookup.findMetaParam(Class<T>), the only supported Metadata implementation is the MetaParamsInternalMetadata (which external classes can't create because all the constructors of MetaParams are package-private), and there is a TODO to add interoperability support. > The PR I'm about to send fixes this by just allowing external classes to instantiate MetaParams so that they can create MetaParamsInternalMetadata which in turn can be returned from CacheLoader.load(). But this is just a RFC, as usual. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6755) Functional API's metadata support is unusable when using CacheLoaders

by Krzysztof Sobolewski (JIRA)

Krzysztof Sobolewski created ISPN-6755: ------------------------------------------ Summary: Functional API's metadata support is unusable when using CacheLoaders Key: ISPN-6755 URL: https://issues.jboss.org/browse/ISPN-6755 Project: Infinispan Issue Type: Bug Components: Loaders and Stores Affects Versions: 9.0.0.Alpha2 Reporter: Krzysztof Sobolewski These are the meta parameters used by the Functional API. They are created and updated when we call EntryView.WriteEntryView.set(value, params...), but this is not the only source of these parameters. The other is the cache loaders: the return value of CacheLoader.load() is a MarshalledEntry that contains three values: the key, the value and the metadata. This is a place where the implementations will want to inject information like the lifetime (for expiration). The only way to do that currently is to create a custom implementation of the Metadata interface, but that won't work, partialy because the Functional API is unfinished in these darker, dustier corners. So when we call MetaParam.Lookup.findMetaParam(Class<T>), the only supported Metadata implementation is the MetaParamsInternalMetadata (which external classes can't create because all the constructors of MetaParams are package-private), and there is a TODO to add interoperability support. The PR I'm about to send fixes this by just allowing external classes to instantiate MetaParams so that they can create MetaParamsInternalMetadata which in turn can be returned from CacheLoader.load(). But this is just a RFC, as usual. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6491) Remove total order thread pool.

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6491?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6491: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 9.0.0.Final Resolution: Done > Remove total order thread pool. > ------------------------------- > > Key: ISPN-6491 > URL: https://issues.jboss.org/browse/ISPN-6491 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Reporter: Pedro Ruivo > Assignee: Pedro Ruivo > Fix For: 9.0.0.Alpha3, 9.0.0.Final > > > The thread pool was deprecated and it is no longer used since long time ago. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6422) ServerEventLoggerTest.testClusteredServerEventLogging fails randomly

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-6422?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-6422: ------------------------------- Labels: testsuite_stability (was: ) > ServerEventLoggerTest.testClusteredServerEventLogging fails randomly > -------------------------------------------------------------------- > > Key: ISPN-6422 > URL: https://issues.jboss.org/browse/ISPN-6422 > Project: Infinispan > Issue Type: Bug > Components: Server > Reporter: Adrian Nistor > Assignee: Tristan Tarrant > Labels: testsuite_stability > Fix For: 9.0.0.Alpha3 > > > http://ci.infinispan.org/viewLog.html?buildId=37676&tab=buildResultsDiv&b... > {code} > java.lang.NullPointerException: null > at java.util.ComparableTimSort.binarySort(ComparableTimSort.java:258) > at java.util.ComparableTimSort.sort(ComparableTimSort.java:185) > at java.util.Arrays.sort(Arrays.java:1312) > at java.util.Arrays.sort(Arrays.java:1506) > at java.util.ArrayList.sort(ArrayList.java:1454) > at java.util.Collections.sort(Collections.java:141) > at org.infinispan.server.eventlogger.ServerEventLogger.getEvents(ServerEventLogger.java:131) > at org.infinispan.server.eventlogger.ServerEventLoggerTest$2.call(ServerEventLoggerTest.java:86) > at org.infinispan.test.TestingUtil.withCacheManagers(TestingUtil.java:1348) > at org.infinispan.server.eventlogger.ServerEventLoggerTest.testClusteredServerEventLogging(ServerEventLoggerTest.java:66) > ------- Stdout: ------- > Configuring TestNG with: TestNG652Configurator > Transport protocol stack used = tcp > ------- Stderr: ------- > Mar 20, 2016 2:14:51 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport start > INFO: ISPN000078: Starting JGroups channel ISPN > Mar 20, 2016 2:14:51 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted > INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|0] (1) [ServerEventLoggerTest-NodeA-31008] > Mar 20, 2016 2:14:51 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport startJGroupsChannelIfNeeded > INFO: ISPN000079: Channel ISPN local address is ServerEventLoggerTest-NodeA-31008, physical addresses are [127.0.0.1:7900] > Mar 20, 2016 2:14:51 AM org.infinispan.factories.GlobalComponentRegistry start > INFO: ISPN000128: Infinispan version: Infinispan 'Chakra' 9.0.0-SNAPSHOT > Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport start > INFO: ISPN000078: Starting JGroups channel ISPN > Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted > INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|1] (2) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491] > Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted > INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|1] (2) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491] > Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport startJGroupsChannelIfNeeded > INFO: ISPN000079: Channel ISPN local address is ServerEventLoggerTest-NodeB-14491, physical addresses are [127.0.0.1:7901] > Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport start > INFO: ISPN000078: Starting JGroups channel ISPN > Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted > INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|2] (3) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491, ServerEventLoggerTest-NodeC-47842] > Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted > INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|2] (3) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491, ServerEventLoggerTest-NodeC-47842] > Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted > INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|2] (3) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491, ServerEventLoggerTest-NodeC-47842] > Mar 20, 2016 2:14:52 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport startJGroupsChannelIfNeeded > INFO: ISPN000079: Channel ISPN local address is ServerEventLoggerTest-NodeC-47842, physical addresses are [127.0.0.1:7902] > Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog > INFO: message #1 > Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog > WARN: message #2 > Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog > INFO: message #3 > Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog > WARN: message #4 > Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog > INFO: message #5 > Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog > WARN: message #6 > Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog > INFO: message #7 > Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog > WARN: message #8 > Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog > INFO: message #9 > Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog > WARN: message #10 > Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog > INFO: message #11 > Mar 20, 2016 2:14:52 AM org.infinispan.server.eventlogger.ServerEventLogger textLog > WARN: message #12 > Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport stop > INFO: ISPN000080: Disconnecting JGroups channel ISPN > Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted > INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|3] (2) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491] > Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted > INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|3] (2) [ServerEventLoggerTest-NodeA-31008, ServerEventLoggerTest-NodeB-14491] > Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport stop > INFO: ISPN000082: Stopping the RpcDispatcher for channel ISPN > Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport stop > INFO: ISPN000080: Disconnecting JGroups channel ISPN > Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport viewAccepted > INFO: ISPN000094: Received new cluster view for channel ISPN: [ServerEventLoggerTest-NodeA-31008|4] (1) [ServerEventLoggerTest-NodeA-31008] > Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport stop > INFO: ISPN000082: Stopping the RpcDispatcher for channel ISPN > Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport stop > INFO: ISPN000080: Disconnecting JGroups channel ISPN > Mar 20, 2016 2:14:53 AM org.infinispan.remoting.transport.jgroups.JGroupsTransport stop > INFO: ISPN000082: Stopping the RpcDispatcher for channel ISPN > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6686) Improve fluency of persistent store configuration builders

by Krzysztof Sobolewski (JIRA)

[ https://issues.jboss.org/browse/ISPN-6686?page=com.atlassian.jira.plugin.... ] Krzysztof Sobolewski updated ISPN-6686: --------------------------------------- Summary: Improve fluency of persistent store configuration builders (was: Improve fluidity of persistent store configuration builders) > Improve fluency of persistent store configuration builders > ---------------------------------------------------------- > > Key: ISPN-6686 > URL: https://issues.jboss.org/browse/ISPN-6686 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration, Loaders and Stores > Affects Versions: 8.2.2.Final > Reporter: Krzysztof Sobolewski > > Configuration of cache stores has some fluidity issues. I'd like to do: > {code:java} > ConfigurationBuilder builder = ...; > builder > .persistence() > .addStore(JdbcStringBasedStoreConfigurationBuilder.class) > .dialect(...) > .table() // <- compilation error > ... > .connectionPool() // <- compilation error > ...; > {code} > but I'm forced to do: > {code:java} > ConfigurationBuilder builder = ...; > JdbcStringBasedStoreConfigurationBuilder store = builder > .persistence() > .addStore(JdbcStringBasedStoreConfigurationBuilder.class) > .dialect(...); > store > .table() > ...; > store > .connectionPool() > ...; > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6686) Improve fluency of persistent store configuration builders

by Krzysztof Sobolewski (JIRA)

[ https://issues.jboss.org/browse/ISPN-6686?page=com.atlassian.jira.plugin.... ] Krzysztof Sobolewski updated ISPN-6686: --------------------------------------- Description: Configuration of cache stores has some fluency issues. I'd like to do: {code:java} ConfigurationBuilder builder = ...; builder .persistence() .addStore(JdbcStringBasedStoreConfigurationBuilder.class) .dialect(...) .table() // <- compilation error ... .connectionPool() // <- compilation error ...; {code} but I'm forced to do: {code:java} ConfigurationBuilder builder = ...; JdbcStringBasedStoreConfigurationBuilder store = builder .persistence() .addStore(JdbcStringBasedStoreConfigurationBuilder.class) .dialect(...); store .table() ...; store .connectionPool() ...; {code} was: Configuration of cache stores has some fluidity issues. I'd like to do: {code:java} ConfigurationBuilder builder = ...; builder .persistence() .addStore(JdbcStringBasedStoreConfigurationBuilder.class) .dialect(...) .table() // <- compilation error ... .connectionPool() // <- compilation error ...; {code} but I'm forced to do: {code:java} ConfigurationBuilder builder = ...; JdbcStringBasedStoreConfigurationBuilder store = builder .persistence() .addStore(JdbcStringBasedStoreConfigurationBuilder.class) .dialect(...); store .table() ...; store .connectionPool() ...; {code} > Improve fluency of persistent store configuration builders > ---------------------------------------------------------- > > Key: ISPN-6686 > URL: https://issues.jboss.org/browse/ISPN-6686 > Project: Infinispan > Issue Type: Enhancement > Components: Configuration, Loaders and Stores > Affects Versions: 8.2.2.Final > Reporter: Krzysztof Sobolewski > > Configuration of cache stores has some fluency issues. I'd like to do: > {code:java} > ConfigurationBuilder builder = ...; > builder > .persistence() > .addStore(JdbcStringBasedStoreConfigurationBuilder.class) > .dialect(...) > .table() // <- compilation error > ... > .connectionPool() // <- compilation error > ...; > {code} > but I'm forced to do: > {code:java} > ConfigurationBuilder builder = ...; > JdbcStringBasedStoreConfigurationBuilder store = builder > .persistence() > .addStore(JdbcStringBasedStoreConfigurationBuilder.class) > .dialect(...); > store > .table() > ...; > store > .connectionPool() > ...; > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 6 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues June 2016