[JBoss JIRA] (DROOLS-15) Major problem in Rules evaluation. Can not sort Integers correctly
by John Smith (JIRA)
John Smith created DROOLS-15:
--------------------------------
Summary: Major problem in Rules evaluation. Can not sort Integers correctly
Key: DROOLS-15
URL: https://issues.jboss.org/browse/DROOLS-15
Project: Drools
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: John Smith
Assignee: Mark Proctor
Priority: Blocker
This sample is given in the drools documentation http://docs.jboss.org/drools/release/5.5.0.Final/drools-expert-docs/html_.... This drool rule is expected to sort integers. I just changed the numbers from what are given in the sample and they do not get sorted as expected. Tried using drools version 5.5.0, 5.5.1 and the master 6.0.0, but got the same wrong results.
Following is the main code:
package com.sample;
public class Example2 {
public static void main(String[] args) throws Exception {
Number[] numbers = new Number[] { wrap(5), wrap(6), wrap(4), wrap(1), wrap(2) };
new RuleRunner().runRules(new String[] { "Example3.drl" }, numbers);
}
private static Integer wrap(int i) {
return new Integer(i);
}
}
The RuleRunner class is the same as given in the example and I do not think I should give that here, since it will clutter the question. It simply creates the KnowledgeBase, stateful session, inserts the facts as given in the 'numbers' array above and then calls fireAllRules method on the session.
The rule file (Example3.drl) is:
rule "Rule Sort"
dialect "mvel"
when
$number : Number()
not Number(intValue < $number.intValue)
then
System.out.println("Number found with value: " + $number.intValue());
retract($number);
end
The output I get is as follows:
Loading file: Example3.drl
Inserting fact: 5
Inserting fact: 6
Inserting fact: 4
Inserting fact: 1
Inserting fact: 2
Number found with value: 1
Number found with value: 4
Number found with value: 2
Number found with value: 5
Number found with value: 6
Not the correct expected ascending sorted order.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (JGRP-1564) TP: handling of message batches
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1564?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1564:
--------------------------------
I guess the showtopper for MSG_BATCH is that a batch can contain messages from many protocols, e.g. FRAG(2), UNICAST(2), NAKACK(2), Discovery, STABLE, FD_SOCK etc.
Each protocol would have to iterate through the message batch and remove the message(s) it is interested in handling.
This would require a lot of changes in a lot of places. On top of that, if a protocol developer forgets to handle MSG_BATCH in addition to MSG, then the protocol will miss some messages.
> TP: handling of message batches
> -------------------------------
>
> Key: JGRP-1564
> URL: https://issues.jboss.org/browse/JGRP-1564
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> When B receives a batch of 5 messages from A (unicast or multicast), then B uses the *same thread* to send the 5 messages up (this isn't the case for OOB messages).
> It would be more efficient to either have different threads passing the 5 messages up, or use a new *message batch event type* to pass all 5 messages up in one go.
> The advantage of different threads is that all 5 threads add their message to the window, but only 1 removes them and passes them up, rather than each thread adding and removing its own message (fewer lock acquisitions).
> We could try moving the unmarshalling of messages and message batches into TP.receive(). If a batch was received, that code could unmarshal the 5 messages and pass them to corresponding thread pools to send them up.
> The unmarshalling shouldn't take long, so TP.receive() should return quickly.
> This approach would allow us to send OOB messages in message batches, too (currently not allowed).
> The advantage of a message batch is that we pass *one* event up the stack, passing only *once* through all protocols from TP to UNICAST/2 and NAKACK/2, and not 5 times. Also, adding 5 messages to the window under the same lock is more eficient than acquiring the lock 5 times. Ditto for removal.
> The disadvantage is that we now need to handle a different event type (all protocols under UNICAST/NAKACK), e.g. ENCRYPT, SIZE, FRAG(2) (if placed under UNICAST/NAKACK), COMPRESS etc.
> Also, this solution is not symmetric, ie. messages are batched at the transport level, and should be unbatched at the transport level of the receiver(s) as well...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (JGRP-1564) TP: handling of message batches
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1564?page=com.atlassian.jira.plugin.... ]
Bela Ban updated JGRP-1564:
---------------------------
Description:
When B receives a batch of 5 messages from A (unicast or multicast), then B uses the *same thread* to send the 5 messages up (this isn't the case for OOB messages).
It would be more efficient to either have different threads passing the 5 messages up, or use a new *message batch event type* to pass all 5 messages up in one go.
The advantage of different threads is that all 5 threads add their message to the window, but only 1 removes them and passes them up, rather than each thread adding and removing its own message (fewer lock acquisitions).
We could try moving the unmarshalling of messages and message batches into TP.receive(). If a batch was received, that code could unmarshal the 5 messages and pass them to corresponding thread pools to send them up.
The unmarshalling shouldn't take long, so TP.receive() should return quickly.
This approach would allow us to send OOB messages in message batches, too (currently not allowed).
The advantage of a message batch is that we pass *one* event up the stack, passing only *once* through all protocols from TP to UNICAST/2 and NAKACK/2, and not 5 times. Also, adding 5 messages to the window under the same lock is more eficient than acquiring the lock 5 times. Ditto for removal.
The disadvantage is that we now need to handle a different event type (all protocols under UNICAST/NAKACK), e.g. ENCRYPT, SIZE, FRAG(2) (if placed under UNICAST/NAKACK), COMPRESS etc.
Also, this solution is not symmetric, ie. messages are batched at the transport level, and should be unbatched at the transport level of the receiver(s) as well...
was:
When B receives a batch of 5 messages from A (unicast or multicast), then B uses the *same thread* to send the 5 messages up (this isn't the case for OOB messages).
It would be more efficient to either have different threads passing the 5 messages up, or use a new *message batch event type* to pass all 5 messages up in one go.
The advantage of different threads is that all 5 threads add their message to the window, but only 1 removes them and passes them up, rather than each thread adding and removing its own message (fewer lock acquisitions).
We could try moving the unmarshalling of messages and message batches into TP.receive(). If a batch was received, that code could unmarshal the 5 messages and pass them to corresponding thread pools to send them up.
The unmarshalling shouldn't take long, so TP.receive() should return quickly.
This approach would allow us to send OOB messages in message batches, too (currently not allowed).
The advantage of a message batch is that we pass *one* event up the stack, passing only *once* through all protocols from TP to UNICAST/2 and NAKACK/2, and not 5 times. Also, adding 5 messages to the window under the same lock is more eficient than acquiring the lock 5 times. Ditto for removal.
The disadvantage is that we now need to handle a different event type (all protocols under UNICAST/NAKACK), e.g. ENCRYPT etc.
Also, this solution is not symmetric, ie. messages are batched at the transport level, and should be unbatched at the transport level of the receiver(s) as well...
> TP: handling of message batches
> -------------------------------
>
> Key: JGRP-1564
> URL: https://issues.jboss.org/browse/JGRP-1564
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> When B receives a batch of 5 messages from A (unicast or multicast), then B uses the *same thread* to send the 5 messages up (this isn't the case for OOB messages).
> It would be more efficient to either have different threads passing the 5 messages up, or use a new *message batch event type* to pass all 5 messages up in one go.
> The advantage of different threads is that all 5 threads add their message to the window, but only 1 removes them and passes them up, rather than each thread adding and removing its own message (fewer lock acquisitions).
> We could try moving the unmarshalling of messages and message batches into TP.receive(). If a batch was received, that code could unmarshal the 5 messages and pass them to corresponding thread pools to send them up.
> The unmarshalling shouldn't take long, so TP.receive() should return quickly.
> This approach would allow us to send OOB messages in message batches, too (currently not allowed).
> The advantage of a message batch is that we pass *one* event up the stack, passing only *once* through all protocols from TP to UNICAST/2 and NAKACK/2, and not 5 times. Also, adding 5 messages to the window under the same lock is more eficient than acquiring the lock 5 times. Ditto for removal.
> The disadvantage is that we now need to handle a different event type (all protocols under UNICAST/NAKACK), e.g. ENCRYPT, SIZE, FRAG(2) (if placed under UNICAST/NAKACK), COMPRESS etc.
> Also, this solution is not symmetric, ie. messages are batched at the transport level, and should be unbatched at the transport level of the receiver(s) as well...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-1535) More management operations for timers
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/AS7-1535?page=com.atlassian.jira.plugin.s... ]
Bartosz Baranowski commented on AS7-1535:
-----------------------------------------
Just thinking out loud:
timer:list || timer:list(target="") || timer:list(service="")
timer:suspend(id="", service="", target="")
timer:cancel(id="", service="", target="")
timer:trigger(id="", service="", target="") || timer:trigger(id="", service="", target="", update=false)
> More management operations for timers
> -------------------------------------
>
> Key: AS7-1535
> URL: https://issues.jboss.org/browse/AS7-1535
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Domain Management, EJB
> Reporter: Stuart Douglas
> Assignee: Bartosz Baranowski
> Fix For: 7.3.0.Alpha1
>
>
> Using the management api it should be possible to perform additional operations on timers such as:
> suspending
> cancelling
> invoking a timeout method
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (SECURITY-722) SPNEGO-fallback-to-FORM authentication does not work with httpd+JBossEAP6 if SPNEGO not available
by flame liu (JIRA)
[ https://issues.jboss.org/browse/SECURITY-722?page=com.atlassian.jira.plug... ]
flame liu commented on SECURITY-722:
------------------------------------
Hi Darran,
If I set ProxyErrorOverride to Off in httpd, and if SPNEGO fails, it turns to the page showing source code.
<html>
<head>
<title>Form Authentication</title>
</head>
<body>
<h1>Form Authentication</h1>
<p>If this page is displayed your web broweser is not taking part in the
SPNEGO process, a username and password can be entered instead to fall
back to username/password authentication.</p>
<hr>
<p>
<form method=post action="j_security_check" >
<table>
<tr>
<td>Username</td><td>-</td>
<td><input type="text" name= "j_username" ></td>
</tr>
<tr>
<td>Password</td><td>-</td>
<td><input type="password" name= "j_password" ></td>
</tr>
<tr>
<td colspan="2"><input type="submit"></td>
</tr>
</table>
</form>
</p>
<hr>
</body>
</html>
> SPNEGO-fallback-to-FORM authentication does not work with httpd+JBossEAP6 if SPNEGO not available
> -------------------------------------------------------------------------------------------------
>
> Key: SECURITY-722
> URL: https://issues.jboss.org/browse/SECURITY-722
> Project: PicketBox
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Negotiation
> Affects Versions: Negotiation_2_2_1
> Environment: RHEL6, JBoss EAP 6
> Reporter: flame liu
> Assignee: Darran Lofthouse
>
> I configured SPNEGO in EAP6. It works well both with EAP only and EAP6 + Apache httpd(mod_proxy). Users just run kinit and will be able to be successfully authenticated.
> After that, I added the fallback-to-form files/configurations both in the web app and standalone-full.xml. The fallback-to-form works only if httpd stops. If httpd starts, 401 error will always be thrown out.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months
[JBoss JIRA] (AS7-6347) Upgrade to MSC 1.1.0.Beta3
by Richard Opalka (JIRA)
Richard Opalka created AS7-6347:
-----------------------------------
Summary: Upgrade to MSC 1.1.0.Beta3
Key: AS7-6347
URL: https://issues.jboss.org/browse/AS7-6347
Project: Application Server 7
Issue Type: Task
Components: MSC
Reporter: Richard Opalka
Assignee: Richard Opalka
Fix For: 7.2.0.Alpha1
The upgrade to MSC 1.1.x branch includes code cleanup
to remove all the proprietary solutions for detecting
when ServiceControllers are in REST state plus it removes
all usages of deprecated ServiceListener.Inheritance feature.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 5 months