You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by "Day, Jem" <jd...@paypal.com.INVALID> on 2016/08/10 22:19:35 UTC
DISPATCH: Behavior on delivery failures
Hi,
We’re running a dispatch-router cluster with mobile endpoints attached, the same endpoint address may be registered on multiple DR [Dispatch Router] nodes. We seem to be seeing situations where a message enters a particular DR but never gets delivered, this appears to occur when the associated ‘link’ goes down for some reason.
Q: If a message travels across a network of DR nodes and when it reaches the DR of ‘egress’ the link of interest has died will the DR…
- Attempt re-delivery by re-routing the message within the DR network
- Reject the message back to the producer with a disposition of ‘rejected’
- Reject the message back to the producer with a disposition of ‘modified’
- Other
My end goal is to understand the which dispositions might indicate a scenario whereby a re-send might be appropriate.
Thanks in advance.
—
Jem
Principal Architect, Core Payments
Re: Using symlinks in the qpid dispatch router console
Posted by Ernest Allen <ea...@redhat.com>.
Thanks Chuck. I went ahead and checked in the symlinks.
----- Original Message -----
From: "Chuck Rolke" <cr...@redhat.com>
To: users@qpid.apache.org
Sent: Thursday, August 18, 2016 1:34:48 PM
Subject: Re: Using symlinks in the qpid dispatch router console
I think your option 4 would be fine.
Git will create a symlink. If you delete/rename the actual
file in stand-alone/ then you have to manually recreate
the symlink. Git does not care if the actual file exists
or not. The data referenced by the symlink is not stored
in the repository.
----- Original Message -----
> From: "Ernest Allen" <ea...@redhat.com>
> To: users@qpid.apache.org
> Sent: Wednesday, August 17, 2016 1:11:32 PM
> Subject: Using symlinks in the qpid dispatch router console
>
> Summary: Are there any problems associated with checking in symlinks?
>
> Here is the situation:
>
> qpid-dispatch/
> console/
> stand-alone/
> hawtio/
>
> Basically the stand-alone and hawtio versions of the qpid dispatch router use
> several of the same (html, js, css) files.
>
> I see some possibile scenarios:
> 1) Store duplicate versions of the files in the stand-alone/ and hawtio/
> directories.
> Not ideal from a development/maintenance perspective.
>
> 2) Store the common files in a qpid-dispatch/console/common/ directory and
> use releative references in the stand-alone and hawtio code.
> This prevents a user from copying the stand-alone/ directory into a web
> server since they would also need the common/ dir. Also, this complicates
> the hawtio pom.xml file greatly since some of the source would be under
> hawtio/ and some would be under ../common/.
>
> 3) Store the actual files in the stand-alone/ directory and use relative
> references in the hawtio build.
> This still has the problem of complicating the hawtio build greatly.
>
> 4) Store the actual files in the stand-alone/ directory and use symlinks in
> the hawtio directory.
> This solves both problems. Hawtio builds just fine with symlinks and the
> stand-alone/ directory can be copied because it actually contains the files.
>
> So, is using symlinks in this manner acceptable?
>
> Thanks,
> -Ernie
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Using symlinks in the qpid dispatch router console
Posted by Chuck Rolke <cr...@redhat.com>.
I think your option 4 would be fine.
Git will create a symlink. If you delete/rename the actual
file in stand-alone/ then you have to manually recreate
the symlink. Git does not care if the actual file exists
or not. The data referenced by the symlink is not stored
in the repository.
----- Original Message -----
> From: "Ernest Allen" <ea...@redhat.com>
> To: users@qpid.apache.org
> Sent: Wednesday, August 17, 2016 1:11:32 PM
> Subject: Using symlinks in the qpid dispatch router console
>
> Summary: Are there any problems associated with checking in symlinks?
>
> Here is the situation:
>
> qpid-dispatch/
> console/
> stand-alone/
> hawtio/
>
> Basically the stand-alone and hawtio versions of the qpid dispatch router use
> several of the same (html, js, css) files.
>
> I see some possibile scenarios:
> 1) Store duplicate versions of the files in the stand-alone/ and hawtio/
> directories.
> Not ideal from a development/maintenance perspective.
>
> 2) Store the common files in a qpid-dispatch/console/common/ directory and
> use releative references in the stand-alone and hawtio code.
> This prevents a user from copying the stand-alone/ directory into a web
> server since they would also need the common/ dir. Also, this complicates
> the hawtio pom.xml file greatly since some of the source would be under
> hawtio/ and some would be under ../common/.
>
> 3) Store the actual files in the stand-alone/ directory and use relative
> references in the hawtio build.
> This still has the problem of complicating the hawtio build greatly.
>
> 4) Store the actual files in the stand-alone/ directory and use symlinks in
> the hawtio directory.
> This solves both problems. Hawtio builds just fine with symlinks and the
> stand-alone/ directory can be copied because it actually contains the files.
>
> So, is using symlinks in this manner acceptable?
>
> Thanks,
> -Ernie
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: Using symlinks in the qpid dispatch router console
Posted by Alan Conway <ac...@redhat.com>.
On Wed, 2016-08-17 at 13:11 -0400, Ernest Allen wrote:
> Summary: Are there any problems associated with checking in symlinks?
>
> Here is the situation:
>
> qpid-dispatch/
> ����console/
> ��������stand-alone/
> ��������hawtio/
>
> Basically the stand-alone and hawtio versions of the qpid dispatch
> router use several of the same (html, js, css) files.
>
> I see some possibile scenarios:
> 1) Store duplicate versions of the files in the stand-alone/ and
> hawtio/ directories.
> Not ideal from a development/maintenance perspective.
>
> 2) Store the common files in a qpid-dispatch/console/common/
> directory and use releative references in the stand-alone and hawtio
> code.
> This prevents a user from copying the stand-alone/ directory into a
> web server since they would also need the common/ dir. Also, this
> complicates the hawtio pom.xml file greatly since some of the source
> would be under hawtio/ and some would be under ../common/.
>
> 3) Store the actual files in the stand-alone/ directory and use
> relative references in the hawtio build.�
> This still has the problem of complicating the hawtio build greatly.
>
> 4) Store the actual files in the stand-alone/ directory and use
> symlinks in the hawtio directory.
> This solves both problems. Hawtio builds just fine with symlinks and
> the stand-alone/ directory can be copied because it actually contains
> the files.
>
> So, is using symlinks in this manner acceptable?
I would say this is OK. I caused trouble before by putting directory
symlinks in the root of the repo, but local links like you are propsing
that are only seen by console code shouldn't cause trouble (famous last
words)�
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Using symlinks in the qpid dispatch router console
Posted by Ernest Allen <ea...@redhat.com>.
Summary: Are there any problems associated with checking in symlinks?
Here is the situation:
qpid-dispatch/
console/
stand-alone/
hawtio/
Basically the stand-alone and hawtio versions of the qpid dispatch router use several of the same (html, js, css) files.
I see some possibile scenarios:
1) Store duplicate versions of the files in the stand-alone/ and hawtio/ directories.
Not ideal from a development/maintenance perspective.
2) Store the common files in a qpid-dispatch/console/common/ directory and use releative references in the stand-alone and hawtio code.
This prevents a user from copying the stand-alone/ directory into a web server since they would also need the common/ dir. Also, this complicates the hawtio pom.xml file greatly since some of the source would be under hawtio/ and some would be under ../common/.
3) Store the actual files in the stand-alone/ directory and use relative references in the hawtio build.
This still has the problem of complicating the hawtio build greatly.
4) Store the actual files in the stand-alone/ directory and use symlinks in the hawtio directory.
This solves both problems. Hawtio builds just fine with symlinks and the stand-alone/ directory can be copied because it actually contains the files.
So, is using symlinks in this manner acceptable?
Thanks,
-Ernie
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: DISPATCH: Behavior on delivery failures
Posted by Ted Ross <tr...@redhat.com>.
On 08/11/2016 05:45 AM, Gordon Sim wrote:
> On 10/08/16 23:19, Day, Jem wrote:
>> We\u2019re running a dispatch-router cluster with mobile endpoints
>> attached, the same endpoint address may be registered on multiple DR
>> [Dispatch Router] nodes. We seem to be seeing situations where a
>> message enters a particular DR but never gets delivered, this appears
>> to occur when the associated \u2018link\u2019 goes down for some reason.
>>
>> Q: If a message travels across a network of DR nodes and when it
>> reaches the DR of \u2018egress\u2019 the link of interest has died will the DR\u2026
>>
>> - Attempt re-delivery by re-routing the message within the DR network
>> - Reject the message back to the producer with a disposition of
>> \u2018rejected\u2019
>> - Reject the message back to the producer with a disposition of
>> \u2018modified\u2019
>
> Messages that can't be delivered are released with a modified outcome.
To expand on this, look at the description of
https://issues.apache.org/jira/browse/DISPATCH-366.
If a delivery can't be routed (no destination), it is returned to the
sender with RELEASED disposition. If the delivery _may_ have been
delivered but has not been settled when an outgoing link is dropped, it
is returned to the sender with MODIFIED/delivery-failed disposition.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org
Re: DISPATCH: Behavior on delivery failures
Posted by Gordon Sim <gs...@redhat.com>.
On 10/08/16 23:19, Day, Jem wrote:
> We\u2019re running a dispatch-router cluster with mobile endpoints attached, the same endpoint address may be registered on multiple DR [Dispatch Router] nodes. We seem to be seeing situations where a message enters a particular DR but never gets delivered, this appears to occur when the associated \u2018link\u2019 goes down for some reason.
>
> Q: If a message travels across a network of DR nodes and when it reaches the DR of \u2018egress\u2019 the link of interest has died will the DR\u2026
>
> - Attempt re-delivery by re-routing the message within the DR network
> - Reject the message back to the producer with a disposition of \u2018rejected\u2019
> - Reject the message back to the producer with a disposition of \u2018modified\u2019
Messages that can't be delivered are released with a modified outcome.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org