December 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBCLUSTER-140) Examine need for a distributed service registry outside the AS

by Brian Stansberry (JIRA)

Examine need for a distributed service registry outside the AS -------------------------------------------------------------- Key: JBCLUSTER-140 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-140 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Q3Y6 Is something like DRM needed outside the AS? If it is, do we want to use the JBoss Cache based version (creates JBC dependency.) DRM is used in two ways: 1) To maintain a distributed registry of remote invocation targets. 2) To maintain a distributed registry of services, which is done by having the service register a meaningless token under its key rather than a target. This is used by HASingleton. Need to examine whether this kind of thing is needed by Messaging, or whether simple listening for view changes is sufficient. Listening for view changes could be sufficient if each group member knew how to create a Remoting InvokerLocator for the other members based on the JGroups Address. But, this presupposes use of consistent ports across the cluster, and that the IP address used by JGroups is the one that Messaging traffic should use. -- 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

13 years, 5 months

2
5
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-144) Consider other clustering code that can be removed from the AS

by Brian Stansberry (JIRA)

Consider other clustering code that can be removed from the AS -------------------------------------------------------------- Key: JBCLUSTER-144 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-144 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Q4Y6 Things like the http session replication code that we've considered integrating into Tomcat. -- 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

13 years, 5 months

2
4
0 / 0

[JBoss JIRA] Created: (JBCLUSTER-141) Create a generic HA Singleton API

by Brian Stansberry (JIRA)

Create a generic HA Singleton API --------------------------------- Key: JBCLUSTER-141 URL: http://jira.jboss.com/jira/browse/JBCLUSTER-141 Project: JBoss Clustering Issue Type: Sub-task Security Level: Public (Everyone can see) Reporter: Brian Stansberry Assigned To: Brian Stansberry Fix For: Q3Y6 Also want to extract the HASingletonElectionPolicy code from the AS codebase. -- 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

13 years, 5 months

2
5
0 / 0

[JBoss JIRA] Created: (JBRULES-1135) Move generation should be described in a drl

by Geoffrey De Smet (JIRA)

Move generation should be described in a drl -------------------------------------------- Key: JBRULES-1135 URL: http://jira.jboss.com/jira/browse/JBRULES-1135 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Solver Affects Versions: 4.0.0.GA Reporter: Geoffrey De Smet Assigned To: Geoffrey De Smet Fix For: FUTURE instead of MoveFactory POJO -- 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

13 years, 7 months

1
4
0 / 0

[JBoss JIRA] Created: (JGRP-403) Refactoring of MessageDispatcher, RpcDispatcher, RequestCorrelator and GroupRequest

by Bela Ban (JIRA)

Refactoring of MessageDispatcher, RpcDispatcher, RequestCorrelator and GroupRequest ----------------------------------------------------------------------------------- Key: JGRP-403 URL: http://jira.jboss.com/jira/browse/JGRP-403 Project: JGroups Issue Type: Task Affects Versions: 2.4 Reporter: Bela Ban Assigned To: Bela Ban Fix For: 3.0 We may be able to trash GroupRequest and RequestCorrelator, this functionality can be provided by MessageDispatcher -- 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

13 years, 7 months

2
1
0 / 0

[JBoss JIRA] Created: (JBRULES-1232) [solver] Selector refactor: configurable subset selections, topList usage etc

by Geoffrey De Smet (JIRA)

[solver] Selector refactor: configurable subset selections, topList usage etc ----------------------------------------------------------------------------- Key: JBRULES-1232 URL: http://jira.jboss.com/jira/browse/JBRULES-1232 Project: JBoss Rules Issue Type: Task Security Level: Public (Everyone can see) Components: Solver Reporter: Geoffrey De Smet Assigned To: Geoffrey De Smet Currently all moves are evaluated at every step (with a MaxAllForager at least) if you use the basic cached move factory selector. This doesn't scale well, especially for big data problems where in the beginning, just about every moves improves. The neighbourhood size (= amount of selected moves) could for example increase block-wise or timeGradient-wise until an improving solution is found. Notice the difference with the usage of FirstImprovingForager. -- 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

13 years, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBRULES-540) Create a Java Interface to allow JavaBeans to work more seamlessly as Facts

by Mark Proctor (JIRA)

Create a Java Interface to allow JavaBeans to work more seamlessly as Facts ----------------------------------------------------------------------------- Key: JBRULES-540 URL: http://jira.jboss.com/jira/browse/JBRULES-540 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Rule Assemply/SPI Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 3.1-m1 We want to move management of the bean and its working memory up a layer. When a bean is instantiated by an IoC framework it should weave in an interface to provide better background interoprability between the bean and working memories. further the IoC container should control the life cycle, assert and retract, of that bean in various working memories. -- 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

13 years, 7 months

3
6
0 / 0

[JBoss JIRA] Created: (JBRULES-1226) allow capture of match groups in 'matches' clauses

by Godmar Back (JIRA)

allow capture of match groups in 'matches' clauses -------------------------------------------------- Key: JBRULES-1226 URL: http://jira.jboss.com/jira/browse/JBRULES-1226 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 4.0.1 Reporter: Godmar Back Assigned To: Mark Proctor Please add a way to capture match groups in matches clauses. See http://lists.jboss.org/pipermail/rules-users/2007-September/003227.html -- 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

13 years, 7 months

4
7
0 / 0

[JBoss JIRA] Created: (JBRULES-1322) Accumulate functions are highly unreliable for long's and BigDecimals

by Geoffrey De Smet (JIRA)

Accumulate functions are highly unreliable for long's and BigDecimals --------------------------------------------------------------------- Key: JBRULES-1322 URL: http://jira.jboss.com/jira/browse/JBRULES-1322 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: Drl Parser/Builder Affects Versions: 4.0.3 Reporter: Geoffrey De Smet Assigned To: Edson Tirelli Priority: Critical Fix For: 4.1.0 When dealing with financial data, one should never ever use double's. Instead BigDecimal should be used. Not because BigDecimal is bigger (that's rarely a problem) but because it doesn't do any decimal to binary transformation. For example, it's impossible for a double to correctly represent "0.2", aka 1/5. Summing many doubles (or even a few differing in scale), can easily give wrong results (and for financial data this tends to be important). Using doubles to sum longs have the exact same problem. Attached is a testcase patch which proves this by checking if (MAX_LONG - 4L) and 3L sum up to be (MAX_LONG - 1L). Currently they don't. One possible way to solve this is to fix JBRULES-1075, which just happens to give drools-solver 3% more performance ;) what a coincidence ^^ -- 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

13 years, 7 months

3
21
0 / 0

[JBoss JIRA] Created: (EJBTHREE-1096) Make SLSB and SFSB hot deployable for RAD

by Jason Long (JIRA)

Make SLSB and SFSB hot deployable for RAD ----------------------------------------- Key: EJBTHREE-1096 URL: http://jira.jboss.com/jira/browse/EJBTHREE-1096 Project: EJB 3.0 Issue Type: Feature Request Affects Versions: AS 4.2.2.GA, AS 4.2.1.GA, AS 4.2.0 GA, AS 5.0.0.Beta3, AS 4.2.3.GA, Branch_4_2, Branch_4_4, HEAD Reporter: Jason Long Fix For: AS 4.2.3.GA Seam POJO components are hot deployable for RAD. It would be great if SFSB and SLSB could be used in the same manner. -- 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

13 years, 7 months

13
28
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2007