Re: tapestry.thread-pool.max-pool-size not doing anything
You're rigth. If multiple threads are scheduling jobs and the pool has reached
a threadcount of maxsize-1, chances are that a RejectedExecutionException
is thrown. The offer-method should use a lock. Like so:
public boolean offer(Runnable inJob) {
_lock.lock();
try {
if (_executor.getPoolSize() _executor.getMaximumPoolSize()) {
return false;
}
return super.offer(inJob);
} finally {
_lock.unlock();
}
}
--Arjan Verstoep
On 2 Jul 2014, at 09:52, Lance Java wrote:
I'm not convinced this solution is thread-safe.
On 1 Jul 2014 17:21, Arjan Verstoep a.j.verst...@alumnus.utwente.nl
wrote:
Yes, the default implementation is very counter-intuitive. I have
invesigated once, and it was possible to 'repair' the ThreadPoolExecutor if
you provide the 'right' work-queue.
I don't know if you can apply this to Tapestry's ThreadPoolExecutor, but
anyhow: here's how I do it:
--Arjan Verstoep
/**
* Specific implementation of the {@link LinkedBlockingQueue} that won't
* accept offered elements as long as the given {@link
ThreadPoolExecutor} has
* not yet reached its maximum capacity.
* pThe intended effect is to have a ThreadPoolExecutor that will only
start
* adding Runnables to the Queue iafter/i the maximum number of
Threads is
* reached. The default implementation of the ThreadPoolExecutor is,
that it
* first starts new Threads when the Queue is full, which with an
unbounded
* Queue will inever/i be the case./p
* pThis class will throw an
* unchecked {@link java.lang.NullPointerException} if the
ThreadPoolExecutor
* is not set with {@link #setExecutor(ThreadPoolExecutor)} !/p
*/
class ThreadCreationTriggeringLinkedBlockingQueueT extends
LinkedBlockingQueueRunnable {
private static final long serialVersionUID = 1L;
private transient ThreadPoolExecutor _executor;
/**
* pIf the Executor's current pool size is below the maximum pool
size,
* this method will not add the {@link Runnable} to the Queue.br/
* The {@link ThreadPoolExecutor} will then be forced to start a new
Thread.
* /p{@inheritDoc}
*/
@Override
public boolean offer(Runnable inJob) {
if (_executor.getPoolSize() _executor.getMaximumPoolSize()) {
return false;
}
return super.offer(inJob);
}
/**
* Sets the executor which will be used to decide whether or not to
add the
* Runnable to the Queue.
*
* @param inExecutor the ThreadPoolExecutor
*/
public void setExecutor(ThreadPoolExecutor inExecutor) {
_executor = inExecutor;
}
}
ThreadCreationTriggeringLinkedBlockingQueueRunnable queue = new
ThreadCreationTriggeringLinkedBlockingQueueRunnable();
ThreadPoolExecutor threadpoolExecutor = new
ThreadPoolExecutor(availableProcessors(), THREADPOOLMULTIPLICATOR *
availableProcessors(), 10, TimeUnit.MINUTES, queue);
queue.setExecutor(threadpoolExecutor);
On 1 Jul 2014, at 16:04, Lance Java wrote:
I feel the implementation is flawed.
I would prefer that the pool size would increase from minimum to maximum
under load to increase throughput and then revert back to the minimum
when
not under load.
But instead, the pool size stays at minimum until the queue is full. In
my
opinion, the application is about to fall over at this point. Only then
will the pool size increase which i think is crazy / stupid.
Because of this, I've always seen core pool size and max pool size set to
the same value.
To achieve my preferred behaviour (above) I think you can specify
different
pooling behaviour. I think it required throwing exceptions and extending
ThreadPoolExecutor or something nasty like that.
On 1 Jul 2014 12:14, D Tim Cummings t...@triptera.com.au wrote:
Ok, thanks for explaining this... I think :)
I had a read of the ThreadPoolExecutor javadoc. It seems to me that
core-pool-size should be described as the maximum pool size before
queuing.
Describing it as the minimum pool size is misleading because there is no
minimum. The number of threads in the pool before any have been invoked
is
always zero.
Tim
On 1 Jul 2014, at 16:25, Lance Java lance.j...@googlemail.com wrote:
If you read the javadoc for java.util.concurrent ThreadPoolExecutor
you'll
see that the number of threads will only increase when the queue has
reached its capacity. Crazy / stupid behaviour if you ask me... But
expected.
I've been caught out by this before when I set core pool size to 1,
expecting the thread size to increase under load.
On 1 Jul 2014 02:53, D Tim Cummings t...@triptera.com.au wrote:
Hi
I am using Tapestry 5.3.7 and the ParallelExecutor. When I increase
the
max-pool-size I am not able to use any more threads. However when I
increase the core-pool-size I am able to use more threads. It looks
like
the max-pool-size is not doing anything (or I am not understanding
what
Re: tapestry.thread-pool.max-pool-size not doing anything
Yes, the default implementation is very counter-intuitive. I have invesigated
once, and it was possible to 'repair' the ThreadPoolExecutor if you provide the
'right' work-queue.
I don't know if you can apply this to Tapestry's ThreadPoolExecutor, but
anyhow: here's how I do it:
--Arjan Verstoep
/**
* Specific implementation of the {@link LinkedBlockingQueue} that won't
* accept offered elements as long as the given {@link ThreadPoolExecutor} has
* not yet reached its maximum capacity.
* pThe intended effect is to have a ThreadPoolExecutor that will only start
* adding Runnables to the Queue iafter/i the maximum number of Threads is
* reached. The default implementation of the ThreadPoolExecutor is, that it
* first starts new Threads when the Queue is full, which with an unbounded
* Queue will inever/i be the case./p
* pThis class will throw an
* unchecked {@link java.lang.NullPointerException} if the ThreadPoolExecutor
* is not set with {@link #setExecutor(ThreadPoolExecutor)} !/p
*/
class ThreadCreationTriggeringLinkedBlockingQueueT extends
LinkedBlockingQueueRunnable {
private static final long serialVersionUID = 1L;
private transient ThreadPoolExecutor _executor;
/**
* pIf the Executor's current pool size is below the maximum pool size,
* this method will not add the {@link Runnable} to the Queue.br/
* The {@link ThreadPoolExecutor} will then be forced to start a new Thread.
* /p{@inheritDoc}
*/
@Override
public boolean offer(Runnable inJob) {
if (_executor.getPoolSize() _executor.getMaximumPoolSize()) {
return false;
}
return super.offer(inJob);
}
/**
* Sets the executor which will be used to decide whether or not to add the
* Runnable to the Queue.
*
* @param inExecutor the ThreadPoolExecutor
*/
public void setExecutor(ThreadPoolExecutor inExecutor) {
_executor = inExecutor;
}
}
ThreadCreationTriggeringLinkedBlockingQueueRunnable queue = new
ThreadCreationTriggeringLinkedBlockingQueueRunnable();
ThreadPoolExecutor threadpoolExecutor = new
ThreadPoolExecutor(availableProcessors(), THREADPOOLMULTIPLICATOR *
availableProcessors(), 10, TimeUnit.MINUTES, queue);
queue.setExecutor(threadpoolExecutor);
On 1 Jul 2014, at 16:04, Lance Java wrote:
I feel the implementation is flawed.
I would prefer that the pool size would increase from minimum to maximum
under load to increase throughput and then revert back to the minimum when
not under load.
But instead, the pool size stays at minimum until the queue is full. In my
opinion, the application is about to fall over at this point. Only then
will the pool size increase which i think is crazy / stupid.
Because of this, I've always seen core pool size and max pool size set to
the same value.
To achieve my preferred behaviour (above) I think you can specify different
pooling behaviour. I think it required throwing exceptions and extending
ThreadPoolExecutor or something nasty like that.
On 1 Jul 2014 12:14, D Tim Cummings t...@triptera.com.au wrote:
Ok, thanks for explaining this... I think :)
I had a read of the ThreadPoolExecutor javadoc. It seems to me that
core-pool-size should be described as the maximum pool size before queuing.
Describing it as the minimum pool size is misleading because there is no
minimum. The number of threads in the pool before any have been invoked is
always zero.
Tim
On 1 Jul 2014, at 16:25, Lance Java lance.j...@googlemail.com wrote:
If you read the javadoc for java.util.concurrent ThreadPoolExecutor
you'll
see that the number of threads will only increase when the queue has
reached its capacity. Crazy / stupid behaviour if you ask me... But
expected.
I've been caught out by this before when I set core pool size to 1,
expecting the thread size to increase under load.
On 1 Jul 2014 02:53, D Tim Cummings t...@triptera.com.au wrote:
Hi
I am using Tapestry 5.3.7 and the ParallelExecutor. When I increase the
max-pool-size I am not able to use any more threads. However when I
increase the core-pool-size I am able to use more threads. It looks like
the max-pool-size is not doing anything (or I am not understanding what
it
is supposed to do).
When I use the defaults I get a maximum of 3 threads and other threads
seem to wait in a queue and execute later.
When I use the following settings in web.xml I still get only 3 threads
context-param
param-nametapestry.thread-pool.core-pool-size /param-name
param-value3/param-value
/context-param
context-param
param-nametapestry.thread-pool.max-pool-size/param-name
param-value20/param-value
/context-param
When I use the following settings in web.xml I get 3 threads
context-param
param-nametapestry.thread-pool.core-pool-size /param-name
param-value3/param-value
/context-param
context-param
param-nametapestry.thread-pool.max-pool-size/param-name
Re: OutOfMemoryError after serving N pages
[EMAIL PROTECTED] wrote: We had the same thing, and in our case it was related to a small PermGen Space setting in our Tomcat container. My understanding of the Sun JVM is that it partitions up its allocated memory into heap, perm gen, etc. chunks and that the Perm Gen space is where all meta data about classes gets stored. In modern JEE programming with all the CGLIB and just-in-time abstract class overrides instantiation, the Perm Gen space tends to blow up quicker. Anyway, try throwing a -XX:MaxPermSize=256m on your JVM startup and see if that helps. Note: if you're actually running out of PermGen space, you'll see a reference to that in your OOME. If you are just getting plain old OOMEs, it sounds like something more sinister. HTH, Tom My JVM is complaining about heap space, so I fear that it is something sinister... 10:36:23,289 ERROR [MusiController4]:253 - Servlet.service() for servlet MusiController4 threw exception java.lang.OutOfMemoryError: Java heap space ~Arjan Verstoep - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Populating Tapestry ASO after successful Acegi Auth
[EMAIL PROTECTED] wrote:
Greetings:
I'm using Tapestry 4 and Acegi 1.0.1. I have acegi set up to perform
authentication using the AuthenticationProcessingFilter. I have a
requirement to place the domain object the Acegi UserDetails object is
based upon into a Tapestry ASO for use during the user session. =20
My question is: what the best practice for filling the Tapestry ASO with
the domain model's user object upon successful authentication with
Acegi?
Thanks,
-jason
Hi Jason,
Set up your login-prcedure to redirect you to a certain page after
successful login. Then, on that particular page put this code to get the
Authentication-object. Then, You can put the Authentication object into
the ASO-object.
I currently use this code in my border-component, so it executes way too
often. But I'll get to that eventually.
~ Arjan Verstoep
private Authentication getAuthentication(IRequestCycle cycle) {
Authentication auth = null;
WebSession session =
cycle.getInfrastructure().getRequest().getSession(false);
if (session!=null) {
SecurityContext sc = (SecurityContext)
session.getAttribute(HttpSessionContextIntegrationFilter.ACEGI_SECURITY_CONTEXT_KEY);
if (sc!=null) {
auth = sc.getAuthentication();
}
}
return auth;
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
