June 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-572) Add clustering stress tests

by Tim Fox (JIRA)

Add clustering stress tests --------------------------- Key: JBMESSAGING-572 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-572 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.0.Beta1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years

6
12
0 / 0

[JBoss JIRA] Created: (JBRULES-688) Manual and user Guide for BRMS version 1

by Michael Neale (JIRA)

Manual and user Guide for BRMS version 1 ---------------------------------------- Key: JBRULES-688 URL: http://jira.jboss.com/jira/browse/JBRULES-688 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: drools-brms Reporter: Michael Neale Assigned To: Michael Neale Fix For: 3.1-m2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years

2
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1048) TreeCache registers channel in JMX if it doesn't get it from ChannelFactory

by Brian Stansberry (JIRA)

TreeCache registers channel in JMX if it doesn't get it from ChannelFactory --------------------------------------------------------------------------- Key: JBCACHE-1048 URL: http://jira.jboss.com/jira/browse/JBCACHE-1048 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Manik Surtani Fix For: 1.4.1.SP4 The JON team wants to be able to monitor all channels in the AS via JMX (see JGRP-207). But, channels only get registered in JMX if they are created via a call to JChannelFactory.createMultiplexerChannel(). AS 4.2 currently doesn't use the multiplexer, so none of the JBC-created channels are created this way. Workaround suggestion is to have JBC register the channel it creates via a call to org.jgroups.jmx.JmxConfigurator.registerChannel(). An unregisterChannel call would have to be added any time the channel is closed as well. I marked this for SP4 but the real intent is it would be included in a CP release for AS 4.2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years

1
2
0 / 0

[JBoss JIRA] Created: (JBRULES-847) Continously updating facts and firing rules leads to OutOfMemoryException

by Lars Ivar Igesund (JIRA)

Continously updating facts and firing rules leads to OutOfMemoryException ------------------------------------------------------------------------- Key: JBRULES-847 URL: http://jira.jboss.com/jira/browse/JBRULES-847 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Reteoo Affects Versions: 3.0.5 Environment: Linux, Eclipse 3.2, JDK 1.6, JBoss Rules from Maven rep Reporter: Lars Ivar Igesund Assigned To: Mark Proctor The rules at the end are checked against two facts of type TextileUser. The facts are true for the first rule when asserted. The action modfies the facts to make them true for the other rule, which again make the facts true for the first rule, creating an infinite loop. On my setup, this leads to an OutOfMemoryException after about 40 seconds. Increasing the number of facts to 100 didn't change this. -------------------- rule "User needs textiles" when #conditions tu: TextileUser(wantTextile==true) then #actions tu.collectTextiles(); modify( tu ); end rule "User has dirty textiles" #include attributes such as "salience" here... when #conditions tu: TextileUser(hasDirtyTextiles == true); then #actions tu.returnTextiles(); modify ( tu ); end -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years

3
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-570) Do we need acceptReliableMessages flag on the channel?

by Tim Fox (JIRA)

Do we need acceptReliableMessages flag on the channel? ------------------------------------------------------ Key: JBMESSAGING-570 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-570 Project: JBoss Messaging Issue Type: Task Affects Versions: 1.2.0.Alpha1 Reporter: Tim Fox Priority: Minor Fix For: 1.2.0.Beta1 Is there a real use case for ever setting this to false? I can't think of one in a typical messaging application. If not, we should consider removing this flag. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years

4
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-894) Combine postoffice and clustered post office

by Tim Fox (JIRA)

Combine postoffice and clustered post office -------------------------------------------- Key: JBMESSAGING-894 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-894 Project: JBoss Messaging Issue Type: Task Affects Versions: 1.2.0.CR1 Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.1 We should combine clustered and non clustered post office into one single post office that handles both clusterd and non clustered bindings. This means we can have a single persistence manager config too, and remove all that nasty condition code like If (queue.isClustered()) { postOffice.unbind(); } else { postOffice.clusteredUnbind() } etc which is currently ugly and prone to error -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years

2
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-909) Add tests that test failure on ACK

by Tim Fox (JIRA)

Add tests that test failure on ACK ---------------------------------- Key: JBMESSAGING-909 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-909 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.1 Need to add tests that test failover occuring because an ack failed. This needs to be done for all ack modes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years

2
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-883) Bug in failover with multiple consumers on same queue

by Tim Fox (JIRA)

Bug in failover with multiple consumers on same queue ----------------------------------------------------- Key: JBMESSAGING-883 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-883 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.2.0.CR1 Reporter: Tim Fox Assigned To: Tim Fox Priority: Blocker Fix For: 1.2.0.GA If you have two connections with a consumer each on the same queue, and one of the consumers has consumed a message transactionally but not committed it. Then when failover occurs, if the second connection fails over first then it might "grab" the message before session::recoverDeliveries kicks in for the other connection. This means the message can get delivered more than once. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years

3
21
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1497) Upgrade Jackrabbit to 1.1.1 in 2.4 Branch

by Thomas Heute (JIRA)

Upgrade Jackrabbit to 1.1.1 in 2.4 Branch ----------------------------------------- Key: JBPORTAL-1497 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1497 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal CMS Reporter: Julien Viet Assigned To: Sohil Shah Fix For: 2.6 Final -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years

1
2
0 / 0

[JBoss JIRA] Created: (JBRULES-593) Rule names must be globally unique, even if they come from different packages

by Jeff Lansing (JIRA)

Rule names must be globally unique, even if they come from different packages ----------------------------------------------------------------------------- Key: JBRULES-593 URL: http://jira.jboss.com/jira/browse/JBRULES-593 Project: JBoss Rules Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 3.0.5 Environment: NA Reporter: Jeff Lansing Assigned To: Mark Proctor When 2 DRL rule files with different package names (the name following the 'package' keyword) each have a rule with the same name (the name being the quoted string that follows the 'rule' keyword), then the following exception occurs: org.drools.rule.InvalidRulePackage: Rule Compilation error The type Rule_Incident__Vehicle_0 is already defined at org.drools.rule.Package.checkValidity(Unknown Source) at org.drools.common.AbstractRuleBase.addPackage(Unknown Source) at driver.RulesTest.readRule(RulesTest.java:256) This occurs when using a single org.drools.rule.Package object, as in: private void test(Reader source1, Reader source2) throws Exception { PackageBuilder builder = new PackageBuilder(); builder.addPackageFromDrl( source1 ); builder.addPackageFromDrl( source2 ); Package pkg = builder.getPackage(); RuleBase ruleBase = RuleBaseFactory.newRuleBase(); ruleBase.addPackage( pkg ); } If, on the other hand two org.drools.rule.Package objects are used, as in: private void test2(Reader source1, Reader source2) throws Exception { PackageBuilder builder1 = new PackageBuilder(); PackageBuilder builder2 = new PackageBuilder(); builder1.addPackageFromDrl( source1 ); builder2.addPackageFromDrl( source2 ); Package pkg1 = builder1.getPackage(); Package pkg2 = builder2.getPackage(); RuleBase ruleBase = RuleBaseFactory.newRuleBase(); ruleBase.addPackage( pkg1 ); ruleBase.addPackage( pkg2 ); } then one of the identically named rules is simply ignored. In either case, rule names must be globally unique. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years

3
3
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 June 2007