Skip to content
This repository has been archived by the owner on Aug 27, 2024. It is now read-only.

Timeseries dissapears #22

Open
suweg opened this issue Jun 3, 2020 · 3 comments
Open

Timeseries dissapears #22

suweg opened this issue Jun 3, 2020 · 3 comments

Comments

@suweg
Copy link

suweg commented Jun 3, 2020

Hi,

we encountered a completely new problem with an old SA-series. There is no hint of an error and at the first glimpse everything looks fine. Only one timeseries named "pd0600f" does not have any values in the XML-file received from the webservice.

The series looks like this in the x13requests.xml that we send to the webservice (the values are not officially released yet):

<x13:Item>
<x13:Series name="pd0600f">
<tss:Frequency>12</tss:Frequency>
<tss:FirstYear>2003</tss:FirstYear>
<tss:FirstPeriod>1</tss:FirstPeriod>
<tss:Values>VALUE-1 VALUE-2 ... VALUE-N</tss:Values>
</x13:Series>

This is the result that we get from the webservice:

<tss:item name="pd0600f">
<tss:Subset/>
</tss:item>

It is empty. All the other timeseries in the file are normal tough. I can send you the complete files next week, if necessary, when the new data will be published.

We produced the results anyway, using the JWSACruncher. Strangely, the cruncher produced all the results for the series pd0600f.

I guess you cannot solve this issue withour the complete data files. I can send you the files next week, if necessary, when the new data will be published.

Cheers
Susanne

@maggima
Copy link
Collaborator

maggima commented Jun 5, 2020

Hi Susanne,

It's hard to tell without having the data causing the issue. I won't be able to reproduce your exact same case as it's not happening with every timeseries.
How is your webservice hosted ? If it's hosted on an application server (like Glassfish, Tomcat,...), do you have access to the logs ? There are maybe some hints in those logs about your problem.

Are the versions of the JWSACruncher and WS the same ?

Best regards,
Mats

@nbbrd nbbrd deleted a comment from maggimats Jun 5, 2020
@suweg
Copy link
Author

suweg commented Jun 5, 2020

Hi Mats,

I figured out the part that is causing the problem. I compared the missing timeseries with the other ones and there is a difference in some items:

td|reg_SpecParser.UU0345
(appears twice in the SAPro XML file)

The other timeseries have different elements there that look like this:
reg_SpecParser.UY4712 reg_SpecParser.UY8413

My guess is, that the vertical bar is causing the issue. There is no special character in the timeseries that are working fine. When replacing those strings in the pd0600f series, it worked as well. Might the problem even be related to the encoding issue #13, that we didn't follow further?

We are using v2.2.2 for both, the webservice and the cruncher. We are hosting the webservice on Tomcat, but I cannot easily access the logs, because the server is hosted by our service provider. But I could ask for the log.

sapro_non_missing_ts
sapro_missing_ts

I can also send you the files via email for testing.

Best regards,
Susanne

@maggima
Copy link
Collaborator

maggima commented Jun 5, 2020

It's probably the same issue.
When I tried to reproduce that first issue, I couldn't find where the encoding problem happened.
It could be from your script to the WS call, the WS deserialization trying to parse the request, the config from Tomcat...

I'll try again when I receive an example file from you. Data can be randomized if there are some confidentiality concerns as the problem occurs because of the naming.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants