November 2006 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBMESSAGING-657) Sort out flow control

by Tim Fox (JIRA)

Sort out flow control --------------------- Key: JBMESSAGING-657 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-657 Project: JBoss Messaging Issue Type: Task Affects Versions: 1.2.0.Beta1 Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.0.Beta2 Recent changes to the consumer flow control logic use messagesInTransit but does not remove the old way of doing flow control which involves more() and batching messages in the consumer. Using both methods concurrently is a sub optimal implementation and will probably introduce performance problems. Since message batching and more() is now redundant it should be removed. We should also push for remoting to support asynchronous push callbacks. We need to performance test again to make sure our throughput has not suffered. -- 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, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBPM-785) Process Instance Deletion failed due to Constraint Voilation "`LE_OLTP/JBPM_PROCESSINSTANCE`, CONSTRAINT `FK_PROCIN_SPROCTKN` FOREIGN KEY (`SUPERPROCESSTOKEN_`) REFERENCES `JBPM_TOKEN` (`ID_`))"

by Deepak jAIN (JIRA)

Process Instance Deletion failed due to Constraint Voilation "`LE_OLTP/JBPM_PROCESSINSTANCE`, CONSTRAINT `FK_PROCIN_SPROCTKN` FOREIGN KEY (`SUPERPROCESSTOKEN_`) REFERENCES `JBPM_TOKEN` (`ID_`))" -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: JBPM-785 URL: http://jira.jboss.com/jira/browse/JBPM-785 Project: JBoss jBPM Issue Type: Bug Components: Core Engine Affects Versions: jBPM 3.1.3 Environment: ubuntu linux , JBPM 3.1.3 , mysql 5.0.22 Reporter: Deepak jAIN Assigned To: Tom Baeyens Priority: Blocker I have a complex multi level process scenario where JBPM 3.1.3 was failing to delete a process instance because of the following constraint voilation: "`LE_OLTP/JBPM_PROCESSINSTANCE`, CONSTRAINT `FK_PROCIN_SPROCTKN` FOREIGN KEY (`SUPERPROCESSTOKEN_`) REFERENCES `JBPM_TOKEN` (`ID_`))" Here is my usage scenario in more detail: Top Level Process P1 has following sub processes -> Sub Process P2 -> Sub Process P3 -> Sub Process P4 -> Sub Process P41 -> Sub Process P5 -> Sub Process P6 Step1 : I successfully deployed all these processes and was able to successfully execute "Top Level Process P1". Step2 : When I try to undeploy "Top Level Process P1" or delete (undeploy internally calls deleteProcessInstance) process instance of "Top Level Process P1". I was getting the the above mentioned constraint voliation: "`LE_OLTP/JBPM_PROCESSINSTANCE`, CONSTRAINT `FK_PROCIN_SPROCTKN` FOREIGN KEY (`SUPERPROCESSTOKEN_`) REFERENCES `JBPM_TOKEN` (`ID_`))" NOTE : LE_OLTP is my schema in mysql 5.0.22 I spend a decent amount of time looking at the piece of code in action at 1. org.jbpm.db.GraphSession#deleteProcessInstance(ProcessInstance,boolean,boolean,boolean) and 2. org.jbpm.db.GraphSession#deleteSubProcesses(Token) 3. org.jbpm.db.hibernate.queries.hbm.xml The problem had to do with couple of issues in code like : 1. bug in the query to get sub process tokens. 2. bug around how sub processes are being deleted in cascade deletion process (recursive code). 3. bug arounf the steps to delete the logs of the process instance. NOTE : This bug cause other constraint voilations too which I have fixed as well. I have fixed the issue (org.jbpm.db.GraphSession + hibernate.queries.hbm.xml files with change are attached, one can diff this against JBPM 3.1.3 Version to see the change). I have tested this with the above mentioned test scenarios + far more complex scenarios already. Now I need help with w.r.t Next Steps to further get this fix in main code base: 1. I will like to checkin/provide some unit tests to add more complex scenarios like the above mentioned to help JBPM community. 2. I will like core JBPM dveleopers (tbaeyens or others ) to do a code review of the changes and accept this in main line References : http://www.jboss.com/index.html?module=bb&op=viewtopic&t=94218&view=previous is related but slightly different issue. regards, dj -- 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, 7 months

2
8
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-594) Consider having just one post office instance

by Tim Fox (JIRA)

Consider having just one post office instance --------------------------------------------- Key: JBMESSAGING-594 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-594 Project: JBoss Messaging Issue Type: Task Affects Versions: 1.0.1.CR5 Reporter: Tim Fox Assigned To: Tim Fox Fix For: 1.2.0.Beta1 We should consider whether it is possible to have just one post office instance per server, instead of the current queue and topic post office. We currently have two since a queue and a topic can have the same name so we would need to distinguish whether we wanted to rout to a topic or a queue in some other way. We should also bear in mind that the post office is supposed to be generic and not have any knowledge of what a "topic" is (this is a JMS term). In the future we will want to do wildcard based routing for topic hierarchies or content based routing, so the routing key cannot just be some "destination" class. One possibility is to change the PostOffice interface to take a "RoutingKey" type as opposed to a string. We could then subclass or implement this interface for different post office types. -- 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, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (JBCACHE-859) Known failures in 2.0.0.Alpha1 need cleaning up

by Manik Surtani (JIRA)

Known failures in 2.0.0.Alpha1 need cleaning up ----------------------------------------------- Key: JBCACHE-859 URL: http://jira.jboss.com/jira/browse/JBCACHE-859 Project: JBoss Cache Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 2.0.0.ALPHA1 Reporter: Manik Surtani Assigned To: Manik Surtani Fix For: 2.0.0.ALPHA2 These include: org.jboss.cache.buddyreplication.BuddyAssignmentStateTransferTest org.jboss.cache.eviction.ConcurrentEvictionTest org.jboss.cache.eviction.MRUAlgorithmTest org.jboss.cache.loader.deadlock.ConcurrentCreationDeadlockTest -- 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, 7 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-3469) Enhance the BarrierController with the ability to destroy/re-create the Barrier

by Dimitris Andreadis (JIRA)

Enhance the BarrierController with the ability to destroy/re-create the Barrier ------------------------------------------------------------------------------- Key: JBAS-3469 URL: http://jira.jboss.com/jira/browse/JBAS-3469 Project: JBoss Application Server Issue Type: Feature Request Security Level: Public (Everyone can see) Components: System service Affects Versions: JBossAS-4.0.4.GA Reporter: Dimitris Andreadis Assigned To: Dimitris Andreadis Fix For: JBossAS-4.0.6.CR1 Investigate the possibility of having a special configuration that tells the BarrierController to fully destroy and re-create the Barrier. That would allow services that can be destroyed and re-created to be controlled by the Barrier. -- 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, 7 months

1
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-636) Having Exception initCause being called on ExceptionInterceptor

by Clebert Suconic (JIRA)

Having Exception initCause being called on ExceptionInterceptor --------------------------------------------------------------- Key: JBMESSAGING-636 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-636 Project: JBoss Messaging Issue Type: Feature Request Components: JMS Security Affects Versions: 1.2.0.Alpha2, 1.0.1.GA Reporter: Clebert Suconic Priority: Minor Fix For: 1.0.2.CR1, 1.2.0.CR1 When JMSException is thrown we should call initCause and that would give the customer more information. Simple change that would imporve suportability. -- 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, 7 months

2
4
0 / 0

[JBoss JIRA] Created: (JBESB-122) Schema needed

by Mark Little (JIRA)

Schema needed ------------- Key: JBESB-122 URL: http://jira.jboss.com/jira/browse/JBESB-122 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: ESB Core Affects Versions: 4.0 Beta 1 Reporter: Mark Little Assigned To: Mark Little Fix For: 4.0 XML is the configuration language of choice in Rosetta at the moment. There is no schema(s) for the various configuration files. Different classes have the attribute/element names hard coded into them. We should use the PropertyManager and have the schemas separated out of the implementation classes. -- 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, 7 months

4
16
0 / 0

[JBoss JIRA] Created: (JBESB-153) Make all configuration attribute names have consistent format

by Mark Little (JIRA)

Make all configuration attribute names have consistent format ------------------------------------------------------------- Key: JBESB-153 URL: http://jira.jboss.com/jira/browse/JBESB-153 Project: JBoss ESB Issue Type: Task Security Level: Public (Everyone can see) Components: ESB Core Affects Versions: 4.0 Beta 1 Maintenance Pack 1 Reporter: Mark Little Assigned To: Mark Little Fix For: 4.0 org.jboss.soa.esb as the root of all names. -- 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, 7 months

2
4
0 / 0

[JBoss JIRA] Created: (JBESB-199) Message Store Repository bootstrap

by Daniel Brum (JIRA)

Message Store Repository bootstrap ---------------------------------- Key: JBESB-199 URL: http://jira.jboss.com/jira/browse/JBESB-199 Project: JBoss ESB Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Daniel Brum Assigned To: Daniel Brum Fix For: 4.0 Create a bootstrap process for the message store, same design to be used by service registry -- 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, 7 months

2
7
0 / 0

[JBoss JIRA] Created: (JBESB-192) Listener implementations need to perform the payload to Message wrapping, not the AbstractListener

by Tom Fennelly (JIRA)

Listener implementations need to perform the payload to Message wrapping, not the AbstractListener -------------------------------------------------------------------------------------------------- Key: JBESB-192 URL: http://jira.jboss.com/jira/browse/JBESB-192 Project: JBoss ESB Issue Type: Bug Security Level: Public (Everyone can see) Affects Versions: 4.0 Reporter: Tom Fennelly Assigned To: Mark Little Priority: Blocker Fix For: 4.0 I may be missing something here but, I think there's an issue with the Listeners/Action/Messages that probably requires more immediate attention. The AbstractListener calls the receive method of its implementation (DirectoryPoller etc) in order to get messages from the delivery channel associated with the implementation. At the moment, the receive method returns an Object[] and AbstractListener does the job of converting/wrapping these Objects into Message implementations before pushing the Message instances through the associated pipeline for processing. The AbstractListener also performs the job of triggering "lifecycle" events on the implementation i.e. processingError and processingComplete. In order for these method implementations to perform the appropriate "channel specific" tasks relating to the processing of the message, they need access to "special" info that should be hidden in the message and not accessible to anyone else other than that Listener impl. Hopefully this will make more sense through an example.... The DirectoryPoller listens on the Filesystem for file based message. It manage the lifecycle of these messages as follows: 1. Before it's receive method impl returns the java.io.File associated with the message, it renames the file to "working" so that the file is not picked up for processing again. In fact, it actually returns an extension of java.io.File (WorkingFile) which contains "hidden" info that the Listener uses when message lifecycle events are called (processingError and processingComplete). 2. In response to a call to it's "processingError" implementation, it should get passed the original message object it returned from it's receive method (WorkingFile). WorkingFile is a inner class to DirectoryPoller and it contains a few private methods that only WorkingFile and DirectoryPoller can call. In the case of processingError being called, the DirectoryPoller wants to call the private method "renameToError". 3. In response to a call to it's "processingComplete" implementation, the DirectoryPoller wants to call the private method "renameToDone". The Issue: The AbstractListener implementations should be doing the wrapping of the message payload objects in the relevant Message implementations (not the AbstractListener itself as is currently the case). This way, the channel specific listener implementation can add the channel specific info it needs to the message before returning it for pipeline processing (e.g. the rename to error/done file names etc in the case of the DirectoryPoller). This also means that the receive method definition would need to be changed to return a Message[] (instead of an Object[]) and the lifecycle management methods (processingError and processingComplete) changed to take type Message (Vs type Object). Without making these changes, the lifecycle info will very likely get lost in the pipeline because it's currently being set on the Message body/payload, which will very likely get changed during pipeline processing. -- 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, 7 months

2
4
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 November 2006