September 2014 - infinispan-issues

[JBoss JIRA] (ISPN-4677) Map/Reduce job fails with the wrong explanation on underlying TimeoutException

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/ISPN-4677?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on ISPN-4677: --------------------------------------- Hi Vladimir, welcome back! I'd set a flag somewhere so you can differentiate the two cases; I didn't look in depth but I guess the problem is to be just testing instanceof: you should shelf some more context on error so that you can use it then for a better explanation. > Map/Reduce job fails with the wrong explanation on underlying TimeoutException > ------------------------------------------------------------------------------ > > Key: ISPN-4677 > URL: https://issues.jboss.org/browse/ISPN-4677 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Distributed Execution and Map/Reduce > Affects Versions: 7.0.0.Beta1 > Reporter: Sanne Grinovero > Assignee: Vladimir Blagojevic > Fix For: 7.0.0.Beta2 > > > I'm running a task which is throwing the following exception during the Map phase: > {noformat} > org.infinispan.util.concurrent.TimeoutException: Node main-NodeC-22183 timed out{noformat} > The user facing error however is this very confusing message: > {noformat}org.infinispan.commons.CacheException: java.util.concurrent.ExecutionException: Map phase executing at main-NodeA-39904 did not complete within 0 sec timeout{noformat} > I have no timeout enabled. > The problem is the instanceof operation on the cause of the error in org.infinispan.distexec.mapreduce.MapReduceTask.executeMapPhaseWithLocalReduction(Map<KOut, VOut>): the check on the type only is not good enough. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3807) Caching of parsed HQL queries

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3807?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-3807: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1136438 > Caching of parsed HQL queries > ----------------------------- > > Key: ISPN-3807 > URL: https://issues.jboss.org/browse/ISPN-3807 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Embedded Querying > Affects Versions: 6.0.0.Final > Reporter: Sanne Grinovero > Assignee: Adrian Nistor > > We'll probably need to use a cache (lowercase) to avoid invoking ANTLR on each request. > Ideally we could think of caching parameterized templates, or recognize constants: in case of constants the output could degenerate in caching a Lucene Filter. > Priority do be defined after performance tests. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4685) Lucene Directory Externalizers not used on server deployment

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4685?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration updated ISPN-4685: ------------------------------------------ Bugzilla Update: Perform Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1136064 > Lucene Directory Externalizers not used on server deployment > ------------------------------------------------------------ > > Key: ISPN-4685 > URL: https://issues.jboss.org/browse/ISPN-4685 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Embedded Querying, Remote Querying > Affects Versions: 7.0.0.Beta1 > Reporter: Gustavo Fernandes > Assignee: Gustavo Fernandes > Fix For: 7.0.0.Beta2 > > > Infinispan server module does not import services from lucene directory module, and java serialization is used since all Lucene cache objets (wrongly) implements Serializable -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4686) Make Infinispan 7.0 binary compatible with 6.x

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-4686?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on ISPN-4686: ------------------------------------ Other incompatiblities: * org.infinispan.manager.AbstractDelegatingEmbeddedCacheManager -> org.infinispan.manager.impl.AbstractDelegatingEmbeddedCacheManager * org.infinispan.affinity.KeyAffinityServiceImpl -> org.infinispan.affinity.impl.KeyAffinityServiceImpl * org.infinispan.persistence.jdbc.DatabaseType -> org.infinispan.persistence.jdbc.Dialect * org.infinispan.distribution.ch.[Default|Replicated|Sync|TopologyAware|TopologyAware]SyncConsistentHashFactory -> org.infinispan.distribution.ch.impl.[Default|Replicated|Sync|TopologyAware|TopologyAwareSync]ConsistentHashFactory > Make Infinispan 7.0 binary compatible with 6.x > ---------------------------------------------- > > Key: ISPN-4686 > URL: https://issues.jboss.org/browse/ISPN-4686 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 7.0.0.Beta1 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Beta2 > > > The idea here is to try to produce a Infinispan 7.0 jar that's binary compatible with 6.0 in order to ease upgrading. So far, the following elements have been found to be problematic: > * FileLookupFactory -> FileLookup changes - ISPN-3850 > * JBossStandaloneJTAManagerLookup.init changes - ISPN-3850 > * org.infinispan.AbstractDelegatingAdvancedCache refactoring to org.infinispan.cache.impl.AbstractDelegatingAdvancedCache - ISPN-4074 > XML configuration stays apart since one of the key aspects of 7.0 is to produce WF-like configuration that's as close as possible, to improve usability between library and server mode. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4686) Make Infinispan 7.0 binary compatible with 6.x

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/ISPN-4686?page=com.atlassian.jira.plugin.... ] Paul Ferraro edited comment on ISPN-4686 at 9/2/14 10:40 AM: ------------------------------------------------------------- Other incompatibilities: * org.infinispan.manager.AbstractDelegatingEmbeddedCacheManager -> org.infinispan.manager.impl.AbstractDelegatingEmbeddedCacheManager * org.infinispan.affinity.KeyAffinityServiceImpl -> org.infinispan.affinity.impl.KeyAffinityServiceImpl * org.infinispan.persistence.jdbc.DatabaseType -> org.infinispan.persistence.jdbc.Dialect * org.infinispan.distribution.ch.[Default|Replicated|Sync|TopologyAware|TopologyAware]SyncConsistentHashFactory -> org.infinispan.distribution.ch.impl.[Default|Replicated|Sync|TopologyAware|TopologyAwareSync]ConsistentHashFactory was (Author: pferraro): Other incompatiblities: * org.infinispan.manager.AbstractDelegatingEmbeddedCacheManager -> org.infinispan.manager.impl.AbstractDelegatingEmbeddedCacheManager * org.infinispan.affinity.KeyAffinityServiceImpl -> org.infinispan.affinity.impl.KeyAffinityServiceImpl * org.infinispan.persistence.jdbc.DatabaseType -> org.infinispan.persistence.jdbc.Dialect * org.infinispan.distribution.ch.[Default|Replicated|Sync|TopologyAware|TopologyAware]SyncConsistentHashFactory -> org.infinispan.distribution.ch.impl.[Default|Replicated|Sync|TopologyAware|TopologyAwareSync]ConsistentHashFactory > Make Infinispan 7.0 binary compatible with 6.x > ---------------------------------------------- > > Key: ISPN-4686 > URL: https://issues.jboss.org/browse/ISPN-4686 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Affects Versions: 7.0.0.Beta1 > Reporter: Galder Zamarreño > Assignee: Galder Zamarreño > Fix For: 7.0.0.Beta2 > > > The idea here is to try to produce a Infinispan 7.0 jar that's binary compatible with 6.0 in order to ease upgrading. So far, the following elements have been found to be problematic: > * FileLookupFactory -> FileLookup changes - ISPN-3850 > * JBossStandaloneJTAManagerLookup.init changes - ISPN-3850 > * org.infinispan.AbstractDelegatingAdvancedCache refactoring to org.infinispan.cache.impl.AbstractDelegatingAdvancedCache - ISPN-4074 > XML configuration stays apart since one of the key aspects of 7.0 is to produce WF-like configuration that's as close as possible, to improve usability between library and server mode. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-1204) Make JDBC cache store use implicit schemas for database tables

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-1204?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-1204: ----------------------------------------------- Paul Ferraro <paul.ferraro(a)redhat.com> changed the Status of [bug 1087218|https://bugzilla.redhat.com/show_bug.cgi?id=1087218] from NEW to ON_QA > Make JDBC cache store use implicit schemas for database tables > -------------------------------------------------------------- > > Key: ISPN-1204 > URL: https://issues.jboss.org/browse/ISPN-1204 > Project: Infinispan > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Components: Loaders and Stores > Reporter: Nicolas Filotto > Assignee: Galder Zamarreño > Fix For: 5.1.0.BETA1, 5.1.0.FINAL > > > The current code checks if a table exists thanks to con.getMetaData().getTables(...) which is totally DB schema dependent, your code allow us to specify the schema by prefixing the table name with the name of the schema in the config which is not really convenient in practice especially if we have a lot of config files. You could easily make your code fully DB schema independent by replacing the method org.infinispan.loaders.jdbc.TableManipulation.tableExists(Connection connection, String tableName) with this content: > {code} > public boolean tableExists(Connection connection, String tableName) { > assertNotNull(getTableName(), "table name is mandatory"); > Statement stmt = null; > ResultSet trs = null; > try { > stmt = connection.createStatement(); > trs = stmt.executeQuery("SELECT count(*) FROM " + tableName); > return trs.next(); > } > catch (SQLException e) { > if (log.isTraceEnabled()) { > log.trace("SQLException occurs while checking the table " + tableName, e); > } > return false; > } > finally { > JdbcUtil.safeClose(trs); > JdbcUtil.safeClose(stmt); > } > } > {code} > I know that it is a much less elegant and standard approach but it allows to simplify so much the config that I think that it makes sense to at least think about at it more than one second. Feel free to resolve it as won't fix if you don't find it relevant. > NB1: We use the same approach in our product (EXOJCR-1374) with JBC and we successfully tested it on Oracle, MySQL, MS SQL, PostgreSQL, DB2 and Sybase > NB2: This patch works well on all listed DB only if auto commit is set to true which should be true in your case since it seems to be the exact same code as JBC -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4677) Map/Reduce job fails with the wrong explanation on underlying TimeoutException

by Vladimir Blagojevic (JIRA)

[ https://issues.jboss.org/browse/ISPN-4677?page=com.atlassian.jira.plugin.... ] Vladimir Blagojevic commented on ISPN-4677: ------------------------------------------- I am not sure how to handle this as we can have the timeout greater than 0 and still the same cause of exception as we did here. Any suggestions Sanne, Dan? > Map/Reduce job fails with the wrong explanation on underlying TimeoutException > ------------------------------------------------------------------------------ > > Key: ISPN-4677 > URL: https://issues.jboss.org/browse/ISPN-4677 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Distributed Execution and Map/Reduce > Affects Versions: 7.0.0.Beta1 > Reporter: Sanne Grinovero > Assignee: Vladimir Blagojevic > Fix For: 7.0.0.Beta2 > > > I'm running a task which is throwing the following exception during the Map phase: > {noformat} > org.infinispan.util.concurrent.TimeoutException: Node main-NodeC-22183 timed out{noformat} > The user facing error however is this very confusing message: > {noformat}org.infinispan.commons.CacheException: java.util.concurrent.ExecutionException: Map phase executing at main-NodeA-39904 did not complete within 0 sec timeout{noformat} > I have no timeout enabled. > The problem is the instanceof operation on the cause of the error in org.infinispan.distexec.mapreduce.MapReduceTask.executeMapPhaseWithLocalReduction(Map<KOut, VOut>): the check on the type only is not good enough. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4686) Make Infinispan 7.0 binary compatible with 6.x

by Galder Zamarreño (JIRA)

Galder Zamarreño created ISPN-4686: -------------------------------------- Summary: Make Infinispan 7.0 binary compatible with 6.x Key: ISPN-4686 URL: https://issues.jboss.org/browse/ISPN-4686 Project: Infinispan Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 7.0.0.Beta1 Reporter: Galder Zamarreño Assignee: Galder Zamarreño Fix For: 7.0.0.Beta2 The idea here is to try to produce a Infinispan 7.0 jar that's binary compatible with 6.0 in order to ease upgrading. So far, the following elements have been found to be problematic: * FileLookupFactory -> FileLookup changes - ISPN-3850 * JBossStandaloneJTAManagerLookup.init changes - ISPN-3850 * org.infinispan.AbstractDelegatingAdvancedCache refactoring to org.infinispan.cache.impl.AbstractDelegatingAdvancedCache - ISPN-4074 XML configuration stays apart since one of the key aspects of 7.0 is to produce WF-like configuration that's as close as possible, to improve usability between library and server mode. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4679) OsgiClassLoader needs null check when iterating bundles

by Dan Berindei (JIRA)

[ https://issues.jboss.org/browse/ISPN-4679?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4679: ------------------------------- Status: Resolved (was: Pull Request Sent) Fix Version/s: 7.0.0.Beta2 Resolution: Done > OsgiClassLoader needs null check when iterating bundles > ------------------------------------------------------- > > Key: ISPN-4679 > URL: https://issues.jboss.org/browse/ISPN-4679 > Project: Infinispan > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Core > Affects Versions: 7.0.0.Beta1 > Reporter: Niels Bertram > Assignee: Dan Berindei > Priority: Minor > Fix For: 7.0.0.Beta2, 7.0.0.Final > > > {{org.infinispan.commons.util.OsgiClassLoader}} requires a null check when the bundle is retrieved from a WeakReference. > {code:java} > for (WeakReference<Bundle> ref : bundles) { > final Bundle bundle = ref.get(); > // BUG: we may not get a bundle back from the weak reference, eg. if uninstalled or deactivated > if (bundle.getState() == Bundle.ACTIVE) { > try { > final Class clazz = bundle.loadClass(name); > if (clazz != null) { > classCache.put(name, clazz); > return clazz; > } > } catch (Exception ignore) { > } > } > } > {code} > I am running 7.0.0.Beta1 on servicemix 5.1.1 and can't load this simple infinispan.xml: > {code:xml} > <infinispan xmlns="urn:infinispan:config:7.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="urn:infinispan:config:7.0 http://infinispan.org/schemas/infinispan-config-7.0.xsd"> > <cache-container default-cache="default" name="TestContainer"> > <jmx domain="TestDomain" mbean-server-lookup="org.infinispan.jmx.PerThreadMBeanServerLookup" duplicate-domains="true"/> >  > <local-cache name="default" statistics="false"> > <locking concurrency-level="100" acquire-timeout="1000"/> > <transaction mode="NONE" complete-timeout="3123" reaper-interval="123"/> > </local-cache> > </cache-container> > </infinispan> > {code} -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4685) Lucene Directory Externalizers not used on server deployment

by Gustavo Fernandes (JIRA)

Gustavo Fernandes created ISPN-4685: --------------------------------------- Summary: Lucene Directory Externalizers not used on server deployment Key: ISPN-4685 URL: https://issues.jboss.org/browse/ISPN-4685 Project: Infinispan Issue Type: Bug Security Level: Public (Everyone can see) Components: Embedded Querying, Remote Querying Affects Versions: 7.0.0.Beta1 Reporter: Gustavo Fernandes Assignee: Gustavo Fernandes Fix For: 7.0.0.Beta2 Infinispan server module does not import services from lucene directory module, and java serialization is used since all Lucene cache objets (wrongly) implements Serializable -- This message was sent by Atlassian JIRA (v6.3.1#6329)

9 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

infinispan-issues September 2014