Can we start by looking at a thread dump (jstack) taken at the point where
you've encountered the exception?
That will hopefully show where your stateless bean instances are being
used. We may need to debug why they aren't being returned to the pool if it
looks like there is a leak (although I think that's unlikely).
Increasing the maxSize is often the first port of call, but I tend to find
it makes things crash and burn harder. We're better off finding the root
cause before increasing the parameters.
Jon
On Tue, Oct 6, 2020 at 8:25 AM Kean Erickson
wrote:
> Hello,
>
> So I've doubled maxSize to 40 and I'm still seeing the same problem
> of timeouts encountered while waiting for an available stateless
> bean, which was never an issue until tomee 8 was introduced.
>
> Is there any known consideration with tomee 8 vs. 7 that the number of
> available instances in a stateless pool would wind up being somehow
> smaller, to the point that the pool runs out?
>
> On Sat, Oct 3, 2020 at 10:57 PM Kean Erickson
> wrote:
>
> > I am using a BeanManager to acquire classes annotated @Stateless in
> > multiple threads. This worked fine in 7.1.3, but now in 8.0.3 I'm
> receiving
> > this error:
> >
> > javax.ejb.ConcurrentAccessTimeoutException: No instances available in
> > Stateless Session Bean pool. Waited 30 SECONDS
> >
> > I see a number of these exceptions until the machine roughly runs out of
> > memory and restarts (though there's never an OutOfMemoryError in logs). I
> > had encountered this error in the past and solved it completely by
> > increasing the maxSize to 20 in tomee.xml:
> >
> >
> > maxSize = 20
> >
> >
> > Is there any reason that I would need to boost this value in tomee 8
> > compared to tomee 7? Or any reason the memory footprint would be
> different
> > enough to cause a crash. No other differences, same configuration
> >
> > Thanks,
> > -Kean
> >
> >
>
