search

namgk / ambienttalk

Automatically exported from code.google.com/p/ambienttalk
0 stars 0 forks source link

java.lang.ArrayIndexOutOfBoundException when serializing a message in a pooled FarRef Thread #45

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?

It don't seem to be reproducible anymore in the trunk after commit 2519. 
It was reproducible before in the net-refactor branch sometimes. 
It was also reproducible if AT in used in virtual private networks (e.g. if 
your laptop uses VMWare software).

What is the expected output? What do you see instead?

Exception in thread "pool-3-thread-1" java.lang.ArrayIndexOutOfBoundsException
    at java.lang.System.arraycopy(Native Method)
    at java.io.BufferedOutputStream.write(BufferedOutputStream.java:111)
    at java.io.ObjectOutputStream$BlockDataOutputStream.drain(ObjectOutputStream.java:1847)
    at java.io.ObjectOutputStream$BlockDataOutputStream.write(ObjectOutputStream.java:1818)
    at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1302)
    at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1154)
    at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
    at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
    at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
    at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
    at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1518)
    at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1483)
    at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1400)
    at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1158)
    at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:330)
    at edu.vub.at.actors.net.comm.net.NetCommunicationBus.sendSynchronousUnicast(NetCommunicationBus.java:511)
    at edu.vub.at.actors.net.cmd.CMDTransmitATMessage.send(CMDTransmitATMessage.java:66)
    at edu.vub.at.actors.natives.FarReferencesThreadPool$TransmissionEvent.process(FarReferencesThreadPool.java:117)
    at edu.vub.at.actors.natives.FarReferencesThreadPool$1.process(FarReferencesThreadPool.java:168)
    at edu.vub.at.actors.natives.FarReferencesThreadPool$Handle.run(FarReferencesThreadPool.java:86)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:680)

Please use labels and text to provide additional information.

This issue seems to be solved by the solution in issue#44

Original issue reported on code.google.com by egonzal...@gmail.com on 10 Dec 2010 at 1:02

GoogleCodeExporter commented 8 years ago 
Note: This exception is raised by a thread in the ThreadPool trying to send an 
asynchronous message to another VM when the contents of the message are being 
serialized.

Original comment by egonzal...@gmail.com on 10 Dec 2010 at 1:11

GoogleCodeExporter commented 8 years ago

Original comment by tvcut...@gmail.com on 10 Dec 2010 at 4:09

GoogleCodeExporter commented 8 years ago 
The issue is not fixed: I got again today the same exception with the latest 
version of the trunk.
I could not reproduce it again. 
A theory of what is happening: a thread of the pool thinks the at message was 
correctly transmitted, so, another thread of the pool starts serving another 
message and then both try to access the CommunicationBus at the same time. This 
means the second thread changes the number of bytes pushed to the bus which 
causes the exception.
Code to capture it and print some more useful information has been added to the 
trunk. 
This should help to figure out what's going on next time it appears. 
To be continued..

Original comment by egonzal...@gmail.com on 13 Dec 2010 at 5:07

GoogleCodeExporter commented 8 years ago 
The issue seems to happen because two threads of different thread pools where 
accessing the communication bus at the same time. The sendSynchronousUnicast in 
CommunicationBus.java does synchronize the access to get the connection from 
the address book, but they were not synchronized in writing to the connection 
neither closing the socket.  So, threads from different pools may be executing 
the writeObject() code at the same time, making that the buffer size change, 
which results in the ArrayIndexOutOfBoundException for the "loser thread". 

This problem could eventually happen before as well with the original 
ELFarReference and I cannot explain why it manifest more times with thread 
pools.

Solution (included in the trunk since revision 2561): 

-Changes on Connection.java to make close() method synchronized + adda public 
synchronized send(msg) method which calls the writeObject and flush methods.
-Having one thread pool for at VM may be enough since we only have one 
CommunicationBus per at VM (which is the "bottleneck"). So, there will be one 
thread to one per VM rather than one per actor.

Original comment by egonzal...@gmail.com on 16 Dec 2010 at 12:59

GoogleCodeExporter commented 8 years ago

Original comment by egonzal...@gmail.com on 22 Dec 2010 at 2:30