On 17 Mar 2009, at 14:07, Jeremy Zawodny wrote:
On Tue, Mar 17, 2009 at 5:29 AM, Mark Leith <[email protected]> wrote:
On 16 Mar 2009, at 21:08, Jeremy Zawodny wrote:
On Mon, Mar 16, 2009 at 1:37 PM, MARK CALLAGHAN
<[email protected]> wrote:
On Mon, Mar 16, 2009 at 1:24 PM, John David Duncan <[email protected]>
wrote:
>
>
> Also, there are timeout-based problems, and if all 6 (or 8, or
whatever)
> running threads stall, then the whole server is hung. Folks who
work at Sun
> can look at MySQL support issue #25334 and see some problems that
might also
> pop up in conceivable libevent-based implementations...
JD,
Am I correct in summarizing this by stating that MySQL has a fast
version of this in code I can't review and problems with it are
described in a problem report I cannot read?
Yay for open source, eh?
So we are not allowed paying customers, with custom NRE work, if we
are open source? :)
Not at all. But in a world when there's a community actively
working on similar enhancements, having the code available for
study seems more useful than hiding it--unless these customers fear
that it'll somehow damage their businesses.
I don't really think that's the case here..
The current 5.0 custom branch was/is based on Solaris event ports
only (http://developers.sun.com/solaris/articles/
event_completion.html), so wasn't really applicable for the main
stream server (because it only supported one platform). That's why
we looked at doing it with libevent in 6.0 - so the NRE work helped
to drive the new feature in the later release which is more
applicable to everybody..
It would be far from the first open source code that didn't support
a lot of platforms when it first became public, now would it?
Sure, does that mean that it's OK for MySQL to do it though? I
personally am against releasing for Solaris only (even though we are
Sun), it could give another bad message to the community.
Yes, it has some issues. Yes, Support (and others) are pushing for
fixes to much of that as well - 6.0 is still Alpha, so hopefully we
should see some good headway before GA.
Yay for closed source NRE work pushing Open Source development too! ;)
Does that mean we *are* likely to see the code someday?
I'm now a little confused? Is it that the code isn't worth sharing
because it only runs on one platform and will likely be replaced,
or is it that you're worried about having to support it and want to
get some bugs worked out first?
The former, I believe, though I haven't been in any discussions about
this actually getting released to the masses (so don't take my word
as gospel on this). And it's not "will likely be replaced", it
already has.. :) The libevent based thread pooling is already in 6.0:
http://dev.mysql.com/doc/refman/6.0/en/connection-threads.html
http://dev.mysql.com/doc/refman/6.0/en/server-system-
variables.html#sysvar_thread_handling
Whilst the old stuff is still maintained as part of a contract, we
are now moving towards this newer implementation as a standard across
all platforms, in a version where we can make changes like this. I
guess we learned from our mistakes already, and have already moved on.
In either case, it's not like Drizzle is in the hands of a
population of users asking for support already. It's very much in
active development.
Isn't one of Drizzle's core goals to use externally maintained
libraries where they are available? I think the libevent route is
much more applicable to drizzle then a self rolled one based on
Solaris event ports..
Thanks for speaking up on this, but please do clarify the intent
here. I get the sense that the non-Sun/MySQL folks may benefit
from seeing what's built.
Well, look at the 6.0 thread pooling, and give us the feedback! That
is where it matters right now. :)
Best regards
Mark
--
Mark Leith
MySQL Regional Support Manager, Americas
Sun Microsystems, Inc., http://www.sun.com/mysql/
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
