[JBoss Messaging Users] - need help to delete clustered queue without db in 5.1
by augustsimonelli
Hi all,
I have the following queue:
<mbean code="org.jboss.jms.server.destination.QueueService"
|
| name="jboss.messaging.destination:service=Queue,name=MY_QUEUE"
|
| xmbean-dd="xmdesc/Queue-xmbean.xml">
|
| <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
|
| <depends>jboss.messaging:service=PostOffice</depends>
|
| <attribute name="Clustered">true</attribute>
| </mbean>
|
when i remove the queue (ie remove the -server.xml file) it undeploys.
When i put it back i get an error:
anonymous wrote : "Queue MY_QUEUE is already deployed as clustered = true so cannot redeploy as clustered=true . You must delete the destination first before redeploying"
This is clearly addressed here:
https://jira.jboss.org/jira/browse/JBMESSAGING-1235
BUT ... it tells me to "*delete the original destination from storage*."
So, if i don't have access to the DB how can i do that? The queue is no longer visible via the jmx-console.
I'm missing something obvious i'm sure.
Any thoughts? I can get into the DB if needed and adjust the JBM_POSTOFFICE stuff but i'm curious if it can be done from the jmx-console.
thanks!
august
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4253197#4253197
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4253197
16 years, 7 months
[jBPM Users] - Same token seems to be attached to two task instances?
by gfargone
Hello,
We run jbpm 3.2.6.SP1 on Oracle. We use the Command interface to operate JBPM and our applications use that only to interface with JBPM.
(It is a painful way of using it, but we did not have time to replicate all console capabilities to use just the engine) We run jbpm-console in the same JBoss application server for administrative and troubleshooting purposes.
After hundreds of successfully completed workflow instances we got a strange problem. This workflow has no forks, just task and decision nodes so we should never end up with two active nodes on the flow.
In this case we got two tasks active, I think due to the fact that they ended up with the same token attached. At least that how it shows up on the jbpm-console.
This wrecks havoc with everything down the line and there seems to be no way of fixing it without messing with the database.
I was wondering how something like that can occur and if anyone has seen a similar problem.
Thank You,
Tamas
PS: We discovered this during the pilot just days before we were planning to go full deployment at our site.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4253195#4253195
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4253195
16 years, 7 months
[jBPM Users] - Handling failure of automated activities
by emp.tyres
Hello -
I am very, very happy with Jbpm4, and I am currently looking for a hint on best practices for handling failures of automatic activities invoking retries or failovers - for example, a whose class connects to an external server (which may be down at the time of calling)
I understand I can signal the failure in the return variable and model the retry / failover process explicitly with a switch, but that seems rather cumbersome.
My preference would be to have the possibility to implicitly choose from the activity the outgoing transition, pointing to a "retry" state which periodically re-enters the automatic activity with a timer. I am not sure if it is possible to define that an exception in the java class with exception-handlers, because the docs seem incomplete.
Also, about exception handling, I could not find any hints on these two points:
1- what possibilities are there to "recover" a process that has encountered an unhandled exception?
2- will other process instances running in the same PVM keep going in such a case?
Any pointers woud be really appreciated.
Bye and thanks.
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4253180#4253180
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4253180
16 years, 7 months