[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
[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
[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
[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