5

I'm working on a client project & am having some issues pulling DCPs from the broker database. I noticed an error in the deserialization process regarding malformed input (DD4T), but upon investigation it appears that the content being returned is not being decoded properly from the database. Note that we have compression turned OFF for DD4T, both on the CM side & on the CD side. I'm fairly confident it has nothing to do with DD4T for reasons explained below.

Here's the error I am seeing:

com.fasterxml.jackson.core.JsonParseException: Unexpected character ('?' (code 63)): expected a valid value (number, String, array, object, 'true', 'false' or 'null') 
at [Source: ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????????

The key thing to notice is the source is "???...". The deserialization error isn't the problem, it's the content being returned from the Broker call which is causing the deserialization to fail.

The strange thing is that another developer is able to pull the DCPs without issue; our development server is also pulling successfully. I can pull pages which aren't encoded in the broker, but DCPs give me issues every-time.

In my mind it has to be either (1) a database issue during the decoding process, or (2) a JAR issue with my environment causing the input stream to fail reading the content properly. I'm weary to blame the database because it's working for others, so it has to be confined to my environment.

Here's what I've tried..

  • Updating JDK to same as the development server where it's working.
  • I've tried pulling pages from the broker, which works (they're not encoded in DB).
  • I've tried querying with the OOTB CD API which yields the same results. I get back "????..." in content when using the assembler / factory.
  • Ensured content is published to the broker, & encoded.
  • Ensured that the pub target has encoding UTF-8 set.
  • Republished content w/ OOTB Tridion CT to rule out DD4T issue. Same result.

We're currently using..

  • Tridion 2013 SP1
  • WebLogic (12c R2)
  • SSH tunnel (DB connection)
  • DD4T-2 (Java)

I'm currently stumped as to what to try next. Any input or guidance would be greatly appreciated.

  • Have you verified the JARs that you are using vs the JARs used by other users for whom it is working fine? – Hiren Kaku Jun 14 '16 at 17:52
  • We're using ANT & Bamboo for the dependency management, so we should all be using the same JAR set. Sorry I should have clarified that. – Josh Hebb Jun 14 '16 at 18:00
4

We've sorted it out.

The issue ended up being with the WSTL JDBC driver which we had installed in our local WebLogic. We compared it against the development box and noticed the discrepancy, so I installed the same driver on my local machine and voila!

I was using the following driver:

net.sourceforge.jtds.jdbc.Driver

While the server was using:

weblogic.jdbc.sqlserver.SQLServerDriver

We're using a JNDI connection, so when setting up the data source in WSTL we were prompted for the driver. We selected other, and in the text field we put the driver described above. Pointing to the new data source and restarting the server solved the issue!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.