[JBoss JIRA] (WFLY-3767) Update tools/maven handling in 8.x to match master
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-3767:
--------------------------------------
Summary: Update tools/maven handling in 8.x to match master
Key: WFLY-3767
URL: https://issues.jboss.org/browse/WFLY-3767
Project: WildFly
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Brian Stansberry
Fix For: 8.2.0.CR1
The master branch has had its handling of maven changed such that the maven jars are no longer part of the source repo. This results in hassles when the 8.x branch is checked out in a local git repo, as the maven jars pulled down by the master build are now treated as untracked files by git.
Task is to make 8.x work like master so these files will be ignored by git.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (JGRP-1873) UNICAST2: unilateral connection close of receiver can lead to missing seqnos in sender
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1873?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1873:
---------------------------
Description:
In {{UNICAST2}}, if we have a connection between sender A and receiver B, and B closes the connection (but not A), then A can end up with missing messages in its send table.
Example:
* A sends messages to B
* A has an entry for B in its send-table: {{B: 10|20}} (lowest sent=10, highest sent=20)
* B has an entry for A in its recv-table: {{A: 10|20}} (lowest received=10, highest received=20)
* B now gets a view that doesn't contain A and closes its connection to A
** This results in B's connection to A getting removed
* A now sends message {{A::21}}
* B doesn't find an entry in its recv-table for A and sends {{GET-FIRST-SEQNO}} to A
* A receives the request and sends message {{A::11 first}} - {{A:21}} to B. These messages are sent unreliably, so they can get dropped. Let's assume (for this example) that all of them are dropped.
* B creates an entry for A in its recv-table: {{A: 10|21}} (next to be received is {{A:11}})
* Now a spurious {{STABLE(A::15)}} message by B is received by A
** This can happen when B sent the {{STABLE}} message *before* its connection to A was removed, but the message was delayed, e.g. by garbage collection
** Note that the connection ID ({{conn-id}} is the same, so A will _not_ reject the {{STABLE}} message by B
* A receives the {{STABLE}} message and purges elements up to 15, so its new entry for B is: {{B:: 15|21}}
* When B asks A for retransmission of messages {{A::11}} - {{A:21}}, A can only retransmit messages 16-21, but *not* {{A::11}} - {{A:15}} !
was:
In {{UNICAST2}}, if we have a connection between sender A and receiver B, and B closes the connection (but not A), then A can end up with missing messages in its send table.
Example:
* A sends messages to B
* A has an entry for B in its send-table: {{B: 10|20}} (low=10, highest sent=20)
* B has an entry for A in its recv-table: {{A: 10|20}} (lowest received=10, highest received=20)
* B now gets a view that doesn't contain A and closes its connection to A
** This results in B's connection to A getting removed
* A now sends message {{A::21}}
* B doesn't find an entry in its recv-table for A and sends {{GET-FIRST-SEQNO}} to A
* A receives the request and sends message {{A::11 first}} - {{A:21}} to B. These messages are sent unreliably, so they can get dropped. Let's assume (for this example) that all of them are dropped.
* B creates an entry for A in its recv-table: {{A: 10|21}} (next to be received is {{A:11}})
* Now a spurious {{STABLE(A::15)}} message by B is received by A
** This can happen when B sent the {{STABLE}} message *before* its connection to A was removed, but the message was delayed, e.g. by garbage collection
** Note that the connection ID ({{conn-id}} is the same, so A will _not_ reject the {{STABLE}} message by B
* A receives the {{STABLE}} message and purges elements up to 15, so its new entry for B is: {{B:: 15|21}}
* When B asks A for retransmission of messages {{A::11}} - {{A:21}}, A can only retransmit messages 16-21, but *not* {{A::11}} - {{A:15}} !
> UNICAST2: unilateral connection close of receiver can lead to missing seqnos in sender
> --------------------------------------------------------------------------------------
>
> Key: JGRP-1873
> URL: https://issues.jboss.org/browse/JGRP-1873
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> In {{UNICAST2}}, if we have a connection between sender A and receiver B, and B closes the connection (but not A), then A can end up with missing messages in its send table.
> Example:
> * A sends messages to B
> * A has an entry for B in its send-table: {{B: 10|20}} (lowest sent=10, highest sent=20)
> * B has an entry for A in its recv-table: {{A: 10|20}} (lowest received=10, highest received=20)
> * B now gets a view that doesn't contain A and closes its connection to A
> ** This results in B's connection to A getting removed
> * A now sends message {{A::21}}
> * B doesn't find an entry in its recv-table for A and sends {{GET-FIRST-SEQNO}} to A
> * A receives the request and sends message {{A::11 first}} - {{A:21}} to B. These messages are sent unreliably, so they can get dropped. Let's assume (for this example) that all of them are dropped.
> * B creates an entry for A in its recv-table: {{A: 10|21}} (next to be received is {{A:11}})
> * Now a spurious {{STABLE(A::15)}} message by B is received by A
> ** This can happen when B sent the {{STABLE}} message *before* its connection to A was removed, but the message was delayed, e.g. by garbage collection
> ** Note that the connection ID ({{conn-id}} is the same, so A will _not_ reject the {{STABLE}} message by B
> * A receives the {{STABLE}} message and purges elements up to 15, so its new entry for B is: {{B:: 15|21}}
> * When B asks A for retransmission of messages {{A::11}} - {{A:21}}, A can only retransmit messages 16-21, but *not* {{A::11}} - {{A:15}} !
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (JGRP-1873) UNICAST2: unilateral connection close of receiver can lead to missing seqnos in sender
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1873?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1873:
---------------------------
Description:
In {{UNICAST2}}, if we have a connection between sender A and receiver B, and B closes the connection (but not A), then A can end up with missing messages in its send table.
Example:
* A sends messages to B
* A has an entry for B in its send-table: {{B: 10|20}} (low=10, highest sent=20)
* B has an entry for A in its recv-table: {{A: 10|20}} (lowest received=10, highest received=20)
* B now gets a view that doesn't contain A and closes its connection to A
** This results in B's connection to A getting removed
* A now sends message {{A::21}}
* B doesn't find an entry in its recv-table for A and sends {{GET-FIRST-SEQNO}} to A
* A receives the request and sends message {{A::11 first}} - {{A:21}} to B. These messages are sent unreliably, so they can get dropped. Let's assume (for this example) that all of them are dropped.
* B creates an entry for A in its recv-table: {{A: 10|21}} (next to be received is {{A:11}})
* Now a spurious {{STABLE(A::15)}} message by B is received by A
** This can happen when B sent the {{STABLE}} message *before* its connection to A was removed, but the message was delayed, e.g. by garbage collection
** Note that the connection ID ({{conn-id}} is the same, so A will _not_ reject the {{STABLE}} message by B
* A receives the {{STABLE}} message and purges elements up to 15, so its new entry for B is: {{B:: 15|21}}
* When B asks A for retransmission of messages {{A::11}} - {{A:21}}, A can only retransmit messages 16-21, but *not* {{A::11}} - {{A:15}} !
was:
In {{UNICAST2}}, if we have a connection between sender A and receiver B, and B closes the connection (but not A), then A can end up with missing messages in its send table.
Example:
* A sends messages to B
* A has an entry for B in its send-table: {{B: 10|20}} (low=10, highest sent=20)
* B has an entry for A in its recv-table: {{A: 10|20}} (lowest received=10, highest received=20)
* B now gets a view that doesn't contain A and closes its connection to A
** This results in B's connection to A getting removed
* A now sends message {{A::21}}
* B doesn't find an entry in its recv-table for A and sends {{GET-FIRST-SEQNO}} to A
* A receives the request and sends message {{A::10 first}} - {{A:21}} to B. These messages are sent unreliably, so they can get dropped. Let's assume (for this example) that all of them are dropped.
* B creates an entry for A in its recv-table: {{A: 10|21}}
* Now a spurious {{STABLE(A::12)}} message by B is received by A
** This can happen when B sent the {{STABLE}} message *before* its connection to A was removed, but the message was delayed, e.g. by garbage collection
** Note that the connection ID ({{conn-id}} is the same, so the sender will not reject the {{STABLE}} message
* A receives the {{STABLE}} message and purges elements lower than 10, so its new entry for B is: {{B:: 12|21}}
* When B asks A for retransmission of messages {{A::10}} - {{A:21}}, A can only retransmit messages 12-21, but *not* {{A::10}} and {{A:11}} !
> UNICAST2: unilateral connection close of receiver can lead to missing seqnos in sender
> --------------------------------------------------------------------------------------
>
> Key: JGRP-1873
> URL: https://issues.jboss.org/browse/JGRP-1873
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> In {{UNICAST2}}, if we have a connection between sender A and receiver B, and B closes the connection (but not A), then A can end up with missing messages in its send table.
> Example:
> * A sends messages to B
> * A has an entry for B in its send-table: {{B: 10|20}} (low=10, highest sent=20)
> * B has an entry for A in its recv-table: {{A: 10|20}} (lowest received=10, highest received=20)
> * B now gets a view that doesn't contain A and closes its connection to A
> ** This results in B's connection to A getting removed
> * A now sends message {{A::21}}
> * B doesn't find an entry in its recv-table for A and sends {{GET-FIRST-SEQNO}} to A
> * A receives the request and sends message {{A::11 first}} - {{A:21}} to B. These messages are sent unreliably, so they can get dropped. Let's assume (for this example) that all of them are dropped.
> * B creates an entry for A in its recv-table: {{A: 10|21}} (next to be received is {{A:11}})
> * Now a spurious {{STABLE(A::15)}} message by B is received by A
> ** This can happen when B sent the {{STABLE}} message *before* its connection to A was removed, but the message was delayed, e.g. by garbage collection
> ** Note that the connection ID ({{conn-id}} is the same, so A will _not_ reject the {{STABLE}} message by B
> * A receives the {{STABLE}} message and purges elements up to 15, so its new entry for B is: {{B:: 15|21}}
> * When B asks A for retransmission of messages {{A::11}} - {{A:21}}, A can only retransmit messages 16-21, but *not* {{A::11}} - {{A:15}} !
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (JGRP-1873) UNICAST2: unilateral connection close of receiver can lead to missing seqnos in sender
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1873?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1873:
---------------------------
Description:
In {{UNICAST2}}, if we have a connection between sender A and receiver B, and B closes the connection (but not A), then A can end up with missing messages in its send table.
Example:
* A sends messages to B
* A has an entry for B in its send-table: {{B: 10|20}} (low=10, highest sent=20)
* B has an entry for A in its recv-table: {{A: 10|20}} (lowest received=10, highest received=20)
* B now gets a view that doesn't contain A and closes its connection to A
** This results in B's connection to A getting removed
* A now sends message {{A::21}}
* B doesn't find an entry in its recv-table for A and sends {{GET-FIRST-SEQNO}} to A
* A receives the request and sends message {{A::10 first}} - {{A:21}} to B. These messages are sent unreliably, so they can get dropped. Let's assume (for this example) that all of them are dropped.
* B creates an entry for A in its recv-table: {{A: 10|21}}
* Now a spurious {{STABLE(A::12)}} message by B is received by A
** This can happen when B sent the {{STABLE}} message *before* its connection to A was removed, but the message was delayed, e.g. by garbage collection
** Note that the connection ID ({{conn-id}} is the same, so the sender will not reject the {{STABLE}} message
* A receives the {{STABLE}} message and purges elements lower than 10, so its new entry for B is: {{B:: 12|21}}
* When B asks A for retransmission of messages {{A::10}} - {{A:21}}, A can only retransmit messages 12-21, but *not* {{A::10}} and {{A:11}} !
was:
In {{UNICAST2}}, if we have a connection between sender A and receiver B, and B closes the connection (but not A), then A can end up with missing messages in its send table.
Example:
* A send messages to B
* A has an entry for B in its send-table: {{B: 10|20}} (low=10, highest sent=20)
* B has an entry for A in its recv-table: {{A: 10|20}} (lowest received=10, highest received=20)
* B now gets a view that doesn't contain A and closes its connection to A
** This results in B's connection to A getting removed
* A now sends message {{A::21}}
* B doesn't find an entry in its recv-table for A and sends {{GET-FIRST-SEQNO}} to A
* A receives the request and sends message {{A::10 first}} - {{A:21}} to B. These messages are sent unreliably, so they can get dropped. Let's assume (for this example) that all of them are dropped.
* B creates an entry for A in its recv-table: {{A: 10|21}}
* Now a spurious {{STABLE(A::12)}} message by B is received by A
** This can happen when B sent the {{STABLE}} message *before* its connection to A was removed, but the message was delayed, e.g. by garbage collection
** Note that the connection ID ({{conn-id}} is the same, so the sender will not reject the {{STABLE}} message
* A receives the {{STABLE}} message and purges elements lower than 10, so its new entry for B is: {{B:: 12|21}}
* When B asks A for retransmission of messages {{A::10}} - {{A:21}}, A can only retransmit messages 12-21, but *not* {{A::10}} and {{A:11}} !
> UNICAST2: unilateral connection close of receiver can lead to missing seqnos in sender
> --------------------------------------------------------------------------------------
>
> Key: JGRP-1873
> URL: https://issues.jboss.org/browse/JGRP-1873
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.5
>
>
> In {{UNICAST2}}, if we have a connection between sender A and receiver B, and B closes the connection (but not A), then A can end up with missing messages in its send table.
> Example:
> * A sends messages to B
> * A has an entry for B in its send-table: {{B: 10|20}} (low=10, highest sent=20)
> * B has an entry for A in its recv-table: {{A: 10|20}} (lowest received=10, highest received=20)
> * B now gets a view that doesn't contain A and closes its connection to A
> ** This results in B's connection to A getting removed
> * A now sends message {{A::21}}
> * B doesn't find an entry in its recv-table for A and sends {{GET-FIRST-SEQNO}} to A
> * A receives the request and sends message {{A::10 first}} - {{A:21}} to B. These messages are sent unreliably, so they can get dropped. Let's assume (for this example) that all of them are dropped.
> * B creates an entry for A in its recv-table: {{A: 10|21}}
> * Now a spurious {{STABLE(A::12)}} message by B is received by A
> ** This can happen when B sent the {{STABLE}} message *before* its connection to A was removed, but the message was delayed, e.g. by garbage collection
> ** Note that the connection ID ({{conn-id}} is the same, so the sender will not reject the {{STABLE}} message
> * A receives the {{STABLE}} message and purges elements lower than 10, so its new entry for B is: {{B:: 12|21}}
> * When B asks A for retransmission of messages {{A::10}} - {{A:21}}, A can only retransmit messages 12-21, but *not* {{A::10}} and {{A:11}} !
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (JGRP-1873) UNICAST2: unilateral connection close of receiver can lead to missing seqnos in sender
by Bela Ban (JIRA)
Bela Ban created JGRP-1873:
------------------------------
Summary: UNICAST2: unilateral connection close of receiver can lead to missing seqnos in sender
Key: JGRP-1873
URL: https://issues.jboss.org/browse/JGRP-1873
Project: JGroups
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.5
In {{UNICAST2}}, if we have a connection between sender A and receiver B, and B closes the connection (but not A), then A can end up with missing messages in its send table.
Example:
* A send messages to B
* A has an entry for B in its send-table: {{B: 10|20}} (low=10, highest sent=20)
* B has an entry for A in its recv-table: {{A: 10|20}} (lowest received=10, highest received=20)
* B now gets a view that doesn't contain A and closes its connection to A
** This results in B's connection to A getting removed
* A now sends message {{A::21}}
* B doesn't find an entry in its recv-table for A and sends {{GET-FIRST-SEQNO}} to A
* A receives the request and sends message {{A::10 first}} - {{A:21}} to B. These messages are sent unreliably, so they can get dropped. Let's assume (for this example) that all of them are dropped.
* B creates an entry for A in its recv-table: {{A: 10|21}}
* Now a spurious {{STABLE(A::12)}} message by B is received by A
** This can happen when B sent the {{STABLE}} message *before* its connection to A was removed, but the message was delayed, e.g. by garbage collection
** Note that the connection ID ({{conn-id}} is the same, so the sender will not reject the {{STABLE}} message
* A receives the {{STABLE}} message and purges elements lower than 10, so its new entry for B is: {{B:: 12|21}}
* When B asks A for retransmission of messages {{A::10}} - {{A:21}}, A can only retransmit messages 12-21, but *not* {{A::10}} and {{A:11}} !
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months
[JBoss JIRA] (WFLY-3766) Enhance DST changes handling by EJB CalendarBasedTimeout
by Eduardo Martins (JIRA)
[ https://issues.jboss.org/browse/WFLY-3766?page=com.atlassian.jira.plugin.... ]
Eduardo Martins commented on WFLY-3766:
---------------------------------------
This issue should also fix the current issues shown on openjdk with updated timezone data.
> Enhance DST changes handling by EJB CalendarBasedTimeout
> --------------------------------------------------------
>
> Key: WFLY-3766
> URL: https://issues.jboss.org/browse/WFLY-3766
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: EJB
> Reporter: Eduardo Martins
> Assignee: Eduardo Martins
>
> EJB schedule expressions were designed to match UNIX Cron, but WildFly currently does not includes modern Cron handling of DST changes, i.e., on DST rollback avoid duplicate timeouts, and on DST forward avoid skipping timeouts on the skipped time period, running the related timeouts later.
> This issue should add such behaviour to WildFly EJB CalendarBasedTimeout and add tests to ensure its correctness.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 10 months