[JBoss JIRA] (ISPN-4096) The unstable profile for server testsuite is not working correctly
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/ISPN-4096?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on ISPN-4096:
-----------------------------------------------
Martin Gencur <mgencur(a)redhat.com> changed the Status of [bug 1083900|https://bugzilla.redhat.com/show_bug.cgi?id=1083900] from NEW to VERIFIED
> The unstable profile for server testsuite is not working correctly
> ------------------------------------------------------------------
>
> …
[View More] Key: ISPN-4096
> URL: https://issues.jboss.org/browse/ISPN-4096
> Project: Infinispan
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Test Suite - Server
> Reporter: Jakub Markos
> Assignee: Jakub Markos
> Labels: 630
> Fix For: 7.0.0.Alpha2
>
>
> There are several surefire executions defined in the testsuites pom.xml, each can use a different arquillian group (which is just a set of container configurations). There are 4 main executions: suite-client-local, suite-client-dist, suite-client-repl, suite-manual. The unstable profile is configured to run the tests marked with Unstable category, but it's only using the arquillian group from suite-manual, so if there is a unstable client test, it fails because it can't find the arquillian container definition.
> Looking for a nice solution.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
[View Less]
10 years, 8 months
[JBoss JIRA] (ISPN-4585) Prioritize commands in the remote executor
by Pedro Ruivo (JIRA)
[ https://issues.jboss.org/browse/ISPN-4585?page=com.atlassian.jira.plugin.... ]
Pedro Ruivo commented on ISPN-4585:
-----------------------------------
The use of a {{PriorityQueue}} may not be possible if the user inject their own {{ExecutorService}}.
For transactional caches I think we can mark the {{CommitCommand}} as non-blocking and they are processed immediately in the JGroups thread. But I think both of this solutions will not solve the problem for non-transactional cache.
> …
[View More]Prioritize commands in the remote executor
> ------------------------------------------
>
> Key: ISPN-4585
> URL: https://issues.jboss.org/browse/ISPN-4585
> Project: Infinispan
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Core
> Affects Versions: 7.0.0.Alpha5
> Reporter: Dan Berindei
> Assignee: Dan Berindei
> Fix For: 7.0.0.Final
>
>
> The remote executor currently has an unlimited queue of blocked task, but the underlying executor cannot use a queue. With a queue, we wouldn't need to overflow remote commands to the OOB threads, and the OOB threads would be free to process response messages.
> The problem is that {{ThreadPoolExecutor}} executes tasks in the order they are in the queue. If a node has a remote executor thread pool of 100 threads and receives a prepare(tx1, put(k, v1) comand, then 1000 prepare(tx_i, put(k, v_i)) commands, and finally a commit(tx1) command, the commit(tx1) command will block until all but 99 of the the prepare(tx_i, put(k, v_i)) commands have timed out.
> I think we could help this by using a {{PriorityBlockingQueue}} for the underlying executor, with commands ordered so that state transfer commands < commit/tx completion notification < prepare/lock. The commit command would still have to wait for one of the prepare commands currently running to time out, but it wouldn't have to wait for all of them.
> The current code, without a queue, would fill the remote executor and OOB thread pools, and it would discard the commit message (along with most of the prepare commands). The time it would take to process the commit successfully would depend on the timing of the retransmitted messages.
> Another possible improvement would be to keep track of the commands currently being executed, and always keep some threads free for commands with higher priority. But I'm not sure how easy it would be to do that on top of an injected {{ExecutorService}}.
> I believe there is also a problem with {{BlockingTaskAwareExecutorServiceImpl.checkForReadyTasks()}} after a topology change. Commands with the new topology id are all unblocked by submitting them to the underlying executor in FIFO order, on a single thread, so {{CallerRunsPolicy}} is not a valid rejection policy here.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
[View Less]
10 years, 8 months