[JBoss JIRA] (JGRP-1874) UNICAST3/UNICAST2: reduce traffic caused by GET-FIRST-SEQNO
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1874?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1874:
---------------------------
Description:
When we have sender A and receiver B, and B closes its connection unilaterally (see JGRP-1873), then a {{GET-FIRST-SEQNO}} will be sent from B to A when A's next message is received. This can potentially generate a lot of traffic.
Example:
# B has no entry for A in its recv-table
# A has {{B:: 100 | 1000}}, so only message {{A::100}} has been acked by B ({{STABLE}} or {{ACK}} message
# If B now gets {{A::560}}, it sends a {{GET-FIRST-SEQNO(560)}} to A
#* As a matter of fact, for any message from A that not marked as {{first}}, B will send a {{GET-FIRST-SEQNO}} message: too much traffic
# A now sends messages {{A::101}} - {{A::560}} to B
#* This is also not needed: too much traffic
h5. Solution to reduce traffic
* Receiver: add timestamp to recv-table entries which drops {{GET-FIRST-SEQNO}} messages sent sooner than N ms after the previous one
** So rather than sending 1000 {{GET-FIRST-SEQNO}} messages to A when receiving 1000 unicasts from A not marked as {{first}}, we might only send a _single message_
* Sender: when a {{GET-FIRST-SEQNO(560)}} message is received from B, only send the lowest sent (101) and the highest sent (560) back to B
** B will then retransmit all missing messages in that range
** For {{UNICAST3}}, we can only send the lowest sent message (101) as it will retransmit {{A::1000}} anyway and therefore trigger retransmission
was:
When we have sender A and receiver B, and B closes its connection unilaterally (see JGRP-1873), then a {{GET-FIRST-SEQNO}} will be sent from B to A when A's next message is received. This can potentially generate a lot of traffic.
Example:
# B has no entry for A in its recv-table
# A has {{B:: 100 | 1000}}, so only message {{A::100}} has been acked by B ({{STABLE}} or {{ACK}} message
# If B now gets {{A::560}}, it sends a {{GET-FIRST-SEQNO(560)}} to A
#* As a matter of fact, for any message from A that not marked as {{first}}, B will send a {{GET-FIRST-SEQNO}} message: too much traffic
# A now sends messages {{A::101}} - {{A::560}} to B
#* This is also not needed: too much traffic
h5. Solution to reduce traffic
* Receiver: add timestamp to recv-table entries which drops {{GET-FIRST-SEQNO}} messages sent sooner than N ms after the last one
** So rather than sending 1000 {{GET-FIRST-SEQNO}} messages to A when receiving 1000 unicasts from A not marked as {{first}}, we might only send a _single message_
* Sender: when a {{GET-FIRST-SEQNO(560)}} message is received from B, only send the lowest sent (101) and the highest sent (560) back to B
** B will then retransmit all missing messages in that range
** For {{UNICAST3}}, we can only send the lowest sent message (101) as it will retransmit {{A::1000}} anyway and therefore trigger retransmission
> UNICAST3/UNICAST2: reduce traffic caused by GET-FIRST-SEQNO
> -----------------------------------------------------------
>
> Key: JGRP-1874
> URL: https://issues.jboss.org/browse/JGRP-1874
> Project: JGroups
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> When we have sender A and receiver B, and B closes its connection unilaterally (see JGRP-1873), then a {{GET-FIRST-SEQNO}} will be sent from B to A when A's next message is received. This can potentially generate a lot of traffic.
> Example:
> # B has no entry for A in its recv-table
> # A has {{B:: 100 | 1000}}, so only message {{A::100}} has been acked by B ({{STABLE}} or {{ACK}} message
> # If B now gets {{A::560}}, it sends a {{GET-FIRST-SEQNO(560)}} to A
> #* As a matter of fact, for any message from A that not marked as {{first}}, B will send a {{GET-FIRST-SEQNO}} message: too much traffic
> # A now sends messages {{A::101}} - {{A::560}} to B
> #* This is also not needed: too much traffic
> h5. Solution to reduce traffic
> * Receiver: add timestamp to recv-table entries which drops {{GET-FIRST-SEQNO}} messages sent sooner than N ms after the previous one
> ** So rather than sending 1000 {{GET-FIRST-SEQNO}} messages to A when receiving 1000 unicasts from A not marked as {{first}}, we might only send a _single message_
> * Sender: when a {{GET-FIRST-SEQNO(560)}} message is received from B, only send the lowest sent (101) and the highest sent (560) back to B
> ** B will then retransmit all missing messages in that range
> ** For {{UNICAST3}}, we can only send the lowest sent message (101) as it will retransmit {{A::1000}} anyway and therefore trigger retransmission
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (JGRP-1874) UNICAST3/UNICAST2: reduce traffic caused by GET-FIRST-SEQNO
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1874?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1874:
---------------------------
Description:
When we have sender A and receiver B, and B closes its connection unilaterally (see JGRP-1873), then a {{GET-FIRST-SEQNO}} will be sent from B to A when A's next message is received. This can potentially generate a lot of traffic.
Example:
# B has no entry for A in its recv-table
# A has {{B:: 100 | 1000}}, so only message {{A::100}} has been acked by B ({{STABLE}} or {{ACK}} message
# If B now gets {{A::560}}, it sends a {{GET-FIRST-SEQNO(560)}} to A
#* As a matter of fact, for any message from A that not marked as {{first}}, B will send a {{GET-FIRST-SEQNO}} message: too much traffic
# A now sends messages {{A::101}} - {{A::560}} to B
#* This is also not needed: too much traffic
h5. Solution to reduce traffic
* Receiver: add timestamp to recv-table entries which drops {{GET-FIRST-SEQNO}} messages sent sooner than N ms after the last one
** So rather than sending 1000 {{GET-FIRST-SEQNO}} messages to A when receiving 1000 unicasts from A not marked as {{first}}, we might only send a _single message_
* Sender: when a {{GET-FIRST-SEQNO(560)}} message is received from B, only send the lowest sent (101) and the highest sent (560) back to B
** B will then retransmit all missing messages in that range
** For {{UNICAST3}}, we can only send the lowest sent message (101) as it will retransmit {{A::1000}} anyway and therefore trigger retransmission
was:
When we have sender A and receiver B, and B closes its connection unilaterally (see JGRP-1873), then a {{GET-FIRST-SEQNO}} will be sent from B to A when A's next message is received. This can potentially generate a lot of traffic.
Example:
# B has no entry for A in its recv-table
# A has {{B:: 100 | 1000}}, so only message {{A::100}} has been acked by B ({{STABLE}} or {{ACK}} message
# If B now gets {{A::560}}, it sends a {{GET-FIRST-SEQNO(560)}} to A
#* As a matter of fact, for any message from A that not marked as {{first}}, B will send a {{GET-FIRST-SEQNO message}}: too much traffic
# A now sends messages {{A::101}} - {{A::560}} to B
#* This is also not needed: too much traffic
h5. Solution to reduce traffic
* Receiver: add timestamp to recv-table entries which drops {{GET-FIRST-SEQNO}} messages sent sooner than N ms after the last one
** So rather than sending 1000 {{GET-FIRST-SEQNO}} messages to A when receiving 1000 unicasts from A not marked as {{first}}, we might only send a _single message_
* Sender: when a {{GET-FIRST-SEQNO(560)}} message is received from B, only send the lowest sent (101) and the highest sent (560) back to B
** B will then retransmit all missing messages in that range
** For {{UNICAST3}}, we can only send the lowest sent message (101) as it will retransmit {{A::1000}} anyway and therefore trigger retransmission
> UNICAST3/UNICAST2: reduce traffic caused by GET-FIRST-SEQNO
> -----------------------------------------------------------
>
> Key: JGRP-1874
> URL: https://issues.jboss.org/browse/JGRP-1874
> Project: JGroups
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> When we have sender A and receiver B, and B closes its connection unilaterally (see JGRP-1873), then a {{GET-FIRST-SEQNO}} will be sent from B to A when A's next message is received. This can potentially generate a lot of traffic.
> Example:
> # B has no entry for A in its recv-table
> # A has {{B:: 100 | 1000}}, so only message {{A::100}} has been acked by B ({{STABLE}} or {{ACK}} message
> # If B now gets {{A::560}}, it sends a {{GET-FIRST-SEQNO(560)}} to A
> #* As a matter of fact, for any message from A that not marked as {{first}}, B will send a {{GET-FIRST-SEQNO}} message: too much traffic
> # A now sends messages {{A::101}} - {{A::560}} to B
> #* This is also not needed: too much traffic
> h5. Solution to reduce traffic
> * Receiver: add timestamp to recv-table entries which drops {{GET-FIRST-SEQNO}} messages sent sooner than N ms after the last one
> ** So rather than sending 1000 {{GET-FIRST-SEQNO}} messages to A when receiving 1000 unicasts from A not marked as {{first}}, we might only send a _single message_
> * Sender: when a {{GET-FIRST-SEQNO(560)}} message is received from B, only send the lowest sent (101) and the highest sent (560) back to B
> ** B will then retransmit all missing messages in that range
> ** For {{UNICAST3}}, we can only send the lowest sent message (101) as it will retransmit {{A::1000}} anyway and therefore trigger retransmission
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (JGRP-1874) UNICAST3/UNICAST2: reduce traffic caused by GET-FIRST-SEQNO
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1874?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1874:
---------------------------
Description:
When we have sender A and receiver B, and B closes its connection unilaterally (see JGRP-1873), then a {{GET-FIRST-SEQNO}} will be sent from B to A when A's next message is received. This can potentially generate a lot of traffic.
Example:
# B has no entry for A in its recv-table
# A has {{B:: 100 | 1000}}, so only message {{A::100}} has been acked by B ({{STABLE}} or {{ACK}} message
# If B now gets {{A::560}}, it sends a {{GET-FIRST-SEQNO(560)}} to A
#* As a matter of fact, for any message from A that not marked as {{first}}, B will send a {{GET-FIRST-SEQNO message}}: too much traffic
# A now sends messages {{A::101}} - {{A::560}} to B
#* This is also not needed: too much traffic
h5. Solution to reduce traffic
* Receiver: add timestamp to recv-table entries which drops {{GET-FIRST-SEQNO}} messages sent sooner than N ms after the last one
** So rather than sending 1000 {{GET-FIRST-SEQNO}} messages to A when receiving 1000 unicasts from A not marked as {{first}}, we might only send a _single message_
* Sender: when a {{GET-FIRST-SEQNO(560)}} message is received from B, only send the lowest sent (101) and the highest sent (560) back to B
** B will then retransmit all missing messages in that range
** For {{UNICAST3}}, we can only send the lowest sent message (101) as it will retransmit {{A::1000}} anyway and therefore trigger retransmission
was:
When we have sender A and receiver B, and B closes its connection unilaterally (see JGRP-1873), then a {{GET-FIRST-SEQNO}} will be sent from B to A when A's next message is received. This can potentially generate a lot of traffic.
Example:
# B has no entry for A in its recv-table
# A has {{B:: 100 | 1000}}, so only message {{A::100}} has been acked by B ({{STABLE}} or {{ACK}} message
# If B now gets {{A::560}}, it sends a {{GET-FIRST-SEQNO(560)}} to A
#* As a matter of fact, for any message from A that not marked as {{first}}, B will send a {{GET-FIRS-SEQNO message}}: too much traffic
# A now sends messages {{A::101}} - {{A::560}} to B
#* This is also not needed: too much traffic
h5. Solution to reduce traffic
* Receiver: add timestamp to recv-table entries which drops {{GET-FIRST-SEQNO}} messages sent sooner than N ms after the last one
** So rather than sending 1000 {{GET-FIRST-SEQNO}} messages to A when receiving 1000 unicasts from A not marked as {{first}}, we might only send a _single message_
* Sender: when a {{GET-FIRST-SEQNO(560)}} message is received from B, only send the lowest sent (101) and the highest sent (560) back to B
** B will then retransmit all missing messages in that range
** For {{UNICAST3}}, we can only send the lowest sent message (101) as it will retransmit {{A::1000}} anyway and therefore trigger retransmission
> UNICAST3/UNICAST2: reduce traffic caused by GET-FIRST-SEQNO
> -----------------------------------------------------------
>
> Key: JGRP-1874
> URL: https://issues.jboss.org/browse/JGRP-1874
> Project: JGroups
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> When we have sender A and receiver B, and B closes its connection unilaterally (see JGRP-1873), then a {{GET-FIRST-SEQNO}} will be sent from B to A when A's next message is received. This can potentially generate a lot of traffic.
> Example:
> # B has no entry for A in its recv-table
> # A has {{B:: 100 | 1000}}, so only message {{A::100}} has been acked by B ({{STABLE}} or {{ACK}} message
> # If B now gets {{A::560}}, it sends a {{GET-FIRST-SEQNO(560)}} to A
> #* As a matter of fact, for any message from A that not marked as {{first}}, B will send a {{GET-FIRST-SEQNO message}}: too much traffic
> # A now sends messages {{A::101}} - {{A::560}} to B
> #* This is also not needed: too much traffic
> h5. Solution to reduce traffic
> * Receiver: add timestamp to recv-table entries which drops {{GET-FIRST-SEQNO}} messages sent sooner than N ms after the last one
> ** So rather than sending 1000 {{GET-FIRST-SEQNO}} messages to A when receiving 1000 unicasts from A not marked as {{first}}, we might only send a _single message_
> * Sender: when a {{GET-FIRST-SEQNO(560)}} message is received from B, only send the lowest sent (101) and the highest sent (560) back to B
> ** B will then retransmit all missing messages in that range
> ** For {{UNICAST3}}, we can only send the lowest sent message (101) as it will retransmit {{A::1000}} anyway and therefore trigger retransmission
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (JGRP-1872) Table: purge() with incorrect seqnos moves HD/LOW back
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1872?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1872.
----------------------------
Resolution: Done
Added TableTest.testPurgeLower()
> Table: purge() with incorrect seqnos moves HD/LOW back
> ------------------------------------------------------
>
> Key: JGRP-1872
> URL: https://issues.jboss.org/browse/JGRP-1872
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.4.6
>
>
> When we have a Table with {{low=40, hd=40, hr=45}} and receive a {{purge(30,true)}}, then the table will be {{low=30,hd=30,hr=45}}.
> This only happens with parameter {{force}} being {{true}}.
> This doesn't cause any bugs, but until the next (correct) {{purge()}} is invoked, the table will show and incorrect number of missing messages.
> SOLUTION: add the check to the start of {{purge()}}:
> {code}
> if(seqno <= low) // perhaps check for force as well
> return;
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-2996) Remove need for native-interface on the Host Controller
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2996?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-2996:
----------------------------------------
Even in that example code, if the correct constructor of URI is used there is no need to worry about IPv6 as the URI constructor will handle it - URI will also handle the correct concatenation.
> Remove need for native-interface on the Host Controller
> -------------------------------------------------------
>
> Key: WFLY-2996
> URL: https://issues.jboss.org/browse/WFLY-2996
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Emmanuel Hugonnet
> Fix For: 9.0.0.CR1
>
>
> The HC requires a native-interface because the intra-domain comms (slave->master and server->HC) are hard coded to the "remote" protocol. Make this configurable for slave->master and dynamically determine what to use for server->HC.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-2996) Remove need for native-interface on the Host Controller
by Emmanuel Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-2996?page=com.atlassian.jira.plugin.... ]
Emmanuel Hugonnet commented on WFLY-2996:
-----------------------------------------
RemoteDomainConnectionService
public synchronized void register() throws IOException {
...
masterURI = new URI("remote://" + NetworkUtils.formatPossibleIpv6Address(host) + ":" + port);
...
}
> Remove need for native-interface on the Host Controller
> -------------------------------------------------------
>
> Key: WFLY-2996
> URL: https://issues.jboss.org/browse/WFLY-2996
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Emmanuel Hugonnet
> Fix For: 9.0.0.CR1
>
>
> The HC requires a native-interface because the intra-domain comms (slave->master and server->HC) are hard coded to the "remote" protocol. Make this configurable for slave->master and dynamically determine what to use for server->HC.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-3410) Old “remote://“ protocol is hard coded RemoteDomainConnectionService
by Emmanuel Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-3410?page=com.atlassian.jira.plugin.... ]
Emmanuel Hugonnet commented on WFLY-3410:
-----------------------------------------
RemoteDomainConnectionService
public synchronized void register() throws IOException {
...
masterURI = new URI("remote://" + NetworkUtils.formatPossibleIpv6Address(host) + ":" + port);
> Old “remote://“ protocol is hard coded RemoteDomainConnectionService
> --------------------------------------------------------------------
>
> Key: WFLY-3410
> URL: https://issues.jboss.org/browse/WFLY-3410
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Arun Gupta
>
> Email conversation on wildfly-dev:
> http://lists.jboss.org/pipermail/wildfly-dev/2014-May/002157.html
> > 1). Why the following entry is still referring to 9999 ? Shouldn't it be 9990 ?
> >
> > <domain-controller>
> > <remote host="10.211.55.7" port="9999"/>
> > </domain-controller>
> >
> > FTR it only works with 9999, not with 9990.
> >
> > Domain Controller shows the message:
> >
> > [Host Controller] 15:36:22,811 INFO [org.jboss.as.domain] (Host
> > Controller Service Threads - 28) JBAS010918: Registered remote slave
> > host "slave", WildFly 8.1.0.CR2 “Kenny”
> It looks like we hardcode the old “remote://“ protocol in RemoteDomainConnectionService rather than the new http-remoting protocol, so it is a bug. I am not sure if that is something we should attempt to negotiate explicitly, or to make the <remote> element take a ‘protocol’ attribute?
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-3756) Rename package name of whole Arquillian Wildfly adapter
by Karel Piwko (JIRA)
[ https://issues.jboss.org/browse/WFLY-3756?page=com.atlassian.jira.plugin.... ]
Karel Piwko updated WFLY-3756:
------------------------------
Assignee: Stefan Miklosovic (was: Karel Piwko)
> Rename package name of whole Arquillian Wildfly adapter
> -------------------------------------------------------
>
> Key: WFLY-3756
> URL: https://issues.jboss.org/browse/WFLY-3756
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Test Suite
> Affects Versions: 8.1.0.Final
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
>
> Speaking about Arquillian Wildfly container adapter, some time ago it seems to me it was directly embedded into wildfly repository at github when I recall that correctly.
> Right now, it is deleted from there and is moved to https://github.com/wildfly/wildfly-arquillian
> The problem is that when you want to make a test which mixes two containers together, to be concrete, good old AS7 and new Wildfly, you can not do that since its package name are just same so you have naming clash on your class path.
> I am author of multiple container extension (1) (2) under Arquillian umbrella which enables the usage of two different container adapters in one test run which is not possible normally. While it was possible to make the difference between Jboss AS 7 and Wildfly since theirs package names were org.jboss.as and org.wildfly respectively when Wildfly was embedded in Wildfly repo itself, you can not do this anymore.
> This affects e.g. guys from Infinispan project which are trying to cover the migration from JBoss AS to Wildfly and they are writing tests for it. (you have old Jbosses and Wildflies and Infinispan can migrate data from one server to another and drop the old ones).
> I suggest to rename package name to org.wildfly to not collide anymore.
> Thanks a lot!
> (1) https://github.com/arquillian/arquillian-droidium/tree/master/droidium-co...
> (2) https://github.com/arquillian/arquillian-droidium/tree/master/droidium-co...
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months
[JBoss JIRA] (WFLY-3756) Rename package name of whole Arquillian Wildfly adapter
by Karel Piwko (JIRA)
[ https://issues.jboss.org/browse/WFLY-3756?page=com.atlassian.jira.plugin.... ]
Karel Piwko commented on WFLY-3756:
-----------------------------------
+1, this is a nice catch. [~smikloso] can you prepare a PR for such change? It should be completely transparent for users as the depend only on G:A:V. Users of multi-container extensions might be affected but I guess that you can bridge the change to Droidium users quite easily.
> Rename package name of whole Arquillian Wildfly adapter
> -------------------------------------------------------
>
> Key: WFLY-3756
> URL: https://issues.jboss.org/browse/WFLY-3756
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Test Suite
> Affects Versions: 8.1.0.Final
> Reporter: Stefan Miklosovic
> Assignee: Karel Piwko
>
> Speaking about Arquillian Wildfly container adapter, some time ago it seems to me it was directly embedded into wildfly repository at github when I recall that correctly.
> Right now, it is deleted from there and is moved to https://github.com/wildfly/wildfly-arquillian
> The problem is that when you want to make a test which mixes two containers together, to be concrete, good old AS7 and new Wildfly, you can not do that since its package name are just same so you have naming clash on your class path.
> I am author of multiple container extension (1) (2) under Arquillian umbrella which enables the usage of two different container adapters in one test run which is not possible normally. While it was possible to make the difference between Jboss AS 7 and Wildfly since theirs package names were org.jboss.as and org.wildfly respectively when Wildfly was embedded in Wildfly repo itself, you can not do this anymore.
> This affects e.g. guys from Infinispan project which are trying to cover the migration from JBoss AS to Wildfly and they are writing tests for it. (you have old Jbosses and Wildflies and Infinispan can migrate data from one server to another and drop the old ones).
> I suggest to rename package name to org.wildfly to not collide anymore.
> Thanks a lot!
> (1) https://github.com/arquillian/arquillian-droidium/tree/master/droidium-co...
> (2) https://github.com/arquillian/arquillian-droidium/tree/master/droidium-co...
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 2 months