January 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (JGRP-2007) Adapt code to use new Java 8 features

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2007?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2007 at 1/25/16 6:24 AM: --------------------------------------------------------- Also look at * MessageBatch * Table * Use default methods in interfaces * Replace NotifyingFuture with CompletableFuture was (Author: belaban): Also look at * MessageBatch * Table * Use default methods in interfaces > Adapt code to use new Java 8 features > ------------------------------------- > > Key: JGRP-2007 > URL: https://issues.jboss.org/browse/JGRP-2007 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > E.g replace loops for forEach() etc -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2007) Adapt code to use new Java 8 features

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2007?page=com.atlassian.jira.plugin.... ] Bela Ban edited comment on JGRP-2007 at 1/25/16 6:22 AM: --------------------------------------------------------- Also look at * MessageBatch * Table * Use default methods in interfaces was (Author: belaban): Also look at * MessageBatch * Table > Adapt code to use new Java 8 features > ------------------------------------- > > Key: JGRP-2007 > URL: https://issues.jboss.org/browse/JGRP-2007 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > E.g replace loops for forEach() etc -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1980) Improve throughput under contention for FlowControl.Credit

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/JGRP-1980?page=com.atlassian.jira.plugin.... ] Sanne Grinovero commented on JGRP-1980: --------------------------------------- Great, thanks. Getting a synchronized get() out of the picture might have done the trick, we'll test it again and track separately if I see something concrete we could do (and if it still is a problem at all). > Improve throughput under contention for FlowControl.Credit > ---------------------------------------------------------- > > Key: JGRP-1980 > URL: https://issues.jboss.org/browse/JGRP-1980 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 3.6.6 > Reporter: Sanne Grinovero > Assignee: Bela Ban > Fix For: 3.6.8 > > Attachments: bla.java > > > The methods {{org.jgroups.protocols.FlowControl.Credit.decrementIfEnoughCredits(long, long)}} and {{org.jgroups.protocols.FlowControl.Credit.decrementAndGet(long)}} are contending the locks on class synchronization when stress testing JGroups. > Wondering if we can think of polishing the implementation, although it looks like challenging. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2007) Adapt code to use new Java 8 features

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2007?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2007: -------------------------------- Also look at * MessageBatch * Table > Adapt code to use new Java 8 features > ------------------------------------- > > Key: JGRP-2007 > URL: https://issues.jboss.org/browse/JGRP-2007 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > E.g replace loops for forEach() etc -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6061) Deployment error after reboot [WFLYSRV0137]

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-6061?page=com.atlassian.jira.plugin.... ] Thomas Diesler updated WFLY-6061: --------------------------------- Component/s: Domain Management (was: ConfigAdmin) > Deployment error after reboot [WFLYSRV0137] > ------------------------------------------- > > Key: WFLY-6061 > URL: https://issues.jboss.org/browse/WFLY-6061 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Affects Versions: 9.0.2.Final > Environment: Ubuntu 14.04 LTS 64bit, jre-1.8.0_65 > Several deployed (JavaEE) web applications including non XA datasources that connect to a MySQL instance. > Reporter: Tobi Tobias > Assignee: Thomas Diesler > Priority: Critical > > I have a working configuration on wildfly 9.0.2 final with several web applications (JavaEE). > After a couple of days, I deployed another war file via jboss CLI. This application worked correctly and no deployment error occurred. > But if I restart the server now, I get following error message: > 10:36:01,893 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "MM-Controller-0.1.0-SNAPSHOT.war")]) - failure description: "WFLYSRV0137: No deployment content with hash 966847a6f5f5bf8c3470f07ea9e65b7bbcdcd7b7 is available in the deployment content repository for deployment 'MM-Controller-0.1.0-SNAPSHOT.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuration file and restart." > 10:36:01,990 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. > I reproduced this at least 30 times - even with different jars. I always get this error. The server works fine as long as I don't reboot. > The only way to fix the configuration is to manually remove the deployments from the standalone.xml. > But this is not an option for me as I want to have the wildfly running as production server where I have several automatic deployments every day. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6061) Deployment error after reboot [WFLYSRV0137]

by Thomas Diesler (JIRA)

[ https://issues.jboss.org/browse/WFLY-6061?page=com.atlassian.jira.plugin.... ] Thomas Diesler reassigned WFLY-6061: ------------------------------------ Assignee: Brian Stansberry (was: Thomas Diesler) > Deployment error after reboot [WFLYSRV0137] > ------------------------------------------- > > Key: WFLY-6061 > URL: https://issues.jboss.org/browse/WFLY-6061 > Project: WildFly > Issue Type: Bug > Components: Domain Management > Affects Versions: 9.0.2.Final > Environment: Ubuntu 14.04 LTS 64bit, jre-1.8.0_65 > Several deployed (JavaEE) web applications including non XA datasources that connect to a MySQL instance. > Reporter: Tobi Tobias > Assignee: Brian Stansberry > Priority: Critical > > I have a working configuration on wildfly 9.0.2 final with several web applications (JavaEE). > After a couple of days, I deployed another war file via jboss CLI. This application worked correctly and no deployment error occurred. > But if I restart the server now, I get following error message: > 10:36:01,893 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([("deployment" => "MM-Controller-0.1.0-SNAPSHOT.war")]) - failure description: "WFLYSRV0137: No deployment content with hash 966847a6f5f5bf8c3470f07ea9e65b7bbcdcd7b7 is available in the deployment content repository for deployment 'MM-Controller-0.1.0-SNAPSHOT.war'. This is a fatal boot error. To correct the problem, either restart with the --admin-only switch set and use the CLI to install the missing content or remove it from the configuration, or remove the deployment from the xml configuration file and restart." > 10:36:01,990 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. > I reproduced this at least 30 times - even with different jars. I always get this error. The server works fine as long as I don't reboot. > The only way to fix the configuration is to manually remove the deployments from the standalone.xml. > But this is not an option for me as I want to have the wildfly running as production server where I have several automatic deployments every day. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1016) Too much memory consumption while running code on drools6.

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1016?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-1016. --------------------------------- Resolution: Cannot Reproduce Bug I'm not able to reproduce a relevantly higher memory consumption. If can provide a reproducer for this issue feel free to attach it to this jira and reopen the ticket. > Too much memory consumption while running code on drools6. > ---------------------------------------------------------- > > Key: DROOLS-1016 > URL: https://issues.jboss.org/browse/DROOLS-1016 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.2.0.Final > Reporter: Vivek Hingorani > Assignee: Mario Fusco > > The memory usage on drools6 is far more then drools 5. Can we run the drools6 code with Rete algorithm? > We recently migrated our project from Drools 5.3.0.Final version to Drools 6.2.0.Final version. In production we can see a significant increase in the memory consumption per node. we are using java 1.7. We increased the permgen space as well for drools6 from 0.5 GB to 1 GB but still the increase is too much. Is there any solution for the same. > Drools5 memory usage was 0.5GB per node with 0.5GB permgen space > Drools6 memory usage is 1.3GB per node with 1GB permgen space. > Node here is a jvm as we are using oracle coherence. > If further details are needed , let me know. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1015) Wrong MvelConstraint compilation with Unicode class name and the same name property

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1015?page=com.atlassian.jira.plugi... ] Mario Fusco closed DROOLS-1015. ------------------------------- Resolution: Won't Fix > Wrong MvelConstraint compilation with Unicode class name and the same name property > ----------------------------------------------------------------------------------- > > Key: DROOLS-1015 > URL: https://issues.jboss.org/browse/DROOLS-1015 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: Toshiya Kobayashi > Assignee: Mario Fusco > Fix For: 7.0.0.Final > > > If a fact has a property of Unicode class name (e.g. 住所) and the property name is the same (住所), constraint is not correctly compiled by MVEL. Internally, AbstractParser.createPropertyToken() misunderstands the property as a class name literal. > {code:java} > public class I18nPerson implements Serializable { > private 住所住所; // "address" in Japanese > public 住所 get住所() { > return 住所; > } > .... > {code} > {noformat} > when > p : I18nPerson( 住所 != null ) > {noformat} > This constraint is always evaluated to "true". > Essentially, this is not only a problem of Unicode. We can reproduce the issue by a capitalized property name. > {code:java} > public class Person implements Serializable { > private Address address; > public Address getAddress() { > return address; > } > .... > {code} > {noformat} > when > p : I18nPerson( Address != null ) > {noformat} > Of course we should use lower case letters here from JavaBeans point of view so we don't hit this issue with English usually. But some languages like Japanese cannot express "lower case/upper case" so result in this issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1013) Error jitting a compareTo constraint

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1013?page=com.atlassian.jira.plugi... ] Mario Fusco closed DROOLS-1013. ------------------------------- Resolution: Done > Error jitting a compareTo constraint > ------------------------------------ > > Key: DROOLS-1013 > URL: https://issues.jboss.org/browse/DROOLS-1013 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.4.0.CR1 > > > When the implementation of the Comparable interface is not directly declared by a Class, but the Class implements another interface that transitively extends Comparable the jitting of a constraint doing a compareTo on that class fails with the following exception: > {code} > Exception in thread "Thread-0" java.lang.NoSuchMethodError: java.time.LocalDateTime.compareTo(Ljava/time/LocalDateTimeI > at ConditionEvaluator8566b06b2be943a7ba50f1700fa7b033.evaluate(Unknown Source) > at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:248) > at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:204) > at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:141) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1029) Matching expires attribute and accumulate time window makes events expiry infinite

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1029?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-1029. --------------------------------- Resolution: Cannot Reproduce Bug I tried to reproduce the issue you reported with the following test case, but it works for me. In case you're able to provide a different test case reproducing this problem, please attach your reproducer here and reopen this ticket. {code} @Test public void testCheckExpirationWithAccumulateOnSameTimeWindow() { // DROOLS-1029 String drl = "import " + SimpleEvent.class.getCanonicalName() + "\n" + "declare SimpleEvent\n" + " @role( event )\n" + " @expires( 10s )\n" + "end\n" + "\n" + "rule R when\n" + " accumulate(SimpleEvent() over window:time( 10s ); $count:count(); $count>1 )\n" + "then\n" + " System.out.println(\"count = \" + $count);" + "end"; KieSessionConfiguration sessionConfig = KnowledgeBaseFactory.newKnowledgeSessionConfiguration(); sessionConfig.setOption( ClockTypeOption.get( ClockType.PSEUDO_CLOCK.getId() ) ); KieHelper helper = new KieHelper(); helper.addContent( drl, ResourceType.DRL ); KieBase kbase = helper.build( EventProcessingOption.STREAM ); KieSession ksession = kbase.newKieSession( sessionConfig, null ); PseudoClockScheduler clock = ksession.getSessionClock(); ksession.insert(new SimpleEvent("1", 0L)); ksession.insert(new SimpleEvent("2", 0L)); ksession.fireAllRules(); // Session should only contain the events we just inserted assertEquals( 2, ksession.getFactCount() ); clock.advanceTime( 15, TimeUnit.SECONDS ); ksession.fireAllRules(); // Events are expired so session should be empty now assertEquals( 0, ksession.getFactCount() ); ksession.dispose(); } {code} > Matching expires attribute and accumulate time window makes events expiry infinite > ---------------------------------------------------------------------------------- > > Key: DROOLS-1029 > URL: https://issues.jboss.org/browse/DROOLS-1029 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Environment: Windows 10, Java 8 > Reporter: Thibault Daoulas > Assignee: Mario Fusco > > I have declared an event with an attribute @expires 10m. > I have a rule which accumulates these events over window:time(10m). > With this setup, the number of facts keeps growing in WM beyond 10 minutes of corresponding facts. > If I set the the expires to less, say 9 minutes, they do expire after 9 minutes, and if I set the expires to 11 minutes, they do expire after 11 minutes. > So it looks like matching @expires and accumulate time window void any expiry. I couldn't find anything on this in the documentation and please correct if this has been reported already. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira January 2016