ThreadPool with Seaside - how?
Locked
 
|
Hi,
[1] Paul and Ramon suggested to use the ThreadPool [2] to me. I want to replace my forked code for generating reports with it. When trying to use it within my seaside application, I have a problem. I reduced the Problem to this: -> this works, a simple in inspector pops up html mdlButton onClick: (html jQuery ajax script: [ :script | [ #simple inspect ] queueWork ]); with: '0'. -> this does not work. The generation of my reports needs the sessions objects. Also, calling another method of the session does not work. html mdlButton onClick: (html jQuery ajax script: [ :script | [ self session inspect ] queueWorkAndExpireIn: 25 seconds session: self session ]); with: '1' Did I miss something? Paul, thank you for updating [3] a few days ago _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: ThreadPool with Seaside - how?
|
On Wed, Jul 26, 2017 at 12:09 PM, Sabine Manaa <[hidden email]> wrote:
> Hi, > > [1] Paul and Ramon suggested to use the ThreadPool [2] to me. > I want to replace my forked code for generating reports with it. > > When trying to use it within my seaside application, I have a problem. > I reduced the Problem to this: > > -> this works, a simple in inspector pops up > html mdlButton > onClick: (html jQuery ajax script: [ :script | [ #simple inspect ] queueWork > ]); > with: '0'. > > -> this does not work. > > The generation of my reports needs the sessions objects. Most Seaside objects are not thread safe as they are meant to be used only within the request-response thread. WASession is one of them that's why it's normally behind a WAMutualExclusionFilter. In theory any forked access to a session should go through that mutex. In addition forked access to a session is not recorded in the session cache so it may expire at any time. If you need session data in a forked process the recommendation would be to factor that data out into an immutable object and store with object in the session and pass this object to the forked process. Cheers Philippe _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Sabine Manaa
Sabine, I guess you should simply avoid accessing the session in the forked process for now. Not sure I fully understand what Philippe tried to explain, but I can confirm I never saw any problems when using teh current Seaside component for objects to be used in a background process... Joachim Sabine Manaa <[hidden email]> hat am 26. Juli 2017 um 12:09 geschrieben: _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: ThreadPool with Seaside - how?
|
|
In reply to this post by Sabine Manaa
On 07/26/2017 03:09 AM, Sabine Manaa wrote:
> -> this does not work. > The generation of my reports needs the sessions objects. > Also, calling another method of the session does not work. > > html mdlButton > onClick: > (html jQuery ajax > script: [ :script | [ self session inspect ] queueWorkAndExpireIn: 25 > seconds session: self session ]); > with: '1' I concur with Phillipe about being very careful using the session on a background thread as it's not meant to be thread safe and could potentially lead to concurrency bugs if you're not very careful; however, it's easy to do if you want to by simply using a closure. | session | "compute the current session and put into local var" session := self session. html mdlButton onClick: (html jQuery ajax script: [ :script | [ session inspect ] queueWork ]); with: '1' In other words don't access "self session" because that computes the session for the current thread which doesn't work on a background thread. You can pass data to the background thread by having that data within the lexical scope of the block you launch as demonstrated above. Calling fork would work just as well as queueWork, all the ThreadPool does is ensure there's a limited amount of background jobs running at any one time so you don't fork bomb yourself with too many threads and lock up your image. -- Ramon Leon _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: ThreadPool with Seaside - how?
|
|
when the report generation is invoked, the session is alive and I have a long session time. So, it is unlikely that the session will expire. If it does expire nevertheless, the user will not notice it (because he is logged out) and I will stop report generation if the session is not available. Ramon, I tested your suggestion and with the session passed into the fork with the local variable, it works. I was mislead by the method >>queueWorkAndExpireIn:session This works | theSession | theSession := self session. [ theSession dummyMethod ] queueWorkAndExpireIn: 25 seconds session: self session ] and this works too: | theSession | theSession := self session. [ theSession dummyMethod2 ] queueWork ]); ==>I don't understand for what the session parameter in >>queueWorkAndExpireIn:session But I can also use queueWork. This/the smalltalk side seems to work all fine now with the ThreadPool. Thank you for this! I also use an external program to * merge multiple PDFs into one * and to generate pngs from pdfs for the preview The remaining problem is, that I have many pdfbox calls which create a high load on the machine... :-) |
|
|
Sounds like you need a pdfbox box ;-)
_______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: ThreadPool with Seaside - how?
|
|
I switched to www.imagemagick.org and away from pdfbox.
The problem is solved, the howling of my mac disappeared :-) 2017-07-27 9:59 GMT+02:00 jtuchel [via Smalltalk] <[hidden email]>: > > Sounds like you need a pdfbox box ;-) > > > > > Am 27.07.2017 um 09:42 schrieb Sabine Manaa <[hidden email]>: > > when the report generation is invoked, the session is alive and I have a long session time. > So, it is unlikely that the session will expire. > If it does expire nevertheless, the user will not notice it (because he is logged out) and I will stop report generation if the session is not available. > > Ramon, I tested your suggestion and with the session passed into the fork with the local variable, it works. > > I was mislead by the method >>queueWorkAndExpireIn:session: > > This works > | theSession | > theSession := self session. > [ theSession dummyMethod ] queueWorkAndExpireIn: 25 seconds session: self session ] > > and this works too: > | theSession | > theSession := self session. > [ theSession dummyMethod2 ] queueWork ]); > > ==>I don't understand for what the session parameter in >>queueWorkAndExpireIn:session: is used. > > But I can also use queueWork. > > This/the smalltalk side seems to work all fine now with the ThreadPool. Thank you for this! > > I also use an external program to > * merge multiple PDFs into one > * and to generate pngs from pdfs for the preview > (https://pdfbox.apache.org). > > The remaining problem is, that I have many pdfbox calls which create a high load on the machine... > :-) > > > > > > > > > > > > ________________________________ > View this message in context: Re: ThreadPool with Seaside - how? > Sent from the Seaside General mailing list archive at Nabble.com. > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > > ________________________________ > If you reply to this email, your message will be added to the discussion below: > http://forum.world.st/ThreadPool-with-Seaside-how-tp4956812p4957128.html > To start a new topic under Seaside General, email [hidden email] > To unsubscribe from Seaside, click here. > NAML |
Re: ThreadPool with Seaside - how?
|
|
In reply to this post by Sabine Manaa
> I was mislead by the method >>queueWorkAndExpireIn:session:
That was built for Seaside 2.8 and passing the session in there ensures that that "self session" used anywhere in a background task still works. I had you pass in the param via the lexical context because I know you're using a newer version of Seaside and queueWorkAndExpireIn:session: may no longer work however perhaps that's been fixed in the version of the thread pool you're using. So you only need use queueWork or fork like I showed. I still use Seaside 2.8 -- Ramon Leon _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: ThreadPool with Seaside - how?
|
|
Ramon and Paul, did you see my question about ThreadPool and OS windows? Do you have an idea how to solve this? Regards Sabine 2017-07-28 17:00 GMT+02:00 Ramon Leon-5 [via Smalltalk] <[hidden email]>: > I was mislead by the method >>queueWorkAndExpireIn: |
Re: ThreadPool with Seaside - how?
|
|
On 08/06/2017 11:59 PM, Sabine Manaa wrote:
> Ramon and Paul, > > did you see my question about ThreadPool and OS windows? > > http://forum.world.st/Problem-with-ThreadPool-on-os-windows-no-execution-td4958454.html > > Do you have an idea how to solve this? Sorry I'm a Linux guy, can't help you with Windows. I'd take a look at the class side of the thread pool, follow the startUp logic, it's very simple, and walk through to see what might be going wrong in Windows. -- Ramon Leon _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: ThreadPool with Seaside - how?
|
|
Hi Ramon,
thank you for the reaction. I will try it. Regards Sabine 2017-08-07 17:03 GMT+02:00 Ramon Leon-5 [via Smalltalk] <[hidden email]>: On 08/06/2017 11:59 PM, Sabine Manaa wrote: |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |