-
Notifications
You must be signed in to change notification settings - Fork 1
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
reconnect seems to fail in this scenario #1
Comments
Looking at the error a 'PDO::query(): Error reading result set's header' error occures, which this plugin doesn't handle. Are you able to repeat this error? You could try to set this Additionally I believe you should FALSE as a result from the query at 'src/exampleDomainModel/Queue/Job/PersistentSearch/PollFeedProviders.php:34' and recover as required. |
Interesting -- I think I may be able to remove some deprecated / incompatible code. Here's what's broken/incompatible with the auto-reconnection magic (what I was using before integrating your module):
In this case, I'm not using PDO directly, but rather the DBAL stuff seems to be calling to that. |
I found one more that mimicks this -- this time, without any usage of ping() or other application-reconnection magic in place:
|
Hello, Just following up on this as I have another example here that may be useful / related. I can reproduce this issue again and it's exhibiting the same symptoms -- throwing a mysql server has gone away exception; however, the part of code,
seems to be returning false since the TransactionNestingLevel is 0. Now, I'm not sure what the exact behavior is intended to be with this part; however, it appears that this would return false, which would immediately cause the reconnect flow to be aborted. In the meantime, I've forked the repository and will be testing this out to see if this 'resolves the issue'. If so, perhaps we can work something out that's a bit more friendly to non-transactional queries that may fail. |
…econnect if a Doctrine transaction is nested. As such, I'm flipping this to use the method that does the checking (count of transactions > 0) to check if the transaction is active. If so, it seems like we would need to immediately throw a nested transaction error where the count of incremented transactional items has not been decremented back down to 0 -- This is related to issue bushbaby#1
Okay, after playing around quite a bit with this module ... I've found various issues -- only some of which are appropriately handled: #1 - I can successfully reproduce this issue on a consistent basis by dropping wait_time down to less than the duration of a loop where I perform some doctrine queries (in this case, I'm pushing up status events for jobs running in SlmQueueSQS). Those are long-running tasks and they consistently hit the
error conditions as described above. #2 - The other weird thing that then comes up is a PHP warning that I didn't see earlier:
Either way though, the module doesn't appear to safely restart the connection. Instead, the job fails and is eventually re-sent to another worker that doesn't have a dead connection. |
http://stackoverflow.com/questions/30753674/error-while-sending-query-packet |
hi, i've update master a bit. nothing in src actually changed. you should be ably to rebase without problems... By the way, you mentioned SlmQueueSQS. I've just released 0.6.... |
Cool, I'll check out the SlmQueue[SQS] updates. What we decided to do in the meantime is adjust our wait_timeout to be longer than the maximum lifetime of our workers. Then every 30 minutes or so we exit the worker loop and then supervisor restarts a new worker in the background. I think for our purposes that may be enough to keep things running smoothly. But I'll poke around with this a bit more -- it was just weird that things wouldn't resume after a connection was closed (it seems almost like the query wasn't replaying or something like that). |
Well I seems to me you found an pretty big bug that essentially rendered the whole thing useless. :) I must admit I don't follow the complete implementation at the moment, but this is wrongish If not is transaction then don't attempt to reconnect I'll try to setup a test locally and test a bit... You would not be any chance know how to actually test such behavior do you? How can we test a gone away server???
|
So how I ended up testing the issues at hand were to drop the wait_timeout directive in MySQL to something reasonably low (eg., 30 seconds, rather than say something incredibly long like 30 minutes -- as I currently have my API MySQL server configured) ... This then chokes out an idle connection after 30 seconds. You could make it much shorter just as well to speed things along. Start a persist/flush operation ... sleep that sucker for say 35 seconds ... then attempt to modify an entity and do another persist / flush operation. |
This i did not know. I'll try that. 'kill -9 xxx', is what I use to test. Have you seen the latest master? I've added the fix we discussed (removed that !) and added a few delays of a sec (or I would get a path not found exception, bc the socket wasn't recreated yet) That made sure my connection was correctly restarted...
|
The text was updated successfully, but these errors were encountered: