[JBoss JIRA] (WFLY-3078) directory-grouping configuration is not getting persisted via CLI when no servers defined
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-3078?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-3078:
-----------------------------------------------
mark yarborough <myarboro(a)redhat.com> changed the Status of [bug 1073715|https://bugzilla.redhat.com/show_bug.cgi?id=1073715] from VERIFIED to CLOSED
> directory-grouping configuration is not getting persisted via CLI when no servers defined
> -----------------------------------------------------------------------------------------
>
> Key: WFLY-3078
> URL: https://issues.jboss.org/browse/WFLY-3078
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Environment: All Operating System
> Reporter: Jay Kumar SenSharma
> Assignee: Emanuel Muckenhuber
> Fix For: 8.1.0.CR1, 8.1.0.Final
>
>
> - If none of the servers are defined in "host.xml" (means <servers></servers> empty tag is present) and if the user tries to run the following CLI command to change the "directory-grouping" to "by-type" then the value is not persisted in the configuration file (host.xml) and the <servers></servers> tag is also removed from the host.xml
> {code}
> /host=master/:write-attribute(name=directory-grouping,value=by-type)
> {code}
> - The value of "directory-grouping" is stored "in memory" so this change does not survive the host restart.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 11 months
[JBoss JIRA] (DROOLS-703) Add ability to see more text in a text field using a textarea or other multi-line wrapping capability
by Stephen Slaboda (JIRA)
Stephen Slaboda created DROOLS-703:
--------------------------------------
Summary: Add ability to see more text in a text field using a textarea or other multi-line wrapping capability
Key: DROOLS-703
URL: https://issues.jboss.org/browse/DROOLS-703
Project: Drools
Issue Type: Enhancement
Affects Versions: 6.1.0.Final
Environment: RedHat 6.3 Linux x86_64; Firefox 10.0.5
Reporter: Stephen Slaboda
Assignee: Mark Proctor
Currently, if we want to assemble a string in a formula text field using various bound variables, the full text being constructed does not display all at once. The size of the box forces you to scroll around or copy/paste to see all the text after you get to a few dozen characters. We like to be somewhat verbose in our naming of variables to offer more clarity, so in some cases the text field may do this even when using a single variable name. Perhaps there could be a way to wrap the text into a multi-line display so that it is easier to edit these fields?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 11 months
[JBoss JIRA] (DROOLS-702) Rule Inheritance fired the sub rule even the condition doen't match
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/DROOLS-702?page=com.atlassian.jira.plugin... ]
Davide Sottara edited comment on DROOLS-702 at 2/1/15 12:42 PM:
----------------------------------------------------------------
Yacine,
"from" leads to this situation:
{code}
$p : Person( ... )
Person( ... ) from $p
{code}
This ensures that both patterns are applied to the same object.
In fact, the second will only be applied id an object passes the first.
unification is effectively an equality constraint:
{code}
$p Person( ... )
Person( this == $p, ... )
{code}
so it may even match two different objects that are equal to each other.
Pick the one that you prefer based on your actual use case
was (Author: dsotty):
Yacine,
"from" leads to this situation:
{code}
$p : Person( ... )
Person( ... ) from $p
{code}
This ensures that both patterns are applied to the same object.
In fact, the second will only be applied id an object passes the first.
unification is effectively an equality constraint:
{code}
$p Person()
Person( this == $p )
{code}
so it may even match two different objects that are equal to each other.
Pick the one that you prefer based on your actual use case
> Rule Inheritance fired the sub rule even the condition doen't match
> -------------------------------------------------------------------
>
> Key: DROOLS-702
> URL: https://issues.jboss.org/browse/DROOLS-702
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final
> Environment: Windows, Java6.0.29
> Reporter: Yacine Jaber
> Assignee: Davide Sottara
> Priority: Critical
> Attachments: wod-drools-test.7z
>
>
> You can find the attached a simple maven project that shows this error.
> You can run ExampleDrools class as main java application.
> The sub rules are fired even if the condition is not matched.
> There are a work arround by using <from $fact> into a sub rule to avoid firing this one.
> This simple project shows the failed and work arround test.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 11 months
[JBoss JIRA] (DROOLS-702) Rule Inheritance fired the sub rule even the condition doen't match
by Davide Sottara (JIRA)
[ https://issues.jboss.org/browse/DROOLS-702?page=com.atlassian.jira.plugin... ]
Davide Sottara commented on DROOLS-702:
---------------------------------------
Yacine,
"from" leads to this situation:
{code}
$p : Person( ... )
Person( ... ) from $p
{code}
This ensures that both patterns are applied to the same object.
In fact, the second will only be applied id an object passes the first.
unification is effectively an equality constraint:
{code}
$p Person()
Person( this == $p )
{code}
so it may even match two different objects that are equal to each other.
Pick the one that you prefer based on your actual use case
> Rule Inheritance fired the sub rule even the condition doen't match
> -------------------------------------------------------------------
>
> Key: DROOLS-702
> URL: https://issues.jboss.org/browse/DROOLS-702
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final
> Environment: Windows, Java6.0.29
> Reporter: Yacine Jaber
> Assignee: Davide Sottara
> Priority: Critical
> Attachments: wod-drools-test.7z
>
>
> You can find the attached a simple maven project that shows this error.
> You can run ExampleDrools class as main java application.
> The sub rules are fired even if the condition is not matched.
> There are a work arround by using <from $fact> into a sub rule to avoid firing this one.
> This simple project shows the failed and work arround test.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 11 months
[JBoss JIRA] (DROOLS-702) Rule Inheritance fired the sub rule even the condition doen't match
by Yacine Jaber (JIRA)
[ https://issues.jboss.org/browse/DROOLS-702?page=com.atlassian.jira.plugin... ]
Yacine Jaber commented on DROOLS-702:
-------------------------------------
Hi David,
Thank you for your answer. I though that even if we use the same fact on the parent & child rule, the evaluation will be made on these two rules.
It's could be interesting to mention this case on documentation (7.8.5. Conditional named consequences).
The unification works as expected. Can you tell me which solution is strong (Unification or from)?
> Rule Inheritance fired the sub rule even the condition doen't match
> -------------------------------------------------------------------
>
> Key: DROOLS-702
> URL: https://issues.jboss.org/browse/DROOLS-702
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.1.0.Final
> Environment: Windows, Java6.0.29
> Reporter: Yacine Jaber
> Assignee: Davide Sottara
> Priority: Critical
> Attachments: wod-drools-test.7z
>
>
> You can find the attached a simple maven project that shows this error.
> You can run ExampleDrools class as main java application.
> The sub rules are fired even if the condition is not matched.
> There are a work arround by using <from $fact> into a sub rule to avoid firing this one.
> This simple project shows the failed and work arround test.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 11 months
[JBoss JIRA] (JGRP-1908) Optional Executing protocol behavior to not attempt to repeat tasks
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1908?page=com.atlassian.jira.plugin.... ]
Bela Ban reassigned JGRP-1908:
------------------------------
Assignee: William Burns (was: Bela Ban)
William, can you take a look ?
> Optional Executing protocol behavior to not attempt to repeat tasks
> -------------------------------------------------------------------
>
> Key: JGRP-1908
> URL: https://issues.jboss.org/browse/JGRP-1908
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Anuj Shah
> Assignee: William Burns
> Labels: executionservice
> Fix For: 3.6.2
>
>
> As discussed on forum:
> http://jgroups.1086181.n5.nabble.com/jgroups-users-ExecutionService-at-le...
> {quote}
> I've noticed that runnable tasks submitted to the ExecutionService can be run more than once!
> This would happen when a member executing the task is suspected and is removed from the cluster. The protocol handles this by resubmitting the request in Executing#handleView. I note the following JavaDoc
> // The person currently servicing our request has gone down
> // without completing so we have to keep our request alive by
> // sending ours back to the coordinator
> The problem is that there is no guarantee that the request was not completed.
> For my application a member executing the task had a absurdly long GC pause (30s) which meant it was temporarily removed from the cluster, when the pause completed it happily continued executing the task which had already been resubmitted and completed. The task in question involves modifying the database and is quite destructive, so you can imagine the fallout.
> I was hoping to get an opinion of if we think this behaviour is correct, especially since we are implementing a standard java,util.concurrent interface. (I couldn't find anything in the ExecutorService JavaDoc to say it is wrong though)
> Perhaps there could be control over the behaviour:
> * At least once - assumes task failed and resubmits
> * At most once - assumes task completed and cleans up - may not actually be complete
> * Exactly once - not sure if this is possible
> {quote}
> There is a simple change to exhibit the at least once behaviour by ignoring consumers that have left. I have the patch in my fork:
> https://github.com/anujshahwork/JGroups/commit/0f2c1f6f9ed57744841acdd192...
> Which my project is using. This can be wrapped in some simple configuration on the protocol to control the behaviour and would be a useful addition.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 11 months
[JBoss JIRA] (JGRP-1908) Optional Executing protocol behavior to not attempt to repeat tasks
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1908?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1908:
---------------------------
Fix Version/s: 3.6.2
> Optional Executing protocol behavior to not attempt to repeat tasks
> -------------------------------------------------------------------
>
> Key: JGRP-1908
> URL: https://issues.jboss.org/browse/JGRP-1908
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Anuj Shah
> Assignee: William Burns
> Labels: executionservice
> Fix For: 3.6.2
>
>
> As discussed on forum:
> http://jgroups.1086181.n5.nabble.com/jgroups-users-ExecutionService-at-le...
> {quote}
> I've noticed that runnable tasks submitted to the ExecutionService can be run more than once!
> This would happen when a member executing the task is suspected and is removed from the cluster. The protocol handles this by resubmitting the request in Executing#handleView. I note the following JavaDoc
> // The person currently servicing our request has gone down
> // without completing so we have to keep our request alive by
> // sending ours back to the coordinator
> The problem is that there is no guarantee that the request was not completed.
> For my application a member executing the task had a absurdly long GC pause (30s) which meant it was temporarily removed from the cluster, when the pause completed it happily continued executing the task which had already been resubmitted and completed. The task in question involves modifying the database and is quite destructive, so you can imagine the fallout.
> I was hoping to get an opinion of if we think this behaviour is correct, especially since we are implementing a standard java,util.concurrent interface. (I couldn't find anything in the ExecutorService JavaDoc to say it is wrong though)
> Perhaps there could be control over the behaviour:
> * At least once - assumes task failed and resubmits
> * At most once - assumes task completed and cleans up - may not actually be complete
> * Exactly once - not sure if this is possible
> {quote}
> There is a simple change to exhibit the at least once behaviour by ignoring consumers that have left. I have the patch in my fork:
> https://github.com/anujshahwork/JGroups/commit/0f2c1f6f9ed57744841acdd192...
> Which my project is using. This can be wrapped in some simple configuration on the protocol to control the behaviour and would be a useful addition.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 11 months