qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Ritchie (JIRA)" <qpid-...@incubator.apache.org>
Subject [jira] Commented: (QPID-895) FailoverSingleServer delays on first connection.
Date Fri, 02 May 2008 12:12:55 GMT

    [ https://issues.apache.org/jira/browse/QPID-895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12593762#action_12593762
] 

Martin Ritchie commented on QPID-895:
-------------------------------------

Sorry Senaka, I didn't see your response here. My JIRA mail is currently poorly filtered as
we have historically been very bad at communicating via JIRA.
Good to see someone actually commenting on JIRAs.

Your patch is ideal.. and I'll commit it just as soon as svn allows me to.

1.
Both the FailoverMethods (RoundRobin and Single) are quite weak:
They have side effects on calling failoverAllowed(). 
They are dependant on calling attainedConnection()

The RoundRobin requires that getNextBrokerDetails() to be called before getCurrentBrokerDetails()
will return a value.

2. If you look at FailoverRoundRobinServer you will see how it should be.. the FSS clearly
was incomplete when it was checked in. Sorry about that, I shall correct it.

I'm sure there has to be a better way of doing this work.

Retry logic should probably be separate from Failover.
Especially as I don't think you can set retries to 0. It will always retry once, see QPID-208


> FailoverSingleServer delays on first connection.
> ------------------------------------------------
>
>                 Key: QPID-895
>                 URL: https://issues.apache.org/jira/browse/QPID-895
>             Project: Qpid
>          Issue Type: Bug
>          Components: Java Client
>    Affects Versions: M2.1, M3
>            Reporter: Martin Ritchie
>            Assignee: Martin Ritchie
>            Priority: Minor
>         Attachments: FailoverSingleServer.patch.txt
>
>
> Summary:
> _currentRetries is -1 on first connection but at the delay point in getNextBroker it
has already been incremented.
> I'm sure the code was supposed to incorrectly say '-1' rather than '1' but both of those
are wrong. We want to delay on all subsequent connection attempts which means '> 0'. 
> -        if (delayStr != null && _currentRetries != 1)
> +       if (delayStr != null && _currentRetries > 0)
> So this should fix the issue. A work around is to use two brokers in the URL with their
own connectdelay that way it will use the RoundRobin Method which doesn't have this bug.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message