[QUOTE=gd_barnes;349302]I think sourceforge sounds like a good idea. But my thought is that release numbers should not be changed until new features or fixes are extensively tested. Perhaps I am not understanding the version numbers. I feel like every version should be fully and extensively tested by large numbers of cores before it is considered a new "version". Is that a possibility? It bothers me, for instance, when I hear Lennart say: "5.2.6 is a no no.". Had 5.2.6 been extensively tested, it would not have been an "official version". In other words, what is now 5.2.7 would be 5.2.6 and there would be no "bad" version.[/QUOTE]

I obviously create some of my own problems. 5.2.6 was one of them.

The issue with testing isn't as much about the number of cores, but about executing functionality. For example, CRUS will execute functionality that isn't executed by other server types and those server types won't execute CRUS functionality.

It appears that the latest release of the MySQL ODBC Connector has addressed many of the memory leaks I've experienced on Windows.

[QUOTE=rogue;349402]It appears that the latest release of the MySQL ODBC Connector has addressed many of the memory leaks I've experienced on Windows.[/QUOTE]
Which version are you now using? I have stuck with 5.1.12 as that is what I knew worked. I assume if you move to 5.2 you would have to change the database.ini

[QUOTE=henryzz;349408]Which version are you now using? I have stuck with 5.1.12 as that is what I knew worked. I assume if you move to 5.2 you would have to change the database.ini[/QUOTE]

This is the current version of the server, according to the string I get when I run mysql from the command prompt: "Server version: 5.5.32 MySQL Community Server"

The ODBC driver I'm using is "MySQL ODBC 5.2 ANSI Driver", which Windows identifies as version 5.02.05.00. I had to modify the database.ini to specify that driver after I upgraded.

I am running a 64-bit server.

prpserver has ranged up to 50 MB, but is now under 15 MB. Before the upgrade it would get over 1 GB in a few days.

Unfortunately my tester is not available because of prior commitments and job requirements will keep him on the road in the near future.

Mark, Max and I had a discussion about all of this via Email. I've decided that if you can get just issue #4 fixed, we will upgrade. Perhaps you can coordinate with Henry and/or Lennart on testing the issue. It is the only issue that could impact the large tests here at CRUS.

Thanks!

[QUOTE=gd_barnes;349446]Unfortunately my tester is not available because of prior commitments and job requirements will keep him on the road in the near future.

Mark, Max and I had a discussion about all of this via Email. I've decided that if you can get just issue #4 fixed, we will upgrade. Perhaps you can coordinate with Henry and/or Lennart on testing the issue. It is the only issue that could impact the large tests here at CRUS.[/QUOTE]

I appreciate your efforts to move forward. I really do.

As for issue #4, I'll gladly investigate, but I'm waiting for someone to produce a log with the issue. There just isn't enough information for me to go on. henrys, if you can find this problem in your logs, zip them up and e-mail them to me.

I started making the changes today for the server to handle larger databases. This involves changing the primary key on a number of tables. There will be no change in the communication protocol with clients to support the change, but once it's implemented the server cannot be downgraded. I could try to make it possible to downgrade but that would require much more extensive coding and would thus require much more extensive testing. I can't promise that it will improve overall throughput of the server though. That might require tuning of MySQL, i.e. on the database itself, but I'm no expert in MySQL. I'm much better with Oracle. It would be interesting to know if PostgreSQL is any better.

I have been unable to reproduce this so far. I have even tried the same file.
I just looked more closely at the logs for 5.0.8 and it looks like I had a different problem to #4 anyway.
It looks like for some reason the test was sent out a second time to another client. When it was returned the second(and many more times) time the server encountered a sql error because it already had the prime and rejected the test. It would get added to the PRP.log and completedtests.log as if nothing had happened. Because the test was rejected the client would submit it again in 1 minutes time. This is why it ended up in the log multiple times.

I am uploading those logs and will edit in the link shortly.
[url]http://www.sendspace.com/file/kgw6se[/url]

[QUOTE=henryzz;349470]I have been unable to reproduce this so far. I have even tried the same file.
I just looked more closely at the logs for 5.0.8 and it looks like I had a different problem to #4 anyway.
It looks like for some reason the test was sent out a second time to another client. When it was returned the second(and many more times) time the server encountered a sql error because it already had the prime and rejected the test. It would get added to the PRP.log and completedtests.log as if nothing had happened. Because the test was rejected the client would submit it again in 1 minutes time. This is why it ended up in the log multiple times.

I am uploading those logs and will edit in the link shortly.
[url]http://www.sendspace.com/file/kgw6se[/url][/QUOTE]

I got the files. I'll take a look later tonight.

[QUOTE=rogue;349567]I got the files. I'll take a look later tonight.[/QUOTE]
It would be nice if you could work out why the tests were handed out again. It might be a 5.0.8 bug that is now fixed of course. :smile:

[QUOTE=henryzz;349568]It would be nice if you could work out why the tests were handed out again. It might be a 5.0.8 bug that is now fixed of course. :smile:[/QUOTE]

Are those the right logs? I didn't see any messages about SQL errors. There are few entries from the past week. Almost all are from December 2012.

[QUOTE=rogue;349571]Are those the right logs? I didn't see any messages about SQL errors. There are few entries from the past week. Almost all are from December 2012.[/QUOTE]
This is a bug I found in December. I didn't report it as it seemed a bit of a corner case.
The first SQL_ERROR is prpserver.log line 3998.
It is debatable whether it is worth trying to work out what caused this as it is 5.0.8.
I have a couple more ideas on how I could reproduce it with the latest server. I won't have time until I leave though.