December 2015 - infinispan-issues

[JBoss JIRA] (ISPN-5482) JSR-107 - Provide mechanism to handle expiration events

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5482?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5482: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 8.1.0.Final Resolution: Done > JSR-107 - Provide mechanism to handle expiration events > -------------------------------------------------------- > > Key: ISPN-5482 > URL: https://issues.jboss.org/browse/ISPN-5482 > Project: Infinispan > Issue Type: Feature Request > Components: JCache > Reporter: Matej Čimbora > Assignee: Gustavo Fernandes > Fix For: 8.1.0.Final > > > Currently, expiration events are supported only by embedded mode & additionally require entry to be accessed in order to be created. This can lead to CacheEntryExpiredListener not being notified when an entry expires. > Note: Not covered by TCK tests. > Example: > {code} > @Test > public void testExpiration(Method m) { > Cache<String, String> cache1 = getCache1(m); > Cache<String, String> cache2 = getCache2(m); > TestExpiredListener listener = new TestExpiredListener(); > MutableCacheEntryListenerConfiguration conf1 = new MutableCacheEntryListenerConfiguration(FactoryBuilder.factoryOf(listener), null, false, false); > cache1.registerCacheEntryListener(conf1); > cache2.put("key1", "val1"); > sleep(5000); > // Required by embedded JCache implementation to work > assert cache1.get("key1") == null; > // Failing for remote JCache implementation > assertEquals(1, listener.invocationCount); > } > private static class TestExpiredListener implements CacheEntryExpiredListener, Serializable { > private int invocationCount; > @Override > public void onExpired(Iterable iterable) throws CacheEntryListenerException { > Iterator iterator = iterable.iterator(); > while (iterator.hasNext()) { > iterator.next(); > invocationCount++; > } > } > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6001) The infinispan server schemas are broken in many ways

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-6001?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-6001: ----------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 8.1.0.Final Resolution: Done > The infinispan server schemas are broken in many ways > ----------------------------------------------------- > > Key: ISPN-6001 > URL: https://issues.jboss.org/browse/ISPN-6001 > Project: Infinispan > Issue Type: Bug > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.1.0.Final > > > The server schemas for the infinispan subsystem are broken in many ways: > - unnecessary required "name" attribute on stores > - missing configuration template > - leveldb store schema not referenced in cache declaration > - more -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5998) Server jgroups schema for SASL is broken

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5998?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-5998: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Server jgroups schema for SASL is broken > ---------------------------------------- > > Key: ISPN-5998 > URL: https://issues.jboss.org/browse/ISPN-5998 > Project: Infinispan > Issue Type: Bug > Components: Configuration, Server > Affects Versions: 7.2.5.Final, 8.1.0.CR1, 8.0.2.Final > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 8.1.0.Final, 8.0.3.Final > > > The schema for the jgroups subsystem has a few bugs related to the sasl element: it inherits from <protocol> thus requiring a type and the security-realm attribute is mis-spelt. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3905) Murmurhash3 implementation is slow on String keys

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-3905?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-3905: --------------------------------------- Hi Dan. How is "reuse" of the string related to this issue? > Murmurhash3 implementation is slow on String keys > ------------------------------------------------- > > Key: ISPN-3905 > URL: https://issues.jboss.org/browse/ISPN-3905 > Project: Infinispan > Issue Type: Enhancement > Components: Core > Affects Versions: 6.0.0.Final, 6.0.1.Final > Reporter: Sanne Grinovero > Assignee: Dan Berindei > Priority: Minor > Fix For: 8.1.0.Final > > > String instances are a common choice for being used as key entries, still the getBytes() operation being performed allocates costly buffers, and the computation to get those bytes looks like expensive too. > I suspect there might be good reasons for not using the String's own hashcode directly as an input to Murmurhash? Still that's what other implementations seem to do. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6001) The infinispan server schemas are broken in many ways

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-6001?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-6001: ----------------------------------- Status: Open (was: New) > The infinispan server schemas are broken in many ways > ----------------------------------------------------- > > Key: ISPN-6001 > URL: https://issues.jboss.org/browse/ISPN-6001 > Project: Infinispan > Issue Type: Bug > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > > The server schemas for the infinispan subsystem are broken in many ways: > - unnecessary required "name" attribute on stores > - missing configuration template > - leveldb store schema not referenced in cache declaration > - more -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6001) The infinispan server schemas are broken in many ways

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-6001?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-6001: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/infinispan/infinispan/pull/3858 > The infinispan server schemas are broken in many ways > ----------------------------------------------------- > > Key: ISPN-6001 > URL: https://issues.jboss.org/browse/ISPN-6001 > Project: Infinispan > Issue Type: Bug > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > > The server schemas for the infinispan subsystem are broken in many ways: > - unnecessary required "name" attribute on stores > - missing configuration template > - leveldb store schema not referenced in cache declaration > - more -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5983) Cannot connect via JMX to servers managed in domain mode

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-5983?page=com.atlassian.jira.plugin.... ] Galder Zamarreño resolved ISPN-5983. ------------------------------------ Fix Version/s: 8.1.0.Final Resolution: Done > Cannot connect via JMX to servers managed in domain mode > -------------------------------------------------------- > > Key: ISPN-5983 > URL: https://issues.jboss.org/browse/ISPN-5983 > Project: Infinispan > Issue Type: Bug > Components: Documentation-Servers, Server > Affects Versions: 8.1.0.Beta1 > Reporter: Jiří Holuša > Assignee: Jiří Holuša > Fix For: 8.1.0.Final > > > I was trying to connect remotely to Infinispan servers run in domain mode. I was following instructions that worked for me with Wildfly 10 (e.g. at https://goldmann.pl/blog/2013/04/16/jmx-connections-to-jboss-as/ ), but that didn't work with Infinispan servers. There is no documentation about how to do this and since it's not working the WildFly way, I mark this issue as bug. > After investigation, we (many thanks to [~lthon]) found out that it doesn't work with ISPN server, because WildFly uses http upgrade for this purpose via http-connector. The connector (by default commented in the domain.xml) requires undertow subsystem to work, however, ISPN server doesn't have it. > There are two possible solutions: > * add the undertow subsystem. The modules/ directory already has the jars, therefore it's only needed to add following to domain.xml and than you can connect to the server via JMX URL service:jmx:remote+http://localhost:8080. However, I wouldn't prefer this solution. > {code} > <subsystem xmlns="urn:jboss:domain:undertow:3.0"> > <buffer-cache name="default"/> > <server name="default-server"> > <http-listener name="default" socket-binding="http"/> > <host name="default-host" alias="localhost"/> > </server> > <servlet-container name="default"/> > </subsystem> > {code} > * second solution is to create remoting endpoint just the way it was before in JBoss AS 7, therefore add following to the domain.xml and then connect via JMX URL: service:jmx:remote://localhost:4447. This solution should be preferred IMHO. > {code} > <connector name="remoting-connector" socket-binding="remoting" security-realm="ApplicationRealm"/> > {code} > {code} > <socket-binding name="remoting" port="4447"/> > {code} > I will soon issue a PR with the solution number 2 and appropriate update of documentation. Of course, these options should be disabled by default, by I think it would be nice to have them commented in the domain.xml. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-5940) Add CDI Remote module to Wildfly modules

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-5940?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-5940: ----------------------------------------------- Vojtech Juranek <vjuranek(a)redhat.com> changed the Status of [bug 1279919|https://bugzilla.redhat.com/show_bug.cgi?id=1279919] from ON_QA to VERIFIED > Add CDI Remote module to Wildfly modules > ---------------------------------------- > > Key: ISPN-5940 > URL: https://issues.jboss.org/browse/ISPN-5940 > Project: Infinispan > Issue Type: Enhancement > Reporter: Sebastian Łaskawiec > Assignee: Vaclav Dedik > Priority: Minor > Fix For: 8.1.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6011) ClassCastException in CDI generated keys for JCache

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-6011?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-6011: ----------------------------------- Fix Version/s: 8.2.0.Final > ClassCastException in CDI generated keys for JCache > --------------------------------------------------- > > Key: ISPN-6011 > URL: https://issues.jboss.org/browse/ISPN-6011 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.1.0.CR1, 8.0.2.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 8.2.0.Final > > > When using JCache-annotations the DefaultCacheKeyGenerator exclusively looks at parameter values to form the cache key. Therefore it will be very likely that collissions occur (resulting in difficult to find ClassCastExceptions). The provided patch uses the method- and class names as additionally values to make the cache key more unique. > Might also add that I am aware that by spec this should not be an issue when no cachename is given (as it should generate a cache using the class-name), but when a cache name is given collissions may occur. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ISPN-6011) ClassCastException in CDI generated keys for JCache

by Galder Zamarreño (JIRA)

[ https://issues.jboss.org/browse/ISPN-6011?page=com.atlassian.jira.plugin.... ] Galder Zamarreño updated ISPN-6011: ----------------------------------- Fix Version/s: (was: 8.1.0.Final) > ClassCastException in CDI generated keys for JCache > --------------------------------------------------- > > Key: ISPN-6011 > URL: https://issues.jboss.org/browse/ISPN-6011 > Project: Infinispan > Issue Type: Bug > Affects Versions: 8.1.0.CR1, 8.0.2.Final > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 8.2.0.Final > > > When using JCache-annotations the DefaultCacheKeyGenerator exclusively looks at parameter values to form the cache key. Therefore it will be very likely that collissions occur (resulting in difficult to find ClassCastExceptions). The provided patch uses the method- and class names as additionally values to make the cache key more unique. > Might also add that I am aware that by spec this should not be an issue when no cachename is given (as it should generate a cache using the class-name), but when a cache name is given collissions may occur. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues December 2015