Greetings,
I’m back again. I can’t log in. I stopped the Percussion Service, which ended all [3 or 4] of the Percussion java.exes, waited a minute and restarted the Percussion Service. Upon restart, after about ten minutes, three Percussion java.exes open up and I still get the same error.
I have also tried Tomcat Shutdown and Tomcat Startup and getting same error.
Seeing as I figure Nathaniel will probably respond; what have I forgotten this time, Nathaniel?
Thanks,
Lloyd.
Hi Lloyd!
This is no way to start the weekend, huh? I’m going to create a support ticket for this issue so you can send me your server log. Please check your inbox for that shortly.
To recap, the problem here was that a system misconfiguration was causing IIS to tie up CM1’s main port, 9992. Once we confirmed that this was not another case of a duplicate CM1 startup, we looked into what else might be using port 9992 on the server.
To root out this type of issue on a Windows server, you can run this from a command line:
netstat -a -n -o
This will list out all of the ports in use on the machine, along with their corresponding process IDs (PID). Once you find the PID that is using 9992, you can run:
tasklist /svc /FI “PID eq XXX”
Where “XXX” = the correct PID identified using the previous command. This give you the process / service name of the application that is using the port. Once you know exactly what is tying up the port, it’s simply a matter of reconfiguring or disabling the offending application.
I am having this same issue, which is odd because it worked fine last week.
Ended the java processes, restarted the server and still having the login issue.
netstat command shows 
tasklist command shows:
Am I reading this wrong or does it seem fine at this point?
Hi Scott,
If you’re certain that all java.exe processes were down before you started Percussion back up, another cause of the 404 error page on start-up could be that the system was unable to make a connection to your SQL database. To see if this might be the case, open up your server.log file located in the {perc_root}\AppServer\server\rx\log directory, and, near the end of the file, look for an error stack that looks similar to this:
WARN [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] Throwable while attempting to get a new connection: null
org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (com.mysql.jdbc.exceptions.jdbc4.CommunicationsException: Communications link failure
The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.)
If you are seeing this error, check and ensure that the Percussion SQL database server is up and running, and that the credentials that Percussion uses to connect to the database have not been modified recently.
This is the warning in the server.log.
WARN [org.jboss.resource.connectionmanager.JBossManagedConnectionPool] Throwable while attempting to get a new connection: null
org.jboss.resource.JBossResourceException: Could not create connection; - nested throwable: (java.sql.SQLException: Cannot open user default database. Login failed.)
I talked to my DBA and apparently this morning he removed an old CM1 database.
It seems that for some reason the new instance of CM1 is still using the old database as well as the new database?
Scott,
Interesting. Will your DBA be able to roll back to the state the database was in prior to the deletion, to get you back up and running in the short term?
Yes, we restored it and it now allows me to login and seems to be working correctly.
Scott,
Great, glad that got you unstuck. Will you be looking into why this old database seemed to be tied to your Percussion DB user, or is the plan to simply leave well enough alone?
I will be looking into why it’s utilizing both databases when I get back on Thursday. Any help would be appreciated.
Scott,
My guess is that the DB user account was configured with your old database specified as its “default” database. You can alter this with a statement similar to:
ALTER LOGIN [perc_db_user] WITH DEFAULT_DATABASE = master
Again, just guessing at this point. I’d certainly recommend having your DBA take a closer look into this to be sure that that is what’s happening.