February 2009 - jboss-dev-forums - Jboss List Archives

[Design of JBoss jBPM] - Re: first cut of the new history

by camunda

Okay, now I got it. This is indeed a very good improvement! I will try to have a look at the code asap (but cannot yet promise that I will have time :-/)... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210147#4210147 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210147

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Declaration of process variables in jpdl 4?

by camunda

Hey guys, I just had a recent discussion and remembered how often I (or the forum) was asked if it is possible to declare variables for a jbpm process (via XSD or Java types). This would be interessting if it will be supported in jbpm 4. Not mandatory but possible, since a lot of people want to declare there process variables, and it is an understandable requirement I think. Cheers Bernd View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210146#4210146 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210146

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: blobs, clobs, text and bytes

by kukeltje

Koen wrote on the mailinglist anonymous wrote : +1 | | I agree on reducing complexity if there is no apparent regression. | But.... we should not forget migration... View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210121#4210121 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210121

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Dead Lock on a failover test

by clebert.suconic＠jboss.com

I got a dead lock during a testsuite run. I was doing some other stuff what may had made the behavior worse, but a dead lock shouldn't happen. It happened once during org.jboss.messaging.tests.integration.cluster.failover.FailoverExpiredMessageTest [junit] Found one Java-level deadlock: | [junit] ============================= | [junit] "Thread-6236": | [junit] waiting to lock monitor 0x00007fdcea027d10 (object 0x00007fdd25a50e28, a java.lang.Object), | [junit] which is held by "Thread-6235" | [junit] "Thread-6235": | [junit] waiting to lock monitor 0x00007fdcea027e00 (object 0x00007fdd25a5f790, a org.jboss.messaging.core.remoting.impl.invm.InVMConnection), | [junit] which is held by "Thread-6236" | [junit] | [junit] Java stack information for the threads listed above: | [junit] =================================================== | [junit] "Thread-6236": | [junit] at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.failConnection(ConnectionManagerImpl.java:866) | [junit] - waiting to lock <0x00007fdd25a50e28> (a java.lang.Object) | [junit] at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.connectionDestroyed(ConnectionManagerImpl.java:198) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnector$Listener.connectionDestroyed(InVMConnector.java:187) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnection.close(InVMConnection.java:97) | [junit] - locked <0x00007fdd25a5f790> (a org.jboss.messaging.core.remoting.impl.invm.InVMConnection) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnector.disconnect(InVMConnector.java:161) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMAcceptor$Listener$1.run(InVMAcceptor.java:167) | [junit] "Thread-6235": | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnection.close(InVMConnection.java:87) | [junit] - waiting to lock <0x00007fdd25a5f790> (a org.jboss.messaging.core.remoting.impl.invm.InVMConnection) | [junit] at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.internalClose(RemotingConnectionImpl.java:601) | [junit] at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.destroy(RemotingConnectionImpl.java:470) | [junit] at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.failover(ConnectionManagerImpl.java:587) | [junit] - locked <0x00007fdd25a5f8b8> (a java.lang.Object) | [junit] at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.connectionFailed(ConnectionManagerImpl.java:412) | [junit] at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.callListeners(RemotingConnectionImpl.java:574) | [junit] at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:453) | [junit] at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.failConnection(ConnectionManagerImpl.java:870) | [junit] - locked <0x00007fdd25a50e28> (a java.lang.Object) | [junit] at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.connectionDestroyed(ConnectionManagerImpl.java:198) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnector$Listener.connectionDestroyed(InVMConnector.java:187) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnection.close(InVMConnection.java:97) | [junit] - locked <0x00007fdd25a5fac0> (a org.jboss.messaging.core.remoting.impl.invm.InVMConnection) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnector.disconnect(InVMConnector.java:161) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMAcceptor$Listener$1.run(InVMAcceptor.java:167) | [junit] | [junit] Found one Java-level deadlock: | [junit] ============================= | [junit] "Thread-1433": | [junit] waiting to lock monitor 0x00007fdce92c0ab0 (object 0x00007fdcf0dbe090, a java.lang.Object), | [junit] which is held by "Thread-1432" | [junit] "Thread-1432": | [junit] waiting to lock monitor 0x00007fdce92c0c90 (object 0x00007fdcf0dbe1c0, a org.jboss.messaging.core.remoting.impl.invm.InVMConnection), | [junit] which is held by "Thread-1433" | [junit] | [junit] Java stack information for the threads listed above: | [junit] =================================================== | [junit] "Thread-1433": | [junit] at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.failConnection(ConnectionManagerImpl.java:866) | [junit] - waiting to lock <0x00007fdcf0dbe090> (a java.lang.Object) | [junit] at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.connectionDestroyed(ConnectionManagerImpl.java:198) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnector$Listener.connectionDestroyed(InVMConnector.java:187) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnection.close(InVMConnection.java:97) | [junit] - locked <0x00007fdcf0dbe1c0> (a org.jboss.messaging.core.remoting.impl.invm.InVMConnection) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnector.disconnect(InVMConnector.java:161) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMAcceptor$Listener$1.run(InVMAcceptor.java:167) | [junit] "Thread-1432": | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnection.close(InVMConnection.java:87) | [junit] - waiting to lock <0x00007fdcf0dbe1c0> (a org.jboss.messaging.core.remoting.impl.invm.InVMConnection) | [junit] at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.internalClose(RemotingConnectionImpl.java:601) | [junit] at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:455) | [junit] at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.failConnection(ConnectionManagerImpl.java:870) | [junit] - locked <0x00007fdcf0dbe090> (a java.lang.Object) | [junit] at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.connectionDestroyed(ConnectionManagerImpl.java:198) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnector$Listener.connectionDestroyed(InVMConnector.java:187) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnection.close(InVMConnection.java:97) | [junit] - locked <0x00007fdcf0eabc20> (a org.jboss.messaging.core.remoting.impl.invm.InVMConnection) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnector.disconnect(InVMConnector.java:161) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMAcceptor$Listener$1.run(InVMAcceptor.java:167) | [junit] | [junit] Found one Java-level deadlock: | [junit] ============================= | [junit] "Thread-1355": | [junit] waiting to lock monitor 0x00007fdcea4eb748 (object 0x00007fdcf0eadc30, a java.lang.Object), | [junit] which is held by "Thread-1354" | [junit] "Thread-1354": | [junit] waiting to lock monitor 0x00007fdcea4eb838 (object 0x00007fdcf0eadd60, a org.jboss.messaging.core.remoting.impl.invm.InVMConnection), | [junit] which is held by "Thread-1355" | [junit] | [junit] Java stack information for the threads listed above: | [junit] =================================================== | [junit] "Thread-1355": | [junit] at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.failConnection(ConnectionManagerImpl.java:866) | [junit] - waiting to lock <0x00007fdcf0eadc30> (a java.lang.Object) | [junit] at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.connectionDestroyed(ConnectionManagerImpl.java:198) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnector$Listener.connectionDestroyed(InVMConnector.java:187) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnection.close(InVMConnection.java:97) | [junit] - locked <0x00007fdcf0eadd60> (a org.jboss.messaging.core.remoting.impl.invm.InVMConnection) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnector.disconnect(InVMConnector.java:161) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMAcceptor$Listener$1.run(InVMAcceptor.java:167) | [junit] "Thread-1354": | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnection.close(InVMConnection.java:87) | [junit] - waiting to lock <0x00007fdcf0eadd60> (a org.jboss.messaging.core.remoting.impl.invm.InVMConnection) | [junit] at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.internalClose(RemotingConnectionImpl.java:601) | [junit] at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:455) | [junit] at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.failConnection(ConnectionManagerImpl.java:870) | [junit] - locked <0x00007fdcf0eadc30> (a java.lang.Object) | [junit] at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.connectionDestroyed(ConnectionManagerImpl.java:198) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnector$Listener.connectionDestroyed(InVMConnector.java:187) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnection.close(InVMConnection.java:97) | [junit] - locked <0x00007fdcf0ec6058> (a org.jboss.messaging.core.remoting.impl.invm.InVMConnection) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnector.disconnect(InVMConnector.java:161) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMAcceptor$Listener$1.run(InVMAcceptor.java:167) | [junit] | [junit] Found one Java-level deadlock: | [junit] ============================= | [junit] "Thread-471": | [junit] waiting to lock monitor 0x0000000040401d60 (object 0x00007fdceffad6b8, a java.lang.Object), | [junit] which is held by "Thread-470" | [junit] "Thread-470": | [junit] waiting to lock monitor 0x0000000040401f40 (object 0x00007fdceffad7e8, a org.jboss.messaging.core.remoting.impl.invm.InVMConnection), | [junit] which is held by "Thread-471" | [junit] | [junit] Java stack information for the threads listed above: | [junit] =================================================== | [junit] "Thread-471": | [junit] at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.failConnection(ConnectionManagerImpl.java:866) | [junit] - waiting to lock <0x00007fdceffad6b8> (a java.lang.Object) | [junit] at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.connectionDestroyed(ConnectionManagerImpl.java:198) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnector$Listener.connectionDestroyed(InVMConnector.java:187) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnection.close(InVMConnection.java:97) | [junit] - locked <0x00007fdceffad7e8> (a org.jboss.messaging.core.remoting.impl.invm.InVMConnection) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnector.disconnect(InVMConnector.java:161) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMAcceptor$Listener$1.run(InVMAcceptor.java:167) | [junit] "Thread-470": | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnection.close(InVMConnection.java:87) | [junit] - waiting to lock <0x00007fdceffad7e8> (a org.jboss.messaging.core.remoting.impl.invm.InVMConnection) | [junit] at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.internalClose(RemotingConnectionImpl.java:601) | [junit] at org.jboss.messaging.core.remoting.impl.RemotingConnectionImpl.fail(RemotingConnectionImpl.java:455) | [junit] at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.failConnection(ConnectionManagerImpl.java:870) | [junit] - locked <0x00007fdceffad6b8> (a java.lang.Object) | [junit] at org.jboss.messaging.core.client.impl.ConnectionManagerImpl.connectionDestroyed(ConnectionManagerImpl.java:198) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnector$Listener.connectionDestroyed(InVMConnector.java:187) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnection.close(InVMConnection.java:97) | [junit] - locked <0x00007fdceffb6b98> (a org.jboss.messaging.core.remoting.impl.invm.InVMConnection) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMConnector.disconnect(InVMConnector.java:161) | [junit] at org.jboss.messaging.core.remoting.impl.invm.InVMAcceptor$Listener$1.run(InVMAcceptor.java:167) | [junit] | [junit] Found 4 deadlocks. | [junit] View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210082#4210082 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210082

17 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Dynamic Endpoint Deployment

by richard.opalka＠jboss.com

"jason.greene(a)jboss.com" wrote : | I would recommend creating an AS endpoint deployment/management service that manages all of the AS details. Then you can just delegate calls from the Endpoint API to the endpoint service instead of calling MainDeployer from the web container. | Sounds like a good idea let's start iterate on it. If it will be necessary I can fork another dev thread for it. Could you describe your idea in more details Jason? What kind of service do you mean? How should the service deal with e.g. class loading issue? We're talking about simple usecase: We'd like to publish POJO web service from servlet Looking forward to yours and others ideas ;) View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210048#4210048 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210048

17 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Dynamic Endpoint Deployment

by jason.greene＠jboss.com

Spoke to soon. I glanced at the code, and you kind of have this already, so I don't see the problem in passing the correct information. You just need to enhance the service to track the deployment information associated with a context. Btw DeploymentAspectHttpService isn't thread safe. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210039#4210039 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210039

17 years, 1 month

1
0
0 / 0

[Design of JBoss Web Services] - Re: Dynamic Endpoint Deployment

by jason.greene＠jboss.com

The Endpoint API is really intended for out-of-container usage. The TCK for EE5 doesn't verify it any long since the test used to assume sun implementation details. That said, to "fix" in container usage, I would recommend creating an AS endpoint deployment/management service that manages all of the AS details. Then you can just delegate calls from the Endpoint API to the endpoint service instead of calling MainDeployer from the web container. -Jason View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210033#4210033 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210033

17 years, 1 month

1
0
0 / 0

[Design of JMX on JBoss (JBoss/JMX)] - Destroy service in which order?

by mohitanchlia

I posted this question several times in user forum. Sorry for posting it here. http://www.jboss.org/index.html?module=bb&op=viewtopic&t=149771 We have MDB that we basically need to stop and start cleanly. But the problem is that if we try to stop ProxyBindingMDB (below) then it just stays in stopping state because I think bean instance. Can I destroy ProxyBindingMDB alone? I want to either stop or destroy such that I can re-create and start the MDB back again. But I am not sure in which sequence I should do that because when I tried destroy and create on ProxyBindingMDB it connected as consumers but it wasn't draining the queue. >From jmx-console: : | | 1. binding=ProxyBindingMDB A-PROCESSOR,jndiName=local/A-PROCESSOR@30230132,plugin=invoker,service=EJ | B | | 2. jndiName=local/A-PROCESSOR@30230132,plugin=pool,service=EJB | | 3. jndiName=local/A-PROCESSOR@30230132,service=EJB | View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210014#4210014 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210014

17 years, 1 month

1
0
0 / 0

[Design of JBoss jBPM] - Re: blobs, clobs, text and bytes

by alex.guizar＠jboss.com

I agree we should use BLOB/CLOBs as the default and use the chopping only as needed. I don't even think we will find a *current* database/driver combination that does not support LOBs right. The four databases in continuous integration with jBPM 3 (HSQLDB, MySQL, PostgreSQL and Sybase) have no problem with CLOBs. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4210003#4210003 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4210003

17 years, 1 month

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Possible optimization on journal

by clebert.suconic＠jboss.com

jbossfox: I had a few thoughts about optimizations on routing....as I was debugging the journal. probably for CR1, but they will be fundamental for good performance... it would be better if we could add messages with the route table on them, instead of having separate records... (At least for the case when you don' t have 1 thousand destinations you are routing to). So you would still have the option for a separate update record for the binding on the message. And during ACK.. if it' s the last ACK, no need to update, and delete.. couldn' t we just go straight to delete? Don' t know if we would need fundamental changes on the code for that. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4209954#4209954 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4209954

17 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums February 2009