GTFS RT of Edmonton behavioral differences - issues

[kevin...@transitscreen.com]

HI all,

We are witnessing some behavioral differences while running the GTFS RT of Edmonton via Eclipse or via the bundle and we would like to know your thoughts about these.

1) Using the master branch on Eclipse:

a) using the https: https://data.edmonton.ca/download/uzpc-8bnm/application%2Foctet-stream

This runs correctly but we are getting errors/warnings like these: "StopTimeSequence not found: stopSequence=26" and we dont get any ArrivalAndDeparture entries when trying to get arrivals for a stop.

b) using http: We're getting an error when asking for arrivals at a stop:

Error updating from GTFS-realtime data sources

com.google.protobuf.InvalidProtocolBufferException: Protocol message end-group tag did not match expected tag.

at com.google.protobuf.InvalidProtocolBufferException.invalidEndTag(InvalidProtocolBufferException.java:94)

Question 1: I'm not sure why we witness such a difference just by using https vs http. The feed "seems" the same in both cases.

2) Using the 1.1.15 release:

a) using https: We get an SSL issue: Error updating from GTFS-realtime data sources

javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No subject alternative DNS name matching data.edmonton.ca found.

b) Using http:  Error updating from GTFS-realtime data sources
com.google.protobuf.InvalidProtocolBufferException: Message missing required fields: header
at com.google.protobuf.UninitializedMessageException.asInvalidProtocolBufferException(UninitializedMessageException.java:81)

Question 2: Why is that behaving differently than with the master branch which I think is the same code?

3) To fix some GTFS RT, we also have a proxy in C#. This proxy uses a library to parse GTFS RT (google.protobuf) like the one used in OBA. When we use this proxy to get the feed using the HTTP endpoint, decode it, then recode it (without making any changes in the header or in the other entities etc) and send it to OBA (basically OBA calls our proxy which gets the feed etc), we dont get the error in mentioned in 1)b)2 any more.

We are a bit out of ideas and not sure why this feed behaves like this. I'm wondering if the reason could be that the Java library used in OBA to read and parse the GTFS RT feed is outdated and could not parse the feed correctly for some reason?

Let us know your thoughts.

Thank you,

Kevin

[Sheldon A. Brown]

Dealing with HTTPS in Java can be quite exasperating at times. The
JVM that is running must be able to verify the chain of trust for the
certificate of the URL you are requesting via its internal certstore,
or it must have that certificate in its local keystore. If you don't
know what this means, you can try updating your JVM to the very latest
in hopes that it will pick up a certstore that will have the root
certificate you need.

To go through your questions:

1b)
The difference between HTTP and HTTPS you are seeing -- when you
request "http://data.edmonton.ca/download/uzpc-8bnm/application%2Foctet-stream"
it is simply redirecting you to
"https://data.edmonton.ca/download/uzpc-8bnm/application%2Foctet-stream"
but the HTTPS handshake didn't happen so the stream is unreadable.


2)
This is not likely a difference of OneBusAway versions, but a
difference of Java version. Eclipse will often run a different JVM,
even between workspaces. Verify everything is the same between 1) and
2), and then verify you are able to read HTTPS correctly from
data.edmonton.ca.

3)
I'm not sure why you took the approach. Apache httpd, nginx, and
pound are popular open source applications (to name a few) that will
decode/proxy HTTPS for you if you can't figure it out in Java. No
need to write this yourself and risk getting it wrong.



Good luck!

Sheldon

> --
> You received this message because you are subscribed to the Google Groups
> "onebusaway-developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to onebusaway-devel...@googlegroups.com.
> To post to this group, send email to onebusaway...@googlegroups.com.
> Visit this group at https://groups.google.com/group/onebusaway-developers.
> For more options, visit https://groups.google.com/d/optout.