Re: [rules-users] Parallel / Distributed Optaplanner
Hi Jonathan, On 09-06-14 20:52, jonathan.labin wrote: I know that this topic has come up before. At various times there were responses indicating that it was being considered at some level within the project(s). How has that played out? Was there progress or has the idea been put on the back-burner? Was something discovered that seems to make the idea not worth pursuing? It's still on my mind and in the roadmap: https://issues.jboss.org/browse/PLANNER-76 Other issues have currently taken priority (due to customer requests etc). http://www.optaplanner.org/download/releaseNotes/releaseNotes6.1.html In 6.1 (CR1 is being build right now), more preparation for this is in place: everything is now on the selector architecture. The technical challenge is still the same: don't break incremental score calculation while parallelizing OptaPlanner, because incremental score calculation is a far bigger speedup than anything parallelization can bring to the table. The technical design that adheres to this is still the same (last comment on PLANNER-76): Use surrogate entity id's, to allow migrating Move's from 1 workingSolution to another. I'm contemplating doing some investigating of my own to attempt to leverage additional hardware in a distributed way for our application. But I didn't want to end up re-discovering things or try things that have already proved to be a dead end by an effort ongoing within the project. Any experiments you do would be interesting for me to observe. Especially if it's user-domain agnostic, I am interested to merge a PR adding this functionality. Any insight you could share? Parallelize the method LocalSearchDecider.pickNextStep() :) Replace the LocalSearchDecider instance in DefaultLocalSearchPhase with your own. Extend LocalSearchPhaseConfig to be able to do that. -- View this message in context: http://drools.46999.n3.nabble.com/Parallel-Distributed-Optaplanner-tp4029930.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Drools Workbench - Cloning a local Repo Gives “Invalid remote: origin”
@Michael Due to this error it’s not cloning it. Below is the architecture in which I am deploying the Workbench. Two Workbench instances, one central GIT repo and One central Maven Repo (Details as below) My architecture for Drools deployment is we will deploy two Drools Workbench instances. We will create one central GIT repository, REPO-A.git, which will be cloned by both the instances, REPO-A-Cloned-1, REPO-A-Cloned-2. If any file is committed in instance A, REPO-A-Cloned-1, should also appear in instance B, REPO-A-Cloned-2, and that asset should also appear in central repo, REPO-A. Regards, Zahid From: rules-users-boun...@lists.jboss.orgmailto:rules-users-boun...@lists.jboss.org [mailto:rules-users-boun...@lists.jboss.org] On Behalf Of Michael Anstis Sent: 08 June 2014 14:36 To: Rules Users List Subject: Re: [rules-users] Drools Workbench - Cloning a local Repo Gives “Invalid remote: origin” You won't need a user id or password. The remote origin error message is thrown by the underlying jgit library we use. Any repository that is cloned is considered a remote in git terms. The fact that it's on your local machine makes no difference in git terms. Sent on the move On 8 Jun 2014 11:07, Zahid Ahmed zahid.ah...@emirates.commailto:zahid.ah...@emirates.com wrote: Hi, I am trying to clone a repo in Drools WorkBench and getting the following error, Can't clone repository. java.lang.RuntimeException:Invalid remote: origin The repository which I am cloning, resides in my local machine. D:/Servers/Drools-6-Deployment/repo/repoA.git Following are the inputs I am providing to WorkBench clone Wizard, Repository Name = repoCloned Organizational Unit = inTech GIT URL = file:///D:/Servers/Drools-6-Deployment/repo/repoA.gitfile:///D:\Servers\Drools-6-Deployment\repo\repoA.git User Name = (Currently I am giving my github account cred. What to give in user name?) Password = (Currently I am giving my github account cred. What to give as password?) Question 1 Why am I getting remote origin error when I am cloning from a local GIT repository ? Question 2 Kindly let me know what to give as User Name and Password when I am cloning from an existing GIT repo in my local filesystem ? Regards, Zahid Ahmed ___ rules-users mailing list rules-users@lists.jboss.orgmailto:rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Drools Workbench - Cloning a local Repo Gives “Invalid remote: origin”
I tried with the latest codebase and could clone a repository on my local filesystem without problem (the path needs to be the folder containing the git repository's .git folder). As for your architecture; we don't support what you describe - which appears to be a distributed git installation with automatic synchronization of commits between the two. Changes you make to files within Drools Workbench installation 1 (using the cloned repository REPO-A-Cloned-1) will only appear in the clone. You will need to handle a mechanism to push the commits made there to it's origin (i.e. REPO-A) and synchronization to REPO-A-Clone-2. Google returns links to server-side scripts you can run to synchronize different GIT repositories; however you'll probably encounter merge conflicts if a single file was modified in both clones. With kind regards, Mike On 10 June 2014 09:33, Zahid Ahmed zahid.ah...@emirates.com wrote: @Michael Due to this error it’s not cloning it. Below is the architecture in which I am deploying the Workbench. Two Workbench instances, one central GIT repo and One central Maven Repo (Details as below) My architecture for Drools deployment is we will deploy two Drools Workbench instances. We will create one central GIT repository, REPO-A.git, which will be cloned by both the instances, REPO-A-Cloned-1, REPO-A-Cloned-2. If any file is committed in instance A, REPO-A-Cloned-1, should also appear in instance B, REPO-A-Cloned-2, and that asset should also appear in central repo, REPO-A. Regards, Zahid *From:* rules-users-boun...@lists.jboss.org [ mailto:rules-users-boun...@lists.jboss.org rules-users-boun...@lists.jboss.org] *On Behalf Of *Michael Anstis *Sent:* 08 June 2014 14:36 *To:* Rules Users List *Subject:* Re: [rules-users] Drools Workbench - Cloning a local Repo Gives “Invalid remote: origin” You won't need a user id or password. The remote origin error message is thrown by the underlying jgit library we use. Any repository that is cloned is considered a remote in git terms. The fact that it's on your local machine makes no difference in git terms. Sent on the move On 8 Jun 2014 11:07, Zahid Ahmed zahid.ah...@emirates.com wrote: Hi, I am trying to clone a repo in Drools WorkBench and getting the following error, *Can't clone repository. java.lang.RuntimeException:Invalid remote: origin* The repository which I am cloning, *resides in my local machine*. D:/Servers/Drools-6-Deployment/repo/repoA.git Following are the inputs I am providing to WorkBench clone Wizard, Repository Name = repoCloned Organizational Unit = inTech GIT URL = file:///D:/Servers/Drools-6-Deployment/repo/repoA.git User Name = (Currently I am giving my github account cred. What to give in user name?) Password = (Currently I am giving my github account cred. What to give as password?) *Question 1* Why am I getting remote origin error when I am cloning from a local GIT repository ? *Question 2* Kindly let me know what to give as User Name and Password when I am cloning from an existing GIT repo in my local filesystem ? Regards, Zahid Ahmed ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Are there second-rate fact types?
Consider:
class Foo { /*...*/ }
rule checkFoo
when
Foo( noSuchField 0 )
then ... end
DRL compilation reports an error (Error: unable to resolve method ...)
and identifies rule, line and column, which is fine.
Now let's look at:
import java.util.ArrayList;
rule checkArrayList
when
ArrayList( noSuchField 0 )
then ... end
The same DRL compiler (checked with 5.5.0 and 6.0.0) accepts this, and
there is a nasty exception thrown at runtime. This is inconvenient,
since the exception can be thrown by any code inserting an ArrayList
object, and the faulty rule isn't identified.
Why are certain classes second-rate?
-W
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Are there second-rate fact types?
java.util.Collections (and descendants) are not @typesafe by default,
I'll check the reason for that.
More generally, if a fact is declared as not @typesafe, the runtime
failure should be more graceful.
Davide
On 06/10/2014 01:26 PM, Wolfgang Laun wrote:
Consider:
class Foo { /*...*/ }
rule checkFoo
when
Foo( noSuchField 0 )
then ... end
DRL compilation reports an error (Error: unable to resolve method ...)
and identifies rule, line and column, which is fine.
Now let's look at:
import java.util.ArrayList;
rule checkArrayList
when
ArrayList( noSuchField 0 )
then ... end
The same DRL compiler (checked with 5.5.0 and 6.0.0) accepts this, and
there is a nasty exception thrown at runtime. This is inconvenient,
since the exception can be thrown by any code inserting an ArrayList
object, and the faulty rule isn't identified.
Why are certain classes second-rate?
-W
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Are there second-rate fact types?
On 10/06/2014, Davide Sottara dso...@gmail.com wrote:
java.util.Collections (and descendants) are not @typesafe by default,
I'll check the reason for that.
OK.
More generally, if a fact is declared as not @typesafe, the runtime
failure should be more graceful.
But (according to you) java.util.Collections is *not* @typesafe, and
this runtime failure cannot be called graceful.
Can a java.util.X be declared as @typesafe? If so, how? Is any of this
documented anywhere?
-W
Davide
On 06/10/2014 01:26 PM, Wolfgang Laun wrote:
Consider:
class Foo { /*...*/ }
rule checkFoo
when
Foo( noSuchField 0 )
then ... end
DRL compilation reports an error (Error: unable to resolve method ...)
and identifies rule, line and column, which is fine.
Now let's look at:
import java.util.ArrayList;
rule checkArrayList
when
ArrayList( noSuchField 0 )
then ... end
The same DRL compiler (checked with 5.5.0 and 6.0.0) accepts this, and
there is a nasty exception thrown at runtime. This is inconvenient,
since the exception can be thrown by any code inserting an ArrayList
object, and the faulty rule isn't identified.
Why are certain classes second-rate?
-W
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Are there second-rate fact types?
The feature was more important when we didn’t allow casting, but people still
wanted to work with Maps and Lists.
Map( this[key].age 30)
Collections where defaulted to typefalse(false)
Now that we support inline casts, it can be argued that things should always be
type safe:
Map( this[key]#Person.age 30 )
It’s hard to change this now, without breaking backwards compatability.
The docs don’t say that it’s defaulted to false for collections, only that it’s
useful for Collections. Someone want to submit a pull request fix for this?
4.7.2.1.2. @typesafe( boolean )
By default all type declarations are compiled with type safety enabled;
@typesafe( false ) provides a means to override this behaviour by permitting a
fall-back, to type unsafe evaluation where all constraints are generated as
MVEL constraints and executed dynamically. This can be important when dealing
with collections that do not have any generics or mixed type collections.
4.7.5. Non Typesafe Classes
@typesafe( boolean) has been added to type declarations. By default all type
declarations are compiled with type safety enabled; @typesafe( false ) provides
a means to override this behaviour by permitting a fall-back, to type unsafe
evaluation where all constraints are generated as MVEL constraints and executed
dynamically. This can be important when dealing with collections that do not
have any generics or mixed type collections.
Mark
On 10 Jun 2014, at 13:45, Davide Sottara dso...@gmail.com wrote:
java.util.Collections (and descendants) are not @typesafe by default,
I'll check the reason for that.
More generally, if a fact is declared as not @typesafe, the runtime
failure should be more graceful.
Davide
On 06/10/2014 01:26 PM, Wolfgang Laun wrote:
Consider:
class Foo { /*...*/ }
rule checkFoo
when
Foo( noSuchField 0 )
then ... end
DRL compilation reports an error (Error: unable to resolve method ...)
and identifies rule, line and column, which is fine.
Now let's look at:
import java.util.ArrayList;
rule checkArrayList
when
ArrayList( noSuchField 0 )
then ... end
The same DRL compiler (checked with 5.5.0 and 6.0.0) accepts this, and
there is a nasty exception thrown at runtime. This is inconvenient,
since the exception can be thrown by any code inserting an ArrayList
object, and the faulty rule isn't identified.
Why are certain classes second-rate?
-W
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Memory leak when deploying to Maven repository?
Hello everybody,
I use Drools to create rules from an external source and create an artifact
from those rule strings, putting it into a local repository.
A minimalistic working example can be found at
https://github.com/dadadom/MavenMemoryLeakMinimalExample
The code, taken from that example, is basically like this:
ReleaseId releaseId = new
ReleaseIdImpl(some:releaseid:1.0.0-SNAPSHOT);
String rules = rule \testrule\ ... ;
KieServices kServices = KieServices.Factory.get();
KieFileSystem kfs = kServices.newKieFileSystem();
kfs.write(src/main/resources/someBase/testrule, rules);
kfs.generateAndWritePomXML(releaseId);
String kmoduleXmlString = kmodule ... /kmodule;
kfs.writeKModuleXML(kmoduleXmlString.getBytes());
KieModule kieModule = kServices.newKieBuilder(kfs).getKieModule();
try {
File pomFile = new File(System.getProperty(java.io.tmpdir),
pom.xml);
try (FileOutputStream fos = new FileOutputStream(pomFile)) {
fos.write(KieBuilderImpl.generatePomXml(releaseId).getBytes());
fos.flush();
} catch (IOException e) {
e.printStackTrace();
}
final MavenRepository mavenRepository =
MavenRepository.getMavenRepository();
mavenRepository.deployArtifact(releaseId, (InternalKieModule)
kieModule, pomFile);
When I call this method in a ServletContextListener in a Tomcat Server (version
7 or 8) and undeploy the application afterwards, I get a memory leak.
Tomcat tells me that the application has a memory leak:
The following web applications were stopped (reloaded, undeployed), but their
classes from previous runs are still loaded in memory, thus causing a memory
leak (use a profiler to confirm):
/mvntest
Looking at the memory dump with e.g. JProfiler, I can trace the dangling
instances back to an object
static INSTANCE of class
org.drools.compiler.kie.builder.impl.KieRepositoryImpl
So it seems like there is something which I am either missing or which is a
bug. I cannot find any .close() or .release() method or something alike on any
of the involved objects ...
If anyone could give me a hint how to solve this problem, I'd be happy not to
litter my memory no more :)
Regards and thanks
Dominik
...
mit freundlichen Gr??en / kind regards
Dominik Sandjaja
Fon: +49 (0) 203 60878 183
Fax: +49 (0) 203 60878 222
e-mail: dominik.sandj...@it-motive.de
it-motive AG
Zum Walkm?ller 6
47269 Duisburg
i...@it-motive.de
http://www.it-motive.de
..
Vorsitzender des Aufsichtsrats: Dr.-Ing. J?rgen Sturm
Vorstand: Horst-Dieter Deelmann (Vors.), Matthias Heming, Christoph Tim Klose
HRB 9207, Amtsgericht Duisburg
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Are there second-rate fact types?
In fact what we have now is *NOT* graceful
I'll open a JIRA and try to provide a fix
On 06/10/2014 01:52 PM, Wolfgang Laun wrote:
On 10/06/2014, Davide Sottara dso...@gmail.com wrote:
java.util.Collections (and descendants) are not @typesafe by default,
I'll check the reason for that.
OK.
More generally, if a fact is declared as not @typesafe, the runtime
failure should be more graceful.
But (according to you) java.util.Collections is *not* @typesafe, and
this runtime failure cannot be called graceful.
Can a java.util.X be declared as @typesafe? If so, how? Is any of this
documented anywhere?
-W
Davide
On 06/10/2014 01:26 PM, Wolfgang Laun wrote:
Consider:
class Foo { /*...*/ }
rule checkFoo
when
Foo( noSuchField 0 )
then ... end
DRL compilation reports an error (Error: unable to resolve method ...)
and identifies rule, line and column, which is fine.
Now let's look at:
import java.util.ArrayList;
rule checkArrayList
when
ArrayList( noSuchField 0 )
then ... end
The same DRL compiler (checked with 5.5.0 and 6.0.0) accepts this, and
there is a nasty exception thrown at runtime. This is inconvenient,
since the exception can be thrown by any code inserting an ArrayList
object, and the faulty rule isn't identified.
Why are certain classes second-rate?
-W
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
.
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Are there second-rate fact types?
The primary concern is not so much type safety but the absence of
the check of the name being defined as a getter or class member.
Also, (if I understand the poster correctly) in 5.0.0 the DRL compiler
was able to flag a non-existent member in ArrayList. Three cheers to
not breaking backwards compatability.
Note that even when you abstain from inserting collections as
first-order facts, you'll still need them, e.g., for a from collect.
-W
On 10/06/2014, Mark Proctor mproc...@codehaus.org wrote:
The feature was more important when we didn't allow casting, but people
still wanted to work with Maps and Lists.
Map( this[key].age 30)
Collections where defaulted to typefalse(false)
Now that we support inline casts, it can be argued that things should always
be type safe:
Map( this[key]#Person.age 30 )
It's hard to change this now, without breaking backwards compatability.
The docs don't say that it's defaulted to false for collections, only that
it's useful for Collections. Someone want to submit a pull request fix for
this?
4.7.2.1.2. @typesafe( boolean )
By default all type declarations are compiled with type safety enabled;
@typesafe( false ) provides a means to override this behaviour by permitting
a fall-back, to type unsafe evaluation where all constraints are generated
as MVEL constraints and executed dynamically. This can be important when
dealing with collections that do not have any generics or mixed type
collections.
4.7.5. Non Typesafe Classes
@typesafe( boolean) has been added to type declarations. By default all
type declarations are compiled with type safety enabled; @typesafe( false )
provides a means to override this behaviour by permitting a fall-back, to
type unsafe evaluation where all constraints are generated as MVEL
constraints and executed dynamically. This can be important when dealing
with collections that do not have any generics or mixed type collections.
Mark
On 10 Jun 2014, at 13:45, Davide Sottara dso...@gmail.com wrote:
java.util.Collections (and descendants) are not @typesafe by default,
I'll check the reason for that.
More generally, if a fact is declared as not @typesafe, the runtime
failure should be more graceful.
Davide
On 06/10/2014 01:26 PM, Wolfgang Laun wrote:
Consider:
class Foo { /*...*/ }
rule checkFoo
when
Foo( noSuchField 0 )
then ... end
DRL compilation reports an error (Error: unable to resolve method ...)
and identifies rule, line and column, which is fine.
Now let's look at:
import java.util.ArrayList;
rule checkArrayList
when
ArrayList( noSuchField 0 )
then ... end
The same DRL compiler (checked with 5.5.0 and 6.0.0) accepts this, and
there is a nasty exception thrown at runtime. This is inconvenient,
since the exception can be thrown by any code inserting an ArrayList
object, and the faulty rule isn't identified.
Why are certain classes second-rate?
-W
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Are there second-rate fact types?
But you can do
declare ArrayList
@typesafe( true )
end
which fixes the problem, if not by default :-)
Note that the subsection 4.7.2.1.2 explains things from an
implementer's point of view, which is pretty much useless, and the
wording is rather obscure.
-W
On 10/06/2014, Wolfgang Laun wolfgang.l...@gmail.com wrote:
The primary concern is not so much type safety but the absence of
the check of the name being defined as a getter or class member.
Also, (if I understand the poster correctly) in 5.0.0 the DRL compiler
was able to flag a non-existent member in ArrayList. Three cheers to
not breaking backwards compatability.
Note that even when you abstain from inserting collections as
first-order facts, you'll still need them, e.g., for a from collect.
-W
On 10/06/2014, Mark Proctor mproc...@codehaus.org wrote:
The feature was more important when we didn't allow casting, but people
still wanted to work with Maps and Lists.
Map( this[key].age 30)
Collections where defaulted to typefalse(false)
Now that we support inline casts, it can be argued that things should
always
be type safe:
Map( this[key]#Person.age 30 )
It's hard to change this now, without breaking backwards compatability.
The docs don't say that it's defaulted to false for collections, only
that
it's useful for Collections. Someone want to submit a pull request fix
for
this?
4.7.2.1.2. @typesafe( boolean )
By default all type declarations are compiled with type safety enabled;
@typesafe( false ) provides a means to override this behaviour by
permitting
a fall-back, to type unsafe evaluation where all constraints are
generated
as MVEL constraints and executed dynamically. This can be important when
dealing with collections that do not have any generics or mixed type
collections.
4.7.5. Non Typesafe Classes
@typesafe( boolean) has been added to type declarations. By default all
type declarations are compiled with type safety enabled; @typesafe( false
)
provides a means to override this behaviour by permitting a fall-back, to
type unsafe evaluation where all constraints are generated as MVEL
constraints and executed dynamically. This can be important when dealing
with collections that do not have any generics or mixed type collections.
Mark
On 10 Jun 2014, at 13:45, Davide Sottara dso...@gmail.com wrote:
java.util.Collections (and descendants) are not @typesafe by default,
I'll check the reason for that.
More generally, if a fact is declared as not @typesafe, the runtime
failure should be more graceful.
Davide
On 06/10/2014 01:26 PM, Wolfgang Laun wrote:
Consider:
class Foo { /*...*/ }
rule checkFoo
when
Foo( noSuchField 0 )
then ... end
DRL compilation reports an error (Error: unable to resolve method ...)
and identifies rule, line and column, which is fine.
Now let's look at:
import java.util.ArrayList;
rule checkArrayList
when
ArrayList( noSuchField 0 )
then ... end
The same DRL compiler (checked with 5.5.0 and 6.0.0) accepts this, and
there is a nasty exception thrown at runtime. This is inconvenient,
since the exception can be thrown by any code inserting an ArrayList
object, and the faulty rule isn't identified.
Why are certain classes second-rate?
-W
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
___
rules-users mailing list
rules-users@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] NullPointerException at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion
I already tried with a KnowledgeBase as your link suggest and it works well. But as the KnowledgeBase is deprecated, I would like to use the new way implemented in Drools 6. I'm still searching and if I can't find anything, I will submit this issue to Jira. Thanks -- View this message in context: http://drools.46999.n3.nabble.com/NullPointerException-at-org-drools-compiler-kie-builder-impl-KieContainerImpl-updateToVersion-tp4029894p4029954.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] Memory leak when deploying to Maven repository?
Hi Dominik, I'm honestly not understanding why you're creating a kieModule and most important why you're deploying it on maven in a ServletContextListener, but I am guessing you're doing this only to demonstrate the problem. Also be aware that for doing so you're using some drools internal API and these API aren't guaranteed to be stable. However every time you build a kieModule or you load it from a maven repo, it is stored in the KieRepository. If you need to remove it from there you can do this explicitly by using the KieRepository.removeKieModule(ReleaseId) method. I hope this helps, Mario -- View this message in context: http://drools.46999.n3.nabble.com/rules-users-Memory-leak-when-deploying-to-Maven-repository-tp4029950p4029955.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
Re: [rules-users] NullPointerException at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion
I am doing something similar, and other than a memory leak (which I
have managed to track down and submit a patch for) it works pretty
well...
Try this... (Note that it would possibly be better to build a new
ReleaseId every time, but more complicated)
It has some code to clean up in case of errors, which seemed to be necessary.
private static final String DRL_PATH_PREFIX = src/main/resources;
private KieServices ks = null;
private KieFileSystem kfs = null;
private KieContainer kc = null;
private KieBuilder kb = null;
private ReleaseId snashotReleaseId = null;
public boolean initRules(String commonDrl) {
ks = KieServices.Factory.get();
kfs = ks.newKieFileSystem();
kb = ks.newKieBuilder(kfs).buildAll();
snapshotReleaseId = ks.getRepository().getDefaultReleasId();
// This is a snapshot release id, so it is ok if it stays the same
kfs.generateAndWritePomXML(snapshotReleaseId);
kfs.write(String.format(%s/common.drl, DRL_PATH_PREFIX), commonDrl);
kb.buildAll();
kc = ks.newKieContainer(snapshotReleaseId);
if ( kb.getResults().hasMessages(
org.kie.api.builder.Message.Level.ERROR )) {
for( org.kie.api.builder.Message result :
kb.getResults().getMessages() ) {
System.err.println(DRL error + message.getText() +
in path: + message.getPath() + on line: + message.getLine() +
column: + message.getColumn());
}
return false;
}
}
private String getRulePath(String uniqueRuleId) {
return String.format(%s/rule_%s.drl, DRL_PATH_PREFIX, uniqueRuleId);
}
private java.util.ListString buildIncremental(String path) {
java.util.SetString paths = new java.util.HashSetString();
paths.add(path);
return buildIncremental(paths, true);
}
private java.util.SetString
buildIncremental(java.util.CollectionString paths, boolean finish) {
String[] pathsArray = paths.toArray(new String[0]);
java.util.SetString failedPaths = new java.util.HashSetString();
IncrementalResults results =
((InternalKieBuilder)kBuilder).createFileSet(pathsArray).build();
ListMessage addedMessages = results.getAddedMessages();
for (Message message : addedMessages) {
if (Message.Level.ERROR == message.getLevel()) {
System.err.println(DRL error + message.getText() +
adding path: + message.getPath() + on line: +
message.getLine() + column: + message.getColumn());
String failedPath = message.getPath();
if (!failedPath.startsWith(DRL_PATH_PREFIX)) {
failedPath = String.format(%s/%s,
DRL_PATH_PREFIX, failedPath);
}
failedPaths.add(failedPath);
if (finish) {
kfs.delete(failedPath);
}
}
}
if (finish !failedPaths.isEmpty()) {
buildIncremental(paths, false);
}
ListMessage removedMessages = results.getRemovedMessages();
for (Message message : removedMessages) {
if (Message.Level.ERROR == message.getLevel()) {
System.err.println(DRL error + message.getText() +
removing path: + message.getPath() + on line: +
message.getLine() + column: + message.getColumn());
String failedPath = message.getPath();
if (!failedPath.startsWith(DRL_PATH_PREFIX)) {
failedPath = String.format(%s/%s,
DRL_PATH_PREFIX, failedPath);
}
failedPaths.add(failedPath);
}
}
if (finish) {
kc.updateToVersion(snapshotReleaseId);
}
return failedPaths;
}
public boolean removeRule(String uniqueRuleId) {
String rulePath = getRulePath(uniqueRuleId);
kfs.delete(rulePath);
return buildIncremental(rulePath).isEmpty();
}
public boolean addRule(String uniqueRuleId, String rule){
if (ks == null) {
initRules();
}
String rulePath = getRulePath(uniqueRuleId);
kfs.write(rulePath, rule);
return buildIncremental(rulePath).isEmpty();
}
On Fri, Jun 6, 2014 at 4:12 AM, tia rabarijaonadomo...@gmail.com wrote:
Hello,
I'm trying to add a new rule on the fly like here:
https://github.com/droolsjbpm/drools/blob/master/drools-compiler/src/test/java/org/drools/compiler/integrationtests/IncrementalCompilationTest.java#L158
Here is the method to add a rule, once the KieSession is created and
configured:
public void addRule(String rule){
KieServices ks= KieServices.Factory.get();
ReleaseId rid= ks.newReleaseId(org.kie, businessrules,
1.0);
KieFileSystem kfs = ks.newKieFileSystem();
kfs.generateAndWritePomXML(rid);
kfs.write(src/main/resources/rule.drl,rule);
KieBuilder kb
[rules-users] Kie-wb eclipse integration
So I have cretaed a process with kie-wb but how can I edit this process in eclipse please and then upload this process back into kie-wb? -- View this message in context: http://drools.46999.n3.nabble.com/Kie-wb-eclipse-integration-tp4029957.html Sent from the Drools: User forum mailing list archive at Nabble.com. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Drools-PermissionDeniedException
Hi All , Does any one have idea on this below error ? org.drools.task.service.PermissionDeniedException: User '[User:'XYZ']' was unable to execution operation 'Complete' on task id 3394226 due to no 'current status' matchines we are facing this un-known exception and it is impacting our work very badly :( . Please give me some idea to resolve this error . ---Regards,Sravan. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] Can't clone repository NoSuchElementException
Hello, I have Drools 6.0.1 installed on RedHat Linux 5 and running under JBoss EAP 6.1.1. I would like to clone from a local git server running on the same server. But when I do so, I get a Can't clone repository. java.util.NoSuchElementException message in the browser. There are no errors in the server.log Why doesn't this work? Here's how I'm running the git daemon: $ git daemon --verbose --export-all --port=9419 --base-path=/home/brms/git/ URL I enter into the Clone Repository dialog: git://localhost:9419/test.git This is how I setup my repo: $ cd /home/brms/git/ $ mkdir test.git $ cd test.git/ $ git init --bare Initialized empty Git repository in /home/brms/git/test.git/ Thanks, Clint The contents contained herein may contain confidential information. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, printing or action taken on the contents is strictly prohibited. If you have received this email in error, please notify the sender immediately and delete this message. ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
[rules-users] drools leaving a backgroud thread
Hi, I have a Java servlet running on Tomcat7 which runs multiple drools knowledge bases with a session associated to each one. I am using drools version 6.1.0.Beta3 When tomcat shuts-down I am seeing this message in the log: Jun 10, 2014 6:39:36 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks SEVERE: The web application [/MyRulesServlet-1.0-SNAPSHOT] created a ThreadLocal with key of type [org.drools.core.common.UpgradableReentrantReadWriteLock$1] (value [org.drools.core.common.UpgradableReentrantReadWriteLock$1@5c0bf171mailto:1@5c0bf171]) and a value of type [org.drools.core.common.UpgradableReentrantReadWriteLock.LockRequestCounter] (value [org.drools.core.common.UpgradableReentrantReadWriteLock$LockRequestCounter@141860edmailto:LockRequestCounter@141860ed]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. It seems I am not performing a proper cleanup of resources on shutdown. I am calling kSession.dispose() for all the sessions I have, but apparently this is not enough. What else do I need to do to get rid of this background thread? Thanks, Aliza ___ rules-users mailing list rules-users@lists.jboss.org https://lists.jboss.org/mailman/listinfo/rules-users
