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.

java.sql.SQLException: Unable to connect (localhost:50000): Connection to server lost!
Connection terminated
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/unsupported

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