May 2014 - infinispan-issues - Jboss List Archives

[JBoss JIRA] (ISPN-4076) RHQ server plugin: bytesRead and bytesWritten stats are broken

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4076?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4076: ----------------------------------------------- Tomas Sykora <tsykora(a)redhat.com> changed the Status of [bug 1073509|https://bugzilla.redhat.com/show_bug.cgi?id=1073509] from ON_QA to ASSIGNED > RHQ server plugin: bytesRead and bytesWritten stats are broken > -------------------------------------------------------------- > > Key: ISPN-4076 > URL: https://issues.jboss.org/browse/ISPN-4076 > Project: Infinispan > Issue Type: Bug > Components: JMX, reporting and management > Affects Versions: 7.0.0.Alpha1 > Reporter: Tomas Sykora > Assignee: Tomas Sykora > Labels: 630 > Fix For: 7.0.0.Alpha2, 7.0.0.Final > > > resource path: subsystem=endpoint > and underlined connectors provides statistics: bytesRead, bytesWritten. > However plugin asks for bytes-read and bytes-written which is wrong. Small change in map in MetricsRemappingComponent is needed. > + We will remove monitoring of those statistics for REST endpoint, as this endpoint does not provide those statistics at all. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4279) Upgrade to Apache Lucene 4.8.0

by Adrian Nistor (JIRA)

[ https://issues.jboss.org/browse/ISPN-4279?page=com.atlassian.jira.plugin.... ] Adrian Nistor updated ISPN-4279: -------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done Integrated in master. Thanks! > Upgrade to Apache Lucene 4.8.0 > ------------------------------ > > Key: ISPN-4279 > URL: https://issues.jboss.org/browse/ISPN-4279 > Project: Infinispan > Issue Type: Feature Request > Components: Lucene Directory > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Priority: Blocker > Fix For: 7.0.0.Alpha4 > > > Upgrade to Apache Lucene 4.8.0 -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-3904) Migrate JDBC cache store tests

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-3904?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-3904: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1088310|https://bugzilla.redhat.com/show_bug.cgi?id=1088310] from MODIFIED to ON_QA > Migrate JDBC cache store tests > ------------------------------ > > Key: ISPN-3904 > URL: https://issues.jboss.org/browse/ISPN-3904 > Project: Infinispan > Issue Type: Task > Components: Server > Reporter: Vitalii Chepeliuk > Assignee: Vitalii Chepeliuk > Labels: task > Fix For: 7.0.0.Alpha3 > > > Migrating finctional tests for JDBC cache store > Following modules will be migrated: async-store, binary-no-passivation, binary-with-passivation, invalidation-cache, mixed-no-passivation, mixed-with-passivation, string-based-multinode, string-based-no-passivation, string-based-with-passivation > There is issue with passivating oldest entries https://issues.jboss.org/browse/ISPN-4187 . Should be resolved -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4147) the new EAP-based CLI is not yet compatibile with the old JDG CLI

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4147?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4147: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1079883|https://bugzilla.redhat.com/show_bug.cgi?id=1079883] from MODIFIED to ON_QA > the new EAP-based CLI is not yet compatibile with the old JDG CLI > ----------------------------------------------------------------- > > Key: ISPN-4147 > URL: https://issues.jboss.org/browse/ISPN-4147 > Project: Infinispan > Issue Type: Bug > Components: CLI > Affects Versions: 7.0.0.Alpha1 > Reporter: Vitalii Chepeliuk > Assignee: Pedro Ruivo > Labels: 630betablocker > > * Running JDG tests for CLI > Fcli/standalone_caches_test.rb:84: warning: Insecure world writable dir /qa/tools in PATH, mode 040777 > Exception in thread "main" java.lang.UnsupportedClassVersionError: org/jboss/as/cli/CommandLineMain : Unsupported major.minor version 51.0 > at java.lang.ClassLoader.defineClass1(Native Method) > at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) > at java.lang.ClassLoader.defineClass(ClassLoader.java:615) > at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:345) > at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:423) > at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261) > at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76) > at org.jboss.modules.Module.loadModuleClass(Module.java:548) > at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:189) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) > at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:398) > at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) > at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:249) > at org.jboss.modules.Module.run(Module.java:280) > at org.jboss.modules.Main.main(Main.java:455) > ** Jobs are here > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/j... > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JDG/view/FUNC/job/j... > * ispn-cli --help > Usage: > jboss-cli.sh/jboss-cli.bat [--help] [--version] [--controller=host:port] > [--connect] [--file=file_path] > [--commands=command_or_operation1,command_or_operation2...] > [--command=command_or_operation] > [--user=username --password=password] > [--no-local-auth] > [--timeout=timeout] > --help (-h) - prints (this) basic description of the command line utility. > --version - prints the version info of the JBoss AS release, JVM and system environment. > --controller - the default controller host and port to connect to when > --connect option (described below) is specified or when the connect command is issued w/o the arguments. The default controller host is localhost and the port is 9999. > --connect (-c) - instructs the CLI to connect to the controller on start-up (to avoid issuing a separate connect command later). > --gui - GUI built on top of the CLI, the only difference is that it brings up a GUI instead of a command line. In this mode, the CLI will automatically connect during start-up. You can > optionally specify --controller, if necessary. > --file - specifies a path to a file which contains commands operations (one per line) that should be executed (in a non-interactive mode). The CLI will terminate the session > immediately after the last command has been executed or if > some command or operation failed. > ... etc -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4270) JPA Cache Store is missing from the BOM

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4270?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4270: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1095290|https://bugzilla.redhat.com/show_bug.cgi?id=1095290] from MODIFIED to ON_QA > JPA Cache Store is missing from the BOM > --------------------------------------- > > Key: ISPN-4270 > URL: https://issues.jboss.org/browse/ISPN-4270 > Project: Infinispan > Issue Type: Bug > Components: Build process > Affects Versions: 7.0.0.Alpha3 > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 7.0.0.Alpha4, 7.0.0.Final > > > Add the JPA Cache Store to the BOM -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4247) JPA cachestore fails with Oracle12c and PostgreadPlus 9

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4247?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4247: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1092403|https://bugzilla.redhat.com/show_bug.cgi?id=1092403] from MODIFIED to ON_QA > JPA cachestore fails with Oracle12c and PostgreadPlus 9 > ------------------------------------------------------- > > Key: ISPN-4247 > URL: https://issues.jboss.org/browse/ISPN-4247 > Project: Infinispan > Issue Type: Bug > Components: Core > Reporter: Vojtech Juranek > Assignee: Dan Berindei > Fix For: 7.0.0.Alpha4, 7.0.0.Final > > > JPA cache store fails on Oracle12c and PostgreadPlus 9 as Hibernate is not able to determine the dialect to be used: > {noformat} > [java] Caused by: org.hibernate.HibernateException: Unable to determine Dialect to use [name=Oracle, majorVersion=12]; user must register resolver or explicitly set 'hibernate.dialect' > {noformat} > resp. > {noformat} > [java] Caused by: org.hibernate.HibernateException: Unable to determine Dialect to use [name=EnterpriseDB, majorVersion=9]; user must register resolver or explicitly set 'hibernate.dialect' > {noformat} > To fix it, HIbernate upgrade is needed. PotgresPlus is fixed in 4.3.0.Beta4 (tracking JIRA is [HHH-8349|https://hibernate.atlassian.net/browse/HHH-8349]), Oracle12c is fixed in Hibernate 5.0.0 (tracking JIRA is [HHH-9044|https://hibernate.atlassian.net/browse/HHH-9044]) -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4218) Increase default maxCollectorSize for MapReduceTask

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4218?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4218: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1096468|https://bugzilla.redhat.com/show_bug.cgi?id=1096468] from MODIFIED to ON_QA > Increase default maxCollectorSize for MapReduceTask > --------------------------------------------------- > > Key: ISPN-4218 > URL: https://issues.jboss.org/browse/ISPN-4218 > Project: Infinispan > Issue Type: Enhancement > Components: Distributed Execution and Map/Reduce > Reporter: Vladimir Blagojevic > Assignee: Vladimir Blagojevic > Priority: Minor > Fix For: 7.0.0.Alpha4, 7.0.0.Final > > > During performance testing we have found that the value of around 10K leads to a better performance of large map/reduce tasks containing more than 100K of cache entries. We have concluded that the current default value of 1024 is too small. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4131) Lock acquired forever with delayed PrepareCommand

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4131?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4131: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1080314|https://bugzilla.redhat.com/show_bug.cgi?id=1080314] from MODIFIED to ON_QA > Lock acquired forever with delayed PrepareCommand > ------------------------------------------------- > > Key: ISPN-4131 > URL: https://issues.jboss.org/browse/ISPN-4131 > Project: Infinispan > Issue Type: Bug > Components: Transactions > Affects Versions: 6.0.2.Final, 7.0.0.Alpha1 > Reporter: Radim Vansa > Assignee: Dan Berindei > Priority: Critical > Labels: 630betablocker > > Distributed transactional cache: > 1. A sends Prepare to B > 2. B receives Prepare, but due to ongoing ST it is blocked > 3. B replication timeout elapses > 4. B sends Rollback, this does not find the TX as Prepare was not executed yet. The transaction is put into completedTransactions. > 5. Completed transactions timeout elapses. This is by default 15 seconds, way shorter than ST timeout (due to which the Prepare was blocked) > 6. Prepare is executed on B, acquiring lock on K > Nobody will rollback the TX as originator thinks it was already rolled back. > Result: key K will be locked forever, all attempts to update/remove it will fail. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

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

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4187?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4187: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1090591|https://bugzilla.redhat.com/show_bug.cgi?id=1090591] from MODIFIED to ON_QA > 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 > Labels: 630betablocker > Fix For: 7.0.0.Alpha4 > > 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 was sent by Atlassian JIRA (v6.2.3#6260)

11 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ISPN-4160) Do not allow the state transfer chunk size to be <= 0

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/ISPN-4160?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on ISPN-4160: ----------------------------------------------- Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1096466|https://bugzilla.redhat.com/show_bug.cgi?id=1096466] from MODIFIED to ON_QA > Do not allow the state transfer chunk size to be <= 0 > ----------------------------------------------------- > > Key: ISPN-4160 > URL: https://issues.jboss.org/browse/ISPN-4160 > Project: Infinispan > Issue Type: Task > Components: Configuration, State Transfer > Affects Versions: 7.0.0.Alpha1 > Reporter: Dan Berindei > Assignee: Vladimir Blagojevic > Fix For: 7.0.0.Alpha4 > > > The state transfer chunk size is used in other places as well, and the case of {{chunkSize <= 0}} has to be handled everywhere independently. StateTransferConfigurationBuilder should validate that {{chunkSize > 0}}, so that users of the chunk size setting don't need a default value. > The users will still be able to force state transfer to transfer everything at once with {{chunkSize == Integer.MAX_VALUE}}. -- This message was sent by Atlassian JIRA (v6.2.3#6260)

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 May 2014