Talk:Darkcanuck/RRServer/Updates

Upcoming update

I'm planning to release a new update today that fixes a major concurrency problem. Database-wise it's a beautiful change since it normalizes things and makes retirement and re-activation a breeze. But I'm a bit concerned about performance because the change will make the worst query in the upload process a bit worse. On my test server everything seems fine but I'll need you guys to keep a sharp eye out for oddities in the live rumble. This update could be very difficult to roll back so if there are any problems we'll need to catch them quickly. Ready? --Darkcanuck 18:20, 6 February 2010 (UTC)

I've got 5 CPU's cranking through battles. Will there be an interruption that requires a restart? --Martin 19:19, 6 February 2010 (UTC)

There will be an interruption on the server while I make the switch (hopefully not too long), but your clients will keep running and store battles locally until the server is back. --Darkcanuck 19:22, 6 February 2010 (UTC)

FYI - I still cannot run the server with my new Win 7 box and 1.6.1.4 client. Any chance that this may fix that? --Miked0801 07:20, 7 February 2010 (UTC)

I saw your note elsewhere and it's a client issue, nothing that can be fixed on the server. I think you're stuck until we can use a more recent version of the rumble client. --Darkcanuck 07:27, 7 February 2010 (UTC)

By the way, Mike, I have a 4-core Windows 7 machine and I am running without issues (mostly). I installed the Roborumble, ran the client once, ran the rumble through one iteration, and then made three copies of the entire folder, named inst1-inst4. I bring a command window for one (shift-right-click on folder in explorer), type roborumble+enter, select the java.exe in the Task Manager, right click and choose Set Affinity, and assign it to one of four CPUs. Then I start and set affinity for the other three, to a different CPU each time. I set the battles/iteration to 50 to make more efficient use of the startup-cost of the robocode.jar. Setting to 100 caused an out of memory error typically around iteration 90ish. I was able to run it overnight and all the next day at 50 with no issues. Let me know if there's something specific you are running into. --Martin 19:07, 7 February 2010 (UTC)

Nothing specific. I'll re-install the 1.6.1.4 from scratch and try again. --Miked0801 00:40, 8 February 2010 (UTC)

One note, is I find most things that a re-install fixes, are also fixed by the simpler step of deleting the robot database and cache files from the robots directory. Often that solves odd problems. --Rednaxela 00:47, 8 February 2010 (UTC)

Alas, I have already tried that with no luck... --Miked0801 16:48, 8 February 2010 (UTC)

Re-deleting my robot database fixed it! Got 4 clients running now. Wow the uploads are slow right now - we must be really pounding the heck out of your servers :) --Miked0801 10:26, 9 February 2010 (UTC)

This may be related to the update or it may not, I'm not sure, but some comparisons look weird. The retired bot still has it's battle count and overall score, but it's individual pairings have disappeared. --Rednaxela 15:30, 8 February 2010 (UTC)

Definite bug. Found and fixed! --Darkcanuck 15:53, 8 February 2010 (UTC)

Improved priority battles

Sounds great, this should help new robots stabilize much faster! On that note, I have just switched my client over to your patched version. — Chase-san 03:00, 13 July 2011 (UTC)

Yeah, I stripped my dev server down to 20 bots and this worked beautifully. Will have to see how it does in the real world. Just so you know, I just updated that jar, the original I had uploaded didn't patch melee battles. The link should get the fixed version now. --Darkcanuck 03:03, 13 July 2011 (UTC)

Luckily I was just doing 1-on-1 battles. But updated all the same. — Chase-san 03:33, 13 July 2011 (UTC)