We use JGo as part of one of our software tools. We recently had our tool crashing on a couple of machines at a customer site, while it worked fine on many other machines at that same site.
Eventually it was discovered that the problematic machines had dual processors.
We’ve set up a dual-processor system here in our office, and our tool is crashing on it as well.
Various actions can trigger crashes, but all the crashes seem to end with the same two stack traces:
NullPointerException
JGoView.documentChanged
JGoDocument.A
JGoDocument.fireUpdate
JGoObject.update
JGoObject.update
NullPointerException
JGoDocument.A
JGoDocument.fireUpdate
JGoObject.setVisible
Does anyone have any known issues or bugs relating to multiple processor support and JGo?
-Mark Stracka
At some point in our code we appear to have two threads poking at the JGoDocument. I’m not sure how this is happening, as we never intended to run multiple threads… I’m still digging into it.
At any rate, Walter at Northwoods was kind enough to email me this fix, which worked out very nicely. If you’re having troubles on a multi-processor box, try this:
"Perhaps you could override JGoDocument.fireUpdate to check java.awt.EventQueue.isDispatchThread(), and call invokeLater() if it is false. Something like:
public class InstrumentDocument extends JGoDocument {
public InstrumentDocument() {}
public void fireUpdateHelper(int hint, int flags, Object object, int prevInt, Object prevObj) {
super.fireUpdate(hint, flags, object, prevInt, prevObj);
}
public void fireUpdate(int hint, int flags, Object object, int prevInt, Object prevObj) {
if (java.awt.EventQueue.isDispatchThread()) {
super.fireUpdate(hint, flags, object, prevInt, prevObj);
}
else {
java.awt.EventQueue.invokeLater(new RunnableDocumentEvent(this, hint, flags, object, prevInt, prevObj));
}
}
And the RunnableDocumentEvent is defined as:
public class RunnableDocumentEvent extends JGoDocumentEvent implements Runnable {
public RunnableDocumentEvent(JGoDocument source, int hint, int flags, Object obj, int prevInt, Object prevObj) {
super(source, hint, flags, obj, prevInt, prevObj);
}
public void run() {
InstrumentDocument doc = (InstrumentDocument)getSource();
doc.fireUpdateHelper(getHint(), getFlags(), getObject(), getPreviousValueInt(), getPreviousValue());
}
}
Hi,
We get exactly the same trace as you’ve mentioned above but unfortunately for us, it is hard to replicate it. I’ve tried out the proposed fix but since we can’t replicate it, can’t prove that it actually fixed the issue.
Do you know if the proposed fix above applies to the latest 5.15 release or all 5.0?
thanks.
Neither version 5.0 or 5.1 of JGoDocument includes that code, since it “shouldn’t” be necessary if the application is “correct” in avoiding changes in other threads. I believe that code will work with both versions 5.0 and 5.1.
However, I do recommend you understand what multi-threading is going on in your application. The code above is more safe with respect to threading, but it’s slower too.