Re: Bug in Wicket Push TimerChannelService when used with background threads
I just realized that the current session is also bound to the thread
context. Would it make sense to attach the Session to the background
thread using the same way we do it for the Application?
E.g.
Session oldSession = Session.exists() ? Session.get() : null;
Session.set(_session);
try
{
... invoke...
}
finally
{
if (oldSession == null) Session.unset();
else Session.set(oldSession);
}
Without doing this, the exception IllegalSateException: You can only
locate or create sessions in the context of a request cycle may be thrown.
Seb
On 01.10.2010 00:42, Rodolfo Hansen wrote:
On Thu, 2010-09-30 at 23:48 +0200, Sebastian wrote:
There was an issue in your patch where the application could be left
in the ThreadContext, which was fixed,
Hi Rodolfo,
I think you are referring to
try {
Application.set(_application);
methods[m].invoke(o, parameters);
} finally {
Application.set(originalApplication);
if (originalApplication != null) Application.set(originalApplication);
}
The problem is if this code is executed in a separate thread the
originalApplication will be null. If you just omit the null check in the
finally clause the setter will throw an IllegalArgumentException. So to
remove the app from the ThreadContext we would have to call
Application.unset() instead:
if (originalApplication == null) Application.unset();
else Application.set(originalApplication);
you are right, although i checked the source for set and didn't see the
throw...
amended in the 1.4 branches
Regards,
Seb
On 30.09.2010 23:08, Rodolfo Hansen wrote:
Hi Sebastian, your patch is in:
trunk (1.5)
1.4 branch (future 1.4.13 release)
and 1.4.12
There was an issue in your patch where the application could be left in
the ThreadContext, which was fixed,
as well as a simplification in the trigger function.
On Wed, 2010-09-29 at 21:39 +0200, Sebastian wrote:
Hi,
there is a problem in the Push TimerChannelService implementation:
Callbacks do not work reliable when they are invoked from non-Web
threads. The There is no application attached to current thread
WicketRuntimeException will occur in such a case. The attached patch
fixes this issue.
Regards,
Seb
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Bug in Wicket Push TimerChannelService when used with background threads
Added.
On Fri, 2010-10-01 at 13:14 +0200, Sebastian wrote:
I just realized that the current session is also bound to the thread
context. Would it make sense to attach the Session to the background
thread using the same way we do it for the Application?
E.g.
Session oldSession = Session.exists() ? Session.get() : null;
Session.set(_session);
try
{
... invoke...
}
finally
{
if (oldSession == null) Session.unset();
else Session.set(oldSession);
}
Without doing this, the exception IllegalSateException: You can only
locate or create sessions in the context of a request cycle may be thrown.
Seb
On 01.10.2010 00:42, Rodolfo Hansen wrote:
On Thu, 2010-09-30 at 23:48 +0200, Sebastian wrote:
There was an issue in your patch where the application could be left
in the ThreadContext, which was fixed,
Hi Rodolfo,
I think you are referring to
try {
Application.set(_application);
methods[m].invoke(o, parameters);
} finally {
Application.set(originalApplication);
if (originalApplication != null) Application.set(originalApplication);
}
The problem is if this code is executed in a separate thread the
originalApplication will be null. If you just omit the null check in the
finally clause the setter will throw an IllegalArgumentException. So to
remove the app from the ThreadContext we would have to call
Application.unset() instead:
if (originalApplication == null) Application.unset();
else Application.set(originalApplication);
you are right, although i checked the source for set and didn't see the
throw...
amended in the 1.4 branches
Regards,
Seb
On 30.09.2010 23:08, Rodolfo Hansen wrote:
Hi Sebastian, your patch is in:
trunk (1.5)
1.4 branch (future 1.4.13 release)
and 1.4.12
There was an issue in your patch where the application could be left in
the ThreadContext, which was fixed,
as well as a simplification in the trigger function.
On Wed, 2010-09-29 at 21:39 +0200, Sebastian wrote:
Hi,
there is a problem in the Push TimerChannelService implementation:
Callbacks do not work reliable when they are invoked from non-Web
threads. The There is no application attached to current thread
WicketRuntimeException will occur in such a case. The attached patch
fixes this issue.
Regards,
Seb
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Bug in Wicket Push TimerChannelService when used with background threads
Hi Sebastian, your patch is in: trunk (1.5) 1.4 branch (future 1.4.13 release) and 1.4.12 There was an issue in your patch where the application could be left in the ThreadContext, which was fixed, as well as a simplification in the trigger function. On Wed, 2010-09-29 at 21:39 +0200, Sebastian wrote: Hi, there is a problem in the Push TimerChannelService implementation: Callbacks do not work reliable when they are invoked from non-Web threads. The There is no application attached to current thread WicketRuntimeException will occur in such a case. The attached patch fixes this issue. Regards, Seb - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Bug in Wicket Push TimerChannelService when used with background threads
There was an issue in your patch where the application could be left
in the ThreadContext, which was fixed,
Hi Rodolfo,
I think you are referring to
try {
Application.set(_application);
methods[m].invoke(o, parameters);
} finally {
Application.set(originalApplication);
if (originalApplication != null) Application.set(originalApplication);
}
The problem is if this code is executed in a separate thread the
originalApplication will be null. If you just omit the null check in the
finally clause the setter will throw an IllegalArgumentException. So to
remove the app from the ThreadContext we would have to call
Application.unset() instead:
if (originalApplication == null) Application.unset();
else Application.set(originalApplication);
Regards,
Seb
On 30.09.2010 23:08, Rodolfo Hansen wrote:
Hi Sebastian, your patch is in:
trunk (1.5)
1.4 branch (future 1.4.13 release)
and 1.4.12
There was an issue in your patch where the application could be left in
the ThreadContext, which was fixed,
as well as a simplification in the trigger function.
On Wed, 2010-09-29 at 21:39 +0200, Sebastian wrote:
Hi,
there is a problem in the Push TimerChannelService implementation:
Callbacks do not work reliable when they are invoked from non-Web
threads. The There is no application attached to current thread
WicketRuntimeException will occur in such a case. The attached patch
fixes this issue.
Regards,
Seb
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Bug in Wicket Push TimerChannelService when used with background threads
On Thu, 2010-09-30 at 23:48 +0200, Sebastian wrote:
There was an issue in your patch where the application could be left
in the ThreadContext, which was fixed,
Hi Rodolfo,
I think you are referring to
try {
Application.set(_application);
methods[m].invoke(o, parameters);
} finally {
Application.set(originalApplication);
if (originalApplication != null) Application.set(originalApplication);
}
The problem is if this code is executed in a separate thread the
originalApplication will be null. If you just omit the null check in the
finally clause the setter will throw an IllegalArgumentException. So to
remove the app from the ThreadContext we would have to call
Application.unset() instead:
if (originalApplication == null) Application.unset();
else Application.set(originalApplication);
you are right, although i checked the source for set and didn't see the
throw...
amended in the 1.4 branches
Regards,
Seb
On 30.09.2010 23:08, Rodolfo Hansen wrote:
Hi Sebastian, your patch is in:
trunk (1.5)
1.4 branch (future 1.4.13 release)
and 1.4.12
There was an issue in your patch where the application could be left in
the ThreadContext, which was fixed,
as well as a simplification in the trigger function.
On Wed, 2010-09-29 at 21:39 +0200, Sebastian wrote:
Hi,
there is a problem in the Push TimerChannelService implementation:
Callbacks do not work reliable when they are invoked from non-Web
threads. The There is no application attached to current thread
WicketRuntimeException will occur in such a case. The attached patch
fixes this issue.
Regards,
Seb
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Bug in Wicket Push TimerChannelService when used with background threads
On Wed, Sep 29, 2010 at 2:39 PM, Sebastian nospam...@gmx.net wrote: Hi, there is a problem in the Push TimerChannelService implementation: Callbacks do not work reliable when they are invoked from non-Web threads. The There is no application attached to current thread WicketRuntimeException will occur in such a case. The attached patch fixes this issue. This is a WicketStuff project. Request commit permissions for sf.net and commit the patch. -- Jeremy Thomerson http://www.wickettraining.com
