Trouble on retrieval/data/getDataAtTime

Hi, I'm now trying to follow user guide 'Save/Restore API'. When I type curl -H "Content-Type: application/json" -XPOST -s "http://appliance.fqdn:17668/retrieval/data/getDataAtTime?at=2019-02-22T10:40:00.000-07:00&includeProxies=true" -d '["TESTPV" ]', I got HTTP Status 400 - Bad Request: The server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing)..

Where should I check related log messages and how should I fix the problem?

I'm using archappl_v0.0.1_SNAPSHOT_09-October-2018T15-49-47.tar.gz with Tomcat 7.0.92.

Here is my appliances.xml;

<appliances>
  <appliance>
    <identity>appliance0</identity>
    <cluster_inetport>appliance.fqdn:17670</cluster_inetport>
    <mgmt_url>http://appliance.fqdn:17665/mgmt/bpl</mgmt_url>
    <engine_url>http://appliance.fqdn:17666/engine/bpl</engine_url>
    <etl_url>http://appliance.fqdn:17667/etl/bpl</etl_url>
    <retrieval_url>http://appliance.fqdn:17668/retrieval/bpl</retrieval_url>
    <data_retrieval_url>http://appliance.fqdn/retrieval</data_retrieval_url>
  </appliance>
</appliances>

FQDN is set by /etc/hosts .

Seems ok to me... I took your request and changed around the name/pvname and was able to get data. The "malformed request syntax" points to a client encoding error; I would check for obvious things like quotes (i.e., make sure you are not using the back double quote etc). However; I cut and paste your URL and it seems to be fine.

You can try adding a -v to the curl call to see more details. Also, tomcat logs may have more details.

Thank you for quick answer. I cannot find getDataAtTime related message on arch.log catalina.log, and son on. only localhost_access logs are there.

Output of curl with -v option looks weired more... What is the meaning of '"getDataAtTime" is not a valid API method'?

> POST /retrieval/data/getDataAtTime?at=2019-02-22T10:40:00.000-07:00&includeProxies=true HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.27.1 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: appliancetest.local:17668
> Accept: */*
> Content-Type: application/json
> Content-Length: 49
>
< HTTP/1.1 400 Bad Request
< Server: Apache-Coyote/1.1
< Access-Control-Allow-Origin: "getDataAtTime" is not a valid API method.
< Content-Type: text/html;charset=utf-8
< Content-Language: en
< Content-Length: 1167
< Date: Wed, 27 Mar 2019 14:20:44 GMT
< Connection: close

Oh.... It's literally there is no getDataAtTime... I don't know why, but in my /retrieval/webapps/retrieval/WEB-INF/classes/org/epics/archiverappliance/retrieval directory, there is no getDataAtTime.class . Is it possible to compile and put the class manually?

This call is served by the main DataRetrievalServlet. It is part of commit https://github.com/slacmshankar/epicsarchiverap/commit/8672bb4adfaa4c9e9d0c2f742ff8181e5d8cd8c4. There is a Nov 15 release that has some bug fixes for this feature; but I think that has mostly to do with fields.

Is it possible to compile and put the class manually?

No. There are too many dependencies. I would upgrade the system to the Nov 15th release... This is what I currently have deployed in my production systems.

Hi Murali, have the same/similar issue with the Oktober 2018 Snapshot (I don't know how to deal with the November update ;-) ). I get the message: ... HTTP method POST is not supported by this URL

description The specified HTTP method is not allowed for the requested resource.<... My request string looks like this: curl -v -H "Content-Type: application/json" -XPOST -s "http://185.228.137.144:17668/retrieval/data/getDataAtTime?at=2019-05-04T08:00:00.000-02:00" -d '["BBB:Blau:Weight","BBB:Gelb:Weight"]'

Looking into this...

Thanks for pointing this out. I think I may just messed up the builds on this one. I tried the archappl_v0.0.1_SNAPSHOT_15-November-2018T10-27-25.tar.gz using quickstart.sh and it definitely does have this feature. Very likely I uploaded an older build by mistake.

I will mark the Nov build as the fall release; as it does contain the fix for the fields. Apologies for the mixup.

Just to be safe; I will generate a new release by the end of this week. There have not been that many changes since Nov but it may make sense to have a clean release that is well marked.

I forgot to close the issue. Thank you for care about it :+1:

archiver-appliance / epicsarchiverap

Trouble on retrieval/data/getDataAtTime #77