You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by "Kevan Miller (JIRA)" <de...@geronimo.apache.org> on 2006/03/08 21:03:55 UTC
[jira] Created: (GERONIMO-1719) GBuild agent JMS reconnect logic is
incorrect
GBuild agent JMS reconnect logic is incorrect
---------------------------------------------
Key: GERONIMO-1719
URL: http://issues.apache.org/jira/browse/GERONIMO-1719
Project: Geronimo
Type: Bug
Components: gbuild
Versions: 1.0
Reporter: Kevan Miller
Assigned to: Kevan Miller
Priority: Minor
The gbuild agent reconnect logic has several problems.
User configuration settings for reconnect processing are ignored. Max retries and delay time are all hard-coded.
If the initial connection fails, it seems that the client will never connect.
Also, we should be able to configure agents to attempt to reconnect forever. There should be some retry backoff scheme or bimodal reconnect interval...
I seem to recall that ActiveMQ has similar features in their client api. It might be simpler to remove what GBuild currently does and use the built-in ActiveMQ support...
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Re: [jira] Created: (GERONIMO-1719) GBuild agent JMS reconnect logic is incorrect
Posted by Kevan Miller <ke...@gmail.com>.
On 3/9/06, Jacek Laskowski <el...@gmail.com> wrote:
>
> 2006/3/8, Kevan Miller (JIRA) <de...@geronimo.apache.org>:
> > GBuild agent JMS reconnect logic is incorrect
> > ---------------------------------------------
> >
> > Key: GERONIMO-1719
> > URL: http://issues.apache.org/jira/browse/GERONIMO-1719
>
> I thought GBuild has its own JIRA space. Shouldn't it go there?
Thanks Jacek, you're right... I've moved the jira's...
--kevan
Re: [jira] Created: (GERONIMO-1719) GBuild agent JMS reconnect logic is incorrect
Posted by Jacek Laskowski <el...@gmail.com>.
2006/3/8, Kevan Miller (JIRA) <de...@geronimo.apache.org>:
> GBuild agent JMS reconnect logic is incorrect
> ---------------------------------------------
>
> Key: GERONIMO-1719
> URL: http://issues.apache.org/jira/browse/GERONIMO-1719
I thought GBuild has its own JIRA space. Shouldn't it go there?
Jacek
--
Jacek Laskowski
http://www.laskowski.org.pl
[jira] Commented: (GBUILD-16) Improve GBuild agent JMS reconnect
logic
Posted by "Kevan Miller (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GBUILD-16?page=comments#action_12369714 ]
Kevan Miller commented on GBUILD-16:
------------------------------------
Here's some info on what ActiveMQ provides -- http://activemq.codehaus.org/Failover+Transport+Reference
It seems to provide for the configuration of a retry backoff strategy. Assuming it all works, it should provide the desired function -- fast recovery for short-term problems and long-term recovery for long outages. I don't view the backoff capabilities as super critical, anyway. We could set a fixed retry rate of 30 seconds with few negative consequences...
Apologies if I was overly harsh in my summary of the problems...
> Improve GBuild agent JMS reconnect logic
> ----------------------------------------
>
> Key: GBUILD-16
> URL: http://issues.apache.org/jira/browse/GBUILD-16
> Project: GBuild
> Type: Bug
> Components: agent
> Versions: 1.0.0
> Reporter: Kevan Miller
> Assignee: Kevan Miller
> Priority: Minor
>
> The gbuild agent reconnect logic has several problems.
> User configuration settings for reconnect processing are ignored. Max retries and delay time are all hard-coded.
> If the initial connection fails, it seems that the client will never connect.
> Also, we should be able to configure agents to attempt to reconnect forever. There should be some retry backoff scheme or bimodal reconnect interval...
> I seem to recall that ActiveMQ has similar features in their client api. It might be simpler to remove what GBuild currently does and use the built-in ActiveMQ support...
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Closed: (GBUILD-16) Improve GBuild agent JMS reconnect logic
Posted by "David Blevins (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GBUILD-16?page=all ]
David Blevins closed GBUILD-16:
-------------------------------
Resolution: Fixed
Assign To: David Blevins (was: Kevan Miller)
The strategy is now:
1. Use ActiveMQ failover with exponential delay maxed at 30min
2. Retry every two hours there after up to four days
The activemq maxDelay will be added to our reconnect times, so actually we have 5 days of tolerance.
> Improve GBuild agent JMS reconnect logic
> ----------------------------------------
>
> Key: GBUILD-16
> URL: http://issues.apache.org/jira/browse/GBUILD-16
> Project: GBuild
> Type: Bug
> Components: agent
> Versions: 1.0.0
> Reporter: Kevan Miller
> Assignee: David Blevins
> Priority: Minor
>
> The gbuild agent reconnect logic has several problems.
> User configuration settings for reconnect processing are ignored. Max retries and delay time are all hard-coded.
> If the initial connection fails, it seems that the client will never connect.
> Also, we should be able to configure agents to attempt to reconnect forever. There should be some retry backoff scheme or bimodal reconnect interval...
> I seem to recall that ActiveMQ has similar features in their client api. It might be simpler to remove what GBuild currently does and use the built-in ActiveMQ support...
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (GBUILD-16) Improve GBuild agent JMS reconnect
logic
Posted by "David Blevins (JIRA)" <de...@geronimo.apache.org>.
[ http://issues.apache.org/jira/browse/GBUILD-16?page=all ]
David Blevins updated GBUILD-16:
--------------------------------
Summary: Improve GBuild agent JMS reconnect logic (was: GBuild agent JMS reconnect logic is incorrect)
The activemq feature could potentially be our aggressive reconnect strategy and the current code (sans the two hard-coded values) could maybe be used for the more passive mode. Maybe change the delay setting to minutes.
I can verify that the reconnect logic and synchronization around it all work.
> Improve GBuild agent JMS reconnect logic
> ----------------------------------------
>
> Key: GBUILD-16
> URL: http://issues.apache.org/jira/browse/GBUILD-16
> Project: GBuild
> Type: Bug
> Components: agent
> Versions: 1.0.0
> Reporter: Kevan Miller
> Assignee: Kevan Miller
> Priority: Minor
>
> The gbuild agent reconnect logic has several problems.
> User configuration settings for reconnect processing are ignored. Max retries and delay time are all hard-coded.
> If the initial connection fails, it seems that the client will never connect.
> Also, we should be able to configure agents to attempt to reconnect forever. There should be some retry backoff scheme or bimodal reconnect interval...
> I seem to recall that ActiveMQ has similar features in their client api. It might be simpler to remove what GBuild currently does and use the built-in ActiveMQ support...
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira