[
https://issues.jboss.org/browse/SEAMCRON-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602204#comment-12602204
]
Peter Royle commented on SEAMCRON-13:
-------------------------------------
Another portable solution suggested by Sturat Douglas:
(04:37:00 PM) stuartdouglas: and I had an idea for a protable way to implement
it
(04:37:09 PM) PeteRoyle: awesome
(04:37:49 PM) stuartdouglas: the basic idea is use a threadlocal to control
when then interceptor is actually run
(04:38:17 PM) stuartdouglas: and then look up and re-invoke on the bean in a
new thread
(04:38:43 PM) stuartdouglas: as long as the @Async interceptor is first, this
gives pretty much the same result
(04:39:07 PM) stuartdouglas: as long as the bean being invoked on is normal
scoped
(04:40:25 PM) daniel_hinojosa [[email protected]]
entered the room.
(04:40:55 PM) PeteRoyle: I don't follow all the way. So are there multiple
interceptors?
(04:41:48 PM) stuartdouglas: the basic idea is to re-run the whole invocation
in a new thread, but have a thread local set that will stop the @Asyn
interceptor from firing again
(04:42:28 PM) PeteRoyle: ok I'm getting warmer I think
(04:42:51 PM) stuartdouglas: something that did just occur to me is that weld
will probably not work very well in this new thread anyway, unless you set the
TCCL to the correct one
(04:43:07 PM) PeteRoyle: TCCL?
(04:43:16 PM) stuartdouglas: Thread Context Class Loader
(04:43:28 PM) stuartdouglas: weld uses it a lot, even for stuff that should not
need it to be set
(04:43:51 PM) stuartdouglas: so if it is not set you end up with highly
informative 'Singleton is not set' errors
(04:44:30 PM) PeteRoyle: Ahah! I've been getting those sporadically on
redeployment
(04:44:45 PM) PeteRoyle: But to do with scheduling, not asynch
(04:44:49 PM) PeteRoyle: (so far)
(04:45:20 PM) stuartdouglas: those are pretty much always due to the wrong
class loader being set as the TCCL
(04:45:54 PM) stuartdouglas: also the only beans that will be accessible is
@ApplicationScoped and @Dependant
(04:46:10 PM) stuartdouglas: unless you put in some non-portable code to set up
the contexts
(04:46:11 PM) PeteRoyle: Is there a typical cure for that which doesn
(04:46:29 PM) PeteRoyle: ''t require knowledge of how classloading works?
(04:47:34 PM) stuartdouglas: not really, it depends where you get the errors,
it should only be a problem when you start trying to use threads that you have
spawned yourself to interact with weld
(04:48:31 PM) stuartdouglas: for @Async the solution is to set the TCCL to the
same as the original threads TCCL, and set it back in a finally block
(04:49:11 PM) stuartdouglas: and it should really be run as a PriviliedAction,
because a security manager might not let you set it
(04:50:22 PM) marekn [~mnovotny@nat/redhat/x-wgsrrhabedyogdbb] entered the room.
(04:50:39 PM) PeteRoyle: I get what you're saying, but I'm not sure how to do
that stuff
(04:50:54 PM) PeteRoyle: (setting the TCCL and running as PrivAction)
(04:51:57 PM) stuartdouglas:
https://github.com/stuartwdouglas/jboss-as/blob/master/weld/src/main/java/org/jboss/as/weld/WeldContainer.java#L77
(04:52:11 PM) stuartdouglas:
https://github.com/stuartwdouglas/jboss-as/blob/master/weld/src/main/java/org/jboss/as/weld/SecurityActions.java
(04:52:43 PM) stuartdouglas: note that SecurityActions is package private,
otherwise any class can use it to set the TCCL
(04:53:42 PM) stuartdouglas: basically it just wraps
Thread.currentThread().set/getContextClassLoader
(04:54:38 PM) PeteRoyle: Should I copy this code into Cron, (or Solder) to make
it portable?
(04:55:09 PM) stuartdouglas: it needs to be copied each time
(04:55:38 PM) stuartdouglas: otherwise any code can get/set the TCCL
(04:56:02 PM) kevinpollet [[email protected]] entered the room.
(04:56:56 PM) PeteRoyle: OK so do I set the TCCL as the first thing in the new
thread?
(04:56:59 PM) amitev [[email protected]] entered the room.
(04:57:06 PM) stuartdouglas: yes
(04:57:11 PM) PeteRoyle: (frm within the thread, say inside the run() method)?
(04:57:17 PM) stuartdouglas: yes
(04:57:34 PM) PeteRoyle: and unset it from a finally block from the original
thread which screate the new thread
(04:57:52 PM) PeteRoyle: screate=created
(04:58:21 PM) stuartdouglas: yes, although you can just set it to null rather
than saving and restoring the existing TCCL
(04:59:01 PM) stuartdouglas: otherwise if you are using a thread pool the TCCL
can hang around after redeployment, which results in a memory leak
(04:59:47 PM) PeteRoyle: actually it looks like all the examples in
WeldContainer do both those things in the same thread. Can I unset the TCCL at
the end of the run() method (in a finally)?
(04:59:58 PM) maschmid [~maschmid@nat/redhat/x-fjnivohxvbmhnpfw] entered the
room.
(05:00:00 PM) stuartdouglas: yes
(05:00:06 PM) PeteRoyle: ok
(05:00:33 PM) stuartdouglas: oops, sorry, I mis-read your earlier question
(05:00:50 PM) stuartdouglas: you should only manipulate it inside the run method
(05:00:57 PM) PeteRoyle: ok gotchya
(05:01:47 PM) PeteRoyle: So about this thread local. What exactly will it be
storing?
(05:02:16 PM) PeteRoyle: Just any kind of marker?
(05:02:26 PM) PeteRoyle: Boolean
(05:02:30 PM) stuartdouglas: just a boolean
(05:03:11 PM) PeteRoyle: ok so if it's false I set it and start the thread. If
it's true I return
(05:03:29 PM) stuartdouglas: if it is true set it to false and then proceed
(05:03:39 PM) PeteRoyle: ctx.proceed()?
(05:03:43 PM) stuartdouglas: that will allow additional @Asyn invocations for
the @Async thread to run
(05:03:46 PM) stuartdouglas: yes
> Try workaround for WELD-862 using deep copy
> -------------------------------------------
>
> Key: SEAMCRON-13
> URL: https://issues.jboss.org/browse/SEAMCRON-13
> Project: Seam Cron
> Issue Type: Task
> Reporter: Peter Royle
> Assignee: Peter Royle
> Priority: Blocker
> Fix For: 3.0.0.Alpha1
>
>
> As suggested on WELD-862, possible workaround is to deep copy the
> InvocationContext. Marius Bogoevici has suggested that this can be done using
> stuff from JBoss Interceptor so I should try that.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
seam-issues mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/seam-issues
