Important: Unresolved query promise about mysql

[brstgt]

Maybe also related: Isn't there a way to detect when a connection is lost and to remove these stale connections from the pool? I think that was the case in 0.2.x. At least I did not have to retry the query multiple times in some cases but I MUST do that with 0.3.1

[brstgt]

I just recognized: It has nothing to do with the gone server. It also happens if I remove the yield new Delayed()

[bwoebi]

I believe there is some old TODO with this... Well, looks like we finally have to look into this again properly.

[brstgt]

Insight: It happens if not all column-defs are received in the first read. Wasn't able to debug further yet. Gotta go now. Thanks!

[brstgt]

I am not sure whats the intention of the read barrier in processor::read but I think that's the cause. ::handlequery resolves the deferred that is added by ::query. If the first read chunk does not contain the whole result, handlequery resolves the deferred but more data is needed. The read loop runs into the read barrier as ::$deferred is empty. But ::$waiting will never be resolved. Actually this can even cause the loop to stop as the read watcher is disabled and no writes are pending.
I also think that's the problem why stale connections aren't detected as the socket is only read when there is a pending ::$deferred. I think that's not quite correct and this was different in 0.2.x which worked well wrt to this issues

[brstgt]

Is that read barrier really required? MySQL should only send data when there was a request before anyway, right? And if we have a read without a corresponding Task this should be considered a state or protocol error?!

[trowski]

The purpose of the read barrier was to prevent an idle connection having a busy watcher in the loop, so that the object would be automatically destroyed and the loop stop. The place where the barrier was created and released was wrong however, so the connection was closed prematurely. I believe I fixed the locations, and I also just used the ref/unref API on socket instead of a promise. Please try the current master and let me know if that fixes the issue.

[brstgt]

Makes sense! Will do tomorrow, thanks a lot! Am 20.12.2017 20:50 schrieb "Aaron Piotrowski" <[email protected]>:

…

The purpose of the read barrier was to prevent an *idle* connection having a busy watcher in the loop, so that the object would be automatically destroyed and the loop stop. The place where the barrier was created and released was wrong however, so the connection was closed prematurely. I believe I fixed the locations, and I also just used the ref/unref API on socket instead of a promise. Please try the current master and let me know if that fixes the issue. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#59 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAUQZxFcLSuKApdqUyoNdnHaAhUdtDCbks5tCWOigaJpZM4RIgOL> .

[brstgt]

Seems to work, dude :) You made my day! Thanks!