[JCA] New message: "Re: CachedConnectionManager API issue"
by Vicky Kak
User development,
A new message was posted in the thread "CachedConnectionManager API issue":
http://community.jboss.org/message/524438#524438
Author : Vicky Kak
Profile : http://community.jboss.org/people/vickyk
Message:
--------------------------------------------------------------
> gaohoward wrote:
> As the method setTransactionManagerServiceName(ObjectName), I don't know how to adapt the above code to the new JCA apis. Can you give some advice?
>
>
>
We could inject the tm like this
TransactionManager tm = (TransactionManager) getServer().getAttribute(TRANSACTION_MANAGER_OBJECT_NAME
,"TransactionManager");
ccm.setTransactionManager(tm);
But this will not help you as the following would not behave well
mbeanServer.invoke(on, "start", new Object[0], new String[0]);
We may land up in code change in the CCM.
Before we take a deep look into it, can you explain what exactly your test case is doing?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524438#524438
16 years, 5 months
[jBPM] New message: "jBPM Timer problem"
by Simone Simone
User development,
A new message was posted in the thread "jBPM Timer problem":
http://community.jboss.org/message/524434#524434
Author : Simone Simone
Profile : http://community.jboss.org/people/simoj
Message:
--------------------------------------------------------------
I'm working with jBPM 3.3.1 and I'm trying to use jBPM timer.
I configured a timer on a node in my jbpm process :
<
node name=+"waitForAsync"+>
<timer duedate=+"10 seconds"+ name=+"TimeoutAsincrono"+ transition=+"asyncNotReceived"+>
<action class=+"com.swf.fsm.action.AsyncNotReceivedHandler"+></action>
</timer>
<transition to=+"checkAsyncReceived"+></transition>
<transition to=+"node1"+ name=+"asyncNotReceived"+></transition>
</node>
I start the jbpm process from a Message Driven Bean and it starts correctly but when the process tries to execute the node where I set the Timer, I
obtain the following error :
16:18:15,531 ERROR [GraphElement] action threw exception: ejb timer entity lookup problem
org.jbpm.JbpmException: ejb timer entity lookup problem
at org.jbpm.scheduler.ejbtimer.EntitySchedulerServiceFactory.getTimerEntityHome(EntitySchedulerServiceFactory.java:45)
at org.jbpm.scheduler.ejbtimer.EntitySchedulerServiceFactory.openService(EntitySchedulerServiceFactory.java:62)
.....
Caused by: javax.naming.NameNotFoundException: env not bound
....
could anyone please help me? I think to forget something in the configuration files but I don't know where.
Thanks
Simone
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524434#524434
16 years, 5 months
[JBoss Microcontainer Development] New message: "Re: Pluggable dependency resolver"
by Kabir Khan
User development,
A new message was posted in the thread "Pluggable dependency resolver":
http://community.jboss.org/message/524424#524424
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
Right,
So the basic outline is that AbstractController.install(ControllerContext) installs the contexts into the controller. In doing so the context goes through several states. Upon entry to each state, the controller checks if the context has all its dependencies resolved, and if so it is moved to the next state. If not, it is left in that state, and we try to resolve the context later once another context is added to the controller. Once the context reaches INSTALLED state it is considered to be installed.
The mechanism that is currently in trunk does this by calling a method internally in resolveContexts(). What this essentially does is to iterate over each controller state. For each controller state it gets a list of the contexts in that state and then for each context see if the dependencies are resolved. The contexts with all dependencies resolved are pushed to the next state, and the contexts that don't are left in the current state. If at least one context could be moved to the next state, we iterate over the states again.
Pseudocode:
resolveContexts()
{
while (resolved)
{
resolved = false;
for (ControllerState state : statesInController)
{
Set<ControllerContext> contexts = getContextsForState(state);
Set<ControllerContext) resolvedContexts = new HashSet<ControllerContext>();
for (ControllerContext context : contexts)
{
//Req. state will normaly be INSTALLED so we don't look at the contexts that have reached that state
if (state == context.getRequiredState())
continue;
//Iterate over context's DependencyItems and try to resolve them
//(they are resolved by looking up the information from the DependencyItem in the controller)
if (isResolved(context), state)
{
resolvedContexts.add(context);
}
}
if (resolvedContexts.size() > 0)
{
for (ControllerContext context : contexts)
incrementState(context); // Puts the context's state to state, and invokes any associated ControllerContextAction
resolved = true;
break;
}
}
}
}
So basically every time a context has its state incremented there could potentially be other contexts waiting for it to enter that state via a dependency which is why we go over and check all the contexts in each state.
With my indexing resolver I take a different approach. When adding a context to the controller I index it by its dependencies. Then later when adding another context, I look in the index if something has an indexed dependency on the new context. If that is the case, I only try to increment the state of the contexts registered as having a dependency.
Some basic profiling (take with a pinch of salt) shows that not that much time is spent actually trying to resolve dependencies with either way of doing it. Having spoken about this with Ales, the reason for this is that most stuff deployed in AS is deployed in the right order or more or less at the same time as their dependencies, so we don't have HUGE numbers of contexts waiting in a state while hoping to reach INSTALLED. If that were the case I am pretty confident that the indexing resolver would win easily.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/524424#524424
16 years, 5 months