-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stack overflow caused by retries #16
Comments
As a quick fix, I removed the support for reading the retries from the partnership. I think your version looks like a plan :) |
phax
added a commit
that referenced
this issue
Dec 1, 2015
There is a now a |
Fixed in release 2.2.5 |
Works fine, thank you for the quick fix. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I have this setup
Furthermore (in a specific test) the partnership config specifies 3 retries; and I am sending to an URL where there is no(!) server listening (I was trying to verify that retries are working by delaying listener startup).
While working on that the test fails like this:
The lowest line is from the actual call to "send"; the chain of bouncing from resender -> message-processor -> sender -> ... gets longer.
This seems to be caused by
AbstractSenderModule::getRetryCount
. The value passed viaaOptions
is ignored if checkingaPartnership
yields a result; I assume aOptions shouldhave priority, otherwise decrementing the counter in the resender module has no effect?
This seems to work for me:
The text was updated successfully, but these errors were encountered: