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.
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.
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.