May 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-819) Use of stopping flag in DefaultClusteredPostOffice introduces race conditions

by Tim Fox (JIRA)

Use of stopping flag in DefaultClusteredPostOffice introduces race conditions ----------------------------------------------------------------------------- Key: JBMESSAGING-819 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-819 Project: JBoss Messaging Issue Type: Bug Affects Versions: 1.2.0.Beta2 Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.0.CR1 Using a stopping flag is not a good approach and introduces a race condition the code can check stopping and find it to be false, then the service can stop, setting stopping to true then actually stopping the post office, then the same thread that checked stopping continues and performs its action only to find the service stopped. Should use a read-write lock instead. One way to minimise the chance of the race happening is to sleep for a little while after setting stopping to true before actually stopping the service (see below) -- 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 month

3
8
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-910) Single persistent message always routed in transaction

by Tim Fox (JIRA)

Single persistent message always routed in transaction ------------------------------------------------------ Key: JBMESSAGING-910 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-910 Project: JBoss Messaging Issue Type: Bug Reporter: Tim Fox Assigned To: Tim Fox Priority: Minor Fix For: 1.2.1 When routing a single persistent message to a single local queue using the clustered router, the logs report that an internal transaction is being created to route it since there are more than one queues. This seems unnecessary. 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

19 years, 1 month

2
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-901) RedistributionWithDefaultMessagePullPolicyTest tests fail occasionally

by Ovidiu Feodorov (JIRA)

RedistributionWithDefaultMessagePullPolicyTest tests fail occasionally ---------------------------------------------------------------------- Key: JBMESSAGING-901 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-901 Project: JBoss Messaging Issue Type: Bug Components: Tests and Performance Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Priority: Blocker Fix For: 1.2.0.GA I marked the failure points with // <- in test -- 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 month

3
10
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-907) Add a new "default redistribution policy" DistributedQueueExample and smoke test

by Ovidiu Feodorov (JIRA)

Add a new "default redistribution policy" DistributedQueueExample and smoke test -------------------------------------------------------------------------------- Key: JBMESSAGING-907 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-907 Project: JBoss Messaging Issue Type: Feature Request Reporter: Ovidiu Feodorov Assigned To: Ovidiu Feodorov Fix For: 1.2.1 The development team came to the conclusion that the best choice for a default message redistribution policy configuration - the configuration the release ships with - is org.jboss.messaging.core.plugin.postoffice.cluster.NullMessagePullPolicy. This is the most common case, and this is what should be the out-of-the-box configuration. However, this renders the current DefaultQueueExample, which assumes a DefaultMessagePolicy, irrelevant. It's actually worse, it breaks it. I am changing the DistributedQueueExample to work with NullMessagePullPolicy, and so make it work out-of-the-box. That also makes it extremely boring. We need to add another DistributedQueueExample, that shows how DefaultMessagePullPolicy works. It will require changing some configuration on the fly, so there is no time to write and test it before 1.2.0. This is the original example (the default distribution policy one): --------------------------------------------------------------------------------------------------------------------------------- /** * The example creates two connections to two distinct cluster nodes on which we have previously * deployed a distributed queue. The example creates and sends a message using a connection, and * attempts to receive the message using the other connection. This is an example of message * redistribution in clustered environment at work. The JBoss Messaging clustered Post Offices * need to be configured with a default message redistribution policy for this example to work * correctly. * * Since this example is also used as a smoke test, it is essential that the VM exits with exit * code 0 in case of successful execution and a non-zero value on failure. * * @author <a href="mailto:ovidiu@jboss.org">Ovidiu Feodorov</a> * @version <tt>$Revision: 1001 $</tt> * * $Id: TopicExample.java 1001 2006-06-24 09:05:40Z timfox $ */ public class DistributedQueueExample extends ExampleSupport { public void example() throws Exception { String destinationName = getDestinationJNDIName(); InitialContext ic = null; Connection connection0 = null; Connection connection1 = null; try { // connecting to the first node ic = new InitialContext(); ConnectionFactory cf = (ConnectionFactory)ic.lookup("/ConnectionFactory"); Queue distributedQueue = (Queue)ic.lookup(destinationName); log("Distributed queue " + destinationName + " exists"); // When connecting to a messaging cluster, the ConnectionFactory has the capability of // transparently creating physical connections to different cluster nodes, in a round // robin fashion ... // ... so this is a connection to a cluster node connection0 = cf.createConnection(); // ... and this is a connection to a different cluster node connection1 = cf.createConnection(); // Let's make sure that (this example is also a smoke test) assertNotEquals(getServerID(connection0), getServerID(connection1)); // Create a session and a producer on the first connection Session session0 = connection0.createSession(false, Session.AUTO_ACKNOWLEDGE); MessageProducer publisher = session0.createProducer(distributedQueue); // Create another session and a consumer on the second connection Session session1 = connection1.createSession(false, Session.AUTO_ACKNOWLEDGE); MessageConsumer consumer = session1.createConsumer(distributedQueue); ExampleListener messageListener = new ExampleListener("MessageListener"); consumer.setMessageListener(messageListener); // Start connection1, so we can receive the message connection1.start(); // Send the message TextMessage message = session0.createTextMessage("Hello!"); publisher.send(message); log("The message was successfully sent to the distributed queue"); // Wait longer than clustered Post Office's "StatsSendPeriod", which is usually 10 secs messageListener.waitForMessage(15000); message = (TextMessage)messageListener.getMessage(); log(messageListener.getName() + " received message: " + message.getText()); assertEquals("Hello!", message.getText()); displayProviderInfo(connection0.getMetaData()); } finally { if (ic != null) { try { ic.close(); } catch(Exception e) { throw e; } } try { if (connection0 != null) { connection0.close(); } } catch(JMSException e) { log("Could not close connection " + connection0 + ", exception was " + e); throw e; } try { if (connection1 != null) { connection1.close(); } } catch(JMSException e) { log("Could not close connection " + connection1 + ", exception was " + e); throw e; } } } protected boolean isQueueExample() { return true; } public static void main(String[] args) { new DistributedQueueExample().run(); } } -- 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 month

2
4
0 / 0

[JBoss JIRA] Created: (JBRULES-546) Please implement "collect( ... ) from" functionality

by Dirk Bergstrom (JIRA)

Please implement "collect( ... ) from" functionality ---------------------------------------------------- Key: JBRULES-546 URL: http://jira.jboss.com/jira/browse/JBRULES-546 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Dirk Bergstrom Assigned To: Mark Proctor I need to count the number of sub-objects that meet various criteria. As an example, suppose I have several hundred Town objects, each of which has a list of perhaps a few hundred Person objects. I need to write rules like: "Find all the towns that have more than three disabled people with incomes over $100K." "For each town with more than 1000 residents that has more than 50 poor children under the age of 8, add a teacher for every 25 children." I'm shaky on JBR syntax, but I think those would translate to something like: rule "disabled" when ArrayList(size > 50) from collect( Person( disabled == "yes", income > 100000 ) from town.getPersons() ) then //do stuff end rule "teachers" when town : Town( population > 1000 ) count : Arraylist from collect( Person( disabled == "yes", income > 100000 ) from town.getPersons() ) count( size > 50 ) then town.addTeachers(count.size() / 25) end (I'm not really working with towns and people, but it makes for easily understood examples) -- 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 month

5
6
0 / 0

[JBoss JIRA] Created: (JBCACHE-1022) All notifications should go thru the Notifier and Notification Interceptor

by Manik Surtani (JIRA)

All notifications should go thru the Notifier and Notification Interceptor -------------------------------------------------------------------------- Key: JBCACHE-1022 URL: http://jira.jboss.com/jira/browse/JBCACHE-1022 Project: JBoss Cache Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.1.0.GA -- 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 month

1
4
0 / 0

[JBoss JIRA] Created: (GPD-80) alpha4 eclipse site broken for alpha3 users?

by Edward Staub (JIRA)

alpha4 eclipse site broken for alpha3 users? -------------------------------------------- Key: GPD-80 URL: http://jira.jboss.com/jira/browse/GPD-80 Project: JBoss jBPM GPD Issue Type: Bug Affects Versions: jBPM JPDL Designer 3.1.0.alpha4 Reporter: Edward Staub Assigned To: Koen Aers Priority: Critical Koen, site.xml was not updated from alpha3. I'm not sure, but I think I'm seeing this have the effect that, if you have alpha3 installed, trying to install alpha4 results in a "there's nothing new to install here" at the site. While a workaround is easy (delete - NOT DISABLE - alpha3 first), figuring it out is not - hence the "critical" level. I hope I'm not crying wolf here - apologies in advance if I missed something. I'm not comfortable with Eclipse yet. If I'm right, you may want to post something on the forum. -Ed Staub -- 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 month

2
3
0 / 0

[JBoss JIRA] Created: (JBPM-955) jBPM: support setting Actor or Swimlane on process level (to re-use sub-processes)

by Arjan van Bentem (JIRA)

jBPM: support setting Actor or Swimlane on process level (to re-use sub-processes) ---------------------------------------------------------------------------------- Key: JBPM-955 URL: http://jira.jboss.com/jira/browse/JBPM-955 Project: JBoss jBPM Issue Type: Feature Request Components: Core Engine Affects Versions: jBPM jPDL 3.2 Environment: All Reporter: Arjan van Bentem Assigned To: Tom Baeyens Priority: Minor Currently, an Actor or Swimlane is assigned within the task definition. When using sub-processes it would be very convenient to make the assignments in the parent process, such as in the parent <process-state>, or maybe even in the outermost <process-definition>. For example: both a helpdesk employee and the customer would need to fill in the same questionnaire at different points in the main process. The steps to fill in the questionnaire would be a generic sub-process, in which (at design time) one would not know the Swimlane nor Actor. This would require a way to set the swimlane in the parent's process-state:  <process-state name="Customer survey" swimlane="client"> <sub-process name="survey" /> </process-state> : : <process-state name="Employee survey" swimlane="employer"> <sub-process name="survey" /> </process-state> ... or <process-state name="Employee survey"> <assignment actor-id="..."/> <sub-process name="survey" /> </process-state> ... or maybe even at an even higher level, where jBPM would iterate up into the chain, possibly though nested sub-processes, until some assignment is found? -- 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 month

2
7
0 / 0

[JBoss JIRA] Created: (JBRULES-543) Jboss rules doesnt seem to have a command to halt rule execution from within a rules RHS

by Sridhar Chandrasekharan (JIRA)

Jboss rules doesnt seem to have a command to halt rule execution from within a rules RHS ---------------------------------------------------------------------------------------- Key: JBRULES-543 URL: http://jira.jboss.com/jira/browse/JBRULES-543 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Sridhar Chandrasekharan Assigned To: Mark Proctor Jboss rules doesnt seem to have a command to halt rule execution from within a rules RHS. Jess has a (halt) command which allows a rule to specify that rule execution should be stopped. I could find no such command in JBoss rules. -- 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 month

2
3
0 / 0

[JBoss JIRA] Created: (JGRP-492) Benchmark against JBento ATL cluster

by Bela Ban (JIRA)

Benchmark against JBento ATL cluster ------------------------------------ Key: JGRP-492 URL: http://jira.jboss.com/jira/browse/JGRP-492 Project: JGroups Issue Type: Task Reporter: Bela Ban Assigned To: Bela Ban Fix For: 2.5 Run the same session replication benchmarks as for 2.4.1 SP3 against 2.5 -- 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 month

2
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 May 2007