[JBoss JIRA] (JGRP-1620) RpcDispatcher/MessageDispatcher changes
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1620?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1620:
---------------------------
Description:
* In MessageDispatcher.castMessageXXX() and send(), we pass a Message as argument. Change this to only ship the byte[] buffer and options.
** This prevents a unicast RPC from having a message with a null dest, or a multicast RPC having a message with a non-null dest (JGRP-1617).
* Sync and async calls
** If a unicast call is async, return null immediately after sending it
*** In case of a callWithFuture() -> return a null future as well (not a {{NullFuture}}!)
* If a multicast call is async, return null immediately (instead of an {{RspList}})
*** In case of a callWithFuture -> return a null future (instead of a {{nullFuture}})
* Investigate whether non-blocking RPCs need to create Request instances at all
** This prevents creation and population of the hashmap (for {{GroupRequest}})
** Async requests could be dispatched to {{RequestCorrelator}} directly
* Return a {{CompletableFuture}} instead of a {{NotifyingFuture}}
* Remove {{NotifyingFuture}} and {{FutureListener}}: requires changing {{ExecutionService}}
** Perhaps: https://github.com/wburns/infinispan/blob/ISPN-6074/core/src/main/java/or...
* Replaced {{org.jgroups.TimeoutException}} with {{java.util.concurrent.TimeoutException}}
was:
* In MessageDispatcher.castMessageXXX() and send(), we pass a Message as argument. Change this to only ship the byte[] buffer and options.
** This prevents a unicast RPC from having a message with a null dest, or a multicast RPC having a message with a non-null dest (JGRP-1617).
* Sync and async calls
** If a unicast call is async, return null immediately after sending it
*** In case of a callWithFuture() -> return a null future as well (not a {{NullFuture}}!)
* If a multicast call is async, return null immediately (instead of an {{RspList}})
*** In case of a callWithFuture -> return a null future (instead of a {{nullFuture}})
* Investigate whether non-blocking RPCs need to create Request instances at all
** This prevents creation and population of the hashmap (for {{GroupRequest}})
** Async requests could be dispatched to {{RequestCorrelator}} directly
* Return a {{CompletableFuture}} instead of a {{NotifyingFuture}}
* Remove {{NotifyingFuture}} and {{FutureListener}}: requires changing {{ExecutionService}}
** Perhaps: https://github.com/wburns/infinispan/blob/ISPN-6074/core/src/main/java/or...
> RpcDispatcher/MessageDispatcher changes
> ---------------------------------------
>
> Key: JGRP-1620
> URL: https://issues.jboss.org/browse/JGRP-1620
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> * In MessageDispatcher.castMessageXXX() and send(), we pass a Message as argument. Change this to only ship the byte[] buffer and options.
> ** This prevents a unicast RPC from having a message with a null dest, or a multicast RPC having a message with a non-null dest (JGRP-1617).
> * Sync and async calls
> ** If a unicast call is async, return null immediately after sending it
> *** In case of a callWithFuture() -> return a null future as well (not a {{NullFuture}}!)
> * If a multicast call is async, return null immediately (instead of an {{RspList}})
> *** In case of a callWithFuture -> return a null future (instead of a {{nullFuture}})
> * Investigate whether non-blocking RPCs need to create Request instances at all
> ** This prevents creation and population of the hashmap (for {{GroupRequest}})
> ** Async requests could be dispatched to {{RequestCorrelator}} directly
> * Return a {{CompletableFuture}} instead of a {{NotifyingFuture}}
> * Remove {{NotifyingFuture}} and {{FutureListener}}: requires changing {{ExecutionService}}
> ** Perhaps: https://github.com/wburns/infinispan/blob/ISPN-6074/core/src/main/java/or...
> * Replaced {{org.jgroups.TimeoutException}} with {{java.util.concurrent.TimeoutException}}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6223) Enabling statistics in web console requires reload while it doesn't in CLI
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-6223?page=com.atlassian.jira.plugin.... ]
Chao Wang commented on WFLY-6223:
---------------------------------
This is not an issue in HAL as originally reported. When it writes the attributes in ws provider form, it write also attribute Wsdl host : ${jboss.bind.address:127.0.0.1} as well, which requires a reload action if there is an active ws deployment. Because WSServerConfigAttributeHandler compares unresolved current value to a resolved value. If you click "Save" without changing any value, it asks for a server reload as well.
> Enabling statistics in web console requires reload while it doesn't in CLI
> --------------------------------------------------------------------------
>
> Key: WFLY-6223
> URL: https://issues.jboss.org/browse/WFLY-6223
> Project: WildFly
> Issue Type: Bug
> Components: Web Console, Web Services
> Affects Versions: 10.0.0.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
>
> If I want to enable statistics for Web Services subsystem, I do it in CLI:
> {noformat}
> [standalone@localhost:9990 /] /subsystem=webservices:write-attribute(name=statistics-enabled, value=true)
> {"outcome" => "success"}
> {noformat}
> Via web console, I navigate to Configuration->Subsystems->Web Services->View
> I click edit and click checkbox for statistics enabled attribute. Now when I submit the value by clicking Save, dialog appears with reload require information.
> There is no need to require reload just for enabling statistics, by the way statistics are accessible even before reload (Runtime->Subsystems->Webservices and try to get wsdl for the web service for several times).
> Note: if there is no active deployment, reload is not required in web console (correct). To reproduce the issue you must have some active WS deployment
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5566) org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed
by Ivan Straka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5566?page=com.atlassian.jira.plugin.... ]
Ivan Straka edited comment on WFLY-5566 at 2/16/16 2:30 AM:
------------------------------------------------------------
,,Discovery sends a discovery request, and waits for num_initial_members discovery responses, or timeout ms, whichever occurs first, before returning"
http://www.jgroups.org/manual/#Discovery
Therefore, if more responses arrive cluster will be made up of all of them.
I just think, that using tcpgossip discovery protocol in this test does not make any sense.
was (Author: istraka):
,,Discovery sends a discovery request, and waits for num_initial_members discovery responses, or timeout ms, whichever occurs first, before returning"
http://www.jgroups.org/manual/#Discovery
Therefore, if more responses arrive cluster will be made up of all of them.
> org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed
> --------------------------------------------------------------------------------
>
> Key: WFLY-5566
> URL: https://issues.jboss.org/browse/WFLY-5566
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.CR2
> Reporter: Ivan Straka
> Assignee: Dmitrii Tikhomirov
> Labels: clustering_revalidate
>
> There is org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed failing with exception:
> {code:java}
> Error Message
> expected:<500> but was:<200>
> Stacktrace
> java.lang.AssertionError: expected:<500> but was:<200>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase.testPutToBackupNotRelayed(XSiteSimpleTestCase.java:202)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5566) org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed
by Ivan Straka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5566?page=com.atlassian.jira.plugin.... ]
Ivan Straka commented on WFLY-5566:
-----------------------------------
,,Discovery sends a discovery request, and waits for num_initial_members discovery responses, or timeout ms, whichever occurs first, before returning"
http://www.jgroups.org/manual/#Discovery
Therefore, if more responses arrive cluster will be made up of all of them.
> org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed
> --------------------------------------------------------------------------------
>
> Key: WFLY-5566
> URL: https://issues.jboss.org/browse/WFLY-5566
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.CR2
> Reporter: Ivan Straka
> Assignee: Dmitrii Tikhomirov
> Labels: clustering_revalidate
>
> There is org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed failing with exception:
> {code:java}
> Error Message
> expected:<500> but was:<200>
> Stacktrace
> java.lang.AssertionError: expected:<500> but was:<200>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase.testPutToBackupNotRelayed(XSiteSimpleTestCase.java:202)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5566) org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed
by Ivan Straka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5566?page=com.atlassian.jira.plugin.... ]
Ivan Straka updated WFLY-5566:
------------------------------
Comment: was deleted
(was: ,,Discovery sends a discovery request, and waits for `num_initial_members` discovery responses, or `timeout` ms, whichever occurs first, before returning"
http://www.jgroups.org/manual/#Discovery
)
> org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed
> --------------------------------------------------------------------------------
>
> Key: WFLY-5566
> URL: https://issues.jboss.org/browse/WFLY-5566
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.CR2
> Reporter: Ivan Straka
> Assignee: Dmitrii Tikhomirov
> Labels: clustering_revalidate
>
> There is org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed failing with exception:
> {code:java}
> Error Message
> expected:<500> but was:<200>
> Stacktrace
> java.lang.AssertionError: expected:<500> but was:<200>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase.testPutToBackupNotRelayed(XSiteSimpleTestCase.java:202)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-5566) org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed
by Ivan Straka (JIRA)
[ https://issues.jboss.org/browse/WFLY-5566?page=com.atlassian.jira.plugin.... ]
Ivan Straka commented on WFLY-5566:
-----------------------------------
,,Discovery sends a discovery request, and waits for `num_initial_members` discovery responses, or `timeout` ms, whichever occurs first, before returning"
http://www.jgroups.org/manual/#Discovery
> org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed
> --------------------------------------------------------------------------------
>
> Key: WFLY-5566
> URL: https://issues.jboss.org/browse/WFLY-5566
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Test Suite
> Affects Versions: 10.0.0.CR2
> Reporter: Ivan Straka
> Assignee: Dmitrii Tikhomirov
> Labels: clustering_revalidate
>
> There is org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase#testPutToBackupNotRelayed failing with exception:
> {code:java}
> Error Message
> expected:<500> but was:<200>
> Stacktrace
> java.lang.AssertionError: expected:<500> but was:<200>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at org.jboss.as.test.clustering.xsite.XSiteSimpleTestCase.testPutToBackupNotRelayed(XSiteSimpleTestCase.java:202)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6223) Enabling statistics in web console requires reload while it doesn't in CLI
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-6223?page=com.atlassian.jira.plugin.... ]
Chao Wang moved JBEAP-3425 to WFLY-6223:
----------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6223 (was: JBEAP-3425)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web Console
Web Services
(was: Web Console)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 10.0.0.Final
(was: 7.0.0.ER5)
> Enabling statistics in web console requires reload while it doesn't in CLI
> --------------------------------------------------------------------------
>
> Key: WFLY-6223
> URL: https://issues.jboss.org/browse/WFLY-6223
> Project: WildFly
> Issue Type: Bug
> Components: Web Console, Web Services
> Affects Versions: 10.0.0.Final
> Reporter: Chao Wang
> Assignee: Chao Wang
>
> If I want to enable statistics for Web Services subsystem, I do it in CLI:
> {noformat}
> [standalone@localhost:9990 /] /subsystem=webservices:write-attribute(name=statistics-enabled, value=true)
> {"outcome" => "success"}
> {noformat}
> Via web console, I navigate to Configuration->Subsystems->Web Services->View
> I click edit and click checkbox for statistics enabled attribute. Now when I submit the value by clicking Save, dialog appears with reload require information.
> There is no need to require reload just for enabling statistics, by the way statistics are accessible even before reload (Runtime->Subsystems->Webservices and try to get wsdl for the web service for several times).
> Note: if there is no active deployment, reload is not required in web console (correct). To reproduce the issue you must have some active WS deployment
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-263) Cancelling management op on slave HC tree is broken
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-263?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-263:
------------------------------------------------
baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1202610|https://bugzilla.redhat.com/show_bug.cgi?id=1202610] from ASSIGNED to NEW
> Cancelling management op on slave HC tree is broken
> ---------------------------------------------------
>
> Key: WFCORE-263
> URL: https://issues.jboss.org/browse/WFCORE-263
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.0.Alpha9
> Reporter: James Livingston
> Assignee: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
> Attachments: unundeployable.zip
>
>
> If you have a DC with a slave HC, and perform a management operation which gets stuck, non-progressing operations will be reported for both the DC and the slave HC via:
> /host=master/core-service=management/service=management-operations:find-non-progressing-operation
> /host=slave/core-service=management/service=management-operations:find-non-progressing-operation
> Cancelling the operation under /host=master works as expected, pushing the cancellation down to the slave and the controllers become responsive again.
> If however you attempt to cancel the operation under /host=slave, it goes bad. { "outcome" => "success", "result" => undefined } is reported in the CLI, but the controllers are still unresponsive.
> Running :find-non-progressing-operation against the slave will report the {outcome=success,result=undefined} rather than that no non-progressing operations were found, and active-operation=*:read-resource() shows it as not cancelled.
> Once you attempt to cancel it on a slave, attempting to cancel it under /host=master will report success, but leave the slave op in a weird state, and things requiring the controller lock (such as the web UI) will still not respond.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months