October 2015 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-5900) Cleanup uberjar packaging (ideal solution)

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-5900?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec updated ISPN-5900: -------------------------------------- Git Pull Request: (was: https://github.com/infinispan/infinispan/pull/3775) > Cleanup uberjar packaging (ideal solution) > ------------------------------------------ > > Key: ISPN-5900 > URL: https://issues.jboss.org/browse/ISPN-5900 > Project: Infinispan > Issue Type: Feature Request > Components: Build process > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > Labels: jdg7 > > ISPN-5838 provides a backwards compatible solution whereas an ideal solution involves also changing packages (which will fix Weld/OSGi errors) into: > * org.infinispan.cdi.common > * org.infinispan.cdi.remote > * org.infinispan.cdi.embedded -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5900) Cleanup uberjar packaging (ideal solution)

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/ISPN-5900?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec updated ISPN-5900: -------------------------------------- Description: ISPN-5838 provides a backwards compatible solution whereas an ideal solution involves also changing packages (which will fix Weld/OSGi errors) into: * org.infinispan.cdi.common * org.infinispan.cdi.remote * org.infinispan.cdi.embedded was: Need to minimize shipping non-required or provided dependencies in the uberjar. Some ideas that need to be further refined: * Split CDI into cdi-embedded and cdi-remote * Add only cdi-embedded to infinispan-embedded (and cdi-remote to infinispan-remote) * Add infinispan-client-hotrod to infinispan-embedded ? Used for RemoteCacheStore (which is an embedded use-case) * infinispan-embedded has a compulsory dependency on javax.transaction api. We cannot change this in Infinispan <= 8.2 for backwards compatibility, but we can change it in 8.3 * > Cleanup uberjar packaging (ideal solution) > ------------------------------------------ > > Key: ISPN-5900 > URL: https://issues.jboss.org/browse/ISPN-5900 > Project: Infinispan > Issue Type: Feature Request > Components: Build process > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > Labels: jdg7 > > ISPN-5838 provides a backwards compatible solution whereas an ideal solution involves also changing packages (which will fix Weld/OSGi errors) into: > * org.infinispan.cdi.common > * org.infinispan.cdi.remote > * org.infinispan.cdi.embedded -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5900) Cleanup uberjar packaging (ideal solution)

by Sebastian Łaskawiec (JIRA)

Sebastian Łaskawiec created ISPN-5900: ----------------------------------------- Summary: Cleanup uberjar packaging (ideal solution) Key: ISPN-5900 URL: https://issues.jboss.org/browse/ISPN-5900 Project: Infinispan Issue Type: Feature Request Components: Build process Reporter: Sebastian Łaskawiec Assignee: Sebastian Łaskawiec Need to minimize shipping non-required or provided dependencies in the uberjar. Some ideas that need to be further refined: * Split CDI into cdi-embedded and cdi-remote * Add only cdi-embedded to infinispan-embedded (and cdi-remote to infinispan-remote) * Add infinispan-client-hotrod to infinispan-embedded ? Used for RemoteCacheStore (which is an embedded use-case) * infinispan-embedded has a compulsory dependency on javax.transaction api. We cannot change this in Infinispan <= 8.2 for backwards compatibility, but we can change it in 8.3 * -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5877) PutAll requests can't use skip cache load and skip indexing flags

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5877?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5877: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > PutAll requests can't use skip cache load and skip indexing flags > ----------------------------------------------------------------- > > Key: ISPN-5877 > URL: https://issues.jboss.org/browse/ISPN-5877 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.0.0.Final, 8.1.0.Alpha2 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 8.1.0.Beta1, 8.1.0.Final > > > Hot Rod putAll requests ignore skip cache load and skip indexing flags. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5863) Default metadata not merged for DecoratedCache operations

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5863?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5863: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Default metadata not merged for DecoratedCache operations > --------------------------------------------------------- > > Key: ISPN-5863 > URL: https://issues.jboss.org/browse/ISPN-5863 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.1.0.Alpha1 > Reporter: Wolf-Dieter Fink > Assignee: Galder Zamarreño > Priority: Critical > > If the ISPN server cache is configured with expiration like: > <cache-container name="local" default-cache="default" statistics="true"> > <state-persistence/> > <local-cache name="default" start="EAGER"> > <locking acquire-timeout="30000" concurrency-level="1000" striping="false"/> > <transaction mode="NONE"/> > <expiration lifespan="1000" interval="20000"/> > </local-cache> > The entry should automatic expired in 1second after it is added. > But a client still have the key > - after 1 sec where it should have been expired > - after 20 sec where the reaper should have removed it -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5863) Default metadata not merged for DecoratedCache operations

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-5863?page=com.atlassian.jira.plugin.... ] William Burns updated ISPN-5863: -------------------------------- Fix Version/s: 8.1.0.Beta1 > Default metadata not merged for DecoratedCache operations > --------------------------------------------------------- > > Key: ISPN-5863 > URL: https://issues.jboss.org/browse/ISPN-5863 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.1.0.Alpha1 > Reporter: Wolf-Dieter Fink > Assignee: Galder Zamarreño > Priority: Critical > Fix For: 8.1.0.Beta1 > > > If the ISPN server cache is configured with expiration like: > <cache-container name="local" default-cache="default" statistics="true"> > <state-persistence/> > <local-cache name="default" start="EAGER"> > <locking acquire-timeout="30000" concurrency-level="1000" striping="false"/> > <transaction mode="NONE"/> > <expiration lifespan="1000" interval="20000"/> > </local-cache> > The entry should automatic expired in 1second after it is added. > But a client still have the key > - after 1 sec where it should have been expired > - after 20 sec where the reaper should have removed it -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5691) Server should enable writeSkew for some configurations by default

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5691?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5691: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1255783|https://bugzilla.redhat.com/show_bug.cgi?id=1255783] from POST to MODIFIED > Server should enable writeSkew for some configurations by default > ----------------------------------------------------------------- > > Key: ISPN-5691 > URL: https://issues.jboss.org/browse/ISPN-5691 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Reporter: Galder Zamarreño > Assignee: Tristan Tarrant > Fix For: 8.1.0.Alpha2, 8.1.0.Final, 7.2.6.Final > > > By default, optimistic locking caches do not enable write skew. This was already spotted in ISPN-3655. > In an embedded environment, the user can always enable write skew in its configuration, but this cannot be enabled in server mode. > Widlfly does enable write skew programmatically depending on the configuration: > {quote} > > hey, quick q: can you configure writeSkew on infinispan wildfly > config? > <pferraro> we always enable write skew for synchronous, optimistic, > repeatable-read caches, and disable otherwise > > pferraro: ah, you do it in the integration code? > <pferraro> yes > {quote} > We need to be doing the same in server configuration, otherwise we run the risk of having issues with conditional operations under failure situations (see ISPN-2956) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5875) HotRod Client does not handle failover silent when nodes are stopped if using role based authentication

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5875?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5875: ----------------------------------------------- Dave Stahl <dstahl(a)redhat.com> changed the Status of [bug 1273137|https://bugzilla.redhat.com/show_bug.cgi?id=1273137] from ASSIGNED to MODIFIED > HotRod Client does not handle failover silent when nodes are stopped if using role based authentication > ------------------------------------------------------------------------------------------------------- > > Key: ISPN-5875 > URL: https://issues.jboss.org/browse/ISPN-5875 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols, Security > Reporter: Wolf-Dieter Fink > Assignee: Galder Zamarreño > Priority: Critical > Labels: hotrod, hotrod-java-client, security > Fix For: 8.1.0.Beta1, 8.1.0.Final, 8.0.2.Final > > > A HotRod client fail over silent if one instance is shutting down if there is no Security enabled. > With role based authentication the client fail sporadically with a WARN message > {code}WARN: ISPN004005: Error received from the server: java.security.PrivilegedActionException: > org.infinispan.IllegalLifecycleStateException: ISPN000324: Cache 'testCache' is in 'STOPPING' state and this is an invocation not > belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate the cache container. > {code} > and the following Exception: > {code}org.infinispan.client.hotrod.exceptions.HotRodClientException:Request for message id[2825] returned server error (status=0x85): > java.security.PrivilegedActionException: org.infinispan.IllegalLifecycleStateException: ISPN000324: Cache 'testCache' is in 'STOPPING' > state and this is an invocation not belonging to an on-going transaction, so it does not accept new invocations. Either restart it or recreate > the cache container. > at org.infinispan.client.hotrod.impl.protocol.Codec20.checkForErrorsInResponseStatus(Codec20.java:336) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readPartialHeader(Codec20.java:126) > at org.infinispan.client.hotrod.impl.protocol.Codec20.readHeader(Codec20.java:112) > at org.infinispan.client.hotrod.impl.operations.HotRodOperation.readHeaderAndValidate(HotRodOperation.java:56) > at org.infinispan.client.hotrod.impl.operations.AbstractKeyValueOperation.sendPutOperation(AbstractKeyValueOperation.java:57) > at org.infinispan.client.hotrod.impl.operations.PutIfAbsentOperation.executeOperation(PutIfAbsentOperation.java:36) > at org.infinispan.client.hotrod.impl.operations.PutIfAbsentOperation.executeOperation(PutIfAbsentOperation.java:23) > at org.infinispan.client.hotrod.impl.operations.RetryOnFailureOperation.execute(RetryOnFailureOperation.java:52) > at org.infinispan.client.hotrod.impl.RemoteCacheImpl.putIfAbsent(RemoteCacheImpl.java:257) > at org.infinispan.client.hotrod.impl.RemoteCacheSupport.putIfAbsent(RemoteCacheSupport.java:54) > at HotRodTestClient.updateCache(HotRodTestClient.java:69) > at HotRodTestClient.lambda$queuePut$0(HotRodTestClient.java:88) > 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) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5899) ContinuousQuery tests should disable expiration reaper

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5899?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5899: ----------------------------------------------- William Burns <wburns(a)redhat.com> changed the Status of [bug 1276452|https://bugzilla.redhat.com/show_bug.cgi?id=1276452] from NEW to POST > ContinuousQuery tests should disable expiration reaper > ------------------------------------------------------ > > Key: ISPN-5899 > URL: https://issues.jboss.org/browse/ISPN-5899 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Query > Affects Versions: 8.1.0.Alpha2 > Reporter: William Burns > Assignee: William Burns > Priority: Blocker > Fix For: 8.1.0.Beta1, 8.0.2.Final > > > ContinuousQuery tests rely on an exact number of expiration events. Unfortunately if the reaper fires at the same time an entry is being expired you can get duplicate expiration events. We should disable the reaper to prevent these sporadic failures. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5899) ContinuousQuery tests should disable expiration reaper

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5899?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-5899: ------------------------------------------ Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1276452 Bugzilla Update: Perform > ContinuousQuery tests should disable expiration reaper > ------------------------------------------------------ > > Key: ISPN-5899 > URL: https://issues.jboss.org/browse/ISPN-5899 > Project: Infinispan > Issue Type: Bug > Components: Test Suite - Query > Affects Versions: 8.1.0.Alpha2 > Reporter: William Burns > Assignee: William Burns > Priority: Blocker > Fix For: 8.1.0.Beta1, 8.0.2.Final > > > ContinuousQuery tests rely on an exact number of expiration events. Unfortunately if the reaper fires at the same time an entry is being expired you can get duplicate expiration events. We should disable the reaper to prevent these sporadic failures. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 2 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues October 2015