TimeSeries Update error

ExternalIdBundleWithDates idBundle = historicalTimeSeriesDocument.getObject().getExternalIdBundle();
if(historicalTimeSeriesDocument.isLatest()) {
  ExternalIdBundleWithDates idBundleNew = rectify(idBundle);
  String newNameString = "SomeNewName";

results me for some documents error like…

Exception in thread “Thread-64” java.lang.IllegalArgumentException: Server threw exception: UniqueId is not latest version: DbHts~174134~388685
at sun.reflect.GeneratedConstructorAccessor8.newInstance(Unknown Source)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
at java.lang.reflect.Constructor.newInstance(Unknown Source)
at com.opengamma.util.rest.ExceptionThrowingClientFilter.handle(ExceptionThrowingClientFilter.java:72)
at com.sun.jersey.api.client.Client.handle(Client.java:648)
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:680)
at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74)
at com.sun.jersey.api.client.WebResource$Builder.post(WebResource.java:568)
at com.opengamma.master.historicaltimeseries.impl.RemoteHistoricalTimeSeriesMaster.update(RemoteHistoricalTimeSeriesMaster.java:116)
at com.opengamma.master.historicaltimeseries.impl.RemoteHistoricalTimeSeriesMaster.update(RemoteHistoricalTimeSeriesMaster.java:35)
at com.algotree.timeseries.TimeSeriesDocResource.update(TimeSeriesDocResource.java:155)
at com.algotree.util.tools.TimeSeriesCusip8UpdateThread.run(TimeSeriesCusip8UpdateThread.java:53)
Caused by: com.sun.jersey.api.client.UniformInterfaceException: POST returned a response status of 400 Bad Request
at com.opengamma.util.rest.ExceptionThrowingClientFilter.handle(ExceptionThrowingClientFilter.java:64)
… 8 more

Am I using the recommended way? or is it a bug?


One more problem I face with the above code…

For successful update of timeseriesDocument, I can see additional timeseries with modified idBundle in the UI’s time series tab . The Old one is still there.

What I really need a single timeseries with modified idBundle.


I think the problem here is it’s possible that we don’t support modifying the id bundle during the lifetime of a time series - you would handle that by deleting the old time series and adding a new one with a different bundle. That’s odd because you definitely can do that for securities, for example, and that shares a lot of the code.

I’ve opened a ticket in JIRA (PLAT-3097) for you to track.


Is the behaviour consistent failure or occasional failure?

The master should support updating the bundle (although you should really only ever add IDs to it). The error message would be thrown if another thread had updated the same time-series since the time-series was queried.


OOOhh!..paging, updating and threading may not work altogether…In my particular case, I could see same timeseries document were updated parallelly from multiple threads even though I wrote code for single thread to handle single timeseries expecting different pages are mutually exclusive. I suspect the update query may affect the sequencing of the records on pages, timeserieses get entered in to threads repeatedly causing the above problem.

is there a way to order the TimeSeriesDocSearchResult when it is get paged?