Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

ConcurrentModificationException during ObjectOutputStream.writeObject()

 
ulvi ugur
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi All,

I have this multi-threaded application writing on the socket in a sequence and processing data and writing again. Here is a short code snippet :



Here queue is a LinkedBlockingQueue and outputMsg is an encapsulation of a HashMap. Now, the problem is, this is throwing ConcurrentModificationException on the writeObject() method. Synchronizing on outputMsg didn't really solve the problem.

Any ideas you can share with me about this interesting subject ?

Thanks in advance,

Ulvi

 
Travis Hein
Ranch Hand
Posts: 161
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
if more than one thread writing to the objectOutput (i don't see it declared inside the run), then taht would do it,
 
ulvi ugur
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Thanks Travis ! As this problem only occurs very occasional, I will update this thread later to verify that the solution works.
 
ulvi ugur
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Hi,

I need to come back to this one again !!

The proposal didn't solve the problem again. I changed it to :



but that didn't help either. I am still getting these "java.util.ConcurrentModificationException". Any further suggestions ?

Thanks in advance,

Ulvi

 
Henry Wong
author
Marshal
Pie
Posts: 20997
76
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
ulvi ugur wrote:
but that didn't help either. I am still getting these "java.util.ConcurrentModificationException". Any further suggestions ?



Unfortunately, the answer is ... serialization is *not* thread safe, so don't serialize the same data at the same time.

Locking the message will not work here because it is possible for two messages to have references to instances, which have references to instances, etc., which have references to a shared instance. All it takes is one shared instance, to cause the problem.

And I am willing to bet that the reason locking the object outputstream isn't working, is because you are using more than one.

Henry
 
Travis Hein
Ranch Hand
Posts: 161
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
would it be possible to create a kind of 'stuff to serialize' queue, where you have a 'worker thread' that owns the queue (a vector of the objects you want serialized).. so your threads create a request 'token' that contains the reference to the thing you want serialized, and any additional information that is needed to do the work.

these tokens get queued up by the many threads trying to do the writing, and a single worker thread processes these tokens.

I created something like this one time, at band camp, to make a multi threaded java application invoke a JNI COM bridge, which is horribly not thread safe.

consider,



where a possible use for this




So that should write stuff to the object output stream allowing multiple threads to submit things to be written.

clearly there is no way with this current sample to ensure what order things will get written out of course, many threads submitting things could cause some indeterminate order of things written out. I guess as long as the thing being written out is in itself not dependent on the order it was written out then that is ok.

Note the 'boxing' of the thing we want to write into a 'token' object container is useful to allow for storage of other things like statistics counters, timers, etc over time. I used a model like this for the reverse direction too, where a single data source (select rows from a database), would queue up and this worker would dispatch a token to more than one row processing child worker, because in that case each row was also independent on its order, but the dividing up the work through a simple vector queue is pretty effective.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic