April 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-3917) Filter objects using the query DSL (without using an index)

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-3917?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-3917: -------------------------------- Status: Pull Request Sent (was: Coding In Progress) Git Pull Request: https://github.com/infinispan/infinispan/pull/2514 > Filter objects using the query DSL (without using an index) > ----------------------------------------------------------- > > Key: ISPN-3917 > URL: https://issues.jboss.org/browse/ISPN-3917 > Project: Infinispan > Issue Type: Feature Request > Components: Embedded Querying > Reporter: William Burns > Assignee: Adrian Nistor > Labels: roadmap > Fix For: 7.0.0.Alpha4, 7.0.0.Final > > > The cluster listeners will want to use the Query DSL for filtering and projection views. We don't want to have to tie ourselves to Lucene to do this. It was discussed to implement this using reflection. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4212) Unable to get entries from newly started non-defined caches

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-4212?page=com.atlassian.jira.plugin.... ] Martin Gencur commented on ISPN-4212: ------------------------------------- The root cause is following: When a cache is request by hotrod client and the cache is not among configured caches, a default Infinispan configuration is used (new ConfigurationBuilder().build()). As a result, the AnyServerEquivalence and some other settings are not applied. The problem is that Infinispan subsystem in the server does not set any cache configuration and rather creates every cache by calling .definedConfiguration on the cache manager (this call ignores default cache configuration). We have two options here. The first one is quite easy and I already have a fix. 1) In Infinispan subsystem, pass a default configuration to constructor of DefaultCacheManager. The default configuration is the one from infinispan-defaults.xml (it's a local cache!) and we can easily parse it and pass to DefaultCacheManager 2) The first option is not ideal because users can not set the settings in any way (infinispan-defaults.xml is internal file of the server). Ideally, any new cache that is not configured in standalone.xml would be configured according to the "default" cache in that file. It would have the same configuration as default cache. This is tricky to implement but I'll look if it can be done. > Unable to get entries from newly started non-defined caches > ----------------------------------------------------------- > > Key: ISPN-4212 > URL: https://issues.jboss.org/browse/ISPN-4212 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols, Server > Reporter: Jakub Markos > Assignee: Galder Zamarreño > > If you use hotrod to put entries into a cache which is not defined in standalone.xml, it will be started: > {code} > 15:35:50,676 INFO [org.jboss.as.clustering.infinispan] (HotRodServerWorker-1) JBAS010281: Started nonDefinedCache cache from local container > {code} > but when you try to retrieve the entry back, you'll get null. > {code} > RemoteCacheManager rcm = new RemoteCacheManager(new ConfigurationBuilder().addServer().host("localhost").port(11222).build()); > RemoteCache<String, String> cache = rcm.getCache("nonDefinedCache"); > cache.put("key", "value"); > cache.get("key"); // returns null > {code} > Happens in the current server snapshot. > A while back you'd get this > {code} > WARN: ISPN004005: Error received from the server: org.infinispan.server.hotrod.CacheNotFoundException: Cache with name 'nonDefinedCache' not found amongst the configured caches > {code} > So it seems we're somewhere in the middle now (not throwing exception, but also not working). The documentation here is also wrong https://github.com/infinispan/infinispan/blob/master/client/hotrod-client... . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4187) LRU eviction algorithm does not evict the eldest entry

by William Burns (JIRA)

[ https://issues.jboss.org/browse/ISPN-4187?page=com.atlassian.jira.plugin.... ] William Burns commented on ISPN-4187: ------------------------------------- I can confirm the test fails for me on master. I tried an equivalent test with a single cache and wasn't able to reproduce the issue. My first guess is an issue with key equivalence, however I need to debug this further to find out. > LRU eviction algorithm does not evict the eldest entry > ------------------------------------------------------ > > Key: ISPN-4187 > URL: https://issues.jboss.org/browse/ISPN-4187 > Project: Infinispan > Issue Type: Bug > Components: Eviction > Affects Versions: 7.0.0.Alpha2 > Reporter: Martin Gencur > Assignee: William Burns > Attachments: server2.log > > > The following test for JDBC cache stores fails: > {code:java} > @Test > @WithRunningServer({@RunningServer(name = CONTAINER1, config = CONFIG_FETCH_STATE_1)}) > public void testFetchState() throws Exception { > try { > mc1 = createMemcachedClient(server1); > assertCleanCacheAndStore1(); > mc1.set("k1", "v1"); > mc1.set("k2", "v2"); > mc1.set("k3", "v3"); > assertNotNull(dbServer1.stringTable.getValueByKey("k1")); > startContainer(controller, CONTAINER2, CONFIG_FETCH_STATE_2); > mc2 = createMemcachedClient(server2); > assertTrue(0 < server2.getCacheManager(MANAGER_NAME).getCache(CACHE_NAME).getNumberOfEntries()); > //the cache store should fetch state from the others > //since eviction.max-entries==2, first k2 and k3 is loaded from the other cache, then k1 is loaded > //from the other cache's loader and thus k2 is evicted and ends up in a cache loader > assertNull(dbServer2.stringTable.getValueByKey("k1")); > assertEquals("v1", mc2.get("k1")); > assertEquals("v2", mc2.get("k2")); > assertNull(dbServer2.stringTable.getValueByKey("k1")); > //^^^^^fails here, the K1 was evicted even though it was used recently > //K3 was supposed to be evicted but it did not happen > assertNull(dbServer2.stringTable.getValueByKey("k2")); > assertCleanCacheAndStore2(); > } finally { > controller.stop(CONTAINER2); > } > } > {code} > This tests works properly if the following commit is reverted, so it was caused by this commit: > https://github.com/infinispan/infinispan/commit/b190230d84beb41474bae0239... > Note that there's another commit with the same name but different commit hash: b71da1c > The test above can be run from https://github.com/chepa653/infinispan/tree/t_ISPN-3904 by going to server/integration/testsuite and running mvn clean verify -Dtest=StringBasedStoreMultinodeTest#testFetchState -Dlog.level.infinispan=TRACE -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4225) Upgrade to JGroups 3.5.0.Beta5

by Dan Berindei (JIRA)

Dan Berindei created ISPN-4225: ---------------------------------- Summary: Upgrade to JGroups 3.5.0.Beta5 Key: ISPN-4225 URL: https://issues.jboss.org/browse/ISPN-4225 Project: Infinispan Issue Type: Component Upgrade Components: Core Affects Versions: 7.0.0.Alpha3 Reporter: Dan Berindei Assignee: Dan Berindei Fix For: 7.0.0.Alpha4 The new Beta fixes a problem with the DONT_LOOPBACK flag (JGRP-1823). This allows us to use {{message.setTransientFlag(DONT_LOOPBACK)}} instead of {{channel.setExclusionList(self)}} (ISPN-4190). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4224) Kerberos auth IT fails on JDK8

by Vojtech Juranek (JIRA)

Vojtech Juranek created ISPN-4224: ------------------------------------- Summary: Kerberos auth IT fails on JDK8 Key: ISPN-4224 URL: https://issues.jboss.org/browse/ISPN-4224 Project: Infinispan Issue Type: Bug Components: Test Suite - Core Reporter: Vojtech Juranek Assignee: Vojtech Juranek [Kerberos auth integration test|https://github.com/infinispan/infinispan/blob/master/integrationtest...] passes on JDK7, but fails on JDK8 with {noformat} Caused by: javax.naming.NamingException: JBAS011843: Failed instantiate InitialContextFactory com.sun.jndi.ldap.LdapCtxFactory from classloader ModuleClassLoader for Module "deployment.b5efb5d4-0f0d-448f-b60f-e8bd15023ebd.war:main" from Service Module Loader [Root exception is javax.naming.CommunicationException: Request: 1 cancelled] at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:116) at org.jboss.as.naming.InitialContext.init(InitialContext.java:99) at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153) at org.jboss.as.naming.InitialContext.<init>(InitialContext.java:90) at org.jboss.as.naming.InitialContextFactory.getInitialContext(InitialContextFactory.java:44) at javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:684) at javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:307) at javax.naming.InitialContext.init(InitialContext.java:242) at javax.naming.ldap.InitialLdapContext.<init>(InitialLdapContext.java:153) at org.jboss.security.negotiation.AdvancedLdapLoginModule.constructLdapContext(AdvancedLdapLoginModule.java:431) ... 109 more Caused by: javax.naming.CommunicationException: Request: 1 cancelled at com.sun.jndi.ldap.LdapRequest.getReplyBer(LdapRequest.java:105) at com.sun.jndi.ldap.Connection.readReply(Connection.java:449) at com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:364) at com.sun.jndi.ldap.sasl.LdapSasl.saslBind(LdapSasl.java:126) at com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:235) at com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2740) at com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:316) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:193) at com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:211) at com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:154) at com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:84) at org.jboss.as.naming.InitialContext.getDefaultInitCtx(InitialContext.java:114) ... 118 more {noformat} -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4212) Unable to get entries from newly started non-defined caches

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-4212?page=com.atlassian.jira.plugin.... ] Martin Gencur commented on ISPN-4212: ------------------------------------- I'm looking into this. The entry is really stored in the cache via put operation but can't be retrieved via get(). This points to the Equivalence classes that are badly configured. Currently, all caches that are defined in the XML file and started at the beginning have keyEquivalence and valueEquivalence equal to org.jboss.as.clustering.infinispan.equivalence.AnyServerEquivalence while cache started later have org.infinispan.commons.equivalence.AnyEquivalence. I will look for the right fix. > Unable to get entries from newly started non-defined caches > ----------------------------------------------------------- > > Key: ISPN-4212 > URL: https://issues.jboss.org/browse/ISPN-4212 > Project: Infinispan > Issue Type: Bug > Components: Remote Protocols, Server > Reporter: Jakub Markos > Assignee: Galder Zamarreño > > If you use hotrod to put entries into a cache which is not defined in standalone.xml, it will be started: > {code} > 15:35:50,676 INFO [org.jboss.as.clustering.infinispan] (HotRodServerWorker-1) JBAS010281: Started nonDefinedCache cache from local container > {code} > but when you try to retrieve the entry back, you'll get null. > {code} > RemoteCacheManager rcm = new RemoteCacheManager(new ConfigurationBuilder().addServer().host("localhost").port(11222).build()); > RemoteCache<String, String> cache = rcm.getCache("nonDefinedCache"); > cache.put("key", "value"); > cache.get("key"); // returns null > {code} > Happens in the current server snapshot. > A while back you'd get this > {code} > WARN: ISPN004005: Error received from the server: org.infinispan.server.hotrod.CacheNotFoundException: Cache with name 'nonDefinedCache' not found amongst the configured caches > {code} > So it seems we're somewhere in the middle now (not throwing exception, but also not working). The documentation here is also wrong https://github.com/infinispan/infinispan/blob/master/client/hotrod-client... . -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4223) Introduce an equivalent of fragmentation-factor in the server configuration

by Rajesh Jangam (JIRA)

[ https://issues.jboss.org/browse/ISPN-4223?page=com.atlassian.jira.plugin.... ] Rajesh Jangam updated ISPN-4223: -------------------------------- Involved: Tristan Tarrant Environment: JDK 1.7 Description: This issue is related to ISPN-3894 - SingleFileStore can optimize space usage by coalescing adjacent free entry blocks. A configuration parameter called 'fragmentation-factor' has been introduced in the SingleFileStoreConfiguration. Equivalent changes need to be done for the server side. > Introduce an equivalent of fragmentation-factor in the server configuration > --------------------------------------------------------------------------- > > Key: ISPN-4223 > URL: https://issues.jboss.org/browse/ISPN-4223 > Project: Infinispan > Issue Type: Enhancement > Components: Server > Environment: JDK 1.7 > Reporter: Rajesh Jangam > Assignee: Mircea Markus > > This issue is related to ISPN-3894 - SingleFileStore can optimize space usage by coalescing adjacent free entry blocks. > A configuration parameter called 'fragmentation-factor' has been introduced in the SingleFileStoreConfiguration. > Equivalent changes need to be done for the server side. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4223) Introduce an equivalent of fragmentation-factor in the server configuration

by Rajesh Jangam (JIRA)

Rajesh Jangam created ISPN-4223: ----------------------------------- Summary: Introduce an equivalent of fragmentation-factor in the server configuration Key: ISPN-4223 URL: https://issues.jboss.org/browse/ISPN-4223 Project: Infinispan Issue Type: Enhancement Components: Server Reporter: Rajesh Jangam Assignee: Mircea Markus -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4206) Add test for distributed HotRod RollingUpgrades scenario

by Martin Gencur (JIRA)

[ https://issues.jboss.org/browse/ISPN-4206?page=com.atlassian.jira.plugin.... ] Martin Gencur updated ISPN-4206: -------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Alpha4 Resolution: Done > Add test for distributed HotRod RollingUpgrades scenario > -------------------------------------------------------- > > Key: ISPN-4206 > URL: https://issues.jboss.org/browse/ISPN-4206 > Project: Infinispan > Issue Type: Task > Reporter: Tomas Sykora > Assignee: Tomas Sykora > Fix For: 7.0.0.Alpha4 > > > Test scenario with at least 2 source and 2 target nodes with clustered configuration. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4011) Make it possible to use 'remote-jmx' protocol inside Karaf

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/ISPN-4011?page=com.atlassian.jira.plugin.... ] Thomas Diesler commented on ISPN-4011: -------------------------------------- I believe this is already solved in the context of [fabric8poc|https://github.com/tdiesler/fabric8poc]. Specifically have a look at the [wildfly connector|https://github.com/tdiesler/fabric8poc/tree/master/container/wi...]. It uses remote-jmx to to connect from karaf to wildfly > Make it possible to use 'remote-jmx' protocol inside Karaf > ---------------------------------------------------------- > > Key: ISPN-4011 > URL: https://issues.jboss.org/browse/ISPN-4011 > Project: Infinispan > Issue Type: Feature Request > Reporter: Adrian Nistor > Assignee: Martin Gencur > Labels: 630 > Fix For: 7.0.0.Final > > > This is needed so remote-query clients can register protobuf schemas via jmx. Currently this was circumvented by creating a separate stand-alone app (ProtofileRegistrar) that runs outside Karaf before the actual test. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 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 April 2014