December 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBRULES-1330) Using RuleBase in multithread application server environment

by Navaljit Bhasin (JIRA)

Using RuleBase in multithread application server environment ------------------------------------------------------------ Key: JBRULES-1330 URL: http://jira.jboss.com/jira/browse/JBRULES-1330 Project: JBoss Drools Issue Type: Bug Security Level: Public (Everyone can see) Components: Rule Flow Affects Versions: 4.0.3 Environment: Red Hat Linux as OS, weblogic 9.2 using jrockit-1.5.0_10 Reporter: Navaljit Bhasin We are deploying an applcation which has one major component which executes rules. At the startup of the application server, we load the various rules and save them in a hashmap with appropriate key. The value of these HashMaps is RuleBase. This is part of a singleton service. The applcation is based on JMS. A MDB receives message, calls the sigleton service to get stateful session from a specific RuleBase ( saved in HashMap by key as mentioned above). This singleton service get the RuleBase from Map, call newStatefulSession(false) on this RuleBase object and return the new StatefulSession. This works fine as long as we have one MDB on the application server. When we increase the number of MDB's to more than one, and both MDB's process the messages( different messages) simultaneously, the results from stateful session rule firing are messed up. It skips amny valid LHS and so on. I even tried using the Stateless Session, but the results are still messed up. So my question is: Can we use the Rulebase in multithreaded environment ? My understanding was that we can use it. There should be no interaction between various stateful sessions received from same rulebase object. If we can't use it this way, the we have build it form PackageBuilder for every invocation. There are lots of complex rules and for hundreds of calls it adds up to considerable waste of resources. Thanks for reading this bug report Can you please post or email me the code to use the statefule sessions from a RuleBase object in multithreaded environment? -- 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

16 years, 10 months

2
9
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1200) Session.executor is leaking the first classLoader used

by Clebert Suconic (JIRA)

Session.executor is leaking the first classLoader used ------------------------------------------------------ Key: JBMESSAGING-1200 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1200 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.4.0.SP2 Reporter: Clebert Suconic Assigned To: Clebert Suconic The Session.executor is holding the first ClassLoader reference on its ThreadContextClassLoader. This is also causing invalid classLoader usages when the first ClassLoader used was undeployed, and could lead to other problems on ObjectMessages and StreamMessages. (things like ClassNotFound becuase it's using the wrong classLoader on the executor). -- 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

16 years, 10 months

2
8
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-480) Change contract of Receiver

by Tim Fox (JIRA)

Change contract of Receiver --------------------------- Key: JBMESSAGING-480 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-480 Project: JBoss Messaging Issue Type: Sub-task Reporter: Tim Fox -- 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

16 years, 10 months

3
5
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-876) Allow onMessage to be executed on the remoting thread

by Tim Fox (JIRA)

Allow onMessage to be executed on the remoting thread ----------------------------------------------------- Key: JBMESSAGING-876 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-876 Project: JBoss Messaging Issue Type: Sub-task Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.1 As an optimisation we should allow message listeners to be executed straight through using the same thread that delivers the message to the message callback handler. This would avoid an extra context switch.. Currently the thread used is from an executor per session - so as to be strictly JMS compliant. -- 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

16 years, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1209) Abstract out JMS selector

by Tim Fox (JIRA)

Abstract out JMS selector ------------------------- Key: JBMESSAGING-1209 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1209 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assigned To: Tim Fox Fix For: 2.0.0 Beta We need to abstract out our current JMS selector so can be used in the new core. -- 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

16 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1143) Acknowledge in single tx optimisation

by Tim Fox (JIRA)

Acknowledge in single tx optimisation ------------------------------------- Key: JBMESSAGING-1143 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1143 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assigned To: Tim Fox Fix For: 2.0.0 Beta Current for client_ack or dups_ok we acknowledge each message in the list in a separate jdbc tx when persistent - this can be done in a single tx Furthermore, no need to send the complete list of ids to acknowledge - they will be contiguent - and can be worked out from the delivery list in the session. For a transacted session the same applies. -- 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

16 years, 10 months

1
1
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1039) HTTP poller doesn't stop

by Tim Fox (JIRA)

HTTP poller doesn't stop ------------------------ Key: JBMESSAGING-1039 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1039 Project: JBoss Messaging Issue Type: Bug Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.4.0.CR2 I have temporarily commented out clusterviewupdatetst::testUpdateMixedConnectionFactory since, once started, the HTTP poller doesn't stop. Maybe this is a bug in remoting - need to investigate. -- 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

16 years, 10 months

1
7
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1021) Move client side transaction state to the server side

by Tim Fox (JIRA)

Move client side transaction state to the server side ----------------------------------------------------- Key: JBMESSAGING-1021 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1021 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assigned To: Tim Fox Fix For: 2.0.0 Beta 1 Currently we hold the incomplete JMS transactional state on the client side and send it all in one go on commit. Instead we should store it on the server side. This will simplify things and allow larger transactions to be built without a large pause on commit or exhausting client side memory -- 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

16 years, 10 months

1
4
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-989) Core refactoring

by Tim Fox (JIRA)

Core refactoring ---------------- Key: JBMESSAGING-989 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-989 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assigned To: Tim Fox Fix For: 2.0.0 Beta 1 Core refactoring- The old core classes are in dire need of reviewing and refactoring. The hierarchy of channel classes should be collapsed for simplicity, since there is only one real implementation of a channel. And the router class should be re-examined - do we need iterator etc Do we need iterator on the channel? All classes should be made cluster aware (including router). We can simplify things a *lot*! -- 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

16 years, 10 months

1
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-1014) Look at JGroups anycast

by Tim Fox (JIRA)

Look at JGroups anycast ----------------------- Key: JBMESSAGING-1014 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1014 Project: JBoss Messaging Issue Type: Task Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.4.0.CR2 To avoid issue with having to multicast even when there is only one subscriber -- 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

16 years, 10 months

1
4
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira December 2007