Re: JESS: Help with error
I think Krasnigor, Scott L (N-AST) wrote: I am getting the following exception when trying to do a bsave. It is occurring when the bsave method is executing oss.writeObject(m_rules). I don't understand what could be causing this and am looking for any insight into the issue. I am running Jess version 70b7 from a java application. I will be happy to provide more detail if needed. Thanks. Looks like this is caused by new rules being activated during the call to bsave, presumably because working memory is being modified on another thread. I'm surprised this has never come up before, because thinking of it, it seems that bsave() should probably lock the agenda and working memory while it runs -- but it does not. Thanks for reporting this. Jess reported an error in routine bsave while executing (bsave enginedata). Message: Error during execution. Program text: ( bsave enginedata ) at line 1. at jess.Funcall.execute(Funcall.java:328) at jess.Jesp.parseAndExecuteFuncall(Jesp.java:2261) at jess.Jesp.parseExpression(Jesp.java:436) at jess.Jesp.promptAndParseOneExpression(Jesp.java:291) at jess.Jesp.parse(Jesp.java:270) at jess.Rete.eval(Rete.java:2051) at jess.Rete.eval(Rete.java:2006) at control.Controller.run(Controller.java:67) at java.lang.Thread.run(Unknown Source) Caused by: java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(Unknown Source) at java.util.HashMap$EntryIterator.next(Unknown Source) at java.util.HashMap$EntryIterator.next(Unknown Source) at java.util.HashMap.writeObject(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source) at java.io.ObjectOutputStream.writeSerialData(Unknown Source) at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) at java.io.ObjectOutputStream.writeObject0(Unknown Source) at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) at java.io.ObjectOutputStream.writeSerialData(Unknown Source) at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) at java.io.ObjectOutputStream.writeObject0(Unknown Source) at java.io.ObjectOutputStream.writeObject(Unknown Source) at java.util.TreeMap.writeObject(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source) at java.io.ObjectOutputStream.writeSerialData(Unknown Source) at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) at java.io.ObjectOutputStream.writeObject0(Unknown Source) at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) at java.io.ObjectOutputStream.defaultWriteObject(Unknown Source) at java.util.Collections$SynchronizedMap.writeObject(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source) at java.io.ObjectOutputStream.writeSerialData(Unknown Source) at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) at java.io.ObjectOutputStream.writeObject0(Unknown Source) at java.io.ObjectOutputStream.writeObject(Unknown Source) at jess.Rete.bsave(Rete.java:1768) at jess.Dumper.call(DumpFunctions.java:43) at jess.FunctionHolder.call(FunctionHolder.java:31) at jess.Funcall.execute(Funcall.java:320) ... 8 more Scott L. Krasnigor Principal Engineer/Scientist Advanced Sciences Technologies, LLC. Lockheed Martin - MS2 ' 856-359-3094 * [EMAIL PROTECTED] * 780-1A - Ernest Friedman-Hill Advanced Software Research Phone: (925) 294-2154 Sandia National LabsFAX: (925) 294-2234 PO Box 969, MS 9012 [EMAIL PROTECTED] Livermore, CA 94550 http://herzberg.ca.sandia.gov To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' in the BODY of a message to [EMAIL PROTECTED], NOT to the list (use your own address!) List problems? Notify [EMAIL PROTECTED]
RE: JESS: Help with error
Not a problem. Is there a simple fix I can implement. I am trying to prototype a failover capability and I am dead in the water without the bsave/bload functionality working. I have the source code. I will be happy to figure out a temporary fix if you can just point me in the right direction. Thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of friedman_hill ernest j Sent: Thursday, June 22, 2006 9:43 AM To: jess-users@sandia.gov Subject: Re: JESS: Help with error I think Krasnigor, Scott L (N-AST) wrote: I am getting the following exception when trying to do a bsave. It is occurring when the bsave method is executing oss.writeObject(m_rules). I don't understand what could be causing this and am looking for any insight into the issue. I am running Jess version 70b7 from a java application. I will be happy to provide more detail if needed. Thanks. Looks like this is caused by new rules being activated during the call to bsave, presumably because working memory is being modified on another thread. I'm surprised this has never come up before, because thinking of it, it seems that bsave() should probably lock the agenda and working memory while it runs -- but it does not. Thanks for reporting this. Jess reported an error in routine bsave while executing (bsave enginedata). Message: Error during execution. Program text: ( bsave enginedata ) at line 1. at jess.Funcall.execute(Funcall.java:328) at jess.Jesp.parseAndExecuteFuncall(Jesp.java:2261) at jess.Jesp.parseExpression(Jesp.java:436) at jess.Jesp.promptAndParseOneExpression(Jesp.java:291) at jess.Jesp.parse(Jesp.java:270) at jess.Rete.eval(Rete.java:2051) at jess.Rete.eval(Rete.java:2006) at control.Controller.run(Controller.java:67) at java.lang.Thread.run(Unknown Source) Caused by: java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(Unknown Source) at java.util.HashMap$EntryIterator.next(Unknown Source) at java.util.HashMap$EntryIterator.next(Unknown Source) at java.util.HashMap.writeObject(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source) at java.io.ObjectOutputStream.writeSerialData(Unknown Source) at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) at java.io.ObjectOutputStream.writeObject0(Unknown Source) at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) at java.io.ObjectOutputStream.writeSerialData(Unknown Source) at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) at java.io.ObjectOutputStream.writeObject0(Unknown Source) at java.io.ObjectOutputStream.writeObject(Unknown Source) at java.util.TreeMap.writeObject(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source) at java.io.ObjectOutputStream.writeSerialData(Unknown Source) at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) at java.io.ObjectOutputStream.writeObject0(Unknown Source) at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source) at java.io.ObjectOutputStream.defaultWriteObject(Unknown Source) at java.util.Collections$SynchronizedMap.writeObject(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source) at java.io.ObjectOutputStream.writeSerialData(Unknown Source) at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown Source) at java.io.ObjectOutputStream.writeObject0(Unknown Source) at java.io.ObjectOutputStream.writeObject(Unknown Source) at jess.Rete.bsave(Rete.java:1768) at jess.Dumper.call(DumpFunctions.java:43) at jess.FunctionHolder.call(FunctionHolder.java:31) at jess.Funcall.execute(Funcall.java:320) ... 8 more Scott L. Krasnigor Principal Engineer/Scientist Advanced Sciences Technologies, LLC. Lockheed Martin - MS2 ' 856-359-3094 * [EMAIL PROTECTED] * 780-1A - Ernest Friedman
Re: JESS: Help with error
I think Krasnigor, Scott L (N-AST) wrote:
Not a problem. Is there a simple fix I can implement. I am trying to
prototype a failover capability and I am dead in the water without the
bsave/bload functionality working. I have the source code. I will be
happy to figure out a temporary fix if you can just point me in the
right direction. Thanks.
I am thinking of something like this (jess/Rete.java. around like 1800):
public void bsave(OutputStream os) throws IOException {
ObjectOutputStream oos = new ObjectOutputStream(os);
synchronized (getActivationSemaphore()) {
synchronized (getCompiler()) {
oos.writeObject(m_globalContext);
...
The order of the two nested locks is, of course, significant.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of friedman_hill ernest j
Sent: Thursday, June 22, 2006 9:43 AM
To: jess-users@sandia.gov
Subject: Re: JESS: Help with error
I think Krasnigor, Scott L (N-AST) wrote:
I am getting the following exception when trying to do a bsave. It is
occurring when the bsave method is executing oss.writeObject(m_rules).
I don't understand what could be causing this and am looking for any
insight into the issue. I am running Jess version 70b7 from a java
application. I will be happy to provide more detail if needed. Thanks.
Looks like this is caused by new rules being activated during the call
to bsave, presumably because working memory is being modified on
another thread. I'm surprised this has never come up before, because
thinking of it, it seems that bsave() should probably lock the agenda
and working memory while it runs -- but it does not. Thanks for
reporting this.
Jess reported an error in routine bsave
while executing (bsave enginedata).
Message: Error during execution.
Program text: ( bsave enginedata ) at line 1.
at jess.Funcall.execute(Funcall.java:328)
at jess.Jesp.parseAndExecuteFuncall(Jesp.java:2261)
at jess.Jesp.parseExpression(Jesp.java:436)
at jess.Jesp.promptAndParseOneExpression(Jesp.java:291)
at jess.Jesp.parse(Jesp.java:270)
at jess.Rete.eval(Rete.java:2051)
at jess.Rete.eval(Rete.java:2006)
at control.Controller.run(Controller.java:67)
at java.lang.Thread.run(Unknown Source) Caused by:
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(Unknown Source)
at java.util.HashMap$EntryIterator.next(Unknown Source)
at java.util.HashMap$EntryIterator.next(Unknown Source)
at java.util.HashMap.writeObject(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown
Source)
at java.io.ObjectOutputStream.writeObject0(Unknown Source)
at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source)
at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown
Source)
at java.io.ObjectOutputStream.writeObject0(Unknown Source)
at java.io.ObjectOutputStream.writeObject(Unknown Source)
at java.util.TreeMap.writeObject(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown
Source)
at java.io.ObjectOutputStream.writeObject0(Unknown Source)
at java.io.ObjectOutputStream.defaultWriteFields(Unknown Source)
at java.io.ObjectOutputStream.defaultWriteObject(Unknown Source)
at java.util.Collections$SynchronizedMap.writeObject(Unknown
Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown
Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at java.io.ObjectStreamClass.invokeWriteObject(Unknown Source)
at java.io.ObjectOutputStream.writeSerialData(Unknown Source)
at java.io.ObjectOutputStream.writeOrdinaryObject(Unknown
Source)
at java.io.ObjectOutputStream.writeObject0(Unknown Source)
at java.io.ObjectOutputStream.writeObject(Unknown
Re: JESS: Help! Strange error when inserting a fact-id into a fact
Oops ... I should have seen that. Indeed it was the listener and not the assert statement itself. Sorry for th confusion and many thanks for pointing me in the right direction. Felix [EMAIL PROTECTED] wrote: I think Felix H. Bachmann wrote: Here's the exception Jess threw, which is then rethrown by your other code: Message: Not a string: Fact-21 (type = FACT). at jess.Value.a(Unknown Source) at jess.Value.a(Unknown Source) at jess.Value.stringValue(Unknown Source) at edu.cmu.sei.arche.corebridge.listener.VOUpdate.parseAndUpdateDesignElement(VOUpdate.java:1391) at edu.cmu.sei.arche.corebridge.listener.VOUpdate.parseFactAndUpdateVO(VOUpdate.java:315) at edu.cmu.sei.arche.corebridge.listener.CoreListener.eventHappened(CoreListener.java:82) (... more) So your CoreListener class calls VOUpdate.parseFactAndUpdateVO(), which calls VOUpdate.parseAndUpdateDesignElement(), which, at line 1391, calls stringValue() on a Value object of type RU.FACT. The stringValue() method throws this exception to tell you that a FACT isn't a STRING. You'll have to look at parseAndUpdateDesignElement() to see what it's doing exactly, but it's assuming something will be a String, and it isn't. You can use Value.type() to check the type of a Value before calling one of the xxxValue() methods. - Ernest Friedman-Hill Advanced Software Research Phone: (925) 294-2154 Sandia National LabsFAX: (925) 294-2234 PO Box 969, MS 9012 [EMAIL PROTECTED] Livermore, CA 94550 http://herzberg.ca.sandia.gov To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' in the BODY of a message to [EMAIL PROTECTED], NOT to the list (use your own address!) List problems? Notify [EMAIL PROTECTED] To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' in the BODY of a message to [EMAIL PROTECTED], NOT to the list (use your own address!) List problems? Notify [EMAIL PROTECTED]
Re: JESS: Help! Strange error when inserting a fact-id into a fact
I think Felix H. Bachmann wrote: Here's the exception Jess threw, which is then rethrown by your other code: Message: Not a string: Fact-21 (type = FACT). at jess.Value.a(Unknown Source) at jess.Value.a(Unknown Source) at jess.Value.stringValue(Unknown Source) at edu.cmu.sei.arche.corebridge.listener.VOUpdate.parseAndUpdateDesignElement(VOUpdate.java:1391) at edu.cmu.sei.arche.corebridge.listener.VOUpdate.parseFactAndUpdateVO(VOUpdate.java:315) at edu.cmu.sei.arche.corebridge.listener.CoreListener.eventHappened(CoreListener.java:82) (... more) So your CoreListener class calls VOUpdate.parseFactAndUpdateVO(), which calls VOUpdate.parseAndUpdateDesignElement(), which, at line 1391, calls stringValue() on a Value object of type RU.FACT. The stringValue() method throws this exception to tell you that a FACT isn't a STRING. You'll have to look at parseAndUpdateDesignElement() to see what it's doing exactly, but it's assuming something will be a String, and it isn't. You can use Value.type() to check the type of a Value before calling one of the xxxValue() methods. - Ernest Friedman-Hill Advanced Software Research Phone: (925) 294-2154 Sandia National LabsFAX: (925) 294-2234 PO Box 969, MS 9012 [EMAIL PROTECTED] Livermore, CA 94550 http://herzberg.ca.sandia.gov To unsubscribe, send the words 'unsubscribe jess-users [EMAIL PROTECTED]' in the BODY of a message to [EMAIL PROTECTED], NOT to the list (use your own address!) List problems? Notify [EMAIL PROTECTED]
