March 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5335) ConfigurationBuilder with custom interceptor leads to shared interceptor

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-5335?page=com.atlassian.jira.plugin.... ] Radim Vansa reassigned ISPN-5335: --------------------------------- Assignee: Radim Vansa > ConfigurationBuilder with custom interceptor leads to shared interceptor > ------------------------------------------------------------------------ > > Key: ISPN-5335 > URL: https://issues.jboss.org/browse/ISPN-5335 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.2.0.Alpha1 > Reporter: Radim Vansa > Assignee: Radim Vansa > > If ConfigurationBuilder object with defined Interceptor (even through Parser) is reused in multiple classes, these classes have shared interceptor (which obviously breaks stuff). You cannot copy the ConfigurationBuilder in any way (such as creating configuration and reading it again) because the instance is never cloned/created anew. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-4572) StateTransferReplicationQueueTest.testStateTransferWithNodeRestartedAndBusyNonTx random failures

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4572?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4572: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1206606 > StateTransferReplicationQueueTest.testStateTransferWithNodeRestartedAndBusyNonTx random failures > ------------------------------------------------------------------------------------------------ > > Key: ISPN-4572 > URL: https://issues.jboss.org/browse/ISPN-4572 > Project: Infinispan > Issue Type: Bug > Components: Core, State Transfer, Test Suite - Core > Affects Versions: 7.0.0.Alpha5 > Reporter: Dan Berindei > Priority: Blocker > Labels: testsuite_stability > > {noformat} > java.lang.AssertionError: > at org.testng.AssertJUnit.fail(AssertJUnit.java:59) > at org.testng.AssertJUnit.assertTrue(AssertJUnit.java:24) > at org.testng.AssertJUnit.assertNull(AssertJUnit.java:282) > at org.testng.AssertJUnit.assertNull(AssertJUnit.java:274) > at org.infinispan.statetransfer.StateTransferReplicationQueueTest.doWritingCacheTest(StateTransferReplicationQueueTest.java:144) > at org.infinispan.statetransfer.StateTransferReplicationQueueTest.testStateTransferWithNodeRestartedAndBusyNonTx(StateTransferReplicationQueueTest.java:88) > {noformat} > No trace log available for now. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5221) Java Hotrod client, nearcache broken after a org.infinispan.client.hotrod.exceptions.TransportException:: java.net.SocketTimeoutException

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5221?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5221: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1206590 > Java Hotrod client, nearcache broken after a org.infinispan.client.hotrod.exceptions.TransportException:: java.net.SocketTimeoutException > ----------------------------------------------------------------------------------------------------------------------------------------- > > Key: ISPN-5221 > URL: https://issues.jboss.org/browse/ISPN-5221 > Project: Infinispan > Issue Type: Bug > Affects Versions: 7.1.0.Final > Environment: Infinispan 7.1.0Final > Reporter: Enrico Olivelli > Assignee: Galder Zamarreño > Fix For: 7.2.0.Beta1, 7.2.0.Final > > > Using the LAZY nearcache (new in 7.1.0Final) when a java.net.SocketTimeoutException occurs against one of the given HotRod server the RemoteCache becames not usable any more > This happens very frequently in our DEV environment, but I cannot reproduce it inside a test case > This is the stacktrace > {code} > 15/02/13 14:51:39 ERROR event.ClientListenerNotifier: ISPN004043: Unrecoverable error reading event from server xxx.xxx.xxx/10.168.10.117:11222, exiting event reader thread > org.infinispan.client.hotrod.exceptions.TransportException:: java.net.SocketTimeoutException > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.readByte(TcpTransport.java:184) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readMagic(Codec20.java:282) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readEvent(Codec20.java:126) > at org.infinispan.client.hotrod.event.ClientListenerNotifier$EventDispatcher.run(ClientListenerNotifier.java:236) > at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: java.net.SocketTimeoutException > at sun.nio.ch.SocketAdaptor$SocketInputStream.read(SocketAdaptor.java:211) > at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103) > at java.io.BufferedInputStream.fill(BufferedInputStream.java:246) > at java.io.BufferedInputStream.read(BufferedInputStream.java:265) > at org.infinispan.client.hotrod.impl.transport.tcp.TcpTransport.readByte(TcpTransport.java:179) > ... 8 more > {code} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5022) Create a cachestore archetype

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5022?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5022: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1186857|https://bugzilla.redhat.com/show_bug.cgi?id=1186857] from ASSIGNED to POST > Create a cachestore archetype > ----------------------------- > > Key: ISPN-5022 > URL: https://issues.jboss.org/browse/ISPN-5022 > Project: Infinispan > Issue Type: Feature Request > Components: Demos and Tutorials, Loaders and Stores > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.2.0.Beta2 > > > We should have an AdvancedCacheWriter archetype which describes how to implement a proper cache store. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5131) Deploy custom cache store to Infinispan Server

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5131?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5131: ----------------------------------------------- Sebastian Łaskawiec <slaskawi(a)redhat.com> changed the Status of [bug 1186857|https://bugzilla.redhat.com/show_bug.cgi?id=1186857] from ASSIGNED to POST > Deploy custom cache store to Infinispan Server > ---------------------------------------------- > > Key: ISPN-5131 > URL: https://issues.jboss.org/browse/ISPN-5131 > Project: Infinispan > Issue Type: Feature Request > Components: Loaders and Stores, Server > Reporter: Tristan Tarrant > Assignee: Sebastian Łaskawiec > Fix For: 7.2.0.Final > > > h2. Overview > Support the deployment and configuration of a custom cache store. > h2. Client Perspective > In order to create a deployable Cache Store the client will have to implement {{AdvancedLoadWriteStoreFactory}} (which will contain factory methods for creating {{AdvancedLoadWriteStore}}). Next, the factory will have to be annotated with {{@NamedFactory}} and placed into a jar together with proper entry of {{META-INF/services/org.infinispan.persistence.AdvancedLoadWriteStoreFactory}}. The last activity is to deploy given jar into Hotrod server. > h2. Implementation overview > The implementation is based on Deployable Filters and Converters. > Currently all writers and loaders are instantiated in {{PersistenceManagerImpl#createLoadersAndWriters}}. This implementation will be modified to use {{CacheStoreFactoryRegistry}}, which will contain a list of {{CacheStoreFactories}}. One of the factories will be added by default - the local one (which will the same mechanism as we do now - {{Util.getInstance(classAnnotation)}}. Other {{CacheStoreFactories}} will be added after deployment scanning. > h2. Implementation doubts and questions: > * Should we expose a factory for {{AdvancedLoadWriteStore}} or should we include also {{ExternalStore}} (or even separate factory for {{CacheLoader}} and {{CacheWriter}}? > ** YES, we should expose all of them. > * How to ensure that deployment scanning has finished before creating instantiating {{AdvancedLoadWriteStore}}? > ** Using {{org.infinispan.server.endpoint.subsystem.EndpointSubsystemAdd}} -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5335) ConfigurationBuilder with custom interceptor leads to shared interceptor

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-5335?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-5335: ------------------------------ Affects Version/s: 7.2.0.Alpha1 > ConfigurationBuilder with custom interceptor leads to shared interceptor > ------------------------------------------------------------------------ > > Key: ISPN-5335 > URL: https://issues.jboss.org/browse/ISPN-5335 > Project: Infinispan > Issue Type: Bug > Affects Versions: 7.2.0.Alpha1 > Reporter: Radim Vansa > > If ConfigurationBuilder object with defined Interceptor (even through Parser) is reused in multiple classes, these classes have shared interceptor (which obviously breaks stuff). You cannot copy the ConfigurationBuilder in any way (such as creating configuration and reading it again) because the instance is never cloned/created anew. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5335) ConfigurationBuilder with custom interceptor leads to shared interceptor

by Radim Vansa (JIRA)

[ https://issues.jboss.org/browse/ISPN-5335?page=com.atlassian.jira.plugin.... ] Radim Vansa updated ISPN-5335: ------------------------------ Component/s: Core > ConfigurationBuilder with custom interceptor leads to shared interceptor > ------------------------------------------------------------------------ > > Key: ISPN-5335 > URL: https://issues.jboss.org/browse/ISPN-5335 > Project: Infinispan > Issue Type: Bug > Components: Core > Affects Versions: 7.2.0.Alpha1 > Reporter: Radim Vansa > > If ConfigurationBuilder object with defined Interceptor (even through Parser) is reused in multiple classes, these classes have shared interceptor (which obviously breaks stuff). You cannot copy the ConfigurationBuilder in any way (such as creating configuration and reading it again) because the instance is never cloned/created anew. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5335) ConfigurationBuilder with custom interceptor leads to shared interceptor

by Radim Vansa (JIRA)

Radim Vansa created ISPN-5335: --------------------------------- Summary: ConfigurationBuilder with custom interceptor leads to shared interceptor Key: ISPN-5335 URL: https://issues.jboss.org/browse/ISPN-5335 Project: Infinispan Issue Type: Bug Reporter: Radim Vansa If ConfigurationBuilder object with defined Interceptor (even through Parser) is reused in multiple classes, these classes have shared interceptor (which obviously breaks stuff). You cannot copy the ConfigurationBuilder in any way (such as creating configuration and reading it again) because the instance is never cloned/created anew. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5238) Maintain session in ispn-mgmt-console (ctrl+R)

by Tomas Sykora (JIRA)

[ https://issues.jboss.org/browse/ISPN-5238?page=com.atlassian.jira.plugin.... ] Tomas Sykora commented on ISPN-5238: ------------------------------------ Thinking about that... maybe we just need add some special --dev task for gulp (instead of running only gulp.start('build') in default task. In that task we can specify default admin credentials and process some inits (where we are doing logging into the server mgmt). Then when we change a file during development, file change will be detected, pre-set credentials will be passed, init process will run and we will end up in a browser on the same page but with updated files. Need to do some research about possibilities here. This is really annoying have to log-in after every small change when we want to see results. > Maintain session in ispn-mgmt-console (ctrl+R) > ---------------------------------------------- > > Key: ISPN-5238 > URL: https://issues.jboss.org/browse/ISPN-5238 > Project: Infinispan > Issue Type: Task > Components: JMX, reporting and management > Reporter: Tomas Sykora > Assignee: Vladimir Blagojevic > Fix For: 8.0.0.Final > > > When you reload a page in Infinispan Management Console data is lost and you need to re-login. We need to make sure that the session is maintained properly and operations like ctrl+R, F5 etc. does not affect behaviour negatively. > It will also help with development and testing when you need to reload a page to see some changes from time to time. > I did a small research around this topic and made some experiments but I was not able to achieve what I wanted. Maybe we can come up with even different approach. > Anyway I suppose we can stick to the idea that ctrl+R should just reload the page and data successfully. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 years

1
0
0 / 0

[JBoss JIRA] (ISPN-5334) Define a policy for cluster merge if partition handling is enabled and the availability is changed by an admin

by Wolf-Dieter Fink (JIRA)

Wolf-Dieter Fink created ISPN-5334: -------------------------------------- Summary: Define a policy for cluster merge if partition handling is enabled and the availability is changed by an admin Key: ISPN-5334 URL: https://issues.jboss.org/browse/ISPN-5334 Project: Infinispan Issue Type: Enhancement Components: Core Environment: Clustered caches with Partition Handling enabled Reporter: Wolf-Dieter Fink If there is no user intervention during a cluster split with enabled partition handling there is NO available partition or ONE. It is not possible in this case to have >1 available partitions. Because of that there is no handling defined for this. As a result the cluster is in an undifined and maybe inconsistent state after merge. There should be a definition how this situation will be resolved! - First a manual intervention should be logged in a different way to document it, at the moment the log message is the same no matter whether the state changed by hand or not. - If there is a majority of nodes (from last stable) this partition should stay active and the other (available) should be erased in the same way as the degraded one. - If there is a simple majority this should be used - If there is no majorty ... random? - In any case a merge of avail-avail should be log a WARN (maybe on each node) In any case there should be a documented policy to be sure what the ramifications are if there is a manual intervention for the available state. -- This message was sent by Atlassian JIRA (v6.3.11#6341)

11 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 2015