Re: [jboss-user] [jBPM] - jBPM DispatcherThread : J2SE and JEE behavior
by Sebastian Schneider
Sebastian Schneider [http://community.jboss.org/people/sebastian.s] replied to the discussion
"jBPM DispatcherThread : J2SE and JEE behavior"
To view the discussion, visit: http://community.jboss.org/message/540215#540215
--------------------------------------------------------------
Hello zecas,
if I understand your post correctly it seems to me that you have misunderstood the way jBPM works. Please read the section about asynchronous continuations in the jBPM documentation. The section explains jBPM's behaviour quite well.
If you invoke a jBPM operation - as starting a process for example - the process is executed in the same java thread as the invocation originates from. The process is then executed till it reaches a state where no further activities can be executed. This is the case if the process arrives in a waiting state or in a user task for example. If you don't want this behaviour you can use the async-setting on nodes. This tells jBPM to execute the node via the JobExecutor. The JobExecutor is reponsible for continuing the execution as well as for the execution of timers.
The JobExecutor itself is a thread which need to be started on jBPM initialization. Speaking of jBPM 3.2 this can be achieved via the JobExecutor servlet for example. For the actual execution of activities the JobExecutor maintains a pool of threads to perform the work. You can configure how many threads should be created.
P.S.: You did not mention which version of jBPM you are using but the overall behaviour should be the same for both jBPM 3.2 and 4.x.
HTH
Sebastian
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/540215#540215]
Start a new discussion in jBPM at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 3 months
Re: [jboss-user] [JBoss Web Services] - Need advise on defining a webservice client for Teiid
by Steven Hawkins
Steven Hawkins [http://community.jboss.org/people/shawkins] replied to the discussion
"Need advise on defining a webservice client for Teiid"
To view the discussion, visit: http://community.jboss.org/message/540212#540212
--------------------------------------------------------------
To exand a little more, in MetaMatrix we supported source calls that returned xml through:
SOAP
-doc literal/doc literal wrapped
-rpc
HTTP
-post with dynamic xml document as the content
-get with a single parameter / dynamic xml document value
-post "
-get with dynamic parameter values
-post "
All of the consumption is at the message level, there is no expectation that generated object models, or in many cases even wsdls are available at runtime. There was also a variety of security (predominately basic auth) and ws-* options supported depending up the actual call.
Ideally all transport and environmentally dependent information would be held externally to the Teiid configuration. Utilizing ESB functionality (as opposed to, or in addition to) standard AS is fine too. Out of the box though ESB does not support the latter 4 HTTP invocation modes, since it expects http routers to have their query strings pre-configured.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/540212#540212]
Start a new discussion in JBoss Web Services at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 3 months
[EJB 3.0] - Stateful EJB 3.0 - ClassCastException
by Naga Vijayapuram
Naga Vijayapuram [http://community.jboss.org/people/nvwm] created the discussion
"Stateful EJB 3.0 - ClassCastException"
To view the discussion, visit: http://community.jboss.org/message/540205#540205
--------------------------------------------------------------
Hello,
I am trying out a Stateful EJB 3.0 and am getting this when I try to access it from a remote client -
$ ./Client.sh
Exception in thread "main" java.lang.ClassCastException: javax.naming.Reference cannot be cast to org.jboss.tutorial.stateful.bean.ShoppingCart
at org.jboss.tutorial.stateful.client.Client.main(Client.java:21)
The same client code works fine from within a jsp page.
What could be happenning? Here's the client code - it fails with above exception during "lookup" from the remote client -
> InitialContext ctx = new InitialContext();
> ShoppingCart cart = (ShoppingCart) ctx.lookup("ShoppingCartBean/remote");
NOTE: Reproduced in both JBoss 5.1.0.GA and in JBoss 6 M2.
Naga Vijayapuram
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/540205#540205]
Start a new discussion in EJB 3.0 at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 3 months
[EJB 3.0] - Possible Bug with EJB 3 Timers
by Andrig Miller
Andrig Miller [http://community.jboss.org/people/andy.miller%40jboss.com] created the discussion
"Possible Bug with EJB 3 Timers"
To view the discussion, visit: http://community.jboss.org/message/540195#540195
--------------------------------------------------------------
I have recently added an EJB 3 Timer to my application, and in testing it out, the timer never expired, and called the method in the stateless session bean that has the @Timeout annotation.
Here is the code:
package services.ejb;
import java.math.BigDecimal;
import java.util.Calendar;
import java.util.Date;
import java.util.List;
import javax.annotation.Resource;
import javax.ejb.Stateless;
import javax.ejb.Timeout;
import javax.ejb.Timer;
import javax.ejb.TimerService;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
import javax.persistence.Query;
import services.ejb.OrderManager;
import services.entities.Address;
import services.entities.Customer;
import services.entities.Order;
import services.entities.OrderLine;
import services.exceptions.CreateDataException;
@Stateless
public class OrderManagerBean implements OrderManager {
@Resource
TimerService timerService;
@PersistenceContext (unitName="services")
protected EntityManager entityManager;
...
public void createOrderPurgeTimer(boolean runWithTimer) throws CreateDataException {
for (Object object : timerService.getTimers()) {
Timer timer = (Timer) object;
timer.cancel();
}
if (runWithTimer) {
long twentyFourHours = 1000 * 60 * 60 * 24;
timerService.createTimer(twentyFourHours, twentyFourHours, null);
}
return;
}
@Timeout
public void purgeOldOrders(Timer timer) {
// Delete the previous days worth of orders
Query query = entityManager.createNativeQuery("delete from Order where orderDate < :date");
Calendar now = Calendar.getInstance();
// Back up to the top of the hour, so we only delete orders from the previous period'
now.set(Calendar.MINUTE, 0);
now.set(Calendar.SECOND, 0);
query.setParameter("date", new Date(now.getTimeInMillis()));
query.executeUpdate();
return;
}
}
In the above stateless session bean, I have a method to create the timer, and the one that is the callback when the timer should expire. It creates a single timer that should expire every twenty four hours, so the initial expiration, and the interval are both set to 24 hours. I have a servlet that calls the method to create the timer, along with other reference data needed for the application, and I can see the timer has been persisted in the database, and here is what it looks like:
TIMERID = 1272464496401, TARGETID = [target=jboss.j2ee:ear=OrderManagerApp.ear,jar=OrderManagerEJB.jar,name=OrderManagerBean,service=EJB3], INITIALDATE=2010-04-29 08:26:29, TIMERINTERVAL=86400000, INSTANCEPK=NULL, INFO=NULL
So, I created the timer through the createOrderPurgeTimer method on the OrderManagerBean, and everything looks correct. The INITIALDATE is 24 hours after I created it, and the TIMERINTERVAL is 24 hours in milliseconds, as I would expect.
So, I was expecting, after allowing the application to run all day and night, that at 8:26:49 this morning (the INITIALDATE) the timer would expire, and call the purgeOldOrders method on the OrderManagerBean.
I know this didn't happen, because there is no error created from the method (maybe it failed), and because in looking at the invocation statistics from the JMX Console I see the following:
InvocationStatistics concurrentCalls='0'
method name='createOrderPurgeTimer' count='1' minTime='78' maxTime='78' totalTime='78'
method name='createOrder' count='15' minTime='0' maxTime='4' totalTime='18'
As you can see, the only two methods called on the bean are the createOrderPurgeTimer, and the createOrder (I didn't include that method in the above code snippet). No call to the purgeOldOrders method at all, and its more than 2 hours after the INITIALDATE that is in the TIMER table.
I don't believe I have done anything wrong in the code.
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/540195#540195]
Start a new discussion in EJB 3.0 at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 3 months
[JBoss Messaging] - Disabling ExpiryQueue in JBoss 5.1.0
by Veit Guna
Veit Guna [http://community.jboss.org/people/veitg] created the discussion
"Disabling ExpiryQueue in JBoss 5.1.0"
To view the discussion, visit: http://community.jboss.org/message/540192#540192
--------------------------------------------------------------
Hi.
We're using JBoss 5.1.0 and its standard message queue component. On deployment we create some queues via -service.xml files like so:
<mbean code="org.jboss.jms.server.destination.QueueService"
name="jboss.messaging.destination:service=Queue,name=myQueue"
xmbean-dd="xmdesc/Queue-xmbean.xml">
<depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
<depends>jboss.messaging:service=PostOffice</depends>
</mbean>
It seems that the default ExpiryQueue is always set to "ExpiryQueue" of JBoss. When messages expire, they are moved to that queue. Now
my question is, how can I disable it so the messages get simply dropped? Until 4.0.4 this seemed the default behavior - AFAIK. Setting ExpiryQueue to an empty string doesn't seem to do the trick - an error concerning mandatory occurs then. Any hints?
Also there seems the problem that messages get only expired, when a consumer is listening on the queue. Can this be automated with jboss messaging that comes with JBoss 5.1.0?
Thanks in advance.
Veit
--------------------------------------------------------------
Reply to this message by going to Community
[http://community.jboss.org/message/540192#540192]
Start a new discussion in JBoss Messaging at Community
[http://community.jboss.org/choose-container!input.jspa?contentType=1&cont...]
14 years, 3 months