mysql-proxy-discuss team mailing list archive

[Erwan Ben Souiden <erwan@xxxxxxxxxxxx>]

Hi there,

Just a little up to say that I still have exactly the same behaviour
even if I use the following recomandations :
http://forums.mysql.com/read.php?146,265193,271355#msg-271355 .
(reminder : all is ok until the 11th connection (with default
rw-splitting.lua script parameters : min_idle_connections = 4 and
max_idle_connections = 8 ! Then for every two connections, only one
succeed)

I know that Diego has opened a bug here :
http://bugs.mysql.com/bug.php?id=46141 . May be this could be fix the
problem.
If you need something from me let me know. Now I have time to make all
the tests you would need.

Erwan


On Tue, Jun 16, 2009 at 10:03 AM, Erwan Ben Souiden<erwan@xxxxxxxxxxxx> wrote:
> Yop !
>
>
> On Fri, Jun 12, 2009 at 12:44 PM, Kay Röpke<Kay.Roepke@xxxxxxx> wrote:
>> Hey!
>>
>> On Jun 11, 2009, at 2:35 PM, Erwan Ben Souiden wrote:
>>
>>> On Thu, Jun 11, 2009 at 12:04 PM, Kay Röpke<Kay.Roepke@xxxxxxx> wrote:
>>>
>>> First, thank you to answer me (and how fast !! :) )
>>
>> Sometimes, not always fast :)
>>
>>>>> My configuration :
>>>>> mysql-proxy v 0.7.1 (from
>>>>>
>>>>>
>>>>> http://code.launchpad.net/mysql-proxy/0.7/0.7.1/+download/mysql-proxy-0.7.1.tar.gz)
>>>>> compiled with no particular option
>>>>> rw-splitting.lua script has been patched thanks to the following patch
>>>>> :
>>>>>
>>>>> https://code.launchpad.net/~diego-fmpwizard/mysql-proxy/bug-43424/+merge/4259
>>>>
>>>> Ok, makes sense.
>>>> Have you tried this with a binary from
>>>> http://dev.mysql.com/downloads/mysql-proxy? Shouldn't make a difference,
>>>> but
>>>> it's worth a try.
>>>>
>>>
>>> Nop I didn't try with this binary. I will do some tests with it (just
>>> to be sure)
>>> I have a question about the patch from Diego : why is still in "Needs
>>> review" status ? I understand the different changes but I'm not enough
>>> confident with the rw-splitting.lua script to understand some
>>> commented lines (lines 63 and 79 of the patch)... If you have any clue
>>> about it, I'm really interested ! :)
>>
>> Well, it's in review because … it needs someone to look at :)
>> Since I haven't actually looked at the patch yet (too. much. work.) I can't
>> really comment on why the lines
>> were commented out, sorry.
>> In one version or another the patch will go into version 0.8, though.
>>
>
> No prob Kay.
> May be Diego could help me :) I will ask him !
>
>>>> However, what I think is going on might be related to this bug report:
>>>> http://bugs.mysql.com/bug.php?id=28359
>>>> The gist is that this error can be caused by exceeding the
>>>> connect_timeout
>>>> (the default is rather small) which causes the server to just close the
>>>> connection leading to error 2013 on the client.
>>>
>>> Actually I have no problem when I didn't use the proxy :( .
>>
>> That's good or bad, depending on how you look at it.
>> OTOH it might just mean that proxy changes the timing of things, and that
>> it's not
>> necessarily proxy's fault. But since we don't have any more data, we can't
>> tell.
>> Nevertheless, try to increase the connect_timeout even further (just for
>> testing, of course,
>> if this is a production machine!) to see if the errors with proxy go
>> away/get less.
>>
>
> Ok I understand what you mean ! I try this as soon as possible and
> come back to you with some new results.
> Hopefully I try mysql-proxy in a test environment  ;) So I can test
> what you want (I just need time cause it's not a prior project)
>
>
>>>> What is it set to in your mysqlds? Which versions are you running? (mmmh
>>>> I
>>>> think we should log the server versions we connect to, I'll file a
>>>> feature
>>>> request.)
>>>>
>>>
>>> Oops ! I forgot to mention that ! I use a mysqld 5.0.77
>>
>> Ok, so fairly recent. I asked because sometimes older mysqld versions have
>> known bugs in
>> protocol handling, so I wanted to eliminate that possiblity.
>>
>
> I'm up-to-date :D !
>
>>>> Are your backend servers rather busy? If so that might lead to what's
>>>> described in the bug report mentioned above. If not, it might be a
>>>> problem
>>>> with how we assemble the handshake packet, or a more general problem with
>>>> the connection pool, but all of that is pure speculation at this point.
>>>>
>>>> How often does this occur? If it's quite frequent, could you get a trace
>>>> for
>>>> that connection using wireshark so we can see what the actual packets
>>>> are?
>>>> (Again, maybe it's worthwhile for us to include an option to dump the
>>>> traffic for each connection to a file - that could greatly help with
>>>> debugging!)
>>>
>>> It often occurs when I got the first error.
>>> I'm probably wrong but I think at the beginning there is no connection
>>> in the pool... so I have no problem to create new one... Then I got
>>> the first error and when I try one more time, I have no problem. But
>>> next try I get the error and next it's ok ! And so on...
>>> So with my tiny knowledge of this subject I presume I have a problem
>>> with the connection pool :(
>>
>> It sounds like it, yes. The packet data will show.
>>
>
> Ok I'll do it !
> I will trace what is coming out from the proxy.
> (about the trace option, it will be nice ! but I don't know how is
> complicated to do this)
>
>
>> cheers,
>> -k
>> --
>> Kay Roepke
>> Software Engineer, MySQL Enterprise Tools
>>
>> Sun Microsystems GmbH    Sonnenallee 1, DE-85551 Kirchheim-Heimstetten
>> Geschaeftsfuehrer:    Thomas Schroeder,  Wolfang Engels,  Wolf Frenkel
>> Vorsitz d. Aufs.rat.: Martin Haering                    HRB MUC 161028
>>
>>
>
> Again thank you for the answer !
>
> Erwan
>