Duelbot !signup and !alias doesn't work anymore (probably other commands aswell)

P.S. You need a test environment setup to make sure everything is working alright. If you are going to fix this, you can use TWDev zone for running the bot but I suggest you don't use trenchwars.org's database for it. I can give you access to my twcore test database on twcore.org, just drop me a message and I will send you the connection details.

Associated stacktrace:

java.lang.NullPointerException
	at com.mysql.jdbc.ResultSet.buildIndexMapping(ResultSet.java:575)
	at com.mysql.jdbc.ResultSet.findColumn(ResultSet.java:930)
	at com.mysql.jdbc.ResultSet.getString(ResultSet.java:4755)
	at twcore.bots.duelbot.duelbot.do_enableName(Unknown Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
	at java.lang.reflect.Method.invoke(Method.java:585)
	at twcore.core.command.CommandInterpreter.handleEvent(Unknown Source)
	at twcore.bots.duelbot.duelbot.handleEvent(Unknown Source)
	at twcore.core.util.MessageLimiter.handleEvent(Unknown Source)
	at twcore.core.net.GamePacketInterpreter.handleChatMessage(Unknown Source)
	at twcore.core.net.GamePacketInterpreter.translateNormalPacket(Unknown Source)
	at twcore.core.net.GamePacketInterpreter.translateGamePacket(Unknown Source)
	at twcore.core.net.ReliablePacketHandler.handleReliableMessage(Unknown Source)
	at twcore.core.net.GamePacketInterpreter.translateSpecialPacket(Unknown Source)
	at twcore.core.net.GamePacketInterpreter.translateGamePacket(Unknown Source)
	at twcore.core.Session.run(Unknown Source)

Does !signup give the error for players that are registered, previously unregistered, or both?

I'm unsure why the exception is hitting in do_enableName when !signup and !alias are used. Nothing calls do_enableName except the !enable trigger from what I can see.

What's the exact message the players are receiving? Are there any other commands that have been found to be impacted by this?

It might be a good idea to get someone who knows their SQL to check tblUser and tblTeam.

This method also was throwing a lot of exceptions even before the small database change, as is marked in the code — in fact, it was being thrown so frequently that I temporarily commented out the stack trace print. This might be another way to approach the problem (to see how common it was in the past as well).

According to the end of this thread, this problem seems to occur when the ResultSet is closed prematurely … though like us, this person can't seem to find where it's being closed:

http://forum.java.sun.com/thread.jspa?threadID=771452&messageID=4395719

(It's the last 3-4 posts)

Also, did we recently change versions of the mySQL connector, and if so, are we sure it's bug-free? Which version are we running?

hm yes we have recently switched mysql connector libraries.

from mysql-connector-java-3.1.10-bin.jar to mysql-connector-java-3.1.13-bin.jar . I can switch this around again if you think this has caused it?

Worth a shot. The bug reports I was checking definitely had to do with some version of mySQL 3.1.1x, but not sure which (if any) was specified.

I changed the connector but it didn't resolve the problem.

   MMaverick> !enable
     DuelBot> Problem accessing database.  Please try again later.
     DuelBot> Problem retreiving your info from database.  Please try again later, or talk to a staff member.
   MMaverick> !signup
[No response]

Here is what I found after a good bit of work, adding some logging to the bot, and collaboration with a league op.

DuelBot receives the !signup, and sends *info to the player, but does not ever receive the *info readout back from the server! You can see in the log where it accepts !signup, but when it checks arena commands in do_checkArena, you'll never see a log message that says "DUELTEST: *info received for (name)" which is logged when an arena message starts with "IP:" — the text of an info readout.

This part has nothing to do with the database, so it's particularly unexpected that the problem would halt here.

Further, the database access problems with, for example, the !alias command are only checking tblDuelPlayer, which I didn't personally touch or even look at… I'm inclined to believe something particularly weird is going on here that does not have to do with the recent modifications to tblUser and tblTeam.

odd, quite odd. Are you any closer to solving it though?

Well, because of this, not really. We need to figure out why people can't !signup before !enable will work, as enable was written badly before and threw an NPE anytime someone who was not signed up used it.

Can you verify somehow that duelbot is still on sysop.txt? We have to figure out why *info is not working right. Are other bots able to *info okay? Was the biller changed somehow?

I just verified that Duelbot is still on sysop.txt. It puzzles me why Duelbot can't *info, I also find it hard to believe.

Anyhow, I will try to fix this aswell, doing some tests. Maybe this evening (that is, in 8 hours from now).

It would be nice if we had someone who was cleared to log on as DuelBot even for just a moment and do an *info. Maybe Pure or 2d or another long-timer could get away with it.

I'll do a search for other bots that use *info and try to see if they're still working properly.

I just got on DuelBot (don't tell anyone :p) and checked - it can do *info just fine. There must be something else wrong.

Problem fixed.

The CommandInterpreter class wasn't working correctly with the default command - it wasn't executing the method associated with it. Duelbot relies on this feature because the method do_checkArena() is set to execute as the default command. (Duelbot always checks for the *info information when it gets a non-command message.)

The !enable problem was caused by an incorrectly placed m_botAction.SQLClose() in the sql_getUserIPMID() method. (The ResultSet was closed already before it got returned and used.)

Changesets: [1459] & [1460]

Nice.

Sorry about the bit in sql_getUserIPMID(). I had figured that with the hundreds of changes needed I'd probably make an error or two; also apologies in advance for anything that comes up after as a result of it. :P

Did I also make a change to CommandInterpreter that caused it to work improperly? I don't recall when that one would have been modified, particularly the default command piece. Must have been recently, if !signup has been having problems only a couple weeks?

No need to apologise, Roboking is way more stable then it ever was before - the changes are good

No it seems that CommandInterpreter has been changed a long way back and was never tested properly. I checked the backup of Roboking to see if CommandInterpreter was different there and it was. I checked the history of the file in the repository to see who made the change but it was done before the migration to Subversion.

This class was probably never updated when we had the codebase in CVS but when I updated Roboking from Subversion then this class was replaced/updated aswell.

Speaking of, I'd been meaning to ask: what's King's uptime lately?

(The King memory leaks were the one big reason that DoCk> did not want RoboQueen updated with new code … so that if we've managed to cut them down quite a bit, we might also be able to get Queen updated much more easily.)

Well you can check for yourself by doing ?find Roboking_ (_ = space). I thought it would've been more when I checked today; last seen 25 hours ago. I don't know when I took it down so it might have been up since that time which is 25 hours. Anyway, it's been way more stable then it used to be.

Been playing SS 10 or 11 years now; know the ?find trick. :> I'm mostly asking because it seems you're far more knowledgeable about the day-to-day happenings. Well, if the uptime has been pretty good, ideally with no crashes related to memory leaks, we might be able to encourage a Queen code update soon.

Agreed. However we need to ask a certain staffer that has retired and is the only one who has access :/ I would really like to do it myself but I guess that isn't going to happen anytime soon.

Talked to Pure today. He has Queen access, and the third bot server is also coming on board soon!… Told him King was getting more stable.

Another reason I'm adding to this ticket is because I'm noticing duelbot is still giving off NPEs in enablename. Though the problem is definitely fixed.

NPE should be fixed.