January 2008 - jboss-jira - Jboss List Archives

[JBoss JIRA] Commented: (JBRULES-46) Backward Chaining

by kk Kailasam (JIRA)

[ http://jira.jboss.com/jira/browse/JBRULES-46?page=comments#action_12396173 ] kk Kailasam commented on JBRULES-46: ------------------------------------ Will this feature be available in 5.0? Thanks. > Backward Chaining > ----------------- > > Key: JBRULES-46 > URL: http://jira.jboss.com/jira/browse/JBRULES-46 > Project: JBoss Drools > Issue Type: Feature Request > Security Level: Public(Everyone can see) > Reporter: Mark Proctor > Assigned To: Mark Proctor > > Forward Chaining means that facts are asserted and propgated forward throughout the network, during forward propagation matching takes place which results in rules being fired - the rules are event based, in that they are fired in response to changed in the working memory. > Backward chaining is query based. Rules attempt to fire first but do not have the necessary matched facts, so facts are pulled in from an external source. -- 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

18 years, 5 months

1
0
0 / 0

[JBoss JIRA] Created: (JBCACHE-1231) Implicit use of MarshalledValues in the cache

by Manik Surtani (JIRA)

Implicit use of MarshalledValues in the cache --------------------------------------------- Key: JBCACHE-1231 URL: http://jira.jboss.com/jira/browse/JBCACHE-1231 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.0.0.GA, 2.1.0.CR2 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.1.0.GA Do not use region-based marshalling in the CacheMarshaller; instead, allow for implicit MarshalledValues in the cache which capture the thread's context class loader when an object is inserted into the cache. -- 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

18 years, 5 months

1
3
0 / 0

[JBoss JIRA] Created: (JGRP-664) CopyOnWrite collections should be synchronized

by Bela Ban (JIRA)

CopyOnWrite collections should be synchronized ---------------------------------------------- Key: JGRP-664 URL: http://jira.jboss.com/jira/browse/JGRP-664 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.4.2, 2.6.2, 2.7 [email from Rick Pike] Sometimes when we have nodes start suspecting each other we see intermittent: 2008-01-14 06:49:37,464 [ERROR] UDP failed handling incoming message java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.concurrent.CopyOnWriteArrayList.rangeCheck(CopyOnWriteArrayList.java:708) at java.util.concurrent.CopyOnWriteArrayList.get(CopyOnWriteArrayList.java:328) at org.jgroups.protocols.FD.getPingDest(FD.java:151) at org.jgroups.protocols.FD.up(FD.java:305) at org.jgroups.protocols.FD_ICMP.up(FD_ICMP.java:108) at org.jgroups.protocols.MERGE3.up(MERGE3.java:126) at org.jgroups.protocols.Discovery.up(Discovery.java:246) at org.jgroups.protocols.TP$IncomingPacket.handleMyMessage(TP.java:1535) at org.jgroups.protocols.TP$IncomingPacket.run(TP.java:1484) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675) at java.lang.Thread.run(Thread.java:595) It looks like there's 4 places in FD that modify the pingable_mbrs list: 1. up(HEARTBEAT_ACK) 2. up(SUSPECT) 3. down(VIEW_CHANGE) 4. down(UNSUSPECT) Only #1 and #3 appear to synchronize{} around the edits, and I believe that a concurrent (UN)SUSPECT message is emptying that list whille the HEARTBEAT_ACK is looping and repeatedly reading - inside getPingDest(). Every so often, it calls get(0) on an empty list. We just started seeing this when we started testing with FD_ICMP, but I imagine this would happen with any flavor, and we're seeing it due to the high volume of SUSPECT messages happening in our tests. -- 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

18 years, 5 months

1
5
0 / 0

[JBoss JIRA] Created: (EJBTHREE-853) Partial StringProperty replacement in ejb 3 container

by Roland R?z (JIRA)

Partial StringProperty replacement in ejb 3 container ----------------------------------------------------- Key: EJBTHREE-853 URL: http://jira.jboss.com/jira/browse/EJBTHREE-853 Project: EJB 3.0 Issue Type: Feature Request Affects Versions: EJB 3.0 RC9 - FD Reporter: Roland R?z I tried to change the messageSelector in an EJB 3.0 MDB in the ejb.jar.xml containing partial System Property references (aaa${xyz}bbb). Sadly this didn't work as with ejb 2.1. I think fully supporting system property replacement as with ejb 2.x in EJB 3.0 would be a nice feature. The method org.jboss.ejb3.metamodel.EjbJarDDObjectFactory.getValue(String name, String value) could be changed to { value = org.jboss.util.StringPropertyReplacer.replaceProperties(value); } I would suggest, to implement the string property replacement even better in the class org.jboss.metamodel.descriptor.DDObjectFactory.getValue() and remove the getValue method from JBossDDObjectFactory and EjbJarDDObjectFactory. The idea of using an MBean abstraction to replace system properties is fine but the nice syntax of the StringPropertyReplacer should be still supported (${v1,v2:default}). Returning always the replaced property is one possibility (currently it is not done this way) but probably a new method "getReplaced" would be less surprising. -- 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

18 years, 5 months

2
1
0 / 0

[JBoss JIRA] Created: (JBWEB-100) Accept filters never work

by Remy Maucherat (JIRA)

Accept filters never work ------------------------- Key: JBWEB-100 URL: http://jira.jboss.com/jira/browse/JBWEB-100 Project: JBoss Web Issue Type: Bug Security Level: Public (Everyone can see) Components: Core Reporter: Remy Maucherat Assigned To: Jean-Frederic Clere Priority: Minor Even on platforms where support is supposed to be present (for example, Fedora 8 with the tomcat-native RPM installed, running on IcedTea), accept filters are always reported as not available by the APR listener. Library.APR_HAS_SO_ACCEPTFILTER always returns false (the other flags appear to be working correctly). -- 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

18 years, 5 months

1
0
0 / 0

[JBoss JIRA] Created: (JGRP-660) Model FLUSH in Promela and run simulations in Spin

by Vladimir Blagojevic (JIRA)

Model FLUSH in Promela and run simulations in Spin -------------------------------------------------- Key: JGRP-660 URL: http://jira.jboss.com/jira/browse/JGRP-660 Project: JGroups Issue Type: Feature Request Reporter: Vladimir Blagojevic Assigned To: Vladimir Blagojevic We should model FLUSH in Promela and run model simulations in SPIN. Verify feasibility and cost/benefit of this approach. If the outcome is beneficial consider modeling other protocols as well. -- 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

18 years, 5 months

2
1
0 / 0

[JBoss JIRA] Created: (JGRP-670) Replace StringBuffer with StringBuilder

by Bela Ban (JIRA)

Replace StringBuffer with StringBuilder --------------------------------------- Key: JGRP-670 URL: http://jira.jboss.com/jira/browse/JGRP-670 Project: JGroups Issue Type: Task Reporter: Bela Ban Assigned To: Bela Ban Priority: Minor Fix For: 2.6.2, 2.7 Perf increase -- 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

18 years, 5 months

1
1
0 / 0

[JBoss JIRA] Created: (JGRP-669) Shared transport: NPE in up() when loopback is true

by Bela Ban (JIRA)

Shared transport: NPE in up() when loopback is true --------------------------------------------------- Key: JGRP-669 URL: http://jira.jboss.com/jira/browse/JGRP-669 Project: JGroups Issue Type: Bug Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.6.2, 2.7 The loopback handling code doesn't check whether we have a shared transport and calls up_prot.up() indiscriminately. However, when we have a shared transport, up_prot is null... -- 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

18 years, 5 months

1
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-1255) setUseInterceptorMbeans not available in TreeCacheMBean interface, causing problems when deployed in JBoss AS

by Manik Surtani (JIRA)

setUseInterceptorMbeans not available in TreeCacheMBean interface, causing problems when deployed in JBoss AS ------------------------------------------------------------------------------------------------------------- Key: JBCACHE-1255 URL: http://jira.jboss.com/jira/browse/JBCACHE-1255 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 1.4.1.SP8 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 1.4.1.SP9 Should check that all setters that correspond to configuration elements in TreeCache also exist in TreeCacheMBean -- 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

18 years, 5 months

1
3
0 / 0

[JBoss JIRA] Created: (JBCACHE-1230) Node.toString() should not print entire contents of a node if it exceeds a certain size

by Manik Surtani (JIRA)

Node.toString() should not print entire contents of a node if it exceeds a certain size --------------------------------------------------------------------------------------- Key: JBCACHE-1230 URL: http://jira.jboss.com/jira/browse/JBCACHE-1230 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Affects Versions: 2.1.0.CR2 Reporter: Manik Surtani Assigned To: Manik Surtani Priority: Minor Fix For: 2.1.0.GA Can be very noisy in the logs -- 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

18 years, 5 months

1
5
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 January 2008