[erlang-questions] [HEADS UP] Emysql driver

[Garrett Smith]

On Fri, Jul 5, 2013 at 10:43 AM, Jesper Louis Andersen
<jesper.louis.andersen@REDACTED> wrote:
> On Fri, Jul 5, 2013 at 4:27 PM, Garrett Smith <g@REDACTED> wrote:
>>
>>
>> At first glance, it looks like I'd be losing the connect timeout
>> enhancements from here:
>>
>> https://github.com/gar1t/Emysql
>>
>
> Yes, we are currently missing those changes in the code base. I only took
> branches which were updated fairly recently on github, and yours were
> overlooked for some reason.
>
> I like most of the changes you have in there and most of them definitely
> should be part of the full release. I also agree that your functional change
> to the gen_tcp:recv timeout is something we want to fix. The only slight
> worry is that it may be a too big behavioral change for some people. The
> other changes are changes I want as well, so i'll probably pull them unless
> you want to prepare a PR yourself.

I'll have to look again, but the intent was that default behavior is unchanged.

> I guess the initial reason for having the TCP timeout was to catch slow
> queries and get rid of them quickly, rather than waiting around. This makes
> a lot of sense in an environment where you have a large amount of small
> queries and are not allowed to wait around. But for larger queries and
> procedure calls, this is definitely not what one wants.

A default timeout other than infinity strikes me as a very bad idea.
There are many reasons, but to your point in particular, a client
close during a transaction will trigger a rollback, which can have
profoundly negative effects on the system performance -- in many cases
much worse then just waiting for the query to finish.

Not that this should influence the library feature set, but I tend to
deal with problematic long-running queries as an out-of-band problem.
E.g. a separate monitor that looks for problem connections and kills
them (could be a sys admin in the simplest case).

> The whole decoder loop looks weird as well. It should be possible to make it
> smarter than what is it currently, but this is a future change.
>
> Just drop me a note if you want to push it yourself or I should get to work.
> But it won't be this weekend, so I'll only be able to look at this Monday at
> the earliest, perhaps late Sunday.

I can tackle this -- but it likely won't be within days :)