OPS timeouts on 6 and 7 January 2018

This space is made available to users of Open Patent Services (OPS) web-service and now also to users of EPO’s bulk data subscription products such as 14. EPO worldwide bibliographic database (DOCDB), 14.11 EPO worldwide legal status database (INPADOC), 14.12 EP full text data, 14.1 EP bibliographic data (EBD)and more.

Users can ask each other questions, exchange experiences and solutions, post ideas. The moderator will use this space to announce changes or other relevant information.

Mike_k43
Posts: 52
Joined: Fri Jan 06, 2017 1:34 pm

Re: OPS timeouts on 6 and 7 January 2018

Post by Mike_k43 » Wed Jan 10, 2018 9:19 pm

Confirmed!

The JSON raw response containing the access token now lacks one space at the bold underscored site:
....
"token_type": "BearerToken",
"issued_at": "1515610432202",
"client_id": "EvBooYJ6AwZna6ocokeGTfGRL6l2RQiz",
"access_token": "osmQKWOFAAkaAOqB2Xdk7TUzzxyI",
"application_name": "889c06e1-0bc2-483e-8f63-98fc386301fc",
"scope": "core",
"expires_in": "1199",
....

As the consequence the starting character of the token was not parsed anymore. The access tokens now work again, after correcting the code for the lost space. Who at the EPO programmer staff hat this idea to change this without telling anyone? This presumably caused a lot of unnecessary work for many users including me!

But the problem with the timeouts still persists.

mike_k43


EPO / OPS Support
Posts: 1298
Joined: Thu Feb 22, 2007 5:32 pm

Re: OPS timeouts on 6 and 7 January 2018

Post by EPO / OPS Support » Thu Jan 11, 2018 8:11 am

Hi,

This change was I guess unintentional and we have already ask developers to have a look at this. I will get back on that once I know more,

Best regards

OPS support


Mike_k43
Posts: 52
Joined: Fri Jan 06, 2017 1:34 pm

Re: OPS timeouts on 6 and 7 January 2018

Post by Mike_k43 » Fri Jan 19, 2018 7:20 am

I finally managed to track down the timeout problem. Sometimes the raw XML response data received from OPS are corrupted, causing a local InvalidOperationException when attemping to deserialize them. My software then retries the same query again, to possibly obtain with the second query a deserializable raw XML response. If the second try with the same query also returns a corrupted (non-deserializable) raw XML response, them my software re-tries for the third time the same query. Running the same query for the third time apparently causes OPS to stop responding, which produces a local TimeoutException. In earlier trials such corrupted XML responses seemed to happen in an irreproducible way, but now I have found a situation in my test queries where they happen reproducibly.

I will now post a text log file to support@epo.org, with the subject "OPS timeout", where at the very end of the file the three unsuccessfull trials ("Try:1", "Try: 2", "Try: 3") with one and the same query are visible. The first two trials produce a non-deserializable XML response, the third trial causes UPS to stop responding and produces the timeout.

mike_k43


Mike_k43
Posts: 52
Joined: Fri Jan 06, 2017 1:34 pm

Re: OPS timeouts on 6 and 7 January 2018

Post by Mike_k43 » Tue Jan 23, 2018 7:55 am

Did you receive from EPO support the logfile I announced? Otherwise I will have to re-send it to a new e-mail-address you indicate to me.

mike_k43


EPO / OPS Support
Posts: 1298
Joined: Thu Feb 22, 2007 5:32 pm

Re: OPS timeouts on 6 and 7 January 2018

Post by EPO / OPS Support » Tue Jan 23, 2018 8:10 am

Hi,

I did and I also replied to you before you posted this last reply to this forum

Regards,
OPS support


Mike_k43
Posts: 52
Joined: Fri Jan 06, 2017 1:34 pm

Re: OPS timeouts on 6 and 7 January 2018

Post by Mike_k43 » Thu Feb 15, 2018 11:46 am

I would like to report that OPS timeouts still happen as of today, 15 February 2018. I also note that this thread seems to be of some interest to OPS users. If other OPS users also experience OPS timeouts I would suggest that they communicate this here. Otherwise, OPS support and developer team will remain inactive.

mike_k43


Post Reply