[JBoss JIRA] (WFLY-6731) Problem with cluster, org.wildfly.clustering.web.undertow.session.DistributableSession
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6731?page=com.atlassian.jira.plugin.... ]
Paul Ferraro edited comment on WFLY-6731 at 8/1/16 6:20 AM:
------------------------------------------------------------
[~bcampolina] Can you attach the infinispan configuration being used for your web sessions? The assumption being made by the code is that, since your cache is transactional, a plain HashMap can be used to stored sessions (as opposed to a ConcurrentHashMap), since session attribute iteration is always performed under lock.
was (Author: pferraro):
[~bcampolina] Can you attach the infinispan configuration being used for your web sessions? The assumption being made by the code is that your cache is transactional, thus a plain HashMap is used to stored sessions (as opposed to a ConcurrentHashMap), since session attribute iteration is always performed under lock.
> Problem with cluster, org.wildfly.clustering.web.undertow.session.DistributableSession
> --------------------------------------------------------------------------------------
>
> Key: WFLY-6731
> URL: https://issues.jboss.org/browse/WFLY-6731
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Bruno Silva
> Assignee: Paul Ferraro
>
> {noformat}
> ay0uwkDSnTKoZNLMN9atwQhHB4KiZ url:/autenticacaosso/login.jsf;jsessionid=vrQfTnf0X0ZbbWAOEHUd-BXtb8Oa1TsfMjfqhh1C.node3
> 2016-04-08 08:41:14,766 ERROR [io.undertow.request] (default task-137) UT005023: Exception handling request to /autenticacaosso/login: java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429)
> at java.util.HashMap$KeyIterator.next(HashMap.java:1453)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.changeSessionId(DistributableSession.java:197)
> at io.undertow.servlet.spec.HttpServletRequestImpl.changeSessionId(HttpServletRequestImpl.java:329)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler$SecurityNotificationReceiver.handleNotification(CachedAuthenticatedSessionHandler.java:95)
> at io.undertow.security.impl.AbstractSecurityContext.sendNoticiation(AbstractSecurityContext.java:127)
> at io.undertow.security.impl.AbstractSecurityContext.authenticationComplete(AbstractSecurityContext.java:85)
> at io.undertow.security.impl.AbstractSecurityContext.authenticationComplete(AbstractSecurityContext.java:78)
> at io.undertow.security.impl.SingleSignOnAuthenticationMechanism.authenticate(SingleSignOnAuthenticationMechanism.java:103)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:257)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$2(SecurityContextImpl.java:231)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:123)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:98)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:91)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFLY-6731) Problem with cluster, org.wildfly.clustering.web.undertow.session.DistributableSession
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6731?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-6731:
------------------------------------
[~bcampolina] Can you attach the infinispan configuration being used for your web sessions? The assumption being made by the code is that your cache is transactional, thus a plain HashMap is used to stored sessions (as opposed to a ConcurrentHashMap), since session attribute iteration is always performed under lock.
> Problem with cluster, org.wildfly.clustering.web.undertow.session.DistributableSession
> --------------------------------------------------------------------------------------
>
> Key: WFLY-6731
> URL: https://issues.jboss.org/browse/WFLY-6731
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Bruno Silva
> Assignee: Paul Ferraro
>
> {noformat}
> ay0uwkDSnTKoZNLMN9atwQhHB4KiZ url:/autenticacaosso/login.jsf;jsessionid=vrQfTnf0X0ZbbWAOEHUd-BXtb8Oa1TsfMjfqhh1C.node3
> 2016-04-08 08:41:14,766 ERROR [io.undertow.request] (default task-137) UT005023: Exception handling request to /autenticacaosso/login: java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1429)
> at java.util.HashMap$KeyIterator.next(HashMap.java:1453)
> at org.wildfly.clustering.web.undertow.session.DistributableSession.changeSessionId(DistributableSession.java:197)
> at io.undertow.servlet.spec.HttpServletRequestImpl.changeSessionId(HttpServletRequestImpl.java:329)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler$SecurityNotificationReceiver.handleNotification(CachedAuthenticatedSessionHandler.java:95)
> at io.undertow.security.impl.AbstractSecurityContext.sendNoticiation(AbstractSecurityContext.java:127)
> at io.undertow.security.impl.AbstractSecurityContext.authenticationComplete(AbstractSecurityContext.java:85)
> at io.undertow.security.impl.AbstractSecurityContext.authenticationComplete(AbstractSecurityContext.java:78)
> at io.undertow.security.impl.SingleSignOnAuthenticationMechanism.authenticate(SingleSignOnAuthenticationMechanism.java:103)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:257)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$2(SecurityContextImpl.java:231)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:123)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:98)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:91)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:51)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:56)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:174)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFCORE-1680) Tab completion for echo-dmr command is broken
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1680?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise commented on WFCORE-1680:
----------------------------------------------
This is caused by WFCORE-1627. The cursor value is now used to extract the piece of line to complete. Some completers (such as EchoDMR one) provides 0 for the cursor value although buffer.length should be passed. I suspect that some other completers are affected. I will have to check the various calls to completers.
> Tab completion for echo-dmr command is broken
> ---------------------------------------------
>
> Key: WFCORE-1680
> URL: https://issues.jboss.org/browse/WFCORE-1680
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Jean-Francois Denise
>
> Tab completion for echo-dmr command doesn't work.
> To reproduce, start the standalone server and connect with CLI
> *actual 3.0.0.Alpha5-SNAPSHOT 77673c5*
> {noformat}
> [standalone@localhost:9990 /] echo-dmr /sub[TAB]
> core-service deployment deployment-overlay extension interface path socket-binding-group subsystem system-property
> [standalone@localhost:9990 /] echo-dmr /subsystem=log[TAB]
> core-service deployment deployment-overlay extension interface path socket-binding-group subsystem system-property
> {noformat}
> *expected*
> {noformat}
> [standalone@localhost:9990 /] echo-dmr /sub[TAB]
> [standalone@localhost:9990 /] echo-dmr /subsystem=
> [standalone@localhost:9990 /] echo-dmr /subsystem=log[TAB]
> [standalone@localhost:9990 /] echo-dmr /subsystem=logging
> {noformat}
> The issue is not reproducible with 2.2.0.CR7 (EAP 7.1.0.DR1).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (DROOLS-1150) Problems found by FindBugs in drools-core
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1150?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1150:
-------------------------------------
Infinite recursions and other minor issues fixed by this commit https://github.com/droolsjbpm/drools/commit/a493b58a889cb71258d664dac0112...
I'm leaving this ticket open since there are other FindBugs reports that deserves to be investigated.
> Problems found by FindBugs in drools-core
> -----------------------------------------
>
> Key: DROOLS-1150
> URL: https://issues.jboss.org/browse/DROOLS-1150
> Project: Drools
> Issue Type: Bug
> Affects Versions: 7.0.0.Final
> Reporter: Tibor Zimányi
> Assignee: Mario Fusco
> Attachments: findBugsDroolsCore.ods, FindBugsResult_4_29_16-drools-core.html
>
>
> I ran FindBugs analysis on drools-core module on master. There is 880 warnings in the report. So a pretty decent number. I picked some for start. See attachments. Also we should focus on concurrency warnings. You can find them in the report under "Multithreaded correctness Warnings" section.
> For better description of the warnings, you can install FindBugs-IDEA plugin and run the analysis in IDE. Each warning has some short description, sometimes with a link pointing to an article or more detailed info about the problem.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (DROOLS-1130) Using fireAllRules, Timed rules does not cascade rule execution after modifying a fact, event when Session conf is set to TimedRuleExectionOption.YES
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1130?page=com.atlassian.jira.plugi... ]
Mario Fusco commented on DROOLS-1130:
-------------------------------------
Reproduced with the following test case
{code}
@Test(timeout=10000)
public void testCascadingTimedRule() throws Exception {
String drl =
"package org.simple \n" +
"import " + AtomicInteger.class.getCanonicalName() + "\n" +
"rule R1 \n" +
" timer (int:30s) " +
"when \n" +
" $i : AtomicInteger(get() == 1)" +
"then \n" +
" modify($i) { set(2) }; \n" +
"end \n" +
"rule R2 \n" +
"when \n" +
" $i : AtomicInteger(get() == 2)" +
"then \n" +
" modify($i) { set(3) }; \n" +
"end \n";
KieSessionConfiguration conf = KnowledgeBaseFactory.newKnowledgeSessionConfiguration();
conf.setOption( ClockTypeOption.get( "pseudo" ) );
conf.setOption( TimedRuleExectionOption.YES );
KieSession ksession = new KieHelper().addContent( drl, ResourceType.DRL )
.build()
.newKieSession( conf, null );
PseudoClockScheduler timeService = ( PseudoClockScheduler ) ksession.<SessionClock>getSessionClock();
timeService.advanceTime( new Date().getTime(), TimeUnit.MILLISECONDS );
AtomicInteger i = new AtomicInteger( 1 );
ksession.insert( i );
ksession.fireAllRules();
timeService.advanceTime( 35, TimeUnit.SECONDS );
assertEquals(3, i.get());
}
{code}
> Using fireAllRules, Timed rules does not cascade rule execution after modifying a fact, event when Session conf is set to TimedRuleExectionOption.YES
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1130
> URL: https://issues.jboss.org/browse/DROOLS-1130
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.3.0.Final
> Reporter: Juan Carlos Garcia
> Assignee: Mario Fusco
> Attachments: timer-rule-bug.zip
>
>
> I have a DRL file with 2 rules and the first rule has a timer of 3s, after this rule gets fired and a fact is modified, i expect a second rule to get activate and trigger but is not happening. Even though the documentation explicitly said in the 2.9.2 section of:
> http://docs.jboss.org/drools/release/6.3.0.Final/drools-docs/html/ch02.ht...
> _When the rule engine runs in passive mode (i.e.: using fireAllRules) by default it doesn't fire consequences of timed rules unless fireAllRules isn't invoked again. Now it is possible to change this default behavior by configuring the KieSession with a *TimedRuleExectionOption*_
> Please advise if i have misunderstood the expected behavior, attached is a demo project enclosing the mentioned rules and a testcase.
> *DRL:*
> {code}
> import java.util.logging.Logger
> import bug.timedrules.Table
> rule "table with 1 player"
> timer( int: 3s)
> no-loop true
> when
> $table : Table( getCounter() == 1)
> then
> Logger.getLogger("timer.drl").info("triggered - counter is 1");
> modify($table){
> setCounter(2)
> }
> end
> rule "Table upgrade to 2 player"
> no-loop true
> when
> $table : Table( getCounter() == 2)
> then
> Logger.getLogger("timer.drl").info("triggered - counter is 2");
> modify($table){
> setCounter(3)
> }
> end
> {code}
> *java code:*
> {code}
> @Test
> public void executeNewRuleAfterTimedRuleExecution() throws Exception {
> KieBaseConfiguration config = KnowledgeBaseFactory.newKnowledgeBaseConfiguration();
> KieSessionConfiguration ksconf = KieServices.Factory.get().newKieSessionConfiguration();
> ksconf.setOption(TimedRuleExectionOption.YES);
> config.setOption(EventProcessingOption.STREAM);
> KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase(config);
> final KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
> kbuilder.add(ResourceFactory.newClassPathResource("bug/timer/timer.drl", BugTest.class), ResourceType.DRL);
> if (kbuilder.hasErrors()) {
> throw new IllegalStateException(kbuilder.getErrors().toString());
> }
> kbase = KnowledgeBaseFactory.newKnowledgeBase(config);
> kbase.addKnowledgePackages(kbuilder.getKnowledgePackages());
> final StatefulKnowledgeSession statefulKnowledgeSession = kbase.newStatefulKnowledgeSession(ksconf, null);
> Table table = new Table(1234, 1);
> statefulKnowledgeSession.insert(table);
> statefulKnowledgeSession.fireAllRules();
> Thread.sleep(TimeUnit.SECONDS.toMillis(5));
> statefulKnowledgeSession.dispose();
> Assert.assertThat(table.getCounter(), CoreMatchers.is(3));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFLY-6808) DistributableSession validate method throw misleading exception message
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6808?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-6808.
------------------------------
Fix Version/s: 11.0.0.Alpha1
Resolution: Done
Fixed by WFLY-6878.
> DistributableSession validate method throw misleading exception message
> -----------------------------------------------------------------------
>
> Key: WFLY-6808
> URL: https://issues.jboss.org/browse/WFLY-6808
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 10.0.0.Final
> Reporter: Mathieu Lachance
> Assignee: Paul Ferraro
> Fix For: 10.1.0.Final, 11.0.0.Alpha1
>
>
> In DistributableSession the validate method is getting called for any underlying undertow session access to make sure we are not touching an already invalidated session (which totally make sense):
> {code}
> public class DistributableSession implements io.undertow.server.session.Session {
> private static void validate(Session<LocalSessionContext> session) {
> if (!session.isValid()) {
> throw UndertowMessages.MESSAGES.sessionNotFound(session.getId());
> }
> }
> }
> {code}
> The problem though is the exception message that is thrown is really misleading because in reality the session actually exists but is currently invalid and/or getting invalidated. This can happen especially when running in optimistic mode where we can have many differents threads accessing the very same session.
> I would recommend we do instead:
> {code}
> if (!session.isValid()) {
> throw UndertowMessages.MESSAGES.sessionAlreadyInvalidated();
> }
> {code}
> or even better:
> {code}
> if (!session.isValid()) {
> throw UndertowMessages.MESSAGES.sessionAlreadyInvalidated(session.getId());
> }
> {code}
> but it will require also a change in Undertow to actually template/parametize the sessionAlreadyInvalidated message.
> Thanks,
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFLY-4186) Improve Infinispan module compatibility with older releases
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-4186?page=com.atlassian.jira.plugin.... ]
Paul Ferraro closed WFLY-4186.
------------------------------
Resolution: Out of Date
> Improve Infinispan module compatibility with older releases
> -----------------------------------------------------------
>
> Key: WFLY-4186
> URL: https://issues.jboss.org/browse/WFLY-4186
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 9.0.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 10.1.0.Final
>
>
> Infinispan 7 moved a bunch of classes from the org.infinispan:infinispan-core maven module into the org.infinispan:infinispan-commons module (which, itself, was introduced in Infinispan 6), which can cause user deployments that previously depended on org.infinispan to fail with mysterious NoClassDefFoundErrors if the org.infinispan.commons module was not also previously declared as a deployment dependency.
> I suggest we either:
> 1. Export org.infinispan.commons from the org.infinispan module
> 2. Rename org.infinispan to org.infinispan.core, and create a new org.infinispan that exports both org.infinispan.core and org.infinispan.commons.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (WFCORE-1684) Empty lines between tab completion suggestions on Windows
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1684?page=com.atlassian.jira.plugi... ]
Petr Kremensky moved JBEAP-5478 to WFCORE-1684:
-----------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1684 (was: JBEAP-5478)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: CLI
(was: CLI)
Affects Version/s: (was: 7.1.0.DR1)
> Empty lines between tab completion suggestions on Windows
> ---------------------------------------------------------
>
> Key: WFCORE-1684
> URL: https://issues.jboss.org/browse/WFCORE-1684
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Petr Kremensky
> Assignee: Alexey Loubyansky
> Priority: Minor
>
> I noticed that CLI put empty lines between lines with suggested values once the Windows terminal is set to maximal width. Issue appears *only of the CLI is connected to the EAP running in domain* mode.
> *reproduce*
> \- start EAP in domain mode
> \- open a new terminal window, manually set the terminal width to maximal allowed value, but do not maximize the window
> \- connect CLI to the running server and pres the Tab key
> {noformat}
> [domain@localhost:9990 /]
> : clear data-source echo if pwd reload shutdown unset
> alias command deploy echo-dmr jdbc-driver-info quit rollout-plan try version
> batch connect deployment-info help ls read-attribute run-batch unalias xa-data-source
> cd connection-info deployment-overlay history patch read-operation set undeploy
> {noformat}
> I was able to reproduce the issue on W2K8 and W2K12 servers.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months
[JBoss JIRA] (DROOLS-747) declared window, type length(1), do actually contain more than 1 object (with reteoo)
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-747?page=com.atlassian.jira.plugin... ]
Mario Fusco closed DROOLS-747.
------------------------------
Resolution: Out of Date
> declared window, type length(1), do actually contain more than 1 object (with reteoo)
> -------------------------------------------------------------------------------------
>
> Key: DROOLS-747
> URL: https://issues.jboss.org/browse/DROOLS-747
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.2.0.Final
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Attachments: 20150323.DROOLS-747-reproducer.zip
>
>
> h5. Premise
> I know reteoo is progressively being deprecated, but I think until is there is helpful for A/B testing of possible leaks comparing with phreak (like it happened during 610Final) so reporting this bug.
> h5. Executive summary
> Declaring a window of type length (1) should always contain 1 object.
> h5. Details
> With reference to attached reproducer.
> Given the following knowledge base:
> {code}
> global java.util.concurrent.atomic.AtomicLong globalCounter;
> declare Measurement
> @role(event)
> end
> declare window lastMeasurement
> Measurement() over window:length( 1 ) // from entry-point DEFAULT
> end
> rule "IFF the last Measurement that I know of, is of ID color, increment the counter"
> no-loop
> when
> Measurement( id == "color" ) from window lastMeasurement
> then
> globalCounter.incrementAndGet();
> end
> {code}
> The goal is: IFF the last Measurement that I know of, is of ID "color", increment the counter. Please notice you ought to separate the window being just on Measurement, in order to know the last Measurement regardless of the ID, and then you have a rule acting on the declared window, to check IFF this last Measurement, is actually of ID "color".
> Now assuming you just have created the session and the following increment/insert/fire:
> {code}
> AtomicLong globalCounter = new AtomicLong(0);
> session.setGlobal("globalCounter", globalCounter);
> session.fireAllRules();
> assertEquals("no data, still 0", 0, globalCounter.get());
> LOG.info("Now running data");
> clock.advanceTime(1, TimeUnit.MINUTES);
> Measurement mRed= new Measurement("color", "red");
> session.insert(mRed);
> Measurement mGreen= new Measurement("color", "green");
> session.insert(mGreen);
> Measurement mBlue= new Measurement("color", "blue");
> session.insert(mBlue);
> session.fireAllRules();
> LOG.info("Final checks");
> assertEquals("win lenght =1 was: ", 1, globalCounter.get());
> {code}
> At the end you should have the global counter with value = 1, because we inserted 3 events of type Measurement, but the declared window lastMeasurement should reference only {{mBlue}}, which should be later picked by the rule because the ID is "color", and increment the counter by 1.
> This works with phreak, it does not work with reteo.
> phreak globalCounter = 1 : OK
> reteoo globalCounter = 3 : FAIL.
> Could you kindly advise, please?
> Thanks
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 4 months