Hi , In previous commit I was forgot to test:
http://bazaar.launchpad.net/~srivastavamohit91/drizzle/drizzle-alsosql-keyvalue/revision/2575 -- Mohit On Sat, Jul 14, 2012 at 3:20 PM, Mohit Srivastava < srivastavamohi...@gmail.com> wrote: > Hi Henrik, > I am done with multi-threading and dynamic plugin part.New one for review > :) > > > http://bazaar.launchpad.net/~srivastavamohit91/drizzle/drizzle-alsosql-keyvalue/revision/2574 > > -- > Mohit > > > On Fri, Jul 13, 2012 at 2:48 PM, Henrik Ingo <henrik.i...@avoinelama.fi>wrote: > >> On Fri, Jul 13, 2012 at 4:09 AM, Stewart Smith <stew...@flamingspork.com> >> wrote: >> >> Ability to at least increase max_threads dynamically. >> > >> > Defaulting to roughly number of CPU cores could be a good default. >> >> Ok, 32 then. >> >> >> Use a higher default. Json server isn't loaded by default. So if it is >> >> loaded, we can assume it is going to be used. I would set this at 64. >> >> (It should be even higher, but then we'd need to implement something >> >> that creates more threads as needed, not just 1024 threads at >> >> startup.) >> > >> > If we can easily get number of CPU cores, let's just launch that many >> > threads. If each thread is for the large part non-blocking, then we're >> > going to be pretty sweet with this as default. >> >> I think it is better if the default is the same on all servers. >> >> In the future maybe someone implements code where we don't need to >> launch all threads at startup. In that case the number of threads >> *actually created* could be deduced by such logic. But even then, the >> default value of max_threads should be always the same. (Also, it >> should then be much higher than number of cpu's, since it is then a >> real maximum, not the actual number of threads.) >> >> >> I've been thinking you could just remove all the /0.1/* and /0.2/ and >> >> /latest/ URIs. We are not strictly leaving old versions of the >> >> functions in place (also because they had crashing bugs) so let's just >> >> simplify and just provide /version /sql and /json and nothing more. >> > >> > I'd like if we did keep the version numbers... it allows us to have some >> > form of backwards compat. >> > >> > e.g. if we remove 0.1/ because it's buggy and useless, and somebody has >> > an app, a 404 error is much better than failing weirdly. >> > >> > I did it this way to begin with very much on purpose so that others >> > could come along with much better API ideas and that any users could >> > either continue to be happy with old APIs or get a very simple error >> > message if we removed them. >> >> In theory yes. In practice both 0.1 and 0.2 versions have bugs that >> will crash the server, both in sql/ and in json/. But your proposal >> means we will now support the following urls: >> >> /0.3/* >> /latest/* >> /sql >> /json >> /version >> / >> >> (Also /0.3/sql now has a known crashing bug, unless we fix it soon, >> also that will be removed in the future...) >> >> henrik >> -- >> henrik.i...@avoinelama.fi >> +358-40-8211286 skype: henrik.ingo irc: hingo >> www.openlife.cc >> >> My LinkedIn profile: http://www.linkedin.com/profile/view?id=9522559 >> > >
_______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : drizzle-discuss@lists.launchpad.net Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
