August 2014 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-586) Drools doesn't calculate maximum expiration time properly

by kairat kushaev (JIRA)

kairat kushaev created DROOLS-586: ------------------------------------- Summary: Drools doesn't calculate maximum expiration time properly Key: DROOLS-586 URL: https://issues.jboss.org/browse/DROOLS-586 Project: Drools Issue Type: Bug Security Level: Public (Everyone can see) Environment: Linux, Java SE 1.7 Reporter: kairat kushaev Assignee: Mark Proctor Fix For: 6.1.0.Final Hello guys, we found some contradiction between actual Drools behaviour, We use the following Rule: import com.opensoft.mom.domain.Event; import java.util.List; import java.util.ArrayList; import com.opensoft.mom.domain.MessageModelMap; global com.opensoft.mom.service.actions.Actions actions; dialect "mvel" declare Event @role(event) @expires(10m) end rule "ExampleRule" when ((($Time_delay_order:Event((this.isBelongToEventFormat(38)) && (this.getComparableStringValue("XXXXX") == Event.getDecodedString("ok")))))and(($Time_delay_submit:Event((this.isBelongToEventFormat(39)) && (this.getComparableStringValue("XXXXXX") == Event.getDecodedString("ok")) && (this after[1ms,0h15m20s] $Time_delay_order))))) then List recipients0 = new ArrayList(); recipients0.add(Event.getDecodedString("XXXXXXXXXX(a)gmail.com")); MessageModelMap template0 = new MessageModelMap(); template0.setValue("XXXXXXXXXX", $Time_delay_order.getComparableStringValue("XXXXX")); template0.setValue("XXXXXXXXXX", $Time_delay_order.getComparableStringValue("XXXXX")); String subject0 = Event.getDecodedString(""); actions.sendMail(recipients0, subject0, 14, template0); end In the code above Drools should wait for the second rule when the first rule has fired. But it turns out that Drools doesn't wait for the second Rule because of @expires tag. The value in this tag is less than this after value. According to documentation "The engine will make this analysis for the whole rulebase and find the offset for every event type. Whenever an implicit expiration offset clashes with the explicit expiration offset, then engine will use the greater of the two." but it is not calculating maximal expiration offset. Also we turned on STREAM mode. Could you please clarify the situation? -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1730) Allow supplying a custom KeyStore to ENCRYPT for better integration in embedded environments

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1730?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1730: -------------------------------- Status ? > Allow supplying a custom KeyStore to ENCRYPT for better integration in embedded environments > -------------------------------------------------------------------------------------------- > > Key: JGRP-1730 > URL: https://issues.jboss.org/browse/JGRP-1730 > Project: JGroups > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Tristan Tarrant > Assignee: Tristan Tarrant > Fix For: 3.6 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1874) UNICAST3/UNICAST2: reduce traffic caused by GET-FIRST-SEQNO

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1874?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-1874. ---------------------------- Resolution: Duplicate Issue https://issues.jboss.org/browse/JGRP-1875 includes this functionality > UNICAST3/UNICAST2: reduce traffic caused by GET-FIRST-SEQNO > ----------------------------------------------------------- > > Key: JGRP-1874 > URL: https://issues.jboss.org/browse/JGRP-1874 > Project: JGroups > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5.1, 3.6 > > > When we have sender A and receiver B, and B closes its connection unilaterally (see JGRP-1873), then a {{GET-FIRST-SEQNO}} will be sent from B to A when A's next message is received. This can potentially generate a lot of traffic. > Example: > # B has no entry for A in its recv-table > # A has {{B:: 100 | 1000}}, so only message {{A::100}} has been acked by B ({{STABLE}} or {{ACK}} message > # If B now gets {{A::560}}, it sends a {{GET-FIRST-SEQNO(560)}} to A > #* As a matter of fact, for any message from A that not marked as {{first}}, B will send a {{GET-FIRST-SEQNO}} message: too much traffic > # A now sends messages {{A::101}} - {{A::560}} to B > #* This is also not needed: too much traffic > h5. Solution to reduce traffic > * Receiver: add timestamp to recv-table entries which drops {{GET-FIRST-SEQNO}} messages sent sooner than N ms after the previous one > ** So rather than sending 1000 {{GET-FIRST-SEQNO}} messages to A when receiving 1000 unicasts from A not marked as {{first}}, we might only send a _single message_ > * Sender: when a {{GET-FIRST-SEQNO(560)}} message is received from B, only send the lowest sent (101) and the highest sent (560) back to B > ** B will then retransmit all missing messages in that range > ** For {{UNICAST3}}, we can only send the lowest sent message (101) as it will retransmit {{A::1000}} anyway and therefore trigger retransmission -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1874) UNICAST3/UNICAST2: reduce traffic caused by GET-FIRST-SEQNO

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-1874?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-1874: -------------------------------- Closing this issue as a duplicate: https://issues.jboss.org/browse/JGRP-1875 includes reducing traffic between sender and receiver when syncing the receiver > UNICAST3/UNICAST2: reduce traffic caused by GET-FIRST-SEQNO > ----------------------------------------------------------- > > Key: JGRP-1874 > URL: https://issues.jboss.org/browse/JGRP-1874 > Project: JGroups > Issue Type: Enhancement > Security Level: Public(Everyone can see) > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 3.5.1, 3.6 > > > When we have sender A and receiver B, and B closes its connection unilaterally (see JGRP-1873), then a {{GET-FIRST-SEQNO}} will be sent from B to A when A's next message is received. This can potentially generate a lot of traffic. > Example: > # B has no entry for A in its recv-table > # A has {{B:: 100 | 1000}}, so only message {{A::100}} has been acked by B ({{STABLE}} or {{ACK}} message > # If B now gets {{A::560}}, it sends a {{GET-FIRST-SEQNO(560)}} to A > #* As a matter of fact, for any message from A that not marked as {{first}}, B will send a {{GET-FIRST-SEQNO}} message: too much traffic > # A now sends messages {{A::101}} - {{A::560}} to B > #* This is also not needed: too much traffic > h5. Solution to reduce traffic > * Receiver: add timestamp to recv-table entries which drops {{GET-FIRST-SEQNO}} messages sent sooner than N ms after the previous one > ** So rather than sending 1000 {{GET-FIRST-SEQNO}} messages to A when receiving 1000 unicasts from A not marked as {{first}}, we might only send a _single message_ > * Sender: when a {{GET-FIRST-SEQNO(560)}} message is received from B, only send the lowest sent (101) and the highest sent (560) back to B > ** B will then retransmit all missing messages in that range > ** For {{UNICAST3}}, we can only send the lowest sent message (101) as it will retransmit {{A::1000}} anyway and therefore trigger retransmission -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-28) Add global resource notifications

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFCORE-28?page=com.atlassian.jira.plugin.... ] Jeff Mesnil updated WFCORE-28: ------------------------------ Git Pull Request: https://github.com/wildfly/wildfly-core/pull/45, https://github.com/wildfly/wildfly-core/pull/62, https://github.com/wildfly/wildfly-core/pull/140, https://github.com/wildfly/wildfly/pull/6646 (was: https://github.com/wildfly/wildfly-core/pull/45, https://github.com/wildfly/wildfly-core/pull/62, https://github.com/wildfly/wildfly-core/pull/140) PR for 8.x branch > Add global resource notifications > --------------------------------- > > Key: WFCORE-28 > URL: https://issues.jboss.org/browse/WFCORE-28 > Project: WildFly Core > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 1.0.0.Alpha5 > > > Emit notifications to any resource of WildFly management model: > * resource-added - when a resource is added, it emits a resource-added notification > * resource-removed - when a resource is removed, it emits a resource-removed notification > * attribute-value-written - when a write-attribute operation is performed successfully on a resource, it emits a attribute-value-written notification. The notification's data field contains the following information: > * name - String - the name of the attribute > * old-value - the detyped representation of the previous value of the attribute > * new-value - the detyped representation of the new value -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3791) Error on ModelControllerClient to list sections

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-3791?page=com.atlassian.jira.plugin.... ] Darran Lofthouse commented on WFLY-3791: ---------------------------------------- Yes I understand you are using the latest version, however are you using the default configuration or a clean configuration? Looking at your test code it is on the basis that you are using a modified configuration - what I am asking is that you run your test against an unmodified version of the configuration. An no at this point I have not tried your java code, I have just verified that the security subsystem is accessible on a default installation at the same address as it has always been. The thing I need to know now is do you experience this error in a clean installation or only in your customised installation. > Error on ModelControllerClient to list sections > ----------------------------------------------- > > Key: WFLY-3791 > URL: https://issues.jboss.org/browse/WFLY-3791 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Domain Management > Affects Versions: 8.1.0.Final > Environment: Java 7 > Reporter: ofbiz brazil > Assignee: Darran Lofthouse > > Hello, > When there's a client trying to list a node for a security section, Wildfly says it does not exist but on Jboss 7.1.1 it works fine. > Java Code: > -------------- > final ModelNode request = new ModelNode(); > request.get(ClientConstants.OP).set("read-resource"); > request.get("recursive").set(true); > request.get(ClientConstants.OP_ADDR).add("subsystem", "security"); > final ModelControllerClient client = ModelControllerClient.Factory.create(InetAddress.getByName("127.0.0.1"), 9999); > final ModelNode response = client.execute(new OperationBuilder(request).build()); > final String section = response.get(ClientConstants.RESULT).get("security-domain") > .get("pw_MSSQL_CAS_DS") > Result: > --------- > { > "outcome" => "failed", > "failure-description" => "JBAS014807: Management resource '[(\"subsystem\" => \"security\")]' not found", > "rolled-back" => true > } > Cheers, -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-28) Add global resource notifications

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFCORE-28?page=com.atlassian.jira.plugin.... ] Jeff Mesnil updated WFCORE-28: ------------------------------ Git Pull Request: https://github.com/wildfly/wildfly-core/pull/45, https://github.com/wildfly/wildfly-core/pull/62, https://github.com/wildfly/wildfly-core/pull/140 (was: https://github.com/wildfly/wildfly-core/pull/45, https://github.com/wildfly/wildfly-core/pull/62) PR to add global notification handlers to tests to emit notifications to remove warnings from the test logs > Add global resource notifications > --------------------------------- > > Key: WFCORE-28 > URL: https://issues.jboss.org/browse/WFCORE-28 > Project: WildFly Core > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Components: Domain Management > Reporter: Jeff Mesnil > Assignee: Jeff Mesnil > Fix For: 1.0.0.Alpha5 > > > Emit notifications to any resource of WildFly management model: > * resource-added - when a resource is added, it emits a resource-added notification > * resource-removed - when a resource is removed, it emits a resource-removed notification > * attribute-value-written - when a write-attribute operation is performed successfully on a resource, it emits a attribute-value-written notification. The notification's data field contains the following information: > * name - String - the name of the attribute > * old-value - the detyped representation of the previous value of the attribute > * new-value - the detyped representation of the new value -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3263) ear-sub-deployments-isolated is ignored from jboss-deployment-structure.xml

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3263?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3263: ----------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1029260|https://bugzilla.redhat.com/show_bug.cgi?id=1029260] from ASSIGNED to POST > ear-sub-deployments-isolated is ignored from jboss-deployment-structure.xml > --------------------------------------------------------------------------- > > Key: WFLY-3263 > URL: https://issues.jboss.org/browse/WFLY-3263 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: EE > Reporter: Stuart Douglas > Assignee: Stuart Douglas > Fix For: 8.1.0.CR2, 8.1.0.Final > > > The default processor runs later, and overwrites the value provided by this file. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2569) Components in Web and EJB container should always have access to RAR included in the same EAR

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-2569?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-2569: ----------------------------------------------- baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1029260|https://bugzilla.redhat.com/show_bug.cgi?id=1029260] from ASSIGNED to POST > Components in Web and EJB container should always have access to RAR included in the same EAR > --------------------------------------------------------------------------------------------- > > Key: WFLY-2569 > URL: https://issues.jboss.org/browse/WFLY-2569 > Project: WildFly > Issue Type: Bug > Security Level: Public(Everyone can see) > Components: Class Loading, EE > Affects Versions: 8.0.0.Beta1 > Reporter: Martin Kouba > Assignee: Stuart Douglas > Fix For: 8.1.0.Final > > > See also EE.8.3 Class Loading Requirements. > In the mentioned Arquillian test (servlet protocol) if a class from an EJB module tries to access a class from an RAR you get a NoClassDefFoundError. I also tried to place the class in the WAR with the same result. -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3743) Upgrade to JBoss Negotiation 2.3.4.Final

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-3743?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-3743: ----------------------------------------------- FIlip Bogyai <fbogyai(a)redhat.com> changed the Status of [bug 1131231|https://bugzilla.redhat.com/show_bug.cgi?id=1131231] from ON_QA to VERIFIED > Upgrade to JBoss Negotiation 2.3.4.Final > ---------------------------------------- > > Key: WFLY-3743 > URL: https://issues.jboss.org/browse/WFLY-3743 > Project: WildFly > Issue Type: Component Upgrade > Security Level: Public(Everyone can see) > Components: Security > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 9.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.3.1#6329)

11 years, 10 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 August 2014