Hi Normen. I’d like to do that, but I have over (no joke) 8000 lines of code implied in this project and I’m feeling like I left some extremely obvious detail behind and by making a smaller test case, I fear I’ll make the issue disappear. It’s getting so big so quickly…
Speaking of which, as Paul mentioned (Hi again Paul, sorry for frustating you! Really, I didn’t mean to haha… OK I’ll try to explain and put some code for you guys to actually understand what I’m up to, BTW I’m happily surprised you remember the last question you helped me with :D) I found out after over an hour of close looking at the code that THERE IS INDEED TWO CONCURRENT THREADS going on but they’re so fast (?) that when I print them, it never seems like they cross each other (execute at the same time). The exception happens even tough all the println()'s are always citing the same thread name (thread-1 for instance). BUT come to think about it again, it’s honestly stupid of me to have thought multithreading was not part of it. It’s now obvious it’s part of the problem, because of one of the implied exceptions name.
So that’s on the table. THERE IS a concurrent modification going on in a second thread but not always AND YES PAUL, now I have put TRY CATCH every god damn place, because yes, it was swallowing all the exceptions, that’s why I was lost at the beginning of this post, now I see all exceptions)… and it happens so fast that sometimes it’s not doing it (probably because the other thread is not messing with this variable at this point in time) it’s pretty much random, altough ALL THE DATA IS STATIC and always exactly the same on all runs. It’s in a text file, it’s not randomly generated.
OK so let’s skip to the actual thing:
What I don’t understand is how can a function throw a concurrent modification exception when that function actually creates all its used variables? I mean, let’s say 2 threads are calling the same function in a Future pattern exactly like mine:
[java]
private List<Future<Node>> arr_threads = new ArrayList<>();
arr_threads.add(0, threadpool.submit(
new Callable<Node>(){
@Override
public Node call() throws Exception {
try{
Node n = get_item(new Vector3f(locX, 0, locZ), true, new Vector3f(entering_side_x, 0, entering_side_z));
return n;
}
catch(Exception e){
return null;
}
}
}
));
[/java]
…all is 100% well if I comment out the collideWith() function inside the get_item() function. By following the stack, it throws the concurrent modification exception while sorting the collideWith() results variable. But that variable is created inside the get_item() function, so how can it be shared among threaded calls? I’m pinpointing the problem but I don’t understand how this is possible and what’s the real fix to have collideWith() working on threaded calls.
Basically, inside the get_item() function, I create a Node and I attach lots of spatials on it and then I do some ray tracing to align them and it crashes there SOMETIMES and sometimes it’s fine and also like I said if I comment this part out, the WHOLE rest of that function (+500 lines of code) with a bunch of manipulations on spatials, materials and stuff all works PERFECTLY. Basically, the collideWith() function throws a ConcurrentException or sometimes a NoSuchElementException and even sometimes NULL exception even tough none of the variables listed here-after are NEVER null. So I’m 100% sure that results is RE-USED across all the running threads, but it doesn’t make sense to me, because I just instanciated right there from inside the get_item() function:
[java]
CollisionResults results = new CollisionResults();
Ray ray = new Ray(child.getLocalTranslation(), new Vector3f(0, -1, 0));
if(layer.getQuantity() > 0){
try{
layer.collideWith(ray, results);
}
catch(Exception e){
e.printStackTrace();
// ConcurrentException / NoSuchElementException… weird.
}
}
[/java]
Thank you so much for your support guys.
