Error 1227: invalid document type on ordinary BaseDocuments

[snout1979]

When creating new documents using the BaseDocument class occassionally an ArangoDBException gets thrown warning of an invalid document type. This happens when runnig ArangoDB 3.1RC2 with arangodb-java-driver 4.0.0 (vpp)

It appears to be related to the amount of data sent. Document's that generate this error all have a document.properties.toString.length of ~240 characters.

Additionally, occasionally a java.io.IOexception (reached the end of the stream) can get thrown, this time with a document.properties.toString.lenght of ~284 characters.

Relevant stacktraces:
com.arangodb.ArangoDBException: Response: 400, Error: 1227 - invalid document type
at com.arangodb.internal.velocystream.Communication.checkError(Communication.java:104)
at com.arangodb.internal.velocystream.CommunicationSync.execute(CommunicationSync.java:122)
at com.arangodb.internal.velocystream.CommunicationSync.execute(CommunicationSync.java:42)
at com.arangodb.internal.ArangoExecutorSync.execute(ArangoExecutorSync.java:58)
at com.arangodb.ArangoCollection.insertDocument(ArangoCollection.java:77)

com.arangodb.ArangoDBException: java.io.IOException: Reached the end of the stream.
at com.arangodb.internal.velocystream.ConnectionSync.write(ConnectionSync.java:111)
at com.arangodb.internal.velocystream.CommunicationSync.send(CommunicationSync.java:137)
at com.arangodb.internal.velocystream.CommunicationSync.execute(CommunicationSync.java:119)
at com.arangodb.internal.velocystream.CommunicationSync.execute(CommunicationSync.java:42)
at com.arangodb.internal.ArangoExecutorSync.execute(ArangoExecutorSync.java:58)
at com.arangodb.ArangoCollection.insertDocument(ArangoCollection.java:77)
`

[mvollmary]

can you post some code, how the documents look like? Thanks

[snout1979]

I can provide a bit more detail now. I'm storing BaseDocuments that I can store without any issue using the arangodb-java-driver 3.1.0.

Using driver 4.1.0 documents that cotain strings with non-ASCII characters such as "·ÃÂ " consistently fail. I'm not getting an error message, but the documents don't get stored in the database. The _key I defined in the document does get reserved (so attempting to insertDocument with the same key will fail with error message)

Another document I'm not able to store consistently (possibly because of the slashes?) is as simple as

{
"article": {
"artist": "PREGARDIEN/RHEINISCHE KANTOREI/DAS",
"releaseDate": "1970-01-01",
"composer": "BACH",
"format": "CD",
"vat": "H",
"carriers": 1,
"label": "CAPRICCIO",
"title": "BACH ST MATTHEW PASSION BWV244",
"barcode": [
"4006408600466"
],
"conductor": "MAX, H."
},
"stock": {
"status": "RMV",
"lastUpdate": "2016-11-01 00:00"
}
}

For the time being, I'll stick to driver 3.1.0 - please let me know if you need any more information.

[mvollmary]

Fixed a bug which was responsible for the problem with non-ASCII characters. This should work now in version 4.1.1-SNAPSHOT. (I release it as soon as we found the other bug)

I also tried to reproduce your other problem with the example document you posted, but I was not be able to reproduce it. I commited the test in branch 4.1 which you can find here. In this test I created the document as plain json and as BaseDocument. Maybe you can take a look at it and let me know what I have to change to get the error you got.

Thanks!
Mark

[mvollmary]

Released version 4.1.1 today with the encoding bugfix.

[angelogeminiani]

Same error with driver 4.1.2 and 4.1.3.
Always if I have a long string (more than 140 chars) and one ore more non ASCII chars

[angelogeminiani]

This issue is related to string byte size.
Take this 2 strings:

final String working_item = "{\"name1\":\"job_04_detail_1\",\"seven__\":\"123456789\",\"_key\":\"191d936d-1eb9-4094-9c1c-9e0ba1d01867\",\"lang\":\"it\",\"value\":\"[CTO]\\n Ha supervisionato e gestito il reparto di R&D per il software, 1234567 formulando una visione di lungo periodo con la Direzione dell'Azienda.\"}";

final String no_working_item = "{\"name\":\"job_04_detail_1\",\"seven__\":\"123456789\",\"_key\":\"191d936d-1eb9-4094-9c1c-9e0ba1d01867\",\"lang\":\"it\",\"value\":\"[CTO]\\n Ha supervisionato e gestito il reparto di R&D per il software, 1234567 formulando una visione di lungo periodo con la Direzione dell'Azienda.\"}";

First one is working fine while second one throw exception.
The only difference in this sample is 1 char ("name1" was renamed to "name").