[JBoss Messaging] - 2CA0081E: Method cleanup failed while trying to execute method cleanup on ManagedConnection
by h Ruan
h Ruan [http://community.jboss.org/people/honglei_ruan] created the discussion
"2CA0081E: Method cleanup failed while trying to execute method cleanup on ManagedConnection"
To view the discussion, visit: http://community.jboss.org/message/582171#582171
--------------------------------------------------------------
Hi,
I have an app running on websphere 61 server and using jboss jbm as messaging provider. the app has been running file except yesterday an exception as below was thrown:
00022e1c MCWrapper E J2CA0081E: Method cleanup failed while trying to execute method cleanup on ManagedConnection mailto:com.ibm.ejs.jms.JMSManagedQueueConnection@75e875e8 com.ibm.ejs.jms.JMSManagedQueueConnection@75e875e8
managed connection factory = mailto:com.ibm.ejs.jms.GenericJMSManagedQueueConnectionFactory@239e239e com.ibm.ejs.jms.GenericJMSManagedQueueConnectionFactory@239e239e
physical connection = JBossConnection->ConnectionDelegate[24117616, ID=f5ok2-4yp324jg-1-nw2ns0ig-9xv9s5-x5r3h3h4, SID=0]
credential = mailto:javax.resource.spi.security.PasswordCredential@3e0fddd0 javax.resource.spi.security.PasswordCredential@3e0fddd0
open connection handles = [] from resource jms/XAConnectionFactory. Caught exception: javax.resource.spi.ResourceAdapterInternalException: Failed to stop connection on cleanup
at com.ibm.ejs.jms.JMSCMUtils.mapToResourceException(JMSCMUtils.java:176)
at com.ibm.ejs.jms.JMSManagedConnection.cleanup(JMSManagedConnection.java:981)
at com.ibm.ejs.j2c.MCWrapper.cleanup(MCWrapper.java:1467)
at com.ibm.ejs.j2c.FreePool.returnToFreePool(FreePool.java:492)
at com.ibm.ejs.j2c.PoolManager.release(PoolManager.java:1783)
at com.ibm.ejs.j2c.MCWrapper.releaseToPoolManager(MCWrapper.java:2301)
at com.ibm.ejs.j2c.ConnectionEventListener.connectionClosed(ConnectionEventListener.java:326)
at com.ibm.ejs.jms.JMSManagedConnection.handleClosed(JMSManagedConnection.java:1637)
at com.ibm.ejs.jms.JMSConnectionHandle.close(JMSConnectionHandle.java:564)
at org.springframework.jms.support.JmsUtils.closeConnection(JmsUtils.java:57)
at org.springframework.jms.core.JmsTemplate.execute(JmsTemplate.java:439)
at org.springframework.jms.core.JmsTemplate.send(JmsTemplate.java:477)
at org.springframework.jms.core.JmsTemplate.convertAndSend(JmsTemplate.java:543)
at org.springframework.jms.core.JmsTemplate.convertAndSend(JmsTemplate.java:534)
at com.valueoptions.fileconnect.jms.FileConnectSender.sendFile(FileConnectSender.java:57)
at com.valueoptions.fileconnect.handler.JmsSenderFileHandler.handle(JmsSenderFileHandler.java:14)
This exception immediately followed an DB transaction rollback so I think maybe the DB transaction rollback triggered such an exception. And finally message listeners are stopped on that server.
Please help!
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/582171#582171]
Start a new discussion in JBoss Messaging at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
15 years, 2 months
[jBPM] - jBPM3 Web Console Test Protocol
by Administrator Administrator
Administrator Administrator [http://community.jboss.org/people/admin] modified the document:
"jBPM3 Web Console Test Protocol"
To view the document, visit: http://community.jboss.org/docs/DOC-13416
--------------------------------------------------------------
h3. Build and install the jBPM distribution
Refer to http://community.jboss.org/docs/DOC-12866 jBPM3 Building the Installer for details.
h3. Load sample identity data
Run the attached identity.sql script on your target database.
h3. Deploy sample process
Point your browser to the jBPM http://localhost:8080/jbpm-console console. Log in as either admin or manager. Follow the *Processes* link in the top bar. In the *Actions* pane on the left, press *Deploy* a new process.
http://community.jboss.org/servlet/JiveServlet/showImage/102-13416-11-128... http://community.jboss.org/servlet/JiveServlet/downloadImage/102-13416-11...
Download the attached websale.jpdl.zip process archive, select it as the file to upload, and click on *Deploy*.
h3. Go through the ticklist
|| Use Case || Notes ||
| Log in | user/user |
| View processes | |
| Examine process | websale |
| Start a new process instance | |
| View personal/group tasks | |
| Start task | Create new web sale order |
| Examine task | idem |
| Fill task form, Save | |
| View variables, verify captured data | |
| Remove variable | quantity |
| View task form, confirm field was removed | idem |
| Fill field again, Evaluate | idem |
| View comments | |
| Add a comment, save | |
| Log out | |
| Log in | manager/manager |
| View jobs, confirm timer was created | Evaluate web order |
| Delete timer, disregard stack trace in server console (see JBPM-2103 (https://jira.jboss.org/jira/browse/JBPM-2103)) | idem |
| View personal/group tasks | idem |
| Examine task | |
| Reassign task | shipper |
| Log out | |
| Log in | shipper/shipper |
| View personal/group tasks | |
| Start task | Evaluate web order |
| End task: OK | idem |
| Examine task | Wait for money |
| Fill form, update books | |
| View process instance | |
| View comments, verify comment was added | |
| View tokens, confirm all tokens were ended | |
| View process image, confirm picture corresponds to token data | |
| View process variables, verify captured data | |
| Delete process instance | |
| Start a new process instance | |
| View tokens | |
| Signal token | |
| Signal token: OK | |
| Suspend process instance, confirm tokens are suspended | |
| Resume process instance, verify tokens are running | |
| End process instance, check tokens are ended | |
| View process definition | |
| Delete process | |
| Log out | |
| Congratulations! You have a working console. | |
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-13416]
Create a new document in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
15 years, 2 months
[jBPM] - MultiChoiceForkAH
by Administrator Administrator
Administrator Administrator [http://community.jboss.org/people/admin] modified the document:
"MultiChoiceForkAH"
To view the document, visit: http://community.jboss.org/docs/DOC-11442
--------------------------------------------------------------
This Multi Choice fork will create an appropriate thread of execution (token) for each dynamically specified item. For instance, in the case of a customer order containing one phone service product, one internet service product, and two web hosting products: one token will be created and sent down the 'phone' transition, one token will be created and sent down the 'internet' transition, and two separate tokens can be each created and sent separately down the 'web' transition.
Optionally, this fork can be configured to simply create a token for each combination of 'item' and 'transition'.
A Collection of Objects driving the choices must be stored in a process instance variable, and each object must share a common accessor method for determining its 'type' (or just use a String). Just about everything is configurable--see the comments in the sample process definition and attached code.
<?xml version="1.0" encoding="UTF-8"?>
<process-definition name='ForEachFork Test'>
<start-state name='START' >
<event type='node-leave' >
<script>
<expression>List list = new ArrayList(); list.add("item1"); list.add("item2"); list.add("item3");</expression>
<variable name='myList' access='write' mapped-name='list' ></variable>
</script>
</event>
<transition name='done' to='_TEST_FORK'></transition>
</start-state>
<!-- Attempts to provide a robust implementation of workflow pattern 6, multi-choice. -->
<state name='_TEST_FORK' >
<event type='node-enter' >
<action class='org.bminer.jbpm.pd.ah.ForEachForkAH' config-type='bean'>
<!-- process instance variable containing a Collection of items for which we will
create sub tokens. -->
<inputCollectionVar>myList</inputCollectionVar>
<!-- If the collection is not of Strings, this property may be specified and
should be available via a 'get', 'is', or 'has' accessor method on each item in
the collection. Alternatively, an EL expression may be supplied where
'tempForEachForkAHInputItem' is the Input Item being evaluated against.
The returned value must be a String or String.valueOf() compatible value.
The value will be used to identify the item and to match
against available transition names when matchItemWithTrans = 'true'.
If not provided for non-String inputCollections, toString() will be
called on those items to provide a String value. -->
<inputItemProperty></inputItemProperty>
<!-- The variable name in the branch token which will hold the Input Item from the
inputCollectionVar that caused the creation of the branch token. If no name is
given, the Input Item will not be stored separately under its associated
branch token. -->
<inputItemMappedName>inputItem</inputItemMappedName>
<!-- 'true' will create a token for each inputCollection item that corresponds to a
non-reserved transition name, and then signal that token down the matching
transition. ('reserved' transition names include those configured under
'noMatchTrans' and 'noListTrans' as well as any transition beginning with
'_sys_'.) 'false' will create and signal a token for every combination of
inputCollection item and transition. Required. -->
<matchItemWithTrans>true</matchItemWithTrans>
<!-- 'true' reduces the inputCollection to a Set prior to matching the collection
to the configured transitions. Default is 'false' -->
<matchUnique>true</matchUnique>
<!-- When using matchItemWithTrans = 'true', this is the default transition to take for
any inputCollection item that has no matching transition name,
otherwise no token will be generated for that item -->
<noMatchTrans>noMatch</noMatchTrans>
<!-- 'true' if the specified 'noMatchTrans' should be taken only once regardless of
how many un-matched items exist, or 'false' if the 'noMatchTrans' should be
taken for each item that has no matching transition. Default is 'true'. -->
<noMatchDoTransOnce>true</noMatchDoTransOnce>
<!-- If any item fails to have a matching transition, set this to 'true' if other matched
transitions should be taken, 'false' if only 'notMatchTrans' transitions should be taken.
In other words, if there is any failure to match, nothing but the failure(s) will be
processed if this is set to 'false'. Default is 'false'. -->
<noMatchDoMatched>false</noMatchDoMatched>
<!-- transition to take if there is nothing in the inputCollection, otherwise
nothing will be done and we'll halt execution in this node.
Since we don't fork in this scenario, any subsequent nodes should
lead the root token past the join that corresponds to this fork -->
<noListTrans>noList</noListTrans>
</action>
</event>
<transition name='item1' to='ITEM_1' ></transition>
<transition name='item2' to='ITEM_2' ></transition>
<transition name='item3' to='ITEM_3' ></transition>
<transition name='noMatch' to='UNSUPPORTED_ITEM' ></transition>
<transition name='noList' to='NO_ITEMS' ></transition>
<transition name='_sys_redoNode' to='_TEST_FORK' ></transition>
</state>
<state name='ITEM_1' >
<event type='node-enter' >
<script>System.out.println("Processing item 1!");</script>
</event>
<transition name='done' to='JOIN' ></transition>
</state>
<state name='ITEM_2' >
<event type='node-enter' >
<script>System.out.println("Processing item 2!");</script>
</event>
<transition name='done' to='JOIN' ></transition>
</state>
<state name='ITEM_3' >
<event type='node-enter' >
<script>System.out.println("Processing item 3!");</script>
</event>
<transition name='done' to='JOIN' ></transition>
</state>
<state name='UNSUPPORTED_ITEM' >
<event type='node-enter' >
<script>System.out.println("Received an unsupported item!");</script>
</event>
<transition name='done' to='JOIN' ></transition>
</state>
<state name='NO_ITEMS' >
<event type='node-enter' >
<script>System.out.println("There was no collection, so I didn't fork!");</script>
</event>
<transition name='nothingToDo' to='END' ></transition>
</state>
<join name='JOIN'>
<transition name='done' to='END' ></transition>
</join>
<end-state name='END' ></end-state>
</process-definition>
Hope this is useful.
(updated to provide a more recent example that fixes two mentioned bugs and includes the "inputMappedName" configuration parameter.)
*Referenced by:*
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-11442]
Create a new document in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
15 years, 2 months
[jBPM] - JbpmMeetingTomHeikoJanuary2009
by Administrator Administrator
Administrator Administrator [http://community.jboss.org/people/admin] modified the document:
"JbpmMeetingTomHeikoJanuary2009"
To view the document, visit: http://community.jboss.org/docs/DOC-13281
--------------------------------------------------------------
h3. Logging / History [ https://jira.jboss.org/jira/browse/JBPM-1994 JBPM-1994]
* Transactional storage of the history of a process execution (not software logging)
* Do we have a good name for this ?
* Log pluggability is in place
* Basic pluggability infrastructure is in place
* TODO
** HistoryRecords generated during process execution need to be created
** HistoryRecords need to merge themselves into the History DB schema
** Schema for storing history information needs to be build
** Filtering the history storage should be based on features
*** We should not place the burden on the users to link log filtering to the features that remain available
h3. Database schema
Analyse the DB schema
Compatibility needs to be installed in the project
h3.
Database schema
* Analyse the DB schema
* Developmemt process for DB evolution [ https://jira.jboss.org/jira/browse/JBPM-1995 JBPM-1995]
h3. Project Structure
(add this to developer docs in wiki)
h4. API package refactoring [ https://jira.jboss.org/jira/browse/JBPM-1997 JBPM-1997]
* api
- the public api (client services, client, activity, eventlisteners)
- all other modules should have package names that include ..internal..
* config
h4. Test suite consolidation [ https://jira.jboss.org/jira/browse/JBPM-1996 JBPM-1996]
* jpdl
- parsing jpdl
- jpdl activity impl
- base jpdl test suite jpdl/src/test/java
- base jpdl test suite should be able to access jpdl impl and pvm impl classes
* examples --> jpdl/src/test/examples
- can be merged into jpdl module
- works against public api and jpdl
- part of test suite
- included in docs
- examples project in distro
- compile time checking on api usage only
* test-db --> jpdl/src/test/examples/org/jbpm/examples/advanced
- can be merged into jpdl module
- more elaborate functional testing
- works against public api and jpdl
- part of test suite
- compile time checking on api usage only
* task ?
h3. Task management
* assignment
- distinction between assignable user and groups [ https://jira.jboss.org/jira/browse/JBPM-1998 JBPM-1998]
* context data
* task definition
- add outcomes [ https://jira.jboss.org/jira/browse/JBPM-1999 JBPM-1999]
* process integration
- variables
- signal execution upon completion
- provide outcome to signal mapping [ https://jira.jboss.org/jira/browse/JBPM-1999 JBPM-1999]
* external presentation
- web form [ https://jira.jboss.org/jira/browse/JBPM-2000 JBPM-2000]
- email
- db record
* reporting
- history https://jira.jboss.org/jira/browse/JBPM-1994 JBPM-1994
- how was the workload in this department last month
* monitoring
- e.g. notify me when the resource alloction in group x goes beyond 80%
* embedded / standalone
h3. In scope for jBPM 4.0.0.GA
*jPDL*
* Environments in order of priority (installer, qa, docs)
1) JBoss 5.0.0
2) Tomcat latest
3) JBoss 4.2.3
* Examples and test-db need to run with cactus on the target container
* Local EJB in scope
* Remote EJB out of scope
*Logging / History*
* Transactional storage of the history of a process execution (not software logging)
* Do we have a good name for this ?
* Log pluggability is in place
* Basic pluggability infrastructure is in place
* TODO
o HistoryRecords generated during process execution need to be created
o HistoryRecords need to merge themselves into the History DB schema
o Schema for storing history information needs to be build
*Console*
* management
* task management
* process management
* reporting (strategical dashboard)
* monitoring (analythical dashboard)
* roles ?
*Designer*
*
*Scenario 1*
* Install distro
* Import examples project (done)
* Execute example test in eclipse (done)
* Create new process definition file with designer wizard (done)
* Declare couple of variables
* Create 2 human task activities
- Generate task form with designer
- Using variables declared in the process
- Associate task form with task activity
(this should be done automatically by using the designer task form generation)
* Create esb service activity
- ESB is assumed running and having a service
* Create Include Java pojo
- Write minimal PrintLn activity
* Start AS
- the one you installed jbpm in
- maybe installer can generate start-server.bat script in jbpm instsallation directory ?
* Dynamically deploy process from designer
- might involve defining the process archive package
* In console start the process (with form)
* For each task,
- log in as the task user
- see task list
- navigate to task form
- complete task form
* Run through process execution by submitting task forms
* Show reports including this execution
optional extension:
* redeploy an update to the process
*Scenario 2*
* Burr's demo
* Existing: 3 Session EJB's with 1 method
* jPDL process orchestrates these 3 methods
* jPDL process gets updated and redeployed
* No redeployment of the ejbs
--> ejb invocation activity
Variation:
* show how 2 pojo methods
* in case you want to execute those asynchronous, show how this can be done with 2 MDBs
* show how this can be done easily in a process with 2 asynchronous continuations
* other variations: show how you can implement competing consumers with jpdl
*
BPMN*
* api will be PVM based so process language and BPMN neutral
* jPDL will use bpmn terminology on a best effort basis
* jPDL 4 will drive the activity types and we'll select the BPMN
symbol that matches the jPDL activity type
* the BPMN interpretation of the notational element that we pick must
match exactly with the jpdl element. if not, we need to clearly indicate
grafically that notation is jPDL specific
* we'll also go over the most common BPMN elements and see if we
can come up with meaningfull jPDL for all the elements.
*Task Management*
* basic task model
- task activity creates task when execution arrives.
- tasks can have a map of variables
- upon creations, optionally data is passed from the execution into the task scope
- users can complete tasks and provide data optionally
- a special piece of information that can be supplied with the task completion is the outcome
- the potential outcomes are stored in task definition
- the task activity will implement the task definition interface
- upon completion of a task, the execution signal and parameters need to be provided
- by default, the outcome will map to the signal and hence bind to the outgoing transition
- task data will be stored as process variables, same techniques apply as the process variable scoping
- a TaskHandler interface will have methods for all task-processexecution integration
createTask(Execution)
taskCompleted(Task)
- The default task handler will use the task outcome as the signal that is given on the execution.
- Custom task handlers can be specified to overwrite this default behaviour
* assignment
* sub tasks
- dynamic
- for grouping (3 out of 5) (with a certain outcome ?)
h3. Roadmap
*jBPM 4.0.0.Alpha2 (March 1st)*
* identity spi [ https://jira.jboss.org/jira/browse/JBPM-1860 JBPM-1860]
* integrate identity component [ https://jira.jboss.org/jira/browse/JBPM-1993 JBPM-1993]
* introduce distinction between users and groups
* process definition attachments
* review console dao and compare with current process and execution service
* variable declaration in jpdl
* task form url and form type property (explain to heiko for review)
* installer with profiles for all target containers
* introduce console (process management)
*
*
*jBPM 4.0.0.Beta1 (April 1st)*
* get facelets generation work in jbpm 4 (beginning of iteration so that heiko could include this later in this iteration)
no designer support yet
* alternative form generation can be prototyped
* define process archive packaging strategy
* define how to deploy process archives on the target containers
* task management and task forms
- starting a process
- associated to process definition
- authorization ?
- perform a task in the middle of the process
- associated to task list
- task assignment
*jBPM 4.0.0.Beta2 (May 1st)*
*
*
*jBPM 4.0.0.CR1 (June 1st)*
*
*
*jBPM 4.0.0.GA (July 1st)*
h3. Ideas for jBPM 4 after GA
1) Migration Aspects
* DB schema
* jPDL process files
* custom activities
* user components using
- client api
- db schema
- hibernate api / hql
* select 1 or 2 key customers and assist them with migration
- leverage that knowledge in building migration
* set up infrastructure to capture knowledge that we build up: wiki page ?
* This effort can be started as of CR earliest
* Not a requirement to release 4.0.0.GA
2) Spring support
Task for a new hire ?
3) Logging / History
Filtering the history storage should be based on features
We should not place the burden on the users to link log filtering to the features that remain available
h3. Links/Resources
Work 2.0 Peter Fingar
Orbeon
NetKernel
OrganisationalManagement (Meuhlen)
http://in.relation.to/service/File/2994 http://in.relation.to/service/File/2994
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-13281]
Create a new document in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
15 years, 2 months
[jBPM] - jBPM4 Productization Requirements
by Administrator Administrator
Administrator Administrator [http://community.jboss.org/people/admin] modified the document:
"jBPM4 Productization Requirements"
To view the document, visit: http://community.jboss.org/docs/DOC-13680
--------------------------------------------------------------
h1. Realized productization
h4. Features
* jPDL
** Control flow activities: start, state, decision, fork, join, end, task, sub-process, custom
** Automatic activities: java, script, hql, sql, mail
** Timers
** Asynchronous continuations
* JBoss integration
** Deployment as a service archive
** ProcessEngine in JNDI
h4. QA
* Integration test suite is formed by modules examples and the test-db
* Module examples contains tests that are explained in the user guide. Aka public test suite. The examples are also included as a project in the distribution.
* Module test-db contains tests that verify all aspects of functionality using public API. Aka private test suite.
* Both modules examples and test-db only make use of public API.
* CI is set up for the matrix {jdks}x{jboss's}x{databases}. See job jbpm4-jboss: http://hudson.qa.jboss.com/hudson/view/JBPM4/ http://hudson.qa.jboss.com/hudson/view/JBPM4/
h4. Engine
* A release is only done if the continuous integration runs OK.
* Clear, minimal session facade API
* XSD Schema for the jPDL language
** http://docs.jboss.org/jbpm/v4.0/schemadocs/ http://docs.jboss.org/jbpm/v4.0/schemadocs/
* Automatic installer for installing jBPM into JBoss
** Parameters: jboss version, database, jdbc parameters, identity component
** Support is only given on these automated installations
h4. Documentation
* A userguide documents all the features and functionalities that are supported.
** Each functionality must be illustrated with an example
** Each functionality must have sufficient test coverage in the extended test suite (test-db)
** http://docs.jboss.org/jbpm/v4.0/userguide/html_single/ http://docs.jboss.org/jbpm/v4.0/userguide/html_single/
* Javadocs for the API
** http://docs.jboss.org/jbpm/v4.0/javadocs/ http://docs.jboss.org/jbpm/v4.0/javadocs/
h4. Designer
* Each piece of supported functionality in the jPDL language must be supported by the designer
* Designer plugins included in JBossTools/JBDS
h4. Migration
* jBPM 3 should be able to run side by side with jBPM 4
h1. Roadmap and prioritization
h4. Work in progress
* Integration with JBoss IDM (Jeff Yu is working on this)
* Process conversion tool (Jim Ma is working on this)
* Controlled minimal tests for concurrent DB access: SOSE's (Joram Barrez)
* Designer support for older versions (Koen Aers)
** Support for multiple, configurable runtimes
h4. Prioritization of new productization requirements
* Clustering
* Automated QA for console and/or documentation of manual test procedures
* Automated QA for designer and/or documentation of manual test procedures
* SEAM integration
** Pageflow
** Pageflow designer
* JMS support (and/or JCA inflow support) for asynchronous messaging
* ProcessInstance migration in case of new process definition deployment
* jBPM-ESB integration
** Locate services through the registry
** Invoke services without regard to their underlying implementation
** Support synchronous or asynchronous calls
** Make invocation layer pluggable so that third-party ESBs can be integrated as well
** Part of community download ?
* Putting script code in privileged blocks to allow security mgr to control authorization inside scripts. (Marc Schoenefeld)
h1. Process
* jBPM is consumed by EAP and SOA-P
* EAP and SOA-P can create issues in JBPM's bug tracker: https://jira.jboss.org/jira/browse/JBPM https://jira.jboss.org/jira/browse/JBPM
** Platform people are responsible for creating platform issues and linking them to project issues.
** jBPM bug tracker will have releases defined corresponding the platform releases. E.g. SOA 4.3 CP02, EAP 5.0
** The jBPM team will discuss these issues with the platform team
** The jBPM team will assign product related issues into a platform release and the responsible team member
* Each jBPM community release can be identified as a product version.
** A product branch is created in the project
** Only productization issues (bug fixes) are committed to that branch
** The platforms consume that product branch in their build
* The jBPM team will commit issues before the platform code freeze date
* The platform teams are responsible for creating the platform tags that are based on the platform branches
--------------------------------------------------------------
Comment by going to Community
[http://community.jboss.org/docs/DOC-13680]
Create a new document in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=102&co...]
15 years, 2 months
