You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Shawn Ellis (JIRA)" <ji...@apache.org> on 2018/05/13 19:57:00 UTC
[jira] [Updated] (RIVER-466) ServiceDiscoveryManager not exiting
lookup loop when serviceItems.length >= minMatches
[ https://issues.apache.org/jira/browse/RIVER-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Shawn Ellis updated RIVER-466:
------------------------------
Description:
The problem occurs when a lookup for only one service is required, but more than one is found. Currently, the lookup loop only exits if the number of services found is equivalent to the minMatches or the timeout has expired.
How to Reproduce:
1. Have multiple instances of a service registered with reggie.
2. Have a client call that performs a lookup with a constraint of only one service
{code:java}
lookup(serviceTemplate, 1, 1, null, 30 * 100){code}
3. The lookup loop will not exit until the timeout has expired even though more than minMatches were found.
The attached patch causes the lookup loop to be exited which results in less time for service lookups.
was:
The problem occurs when a lookup for only one service is required, but more than one is found. Currently, the lookup loop only exits if the number of services found is equivalent to the minMatches or the timeout has expired.
How to Reproduce:
1. Have multiple instances of a service registered with reggie.
2. Have a client call that performs a lookup with a constraint of only one service
{code:java}
lookup(serviceTemplate, 1, 1, null, 30 * 100){code}
3. The lookup loop will not exit until the timeout has expired even though more than minMatches were found.
The attached patch causes the lookup loop to be exited which results in less time to service lookups.
> ServiceDiscoveryManager not exiting lookup loop when serviceItems.length >= minMatches
> --------------------------------------------------------------------------------------
>
> Key: RIVER-466
> URL: https://issues.apache.org/jira/browse/RIVER-466
> Project: River
> Issue Type: Bug
> Components: net_jini_lookup
> Affects Versions: River_3.0.0
> Reporter: Shawn Ellis
> Priority: Minor
> Attachments: MinMatches.patch
>
>
> The problem occurs when a lookup for only one service is required, but more than one is found. Currently, the lookup loop only exits if the number of services found is equivalent to the minMatches or the timeout has expired.
> How to Reproduce:
> 1. Have multiple instances of a service registered with reggie.
> 2. Have a client call that performs a lookup with a constraint of only one service
>
> {code:java}
> lookup(serviceTemplate, 1, 1, null, 30 * 100){code}
> 3. The lookup loop will not exit until the timeout has expired even though more than minMatches were found.
> The attached patch causes the lookup loop to be exited which results in less time for service lookups.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
Re: [jira] [Updated] (RIVER-466) ServiceDiscoveryManager not exiting
lookup loop when serviceItems.length >= minMatches
Posted by Peter Firmstone <pe...@zeus.net.au>.
Thanks Shawn,
A deceptively simple fix, must have taken time and investigation to work
out why it was getting unecessarily delayed, interesting given that it
has gone on for so long too.
Cheers,
Peter.
On 14/05/2018 5:57 AM, Shawn Ellis (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/RIVER-466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Shawn Ellis updated RIVER-466:
> ------------------------------
> Description:
> The problem occurs when a lookup for only one service is required, but more than one is found. Currently, the lookup loop only exits if the number of services found is equivalent to the minMatches or the timeout has expired.
>
> How to Reproduce:
> 1. Have multiple instances of a service registered with reggie.
> 2. Have a client call that performs a lookup with a constraint of only one service
>
> {code:java}
> lookup(serviceTemplate, 1, 1, null, 30 * 100){code}
> 3. The lookup loop will not exit until the timeout has expired even though more than minMatches were found.
>
> The attached patch causes the lookup loop to be exited which results in less time for service lookups.
>
> was:
> The problem occurs when a lookup for only one service is required, but more than one is found. Currently, the lookup loop only exits if the number of services found is equivalent to the minMatches or the timeout has expired.
>
> How to Reproduce:
> 1. Have multiple instances of a service registered with reggie.
> 2. Have a client call that performs a lookup with a constraint of only one service
>
> {code:java}
> lookup(serviceTemplate, 1, 1, null, 30 * 100){code}
> 3. The lookup loop will not exit until the timeout has expired even though more than minMatches were found.
>
> The attached patch causes the lookup loop to be exited which results in less time to service lookups.
>
>
>> ServiceDiscoveryManager not exiting lookup loop when serviceItems.length>= minMatches
>> --------------------------------------------------------------------------------------
>>
>> Key: RIVER-466
>> URL: https://issues.apache.org/jira/browse/RIVER-466
>> Project: River
>> Issue Type: Bug
>> Components: net_jini_lookup
>> Affects Versions: River_3.0.0
>> Reporter: Shawn Ellis
>> Priority: Minor
>> Attachments: MinMatches.patch
>>
>>
>> The problem occurs when a lookup for only one service is required, but more than one is found. Currently, the lookup loop only exits if the number of services found is equivalent to the minMatches or the timeout has expired.
>> How to Reproduce:
>> 1. Have multiple instances of a service registered with reggie.
>> 2. Have a client call that performs a lookup with a constraint of only one service
>>
>> {code:java}
>> lookup(serviceTemplate, 1, 1, null, 30 * 100){code}
>> 3. The lookup loop will not exit until the timeout has expired even though more than minMatches were found.
>> The attached patch causes the lookup loop to be exited which results in less time for service lookups.
>
>
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)