[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)
10 years, 5 months
[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)
10 years, 5 months
[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)
10 years, 5 months
[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)
10 years, 5 months
[JBoss JIRA] (ISPN-3877) SingleFileStore continues to consume space on the disk even if the free entries at end of the file are not in use. This space can be released back to the filesystem
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-3877?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-3877:
-----------------------------------------------
Tristan Tarrant <ttarrant(a)redhat.com> changed the Status of [bug 1096726|https://bugzilla.redhat.com/show_bug.cgi?id=1096726] from MODIFIED to ON_QA
> SingleFileStore continues to consume space on the disk even if the free entries at end of the file are not in use. This space can be released back to the filesystem
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ISPN-3877
> URL: https://issues.jboss.org/browse/ISPN-3877
> Project: Infinispan
> Issue Type: Patch
> Components: Loaders and Stores
> Affects Versions: 6.0.0.Final
> Environment: Oracle JDK 1.7, Windows Server 2008 R2 x64
> Reporter: Rajesh Jangam
> Assignee: Dan Berindei
> Fix For: 7.0.0.Alpha4
>
> Attachments: PersistentQueue.java
>
>
> We are testing the latest Infinispan 6.0 SingleFileStore version for our application.
> We tend to create a lot of entries in the store and remove them when not required.
> However, what we have observed is that the size of the file keeps on increasing as more data is being added/removed and that it does not get reclaimed.
>
> This was not seen with earlier versions like 5.3.0. There the size of the cache folder would reduce as entries got removed.
> We have attempted to create a fix for this issue and tested it in our environment. It keeps the space usage under control as compared to the original implementation.
> As a part of this fix, we truncate the file (as a part of purge cycle) if there are free entries found towards the end of the file. Also these free entries are removed from the freeList.
--
This message was sent by Atlassian JIRA
(v6.2.3#6260)
10 years, 5 months