java.lang.NullPointerException: null at org.transitclock.gtfs.DbConfig.getStopIdsForRoute - core startup failure #251
Comments
|
New findings: RMI Queries to the cores are actually working, I didn't have a hibernate config in the working directory (for the cores and Tomcat it's configured in env vars/cmd line params). From the comparison of log files between the server that works and the one that doesn't I could only find the following difference. catalina.out - server that works catalina.out - server that doesn't work So it looks like one of the lines regarding database connection isn't appearing in the tomcat catalina.out log for the server that doesn't work... All the other apps output both lines after running them. (the servers are using the same Tomcat and Java version with the same WAR archives). |
|
I seemingly finally found a stacktrace which seems to have also been encountered by another user on the other repo Transitime#29 ... And this causes a later So for some reason it crashes here - |
|
I also found that some API endpoints work, apparently the ones that do not directly use GTFS data...? For example |
|
I may have found something peculiar... On the installation that doesn't work properly, I ran If I look at the imported data, I can see the configRev being 0. Could this mean that the import script somehow silently failed although I Can see the data in the tables? (I looked at the server that is working and the activeRevision for that corresponds to the latest one, of course). I tried manually setting both of those values to 0 and the result is that the cores are not launching anymore, which seems very weird. core.log I am starting to think that maybe the data imports introduce some invalid data that makes the program crash... I'll try setting the import logs to a different location in order to have a separate log just with that... and maybe allocate more memory for the import since this is a big dataset. |
|
Weird, looks like the GtfsFileProcessor.jar finishes successfully, but on an emptied database I still get the activeRevision set to -1 after the first import. The NullPointer error that prevents the cores from starting persists. I tried selecting for NULL agencyIds and stopIds with no luck, all result sets are empty. |
BodoMinea
changed the title
BodoMinea
changed the title
|
Looks like the final issue boils down to |
|
For now I solved my issue by adding in the following „bodge”: „Something went wrong” appeared once during core startup but otherwise the app works fine. I tried enablign SQL logging and manually executing queries to find if something NULL is coming from the database but there were far too many queries. The obvious ones yielded zero null results. Since something may have been wrong with my data or setup, I do not consider this a fix and will not push it to my branch or create a PR for it. Thanks! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi everyone,
I am trying to launch my second deployment of TheTransitClock. The first one I managed to get running last year and is still working properly. However, by following the same steps I am now running into some problems that I haven't been able to diagnose.
Expected functionality
After going through the „full” deployment process for system - installing Ubuntu Server with Java 1.8, MariaDB 10, Tomcat 8, building TheTransitClock from GitHub, creating the database, table structures, importing data, adding API keys and WebAgencies and configuring them to be in Tomcat's environment, running the RMI Registry, running the Core.jar-s, the expected outcome would be to see agency names when opening up the web interface, and from there being able to inspect maps and reports in order to assess the functionality of the system.
Describe the bug
The Web UI only shows agency IDs in the table, as if it wasn't able to get the agency names from the system. Maps and reports do not work because the API calls are failing with error 400. There nothing in any log to suggest anything is wrong - catalina.out and core.log have no stack traces.
Version:
Latest develop from github.
Screenshots, Logs, Diagnostics & Additional context
Looking in the console at one of the cores reveals something like this:
Looks pretty normal to me.
Looking into the logs of one of the running cores:
core.log
avl.log
Anyway, it seems to be running normally and doing its job. I can also see assignments being made in autoAssigner.log.
Now to Tomcat. This is relevant output from catalina.out
So... everything seems to be up and running and properly configured. There are no stack traces or errors recorded anywhere, not even when the server spits out a 400 code - I can only find in the normal access log. Some other things I tried:
GET http://127.0.0.1:8080/api/v1/key/KEY/agency/AGENCY/command/routes - INVALID API KEY, VALID AGENCY (invalid agency yields same result)
Application key "a" is not valid.Response seems to come from the app, not from Tomcat itself.
GET http://127.0.0.1:8080/api/v1/key/KEY/agency/AGENCY/command/routes - VALID API KEY, INVALID AGENCY
HTTP 400 Bad RequestResponse seems to come from the app, again, since it's plain text, not from Tomcat itself.
GET http://127.0.0.1:8080/api/v1/key/KEY/agency/AGENCY/command/routes - VALID API KEY, VALID AGENCY (should have an actual response...)
<!DOCTYPE html><html><head><title>Apache Tomcat/8.0.43 - Error report</title><style type="text/css">H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}.line {height: 1px; background-color: #525D76; border: none;}</style> </head><body><h1>HTTP Status 400 - Bad Request</h1><div class="line"></div><p><b>type</b> Status report</p><p><b>message</b> <u>Bad Request</u></p><p><b>description</b> <u>The request sent by the client was syntactically incorrect.</u></p><hr class="line"><h3>Apache Tomcat/8.0.43</h3></body></html>So this is a 400 error from Tomcat itself, hence the formatting. There is no detailed message or stack trace anywhere.
GET http://127.0.0.1:8080/api/v1/key/KEY/agency/AGENCY/command/routesDetails?format=json - VALID API KEY, VALID AGENCY
Index: 0, Size: 0Again a response from the app...
GET http://127.0.0.1:8080/api/v1/key/KEY/agency/AGENCY/command/gtfs-rt/tripUpdates?format=binary (or format=human)
<!DOCTYPE html><html><head><title>Apache Tomcat/8.0.43 - Error report</title><style type="text/css">H1 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:22px;} H2 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:16px;} H3 {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;font-size:14px;} BODY {font-family:Tahoma,Arial,sans-serif;color:black;background-color:white;} B {font-family:Tahoma,Arial,sans-serif;color:white;background-color:#525D76;} P {font-family:Tahoma,Arial,sans-serif;background:white;color:black;font-size:12px;}A {color : black;}A.name {color : black;}.line {height: 1px; background-color: #525D76; border: none;}</style> </head><body><h1>HTTP Status 500 - Internal Server Error</h1><div class="line"></div><p><b>type</b> Status report</p><p><b>message</b> <u>Internal Server Error</u></p><p><b>description</b> <u>The server encountered an internal error that prevented it from fulfilling this request.</u></p><hr class="line"><h3>Apache Tomcat/8.0.43</h3></body></html>Again... this comes from Tomcat and there are no details in the logs.
GET http://127.0.0.1:8080/api/v1/key/KEY/agency/AGENCY/command/serverStatus - the only one that actually seems to work, as you can also see in the screenshot above.
Does anyone have ideas regarding to what might be causing this? My next course of action, over the following days is to extract the JARs, WARs and Java/Tomcat binaries from my other server and replace them onto this installation, to check if that solves it.
Thank you!
The text was updated successfully, but these errors were encountered: