Hi, We have been also analysing MonetDB and quite impressed with its performance. We were very much excited to build our application on it and considered testing it with our app. App communicates with mserver through JDBC. While we ran some basic automation scripts on our app with MonetDB as its backend, we were surprised to meet a few downtimes of the MonetDB database and at time the mserver even.. The automation was ran on an 8GB RAM machine which served 11 threads at a time. We received error messages indicated the mserver down as follows during the automation. 1. java.sql.SQLException: Unable to connect (localhost:50000): Connection to server lost! 2. Connection terminated 3. java.sql.SQLException: no supported password hashes (would like to know what this exception means..) What is the maximum requests limit for mserver? Is it configurable? What are all the other factors that I have to look for to avoid this? Earlier, while I was load testing the database with a few tables with a few million rows (on a CentOS machine with 128GB RAM), I had received the following exception at times while connecting the mclient. There were no well set patterns on which this was reproduced. $ ./bin/mclient -d dbname unsupported hash algorithms: gorithms: nect and the client doesn't open up. In order to get things back, I will have to restart the mserver. And during this process, a single monetdbd stop command doesn't kill the server. Instead, it takes 2 or 3 minutes to kill the mserver. What is this error and how shall it be avoided? Is there any best practices or FAQs to consider around while using MonetDB in production? Being totally impressed with the DB's performance, we wish to move our application on MonetDB. But we consider this as a serious show stopping concern. A little bit stability with the pinnacle of performance would definitely take MonetDB to greater heights. Any tips or help on my exceptions would be much appreaciated. Thanks in advance. Thanks & Regards, Vijayakrishna.P. Mobile : (+91) 9500402305. On Mon, Jun 22, 2015 at 4:01 PM, Frédéric Jolliton < frederic.jolliton+monetdb@securactive.net> wrote:
Thanks for all your answers. I'm grouping the response here.
Regarding SAVEPOINT, I think that if they are not supported at all, they should be disabled!
Maybe add a flag to give access to all the unstable/uncomplete features, but disable them by default. That could be either a global setting or a per-connection setting. This way, no risk to use a feature that may look like it is supported.
You said that it was documented that the feature was not supported, but from what I understand there are two SQL:2003 features involved:
- T271 (Savepoints) - T272 (Enhanced savepoint management)
But in this page:
https://www.monetdb.org/Documentation/Manuals/SQLreference/Features/unsuppor...
only T272 is listed as not supported.
Should this imply that T271 is supported? Isn't that what we were using in our bug report?
Regarding our internals patches, we discussed that a bit when we meet some of you in Paris. We plan to release our patches if they can be useful to the community. We're a shop that make heavy use of Open Source, and in turn, we're releasing various components to the community (including our core business engine.)
Overall, we're pretty happy with reactivity when we fill a bug: it is fixed in few days! And that's awesome. Part on our interest for MonetDB come from that. The projet is well alive and actively maintained.
Nonetheless, the nature of the bugs, which seems to touch "basic" stuff each time (query that are not uncommon) make us doubt about the targeted audience of MonetDB.
Sure, many of you are using MonetDB in production. My article title was a bit harsh. But since we're building an application around it, and that we want a certain assurance regarding the result, we grow some concerns. Especially because we're building the query on the fly from a abstract, dynamic, definition, thus we can't anticipate all the sort of combination we will get (UNION, GROUP BY, aggregates, lot of subselect, ..) and thus might trigger a silent bug returning incorrect data for example.
But don't get me wrong: we love the MonetDB for its design, its speed and its ability to be extended.
Regards,
-- Frédéric Jolliton Sécuractive _______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list