You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by uwe schaefer <uw...@uwe-schaefer.org> on 2013/10/14 21:10:17 UTC
unwanted DefaultPageManagerProvider
Hi
we seem to face a little problem here with wicket 6.11:
Application.class:708
setPageManagerProvider(new DefaultPageManagerProvider(this));
sets the default provider here. Lateron [during init()] we replace this
one by using the snippet from HttpSessionDataStore's javadocs:
setPageManagerProvider(new DefaultPageManagerProvider() {
protected IDataStore newDataStore() {
return new HttpSessionDataStore(
pageManagerContext, new PageNumberEvictionStrategy(20));
}
}
for clustering.
Now the problem is, if anyone (in between) is able to call
getPageManagerProvider().get() on the application, this would (and does)
create a dangeling pageSavingThread by wrapping the unwanted
defaultProvider into an AsynchronousDataStore.
... bad thing.
We seem to have this situation, where an Initializer is calling the
above code.
Now for the question: what is the suggested way to register a
PageManagerProvider BEFORE anyone asks for it?
cu uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: unwanted DefaultPageManagerProvider
Posted by Sven Meier <sv...@meiers.net>.
Hi Uwe,
I wonder why your container is already calling session notifications,
when the initialization of the Wicket filter hasn't finished yet.
Please create a Jira issue with a quickstart. That will make it easier
to come to a solution.
Thanks
Sven
On 10/25/2013 11:39 PM, uwe schaefer wrote:
> On 10/25/2013 09:39 AM, Sven Meier wrote:
>
> Hi Sven,
>
>> I think we have to improve Application#setPageMangerProvider():
>> public synchronized final void setPageManagerProvider(final
>> IPageManagerProvider provider)
>> WDYT?
>
> better, but to my understanding, not quite there yet.
>
> while that helps cleanly shutting down the unwanted (default)
> PageManagerProvider, imho, we should make sure, that the user has the
> chance to register his PageManagerProvider, before the get-call is
> being issued.
>
> in our case, with the above fix, we still have a call originating from
> sessionUnbound, that tries to work with the default PMP, which then
> complains about the file/directory he thinks is associated to the
> session being unbound, does not exist. (because, we dont use the
> DiskPageManager, duh :) )
>
> how about registering to the container AFTER wicket init() has been
> executed, so that the application has had the chance to swap the
> default PMP for some other before it is called first?
>
> for a quick workaround we introduced an application state flag being
> flipped from INITIALIZING to RUNNING at the end of init() and just
> return from sessionUnbound unless this flag is RUNNING.
>
> not quite as elegant - in other words hacky - but works for now.
>
> cu uwe
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: unwanted DefaultPageManagerProvider
Posted by uwe schaefer <uw...@codesmell.de>.
On 10/25/2013 09:39 AM, Sven Meier wrote:
Hi Sven,
> I think we have to improve Application#setPageMangerProvider():
> public synchronized final void setPageManagerProvider(final
> IPageManagerProvider provider)
> WDYT?
better, but to my understanding, not quite there yet.
while that helps cleanly shutting down the unwanted (default)
PageManagerProvider, imho, we should make sure, that the user has the
chance to register his PageManagerProvider, before the get-call is being
issued.
in our case, with the above fix, we still have a call originating from
sessionUnbound, that tries to work with the default PMP, which then
complains about the file/directory he thinks is associated to the
session being unbound, does not exist. (because, we dont use the
DiskPageManager, duh :) )
how about registering to the container AFTER wicket init() has been
executed, so that the application has had the chance to swap the default
PMP for some other before it is called first?
for a quick workaround we introduced an application state flag being
flipped from INITIALIZING to RUNNING at the end of init() and just
return from sessionUnbound unless this flag is RUNNING.
not quite as elegant - in other words hacky - but works for now.
cu uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: unwanted DefaultPageManagerProvider
Posted by Sven Meier <sv...@meiers.net>.
I think we have to improve Application#setPageMangerProvider():
public synchronized final void setPageManagerProvider(final
IPageManagerProvider provider)
{
pageManagerProvider = provider;
if (pageManager != null)
{
synchronized (this)
{
if (pageManager == null)
{
pageManager.destroy();
pageManager = null;
}
}
}
}
WDYT?
Sven
On 10/25/2013 12:14 AM, uwe schaefer wrote:
> On 22.10.2013 10:22, Sven Meier wrote:
>
> Hi Sven,
>
>> currently there's no way to change the PageManager once it's fetched in
>> Application#internalGetPageManager().
>
> agreed.
>
>> Do you have a stacktrace for the code triggering
>> Application.getPageManagerProvider().get() ? Besides devutils I don't
>> see any call to this from Wicket.
>
> it is the sessionUnbound method that supposedly was triggered by the
> container doing its clustering while wicket still initializes;
>
> Application:478
> public void sessionUnbound(final String sessionId){
> internalGetPageManager().sessionExpired(sessionId);
> ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
> }
>
> cu uwe
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: unwanted DefaultPageManagerProvider
Posted by uwe schaefer <uw...@codesmell.de>.
On 22.10.2013 10:22, Sven Meier wrote:
Hi Sven,
> currently there's no way to change the PageManager once it's fetched in
> Application#internalGetPageManager().
agreed.
> Do you have a stacktrace for the code triggering
> Application.getPageManagerProvider().get() ? Besides devutils I don't
> see any call to this from Wicket.
it is the sessionUnbound method that supposedly was triggered by the
container doing its clustering while wicket still initializes;
Application:478
public void sessionUnbound(final String sessionId){
internalGetPageManager().sessionExpired(sessionId);
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
}
cu uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: unwanted DefaultPageManagerProvider
Posted by Sven Meier <sv...@meiers.net>.
Hi Uwe,
currently there's no way to change the PageManager once it's fetched in
Application#internalGetPageManager().
Do you have a stacktrace for the code triggering
Application.getPageManagerProvider().get() ? Besides devutils I don't
see any call to this from Wicket.
Regards
Sven
On 10/21/2013 06:16 PM, uwe schaefer wrote:
> On 10/21/2013 09:07 AM, Martin Grigorov wrote:
>
> Hi Martin,
>
>> I hope the ticket will describe better what "and the damage is done"
>> actually means.
>
> sorry if i was unclear. looks like i got lost in the details.
>
> the actual damage is: there is a Thread started and associated with a
> AsynchronousDataStore, which is not used and superseeded during init()
> with the HttpSession-based DataStore to be actually used.
>
> There is no obvious way to get a reference to that thread, so that it
> cannot be stopped on destruction of the application - thus
> redeployment gets problematic.
>
> cu uwe
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: unwanted DefaultPageManagerProvider
Posted by uwe schaefer <uw...@codesmell.de>.
On 10/21/2013 09:07 AM, Martin Grigorov wrote:
Hi Martin,
> I hope the ticket will describe better what "and the damage is done"
> actually means.
sorry if i was unclear. looks like i got lost in the details.
the actual damage is: there is a Thread started and associated with a
AsynchronousDataStore, which is not used and superseeded during init()
with the HttpSession-based DataStore to be actually used.
There is no obvious way to get a reference to that thread, so that it
cannot be stopped on destruction of the application - thus redeployment
gets problematic.
cu uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: unwanted DefaultPageManagerProvider
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
On Fri, Oct 18, 2013 at 9:50 PM, uwe schaefer <uw...@codesmell.de> wrote:
> On 18.10.2013 09:03, Martin Grigorov wrote:
>
> Hi Martin,
>
>
> Can you give more details about the setup and the problem ?
>>
>
> of course. we use two Tomcat6 with clustering enabled (Backup-Manager)
> with apache in front using sticky sessions.
>
> when redeploying, we restart tomcat.
>
> Now when one tomcat is restarted and the wicket initializes, there is a
> time-window in which wicket is not yet fully initialized (and our DataStore
> is not yet set), yet the application is already bound as an
> UnbindingListener.
>
> This is where we see sessionUnbound being called, which as i mentioned,
> causes a default datastore (disk) being wrapped in an AsyncDatastore and
> the damage is done:
> Application:478
> public void sessionUnbound(final String sessionId){
> internalGetPageManager().**sessionExpired(sessionId);
> }
>
> Application:1387
> pageManager = pageManagerProvider.get(**getPageManagerContext());
>
> DefaultPageManagerProvider:58
> if (dataStore.canBeAsynchronous()**)
> {
> int capacity = storeSettings.**getAsynchronousQueueCapacity()**;
> dataStore = new AsynchronousDataStore(**dataStore, capacity);
> }
>
> and then AsynchronousDataStore:97
> pageSavingThread.start();
>
> what other info in particular are you looking for?
i could create a quickstart and attach it to a jira issue.
I hope the ticket will describe better what "and the damage is done"
actually means.
I'm not sure whether it is just me (there are no other responses in this
thread) but your problem description emphasis more on Wicket's code than on
what really is the problem you face.
>
>
> cu uwe
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: unwanted DefaultPageManagerProvider
Posted by uwe schaefer <uw...@codesmell.de>.
On 18.10.2013 09:03, Martin Grigorov wrote:
Hi Martin,
> Can you give more details about the setup and the problem ?
of course. we use two Tomcat6 with clustering enabled (Backup-Manager)
with apache in front using sticky sessions.
when redeploying, we restart tomcat.
Now when one tomcat is restarted and the wicket initializes, there is a
time-window in which wicket is not yet fully initialized (and our
DataStore is not yet set), yet the application is already bound as an
UnbindingListener.
This is where we see sessionUnbound being called, which as i mentioned,
causes a default datastore (disk) being wrapped in an AsyncDatastore and
the damage is done:
Application:478
public void sessionUnbound(final String sessionId){
internalGetPageManager().sessionExpired(sessionId);
}
Application:1387
pageManager = pageManagerProvider.get(getPageManagerContext());
DefaultPageManagerProvider:58
if (dataStore.canBeAsynchronous())
{
int capacity = storeSettings.getAsynchronousQueueCapacity();
dataStore = new AsynchronousDataStore(dataStore, capacity);
}
and then AsynchronousDataStore:97
pageSavingThread.start();
what other info in particular are you looking for?
i could create a quickstart and attach it to a jira issue.
cu uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: unwanted DefaultPageManagerProvider
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
Can you give more details about the setup and the problem ?
On Thu, Oct 17, 2013 at 11:35 PM, uwe schaefer <uw...@codesmell.de> wrote:
> On 14.10.2013 21:41, uwe schaefer wrote:
>
> could it also be a
>> racecondition with clustering and
>>
>> public void sessionUnbound(final String sessionId)
>>
>> being called before init() returns?
>>
>
> after further investigation it is pretty clear, that the above race
> condition happens (at least on tomcat6) - so if noone objects, i would hop
> to jira and create an issue for that.
>
> our quick workaround includes ignoring all WebApplicatoin.sessionUnbound(*
> *String) calls until initialization is complete.
>
>
> cu uwe
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@wicket.**apache.org<us...@wicket.apache.org>
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: unwanted DefaultPageManagerProvider
Posted by uwe schaefer <uw...@codesmell.de>.
On 14.10.2013 21:41, uwe schaefer wrote:
> could it also be a
> racecondition with clustering and
>
> public void sessionUnbound(final String sessionId)
>
> being called before init() returns?
after further investigation it is pretty clear, that the above race
condition happens (at least on tomcat6) - so if noone objects, i would
hop to jira and create an issue for that.
our quick workaround includes ignoring all
WebApplicatoin.sessionUnbound(String) calls until initialization is
complete.
cu uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: unwanted DefaultPageManagerProvider
Posted by uwe schaefer <uw...@codesmell.de>.
On 14.10.2013 21:10, uwe schaefer wrote:
> Now for the question: what is the suggested way to register a
> PageManagerProvider BEFORE anyone asks for it?
PS: rather than an initializer being the culprit, could it also be a
racecondition with clustering and
public void sessionUnbound(final String sessionId)
being called before init() returns?
cu uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org