[JAVA-1632] IllegalArgumentException: response too long: 1701078386 Created: 26/Jan/15  Updated: 19/Oct/16  Resolved: 15/Oct/15

Status: Closed
Project: Java Driver
Component/s: Connection Management
Affects Version/s: 2.12.2
Fix Version/s: None

Type: Bug Priority: Critical - P2
Reporter: Martin W. Kirst Assignee: Jeffrey Yemin
Resolution: Duplicate Votes: 0
Labels: connection, crash, driver
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

mongo-java-driver v2.12.2
springDataMongo v1.5.0.RELEASE
OS: Oracle Enterprise Linux 6.4
java version "1.8.0_05"
Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)


Issue Links:
Duplicate
duplicates JAVA-1613 Race condition on DBPort usage during... Closed

 Description   

Hi,

we're using MongoDB in our financial application with an estimated data size of 130GB. On a daily basis we're observing strange Exceptions (see stacktrace below).

The code is pretty simple though. Theres a (Http-)Controller, which accepts a single JSON document and saves it to MongoDB. Each document owns about 30 fields. The actual write operation is done via SpringData's CrudRepository.

The strange thing is the number - which seams to be a string!
Consider this Javascript snippet:
new Buffer((1701078386).toString(16),'hex').toString() // => 'eder'
It uncovers the string 'eder'.
The numbers change from time to time, there is another one: 1869642088 ==> 'opyh'.

I blindly guess that the MongoDB driver parses the wrong buffer and goes crazy afterwards.

Can anyone confirm this?

  @RequestMapping(value = "/vorgang/{id}", method = PUT)
  @ResponseStatus(OK)
  public String reportVorgang(@PathVariable("id") String id, @RequestBody Vorgang vorgang) {
    vorgang.setId(id);
    return save(vorgang).id;
  }
 
  public ObjectWithId save(T entity) {
    try {
      return new ObjectWithId(getRepository().save(entity).getId());
    }
    catch (MongoException me) {
      LOG.error(me.getMessage(), me);
      throw new PersistenceException(me.getMessage());
    }
  }
 
  protected abstract CrudRepository<T, String> getRepository(); // returns a pre-configured Spring CrudRepository

Stacktrace

Exception beim Aufruf: /report/vorgang/54c376f2e1b871dba35db75c :  response too long: 1701078386
java.lang.IllegalArgumentException: response too long: 1701078386
	at com.mongodb.Response.<init>(Response.java:49)
	at com.mongodb.DBPort$1.execute(DBPort.java:141)
	at com.mongodb.DBPort$1.execute(DBPort.java:135)
	at com.mongodb.DBPort.doOperation(DBPort.java:164)
	at com.mongodb.DBPort.call(DBPort.java:135)
	at com.mongodb.DBPort.findOne(DBPort.java:189)
	at com.mongodb.DBPort.runCommand(DBPort.java:197)
	at com.mongodb.DBTCPConnector._checkWriteError(DBTCPConnector.java:133)
	at com.mongodb.DBTCPConnector.access$000(DBTCPConnector.java:39)
	at com.mongodb.DBTCPConnector$1.execute(DBTCPConnector.java:186)
	at com.mongodb.DBTCPConnector$1.execute(DBTCPConnector.java:181)
	at com.mongodb.DBTCPConnector.doOperation(DBTCPConnector.java:210)
	at com.mongodb.DBTCPConnector.say(DBTCPConnector.java:181)
	at com.mongodb.DBCollectionImpl.update(DBCollectionImpl.java:275)
	at com.mongodb.DBCollection.update(DBCollection.java:191)
	at com.mongodb.DBCollection.save(DBCollection.java:975)
	at com.mongodb.DBCollection.save(DBCollection.java:934)
	at org.springframework.data.mongodb.core.MongoTemplate$10.doInCollection(MongoTemplate.java:950)
	at org.springframework.data.mongodb.core.MongoTemplate.execute(MongoTemplate.java:410)



 Comments   
Comment by Ross Lawley [ 17/Feb/15 ]

Thanks martin_w_kirst closing this ticket and marking fixed.

Comment by Martin W. Kirst [ 16/Feb/15 ]

Hi,

after updating to 2.12.5 this issue didn't occur anymore.
This issue can be closed.

Thanks for your support.

Regards
Martin

Comment by Jeffrey Yemin [ 26/Jan/15 ]

Thanks Martin, please let us know the results.

Comment by Martin W. Kirst [ 26/Jan/15 ]

@Jeff Yemin

I've read the comments on JAVA-1613.
To my understanding, these conditions may apply to our situation.

Indeed, there are multiple connections to mongodb at the same time (in our case).
Its definitely possible, that a long running read query infers with a short update command.
Of course, we trust on Jetty, that it handles concurrent request right - but in the end, our controllers do share the same MongoDB connection.

I will update to 2.12.5.

Comment by Martin W. Kirst [ 26/Jan/15 ]

Hi,

thanks for the quick response.

I've scanned the MongoDB log file, but couldn't find any access on the used collection within this timeframe.
No inserts nor queries nor error messages. I skipped/ignored lines like "connection accepted" and "end connection".

Regarding Multi-Threading, I've checked the sources but didn't find any ConnectionPool or similar stuff, which may lead to MultiThreading.
We've only written these few lines above. Any other code comes from Spring Data Mongo framework. So I assume that they are already battle proofed

Comment by Jeffrey Yemin [ 26/Jan/15 ]

Also, please check the description of JAVA-1613, which was fixed in the 2.12.5 release, to see if the conditions described there apply to you.

Comment by Ross Lawley [ 26/Jan/15 ]

Hi martin_w_kirst,

Thanks for the bug report - to help understand the cause better I have a couple of questions:

Are you seeing anything posted in the MongoDB server logs that could correspond to these errors?
Also, to double check is it possible that multiple threads are using / accessing the same DBCursor?

Comment by Martin W. Kirst [ 26/Jan/15 ]

I'v forgot to mention, we're using:
MongoDB shell version: 2.2.2
MongoDB server version: 2.4.4

Generated at Thu Feb 08 08:55:05 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.