Asynchronous EJB calls dropped with StrictMaxPool
Hi,
I have an interesting problem with dropped asynchronous EJB calls on AS 6.0.0.Final.
We recently encountered the issue where Stateless Session Beans are not cleaned up. We implemented the recommended work around and moved from ThreadLocalPool to StrictMaxPool, with a StrictMaxPool size of 50. This has resolved the memory leak, however it's introduced a new problem.
Our application periodically scans a directory and calls a Stateless processing bean for all the files present. The method on the processing bean is @Asynchronous, so it returns immediately, and there can be 1000s of files in the directory when the scan occurs. Under these conditions all 50 instances of the processing bean will be utilised and subsequent calls queued until an instance becomes available. It appears that the queue size is only 500, after which calls to the processing bean are dropped.
I have written two simple beans to illustrate the problem - a Singleton bean with a scheduled method and a Stateless Session Bean with an asynchronous method. The scheduled bean calls the asynchronous method 1000 times, of which ~550 calls succeed, with the remaining ~450 dropped.
The Singleton scheduled bean:
@Singleton
@Startup
public class ScheduledBean
{
Logger logger = Logger.getLogger(ScheduledBean.class);
@EJB(lookup="ProcessingBean/local")
ProcessingBeanInterface processingBean;
@Schedule(second="0", minute="*", hour="*", persistent=false)
public void run()
{
for(int i = 0; i < 1000; ++i)
{
logger.info("Running processing bean, id: " + i);
processingBean.doWork(i);
}
}
}
The Stateless processing bean:
@Stateless
@Local(ProcessingBeanInterface.class)
public class ProcessingBean implements ProcessingBeanInterface
{
Logger logger = Logger.getLogger(ProcessingBean.class);
@Asynchronous
public void doWork(int id)
{
logger.info("Doing work, id: " + id);
try
{
Thread.sleep(1000);
}
catch (InterruptedException e)
{
}
}
}
Is this queue size configurable, or can we configure the AS to not drop EJB calls?
If it's not possible to configure the queue for this type of usage then I'll look at modifying our scheduled bean to initiate the processing in batches.
Any help or insight would be greatly appreciated.
Thanks,
Dave
