[JBoss JIRA] (DROOLS-982) DRL file with a rule having long LHS expression takes very long time to parse
by Soumitra Kumar (JIRA)
[ https://issues.jboss.org/browse/DROOLS-982?page=com.atlassian.jira.plugin... ]
Soumitra Kumar commented on DROOLS-982:
---------------------------------------
This issue is reproducible with following testcase:
In DrlExprParserTest.java
public void testDrools982() throws Exception {
String source = "((((((((((((((((((((((((( a > 0 )))))))))))))))))))))))))";
ConstraintConnectiveDescr result = parser.parse( source );
assertFalse( parser.getErrors().toString(),
parser.hasErrors() );
}
> DRL file with a rule having long LHS expression takes very long time to parse
> -----------------------------------------------------------------------------
>
> Key: DROOLS-982
> URL: https://issues.jboss.org/browse/DROOLS-982
> Project: Drools
> Issue Type: Enhancement
> Reporter: Soumitra Kumar
> Assignee: Mark Proctor
>
> My DRL file is:
> package sk.rule.ruleset.r1;
> import sk.event.Event;
> // Event declaration
> declare Event
> @role(event)
> @timestamp(time)
> end
> rule "Long LHS"
> when
> $event : Event ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( (contains ("name", "foo") && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) )
> then
> // Empty
> end
> // Event definition
> package sk.event
> sealed case class Event (time: Long, map: Map [String, String]) {
> def contains (key: String, value: String): Boolean = false
> }
> // Main class
> package sk.apps
> import java.io.File
> import com.typesafe.scalalogging.LazyLogging
> import org.kie.api.io.ResourceType
> import org.kie.internal.io.ResourceFactory
> import org.kie.internal.builder.KnowledgeBuilderFactory
> object DrlParsing extends LazyLogging {
> def main (args: Array [String]): Unit = {
> logger.info (s"Starting KnowledgeBuilder")
> val kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder ()
> args.foreach { fileName =>
> logger.info (s"Adding file $fileName")
> kbuilder.add (ResourceFactory.newFileResource (new File (fileName)), ResourceType.DRL)
> }
> if (kbuilder.hasErrors ())
> logger.error (kbuilder.getErrors ().toString ())
> }
> }
> The project URL is https://github.com/soumitrak/drl-parsing
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (DROOLS-982) DRL file with a rule having long LHS expression takes very long time to parse
by Soumitra Kumar (JIRA)
Soumitra Kumar created DROOLS-982:
-------------------------------------
Summary: DRL file with a rule having long LHS expression takes very long time to parse
Key: DROOLS-982
URL: https://issues.jboss.org/browse/DROOLS-982
Project: Drools
Issue Type: Enhancement
Reporter: Soumitra Kumar
Assignee: Mark Proctor
My DRL file is:
package sk.rule.ruleset.r1;
import sk.event.Event;
// Event declaration
declare Event
@role(event)
@timestamp(time)
end
rule "Long LHS"
when
$event : Event ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( ( (contains ("name", "foo") && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) && contains ("name", "foo")) )
then
// Empty
end
// Event definition
package sk.event
sealed case class Event (time: Long, map: Map [String, String]) {
def contains (key: String, value: String): Boolean = false
}
// Main class
package sk.apps
import java.io.File
import com.typesafe.scalalogging.LazyLogging
import org.kie.api.io.ResourceType
import org.kie.internal.io.ResourceFactory
import org.kie.internal.builder.KnowledgeBuilderFactory
object DrlParsing extends LazyLogging {
def main (args: Array [String]): Unit = {
logger.info (s"Starting KnowledgeBuilder")
val kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder ()
args.foreach { fileName =>
logger.info (s"Adding file $fileName")
kbuilder.add (ResourceFactory.newFileResource (new File (fileName)), ResourceType.DRL)
}
if (kbuilder.hasErrors ())
logger.error (kbuilder.getErrors ().toString ())
}
}
The project URL is https://github.com/soumitrak/drl-parsing
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (JGRP-1979) org.jgroups.blocks.Cache.get() method always evicts values because it does not check Value.insertion_time
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1979?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1979:
--------------------------------
Hi Ben,
thanks for the fix and unit test; I applied them.
> org.jgroups.blocks.Cache.get() method always evicts values because it does not check Value.insertion_time
> ---------------------------------------------------------------------------------------------------------
>
> Key: JGRP-1979
> URL: https://issues.jboss.org/browse/JGRP-1979
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.1, 3.6.6
> Environment: Windows 10 64-bit
> Reporter: Ben Johnson
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.7
>
> Attachments: Cache.java, CacheTest.java
>
>
> org.jgroups.blocks.Cache.get(String key) always evicts the matching entry and returns a value of null. It is doing this because the method is comparing the Value timeout property against the current system time without using the Value's insertion_time (unlike the evict() method, which does).
> I have created a simple unit test to illustrate this and provided a fix (from the 3.6.1.Final code base, which doesn't include the diamond operator updates). I added a couple of helper methods isExpired(Value val) and getValue(Value val)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (JGRP-1979) org.jgroups.blocks.Cache.get() method always evicts values because it does not check Value.insertion_time
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1979?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1979.
----------------------------
Resolution: Done
> org.jgroups.blocks.Cache.get() method always evicts values because it does not check Value.insertion_time
> ---------------------------------------------------------------------------------------------------------
>
> Key: JGRP-1979
> URL: https://issues.jboss.org/browse/JGRP-1979
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.1, 3.6.6
> Environment: Windows 10 64-bit
> Reporter: Ben Johnson
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.7
>
> Attachments: Cache.java, CacheTest.java
>
>
> org.jgroups.blocks.Cache.get(String key) always evicts the matching entry and returns a value of null. It is doing this because the method is comparing the Value timeout property against the current system time without using the Value's insertion_time (unlike the evict() method, which does).
> I have created a simple unit test to illustrate this and provided a fix (from the 3.6.1.Final code base, which doesn't include the diamond operator updates). I added a couple of helper methods isExpired(Value val) and getValue(Value val)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (JGRP-1979) org.jgroups.blocks.Cache.get() method always evicts values because it does not check Value.insertion_time
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1979?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1979:
---------------------------
Fix Version/s: 3.6.7
> org.jgroups.blocks.Cache.get() method always evicts values because it does not check Value.insertion_time
> ---------------------------------------------------------------------------------------------------------
>
> Key: JGRP-1979
> URL: https://issues.jboss.org/browse/JGRP-1979
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.6.1, 3.6.6
> Environment: Windows 10 64-bit
> Reporter: Ben Johnson
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.7
>
> Attachments: Cache.java, CacheTest.java
>
>
> org.jgroups.blocks.Cache.get(String key) always evicts the matching entry and returns a value of null. It is doing this because the method is comparing the Value timeout property against the current system time without using the Value's insertion_time (unlike the evict() method, which does).
> I have created a simple unit test to illustrate this and provided a fix (from the 3.6.1.Final code base, which doesn't include the diamond operator updates). I added a couple of helper methods isExpired(Value val) and getValue(Value val)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (JGRP-1979) org.jgroups.blocks.Cache.get() method always evicts values because it does not check Value.insertion_time
by Ben Johnson (JIRA)
Ben Johnson created JGRP-1979:
---------------------------------
Summary: org.jgroups.blocks.Cache.get() method always evicts values because it does not check Value.insertion_time
Key: JGRP-1979
URL: https://issues.jboss.org/browse/JGRP-1979
Project: JGroups
Issue Type: Bug
Affects Versions: 3.6.6, 3.6.1
Environment: Windows 10 64-bit
Reporter: Ben Johnson
Assignee: Bela Ban
Priority: Minor
Attachments: Cache.java, CacheTest.java
org.jgroups.blocks.Cache.get(String key) always evicts the matching entry and returns a value of null. It is doing this because the method is comparing the Value timeout property against the current system time without using the Value's insertion_time (unlike the evict() method, which does).
I have created a simple unit test to illustrate this and provided a fix (from the 3.6.1.Final code base, which doesn't include the diamond operator updates). I added a couple of helper methods isExpired(Value val) and getValue(Value val)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5681) start process of WildFly-8.2.0-Final never finish (Starting, Synchronized)
by carl zhang (JIRA)
carl zhang created WFLY-5681:
--------------------------------
Summary: start process of WildFly-8.2.0-Final never finish (Starting, Synchronized)
Key: WFLY-5681
URL: https://issues.jboss.org/browse/WFLY-5681
Project: WildFly
Issue Type: Bug
Components: IDE
Affects Versions: 8.2.0.Final
Environment: start process of WildFly-8.2.0-Final never finish (Starting, Synchronized)
Reporter: carl zhang
Assignee: Jason Greene
please refer to
https://developer.jboss.org/thread/265726?start=0&tstart=0
refer to the picture of 28-Oct-2015 9:46 AM (layer 3)
In the left panel: WildFly 8.x is configured to connect to localhost
WildFly 8.x(1) is configured to connect to remote host (Linux)
The localhost cannot finish start process. WildFly 8.x(1) (remote) can.
What ports, or temp files, or anything else are checked when changing from starting to started state?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5679) Classloading issue when running test by using both wildfly-arquillian-container-managed and jboss-as-arquillian-container-managed at the same time
by Matous Jobanek (JIRA)
[ https://issues.jboss.org/browse/WFLY-5679?page=com.atlassian.jira.plugin.... ]
Matous Jobanek updated WFLY-5679:
---------------------------------
Summary: Classloading issue when running test by using both wildfly-arquillian-container-managed and jboss-as-arquillian-container-managed at the same time (was: Classloading issue when running test by using both wildfly-arquillian-container-managed and jboss-as-arquillian-container-managed together)
> Classloading issue when running test by using both wildfly-arquillian-container-managed and jboss-as-arquillian-container-managed at the same time
> --------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5679
> URL: https://issues.jboss.org/browse/WFLY-5679
> Project: WildFly
> Issue Type: Bug
> Reporter: Matous Jobanek
> Assignee: Jason Greene
> Labels: arquillian
>
> When there is a test starting both containers WF9 and JBoss AS 7 (eg. for migration verification) the deployment and stopping of the containers don't behave correctly. To start both of the containers I need relevant container adapters:
> - {{org.jboss.as:jboss-as-arquillian-container-managed}}
> - {{org.wildfly.arquillian:wildfly-arquillian-container-managed (or org.wildfly:wildfly-arquillian-container-managed for WF8)}}
> however, in the case of the WF's adapter the packages haven't been renamed (when there was the migration from the JBoss AS to WF, even though the maven artifact had been renamed).
> The situation of using both of the artifacts leads to the situation that there are two Java classes with the very same name (eg. {{org.jboss.as.arquillian.container.managed.ManagedContainerExtension}}) and only one of them is used - the one that belongs to the artifact used as the first one there in the pom.xml file.
> So, currently there is no easy way how to run two or more containers in a combination of WF8+ and JBoss AS 7 (and older).
> This leads me to the main question - why the packages haven't been renamed after the migration to org.wildfly(.arquillian) ? Current situation is quite confusing and in some cases problematic.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5679) Classloading issue when running test by using both wildfly-arquillian-container-managed and jboss-as-arquillian-container-managed together
by Matous Jobanek (JIRA)
[ https://issues.jboss.org/browse/WFLY-5679?page=com.atlassian.jira.plugin.... ]
Matous Jobanek commented on WFLY-5679:
--------------------------------------
Hi [~ctomc],
yes that's right, but this works only in the case you use the containers separately. I want both of them to be running at the same time - like multiple containers testing https://docs.jboss.org/author/display/ARQ/Multiple+Containers
> Classloading issue when running test by using both wildfly-arquillian-container-managed and jboss-as-arquillian-container-managed together
> ------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5679
> URL: https://issues.jboss.org/browse/WFLY-5679
> Project: WildFly
> Issue Type: Bug
> Reporter: Matous Jobanek
> Assignee: Jason Greene
> Labels: arquillian
>
> When there is a test starting both containers WF9 and JBoss AS 7 (eg. for migration verification) the deployment and stopping of the containers don't behave correctly. To start both of the containers I need relevant container adapters:
> - {{org.jboss.as:jboss-as-arquillian-container-managed}}
> - {{org.wildfly.arquillian:wildfly-arquillian-container-managed (or org.wildfly:wildfly-arquillian-container-managed for WF8)}}
> however, in the case of the WF's adapter the packages haven't been renamed (when there was the migration from the JBoss AS to WF, even though the maven artifact had been renamed).
> The situation of using both of the artifacts leads to the situation that there are two Java classes with the very same name (eg. {{org.jboss.as.arquillian.container.managed.ManagedContainerExtension}}) and only one of them is used - the one that belongs to the artifact used as the first one there in the pom.xml file.
> So, currently there is no easy way how to run two or more containers in a combination of WF8+ and JBoss AS 7 (and older).
> This leads me to the main question - why the packages haven't been renamed after the migration to org.wildfly(.arquillian) ? Current situation is quite confusing and in some cases problematic.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5679) Classloading issue when running test by using both wildfly-arquillian-container-managed and jboss-as-arquillian-container-managed together
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5679?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-5679:
-----------------------------------
For testing with multiple containers you should setup different maven profiles which each has deps only for that profile (app server)
that is common practice when testing with arquillian.
> Classloading issue when running test by using both wildfly-arquillian-container-managed and jboss-as-arquillian-container-managed together
> ------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5679
> URL: https://issues.jboss.org/browse/WFLY-5679
> Project: WildFly
> Issue Type: Bug
> Reporter: Matous Jobanek
> Assignee: Jason Greene
> Labels: arquillian
>
> When there is a test starting both containers WF9 and JBoss AS 7 (eg. for migration verification) the deployment and stopping of the containers don't behave correctly. To start both of the containers I need relevant container adapters:
> - {{org.jboss.as:jboss-as-arquillian-container-managed}}
> - {{org.wildfly.arquillian:wildfly-arquillian-container-managed (or org.wildfly:wildfly-arquillian-container-managed for WF8)}}
> however, in the case of the WF's adapter the packages haven't been renamed (when there was the migration from the JBoss AS to WF, even though the maven artifact had been renamed).
> The situation of using both of the artifacts leads to the situation that there are two Java classes with the very same name (eg. {{org.jboss.as.arquillian.container.managed.ManagedContainerExtension}}) and only one of them is used - the one that belongs to the artifact used as the first one there in the pom.xml file.
> So, currently there is no easy way how to run two or more containers in a combination of WF8+ and JBoss AS 7 (and older).
> This leads me to the main question - why the packages haven't been renamed after the migration to org.wildfly(.arquillian) ? Current situation is quite confusing and in some cases problematic.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months