CoreApi.java : DataSiftClient.usage().sync() : com.datasift.client.exceptions.JsonParsingException

[Albert-Coding]

Hi,

I just started using this client library and ran into a problem. After changing line 21 (i.e. DataSiftConfig().auth) to my API information, I see the following exception thrown by line 49 (i.e. Usage usage = datasift.usage().sync();). Does anyone else see the following? Could someone look into this?

Thanks.

Albert

io.netty.util.internal.logging.Slf4JLogger 10:46:40,225  WARN DefaultChannelPipeline:151 - An exception was thrown by a user handler's exceptionCaught() method while handling the following exception:
com.datasift.client.exceptions.JsonParsingException: Unable to decode JSON from DataSift response
    at com.datasift.client.DataSiftApiClient$1.apply(DataSiftApiClient.java:59)
    at com.datasift.client.DataSiftApiClient$1.apply(DataSiftApiClient.java:41)
    at io.higgs.http.client.future.PageReader.done(PageReader.java:29)
    at io.higgs.http.client.future.Reader.setCompleted(Reader.java:52)
    at io.higgs.http.client.Response.setCompleted(Response.java:69)
    at io.higgs.http.client.ClientHandler.channelRead0(ClientHandler.java:57)
    at io.netty.channel.SimpleChannelInboundHandler.channelRead(SimpleChannelInboundHandler.java:103)
    at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:338)
    at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:324)
    at io.netty.channel.ChannelInboundHandlerAdapter.channelRead(ChannelInboundHandlerAdapter.java:86)
    at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:338)
    at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:324)
    at io.netty.handler.codec.MessageToMessageDecoder.channelRead(MessageToMessageDecoder.java:103)
    at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:338)
    at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:324)
    at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:153)
    at io.netty.channel.CombinedChannelDuplexHandler.channelRead(CombinedChannelDuplexHandler.java:148)
    at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:338)
    at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:324)
    at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:153)
    at io.netty.channel.DefaultChannelHandlerContext.invokeChannelRead(DefaultChannelHandlerContext.java:338)
    at io.netty.channel.DefaultChannelHandlerContext.fireChannelRead(DefaultChannelHandlerContext.java:324)
    at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:785)
    at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:122)
    at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:485)
    at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:452)
    at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:346)
    at io.netty.util.concurrent.SingleThreadEventExecutor$2.run(SingleThreadEventExecutor.java:101)
    at java.lang.Thread.run(Thread.java:744)
Caused by: com.fasterxml.jackson.databind.exc.InvalidFormatException: Can not construct instance of java.util.Date from String value 'Tue, 04 Mar 2014 15:45:00 +0000': not a valid representation (error: Failed to parse Date value 'Tue, 04 Mar 2014 15:45:00 +0000': Unparseable date: "Tue, 04 Mar 2014 15:45:00 +0000")
 at [Source: java.io.StringReader@65e2fa47; line: 1, column: 2] (through reference chain: com.datasift.client.core.Usage["start"])
    at com.fasterxml.jackson.databind.exc.InvalidFormatException.from(InvalidFormatException.java:55)
    at com.fasterxml.jackson.databind.DeserializationContext.weirdStringException(DeserializationContext.java:650)
    at com.fasterxml.jackson.databind.deser.std.StdDeserializer._parseDate(StdDeserializer.java:577)
    at com.fasterxml.jackson.databind.deser.std.DateDeserializers$DateBasedDeserializer._parseDate(DateDeserializers.java:142)
    at com.fasterxml.jackson.databind.deser.std.DateDeserializers$DateDeserializer.deserialize(DateDeserializers.java:227)
    at com.fasterxml.jackson.databind.deser.std.DateDeserializers$DateDeserializer.deserialize(DateDeserializers.java:210)
    at com.fasterxml.jackson.databind.deser.SettableBeanProperty.deserialize(SettableBeanProperty.java:375)
    at com.fasterxml.jackson.databind.deser.impl.FieldProperty.deserializeAndSet(FieldProperty.java:107)
    at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserializeFromObject(BeanDeserializer.java:308)
    at com.fasterxml.jackson.databind.deser.BeanDeserializer.deserialize(BeanDeserializer.java:121)
    at com.fasterxml.jackson.databind.ObjectMapper._readMapAndClose(ObjectMapper.java:2797)
    at com.fasterxml.jackson.databind.ObjectMapper.readValue(ObjectMapper.java:1943)
    at com.datasift.client.DataSiftApiClient$1.apply(DataSiftApiClient.java:55)
    ... 28 more

[zcourts]

Confirmed.
Will create and push a fix as soon as I know what has changed for it to have started happening. Obvious thing right now is that the date format has changed but that shouldn't be so I'll investigate further.

[drazzib]

Just for the record, it seems that all Datasift REST API endpoint don't use same date format.

For instance stream/compile endpoint :

{"hash":"XXXXXX","created_at":"2014-03-19 11:37:36","dpu":"0.2"}

For usage endpoint :

{"start":"Tue, 18 Mar 2014 11:35:00 +0000","end":"Wed, 19 Mar 2014 11:35:00 +0000" [...] }

[zcourts]

Unfortunately not. It's an issue I'm currently trying to get sorted internally which is why I haven't pushed a fix yet. I've been considering removing the Date objects and leaving the raw strings returned until the issue has been addressed with the API.

[drazzib]

If it is in your hands, maybe you can choose to use ISO 8601 format aka "2014-03-18T21:29:15Z". It's easier to read for human and to parse in many language.

[zcourts]

Yup, been trying to get ISO8601, if not it'll be a timestamp in seconds.

[drazzib]

Hi!

I've tested that in latest datasift-java beta3.1 release, "start" / "end" dates are simple Java String.
While it's not perfect, it won't crash anymore so I think this issue should be closed.

Cheers,

[zcourts]

Leaving it open because it's not been dropped as an issue but rolling out a solution is not a simple matter of replacing all existing instances with ISO8601. Customers depend on the current format, it is yet to be decided what the deprecation path will be.

[zcourts]

Update: all dates returned in the API will be timestamps going forward. Currently unable to say when but the lib will be updated as and when this happens.