Re: Thread safety for components
Brill Pappin wrote: Right... I think I'd just invert that, so that the page asked for the stateful data when needed. Yes, that's the only way. The page can easily store the state (and you might rather it did) but it has to be pulled in, not pushed. The general rule is: no external thread can hold a reference to a Wicket model or view, because the model or view is apt, at any moment, to be serialized out of memory. (Restrictions like this must be obvious to a Web developer, but they're counter-intuitive to an old Swing hand.) Similar restrictions apply to the Session (as James was cautioning), because it too is serialized. Furthermore, the Session is not synchronized by the request thread. So code your Session subclass with thread safety in mind. Also code the Application with thread safety in mind. The Application is never serialized, however, so external threads can hold a live reference to it. Finally, clustering affects the environment (including the Application) that pages and components can expect when they pull state. (But maybe this is obvious.) -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thread safety for components
yes in a clustered environment you have multiply instances of the Application because there are more instances of the WicketServlet. And Application/Servlet context stuff are not replicated johan On Mon, May 19, 2008 at 3:41 AM, Michael Allan [EMAIL PROTECTED] wrote: Brill Pappin wrote: ... So non-Wicket threads cannot generally access pages, components, models, and so forth - not safely. True? I was trying to think of a use-case for that problem... Do you have a specific use-case or is that just a potential issue you can think of? I'm thinking generally of state changes that occur in separate processes, changes that need to be presented in Web views. Specifically, I have a Web page that shows recent user activity, in a list view, where each element is a user activity event. Not all of my users are Web users, so the underlying list model is receiving events from other processes (mailer daemon, and so forth). Johan Compagner wrote: Accessing pages in other threads then the request thread is very bad idea. Because http session object shouldnt be touched between requests, you have no idea what the container does with your page/session. Store it on disc, replicate it to other nodes. Of course, now I understand... I was forgetting that instances of these things - pages, components and models - are apt to be serialized out of memory. Non-Wicket threads can't even hold a reference to them. So there's no point in exposing the page lock for other threads (as I suggested). If you want to do stuff in background threads then let page/request threads poll them if they are finished. Then the underlying list model (in my example, above) does not belong in the page; instead it belongs in the Application instance. There it can safely register with other threads, and receive events from them, because the app will never be serialized out of memory. And the list view (in the page) can hook up with the model (in the app), at request time, with appropriate synchronization - polling it, as you say. My only other question, then, is the app life cycle. (This article doesn't really answer my Q: http://cwiki.apache.org/WICKET/lifecycle-of-a-wicket-application.html In a clustered environment, are there multiple instances of the app? Might the page (the one with the list view, for example) find itself connecting to a different instance of the app, a different instance of the list model, from request to request? In a non-clustered environment, can I safely assume a single instance of the app, at any given time? -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thread safety for components
Johan Compagner wrote: yes in a clustered environment you have multiply instances of the Application because there are more instances of the WicketServlet. And Application/Servlet context stuff are not replicated Thanks Johan, I've documented Wicket's thread safety (as I understand it) using annotations in my code. Here's the relevant page from my API: http://zelea.com/project/votorola/_/javadoc/votorola/a/web/VPage.html Thanks for the help, gents, -- Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Thread safety for components
Right... I think I'd just invert that, so that the page asked for the stateful data when needed. - Brill Pappin -Original Message- From: Michael Allan [mailto:[EMAIL PROTECTED] Sent: Sunday, May 18, 2008 9:41 PM To: users@wicket.apache.org Subject: Re: Thread safety for components Brill Pappin wrote: ... So non-Wicket threads cannot generally access pages, components, models, and so forth - not safely. True? I was trying to think of a use-case for that problem... Do you have a specific use-case or is that just a potential issue you can think of? I'm thinking generally of state changes that occur in separate processes, changes that need to be presented in Web views. Specifically, I have a Web page that shows recent user activity, in a list view, where each element is a user activity event. Not all of my users are Web users, so the underlying list model is receiving events from other processes (mailer daemon, and so forth). Johan Compagner wrote: Accessing pages in other threads then the request thread is very bad idea. Because http session object shouldnt be touched between requests, you have no idea what the container does with your page/session. Store it on disc, replicate it to other nodes. Of course, now I understand... I was forgetting that instances of these things - pages, components and models - are apt to be serialized out of memory. Non-Wicket threads can't even hold a reference to them. So there's no point in exposing the page lock for other threads (as I suggested). If you want to do stuff in background threads then let page/request threads poll them if they are finished. Then the underlying list model (in my example, above) does not belong in the page; instead it belongs in the Application instance. There it can safely register with other threads, and receive events from them, because the app will never be serialized out of memory. And the list view (in the page) can hook up with the model (in the app), at request time, with appropriate synchronization - polling it, as you say. My only other question, then, is the app life cycle. (This article doesn't really answer my Q: http://cwiki.apache.org/WICKET/lifecycle-of-a-wicket-application.html In a clustered environment, are there multiple instances of the app? Might the page (the one with the list view, for example) find itself connecting to a different instance of the app, a different instance of the list model, from request to request? In a non-clustered environment, can I safely assume a single instance of the app, at any given time? -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thread safety for components
Accessing pages in other threads then the request thread is very bad idea. Because http session object shouldnt be touched between requests, you have no idea what the container does with your page/session. Store it on disc, replicate it to other nodes. If you want to do stuff in background threads then let page/request threads poll them if they are finished. On 5/17/08, Michael Allan [EMAIL PROTECTED] wrote: Jonathan Locke wrote: ... the overall design is single-threaded, meaning you should not need to provide synchronization ... Is there some specific problem you have run into? No, nothing specific yet - just a general foreboding of future problems - having been bitten, before. Johan Compagner wrote: Pages are threadsafe and that is not done by a big sync block, but by placing a barrier. See Session.getPage() there there is code that makes sure that 1 thread at a time gets a page from the session the rest just has to wait Thanks Johan, that's the info I needed. It looks like Session.getPage() is implementing an independent locking mechanism, similar to java.util.concurrent.locks.Lock (JDK 1.5). One possible problem - not affecting me yet, but just to be clear - no access to the page lock (no official API) is provided for non-Wicket threads. So non-Wicket threads cannot generally access pages, components, models, and so forth - not safely. True? When the core framework moves to 1.5, maybe the page locking can be improved. Maybe each Page could have its own standard Lock, and could publish it as Page.lock(). Thread-safety of pages, components, models, and so forth, could then be documented as must hold Page.lock(). Internal code could check compliance, with: assert page.lock().isHeldByCurrentThread(); Just a suggestion - I'm happy with Wicket as it is, -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thread safety for components
It may even re-use the actual session object instance for another person's session (by filling it with their stuff). On Sun, May 18, 2008 at 9:12 AM, Johan Compagner [EMAIL PROTECTED] wrote: Accessing pages in other threads then the request thread is very bad idea. Because http session object shouldnt be touched between requests, you have no idea what the container does with your page/session. Store it on disc, replicate it to other nodes. If you want to do stuff in background threads then let page/request threads poll them if they are finished. On 5/17/08, Michael Allan [EMAIL PROTECTED] wrote: Jonathan Locke wrote: ... the overall design is single-threaded, meaning you should not need to provide synchronization ... Is there some specific problem you have run into? No, nothing specific yet - just a general foreboding of future problems - having been bitten, before. Johan Compagner wrote: Pages are threadsafe and that is not done by a big sync block, but by placing a barrier. See Session.getPage() there there is code that makes sure that 1 thread at a time gets a page from the session the rest just has to wait Thanks Johan, that's the info I needed. It looks like Session.getPage() is implementing an independent locking mechanism, similar to java.util.concurrent.locks.Lock (JDK 1.5). One possible problem - not affecting me yet, but just to be clear - no access to the page lock (no official API) is provided for non-Wicket threads. So non-Wicket threads cannot generally access pages, components, models, and so forth - not safely. True? When the core framework moves to 1.5, maybe the page locking can be improved. Maybe each Page could have its own standard Lock, and could publish it as Page.lock(). Thread-safety of pages, components, models, and so forth, could then be documented as must hold Page.lock(). Internal code could check compliance, with: assert page.lock().isHeldByCurrentThread(); Just a suggestion - I'm happy with Wicket as it is, -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thread safety for components
Brill Pappin wrote: ... So non-Wicket threads cannot generally access pages, components, models, and so forth - not safely. True? I was trying to think of a use-case for that problem... Do you have a specific use-case or is that just a potential issue you can think of? I'm thinking generally of state changes that occur in separate processes, changes that need to be presented in Web views. Specifically, I have a Web page that shows recent user activity, in a list view, where each element is a user activity event. Not all of my users are Web users, so the underlying list model is receiving events from other processes (mailer daemon, and so forth). Johan Compagner wrote: Accessing pages in other threads then the request thread is very bad idea. Because http session object shouldnt be touched between requests, you have no idea what the container does with your page/session. Store it on disc, replicate it to other nodes. Of course, now I understand... I was forgetting that instances of these things - pages, components and models - are apt to be serialized out of memory. Non-Wicket threads can't even hold a reference to them. So there's no point in exposing the page lock for other threads (as I suggested). If you want to do stuff in background threads then let page/request threads poll them if they are finished. Then the underlying list model (in my example, above) does not belong in the page; instead it belongs in the Application instance. There it can safely register with other threads, and receive events from them, because the app will never be serialized out of memory. And the list view (in the page) can hook up with the model (in the app), at request time, with appropriate synchronization - polling it, as you say. My only other question, then, is the app life cycle. (This article doesn't really answer my Q: http://cwiki.apache.org/WICKET/lifecycle-of-a-wicket-application.html In a clustered environment, are there multiple instances of the app? Might the page (the one with the list view, for example) find itself connecting to a different instance of the app, a different instance of the list model, from request to request? In a non-clustered environment, can I safely assume a single instance of the app, at any given time? -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thread safety for components
Brill Pappin wrote: I didn't know people were even following it :) Small town, :) I'm working on something similar. I can tell you now that I only *wish* we had used something like Wicket for LobbyThem... Ruby on Rails was the biggest mistake we made as I can attest to 8 months after the event. In fact I think we'd be a lot further along now if we had used Wicket (or even plain old PHP)! It's impossible to get it right, on the first pass. If it's anything new, it takes multiple iterations - how many, anybody's guess. Wicket is saving me time. It's plain Java and HTML - that was the initial attraction. I can work it under the hood, if necessary. But the real time saver, it turns out, has been this list. The code's well supported by its developers. They meet the users half way. (Now, if I can do that in my own projects, that might be the key.) -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thread safety for components
Brill Pappin wrote: Does that mean that under heavy load, hitting the index page for instance, I can expect clients to block as each request is processed? Let me guess... The answer is no? Each session will have its own instance of the index page. Threads of other sessions (other users) will never try to access it. PS - What are you indexing, Brill? Is it a political app, like Lobby Them? (Just being nosey... :) -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thread safety for components
Jonathan Locke wrote: ... the overall design is single-threaded, meaning you should not need to provide synchronization ... Is there some specific problem you have run into? No, nothing specific yet - just a general foreboding of future problems - having been bitten, before. Johan Compagner wrote: Pages are threadsafe and that is not done by a big sync block, but by placing a barrier. See Session.getPage() there there is code that makes sure that 1 thread at a time gets a page from the session the rest just has to wait Thanks Johan, that's the info I needed. It looks like Session.getPage() is implementing an independent locking mechanism, similar to java.util.concurrent.locks.Lock (JDK 1.5). One possible problem - not affecting me yet, but just to be clear - no access to the page lock (no official API) is provided for non-Wicket threads. So non-Wicket threads cannot generally access pages, components, models, and so forth - not safely. True? When the core framework moves to 1.5, maybe the page locking can be improved. Maybe each Page could have its own standard Lock, and could publish it as Page.lock(). Thread-safety of pages, components, models, and so forth, could then be documented as must hold Page.lock(). Internal code could check compliance, with: assert page.lock().isHeldByCurrentThread(); Just a suggestion - I'm happy with Wicket as it is, -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Thread safety for components
You don't need to convince me :) It even saves time between the designers and the programmers... My only complaint so far is that it hides a bit to much of the basic http stack which makes a bit harder to understand (for an old fart like me anyway) but I'm not experienced enough with it yet to say that's a bad thing :) I'm looking forward to really getting into it! - Brill -Original Message- From: Jonathan Locke [mailto:[EMAIL PROTECTED] Sent: Saturday, May 17, 2008 1:56 AM To: users@wicket.apache.org Subject: RE: Thread safety for components I wouldn't spend too much time worrying about the possibility of a mistake that big at this point! There are 20 programmers on this project at this point and almost all of them are architects with many years of experience. Wicket is being used by many thousands of users on hundreds if not thousands of projects. We used it at a venture funded startup called thoof to create a fully scalable website with benchmarks you can read about here: http://blog.thoof.com/index.php/geekery/build-to-scale-our-web-architecture/ I know of several Fortune 500 companies using Wicket and even one website with millions of users that is converting to Wicket to save on maintenance costs. While Wicket is not stateless, it is quite efficient for a stateful framework with an excellent programming model. My expectation is that stateful frameworks with good programming models will win in the end. Even today, Wicket applications spend most of their time waiting for databases and services. As hardware improves, this equation will only favor Wicket more and more. Brill Pappin wrote: Ahh... I was getting worried that it synchronous per page-resource (as opposed to per client), the last person could be waiting for a while! So essentially it's single threaded per client (or session) which is pretty much par for the course, and not a problem that I can see :) - Brill Pappin -Original Message- From: Eelco Hillenius [mailto:[EMAIL PROTECTED] Sent: Saturday, May 17, 2008 1:03 AM To: users@wicket.apache.org Subject: Re: Thread safety for components On Fri, May 16, 2008 at 7:50 PM, Brill Pappin [EMAIL PROTECTED] wrote: Does that mean that under heavy load, hitting the index page for instance, I can expect clients to block as each request is processed? Yes, requests to pages/ components that belong to the same pagemap in a session are handled synchronously. Images and other resources like javascript and css files are handled asynchronously. Different clients never block each other. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Thread-safety-for-components-tp17265324p17288470.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Thread safety for components
I didn't know people were even following it :) I can tell you now that I only *wish* we had used something like Wicket for LobbyThem... Ruby on Rails was the biggest mistake we made as I can attest to 8 months after the event. In fact I think we'd be a lot further along now if we had used Wicket (or even plain old PHP)! - Brill -Original Message- From: Michael Allan [mailto:[EMAIL PROTECTED] Sent: Friday, May 16, 2008 11:33 PM To: users@wicket.apache.org Subject: Re: Thread safety for components Brill Pappin wrote: Does that mean that under heavy load, hitting the index page for instance, I can expect clients to block as each request is processed? Let me guess... The answer is no? Each session will have its own instance of the index page. Threads of other sessions (other users) will never try to access it. PS - What are you indexing, Brill? Is it a political app, like Lobby Them? (Just being nosey... :) -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Thread safety for components
I was trying to think of a use-case for that problem... Do you have a specific use-case or is that just a potential issue you can think of? -Original Message- From: Michael Allan [mailto:[EMAIL PROTECTED] Sent: Friday, May 16, 2008 9:00 PM To: users@wicket.apache.org Subject: Re: Thread safety for components [...] One possible problem - not affecting me yet, but just to be clear - no access to the page lock (no official API) is provided for non-Wicket threads. So non-Wicket threads cannot generally access pages, components, models, and so forth - not safely. True? When the core framework moves to 1.5, maybe the page locking can be improved. Maybe each Page could have its own standard Lock, and could publish it as Page.lock(). Thread-safety of pages, components, models, and so forth, could then be documented as must hold Page.lock(). Internal code could check compliance, with: - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thread safety for components
wicket synchronizes on the session. So only one request is processed at a time, (except for resources like images etc) So even ajax requests are synchronized. There might be some more details i am not aware of but this is in a nutshell our synchronization. Maurice On Fri, May 16, 2008 at 4:33 AM, Jonathan Locke [EMAIL PROTECTED] wrote: I'm not sure precisely what the current synchronization implementation is and there may be some edge cases that are not perfect, but the overall design is single-threaded, meaning you should not need to provide synchronization. Some requests, like image resources would potentially be handled in parallel, but anything that calls user code ought to be synchronized by Wicket so you don't have to think about it. I suppose there might be complications with asynchronous Ajax events, but I would expect these cases are already handled. Is there some specific problem you have run into? Michael Allan wrote: I'm trying to get a handle on thread-safety for components. I'm new to Wicket. My best information, so far, comes from the previous discussion Wicket Session and threading: http://mail-archives.apache.org/mod_mbox/wicket-users/200801.mbox/thread Eelco Hillenius, in response to Sebastiaan van Erk, wrote: Yes. We try our best to make pages/ components as thread safe as possible... Is there anywhere a small piece on how to deal with threading within Wicket (i.e., what is/is not synchronized in a request/response roundtrip?). I did some quick searching in the mailing list archives and google, but could not find anything related to version 1.3. Pages are synced on pagemaps, which basically relates to browser windows. RequestCycles are separate instances which are not reused, so no sync needed there. Sessions are not synced so you need to sync manually. Though in practice this wouldn't give much trouble to start with. Applications are shared an not synced. During form processing, however, my own pages are *not* synced on their pagemaps (at least not on their monitor locks). I placed this is in my code: assert Thread.holdsLock( /*page*/this.getPageMap() ); This asserts false during the setting of TextField models (Wicket 1.3.2), and false during the call to Form.onSubmit(). How can I ensure thread safety? In other words, if I am coding a model, what can I assume about my client threads? Are they synchronized somewhere, or must I code defensively within the model? Or, from the client side, if I have a thread that accesses a page's components, how can it avoid tangling with the response/request threads? -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Thread-safety-for-components-tp17265324p17266550.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thread safety for components
It is not sync around session, for one thing the wicket Sessio object is not thread safe.. Same for shared resources those 2 can be hit by multiply rerquest at once. Pages are threadsafe and that is not done by a big sync block, but by placing a barrier. See Session.getPage() there there is code that makes sure that 1 thread at a time gets a page from the session the rest just has to wait On 5/16/08, Maurice Marrink [EMAIL PROTECTED] wrote: wicket synchronizes on the session. So only one request is processed at a time, (except for resources like images etc) So even ajax requests are synchronized. There might be some more details i am not aware of but this is in a nutshell our synchronization. Maurice On Fri, May 16, 2008 at 4:33 AM, Jonathan Locke [EMAIL PROTECTED] wrote: I'm not sure precisely what the current synchronization implementation is and there may be some edge cases that are not perfect, but the overall design is single-threaded, meaning you should not need to provide synchronization. Some requests, like image resources would potentially be handled in parallel, but anything that calls user code ought to be synchronized by Wicket so you don't have to think about it. I suppose there might be complications with asynchronous Ajax events, but I would expect these cases are already handled. Is there some specific problem you have run into? Michael Allan wrote: I'm trying to get a handle on thread-safety for components. I'm new to Wicket. My best information, so far, comes from the previous discussion Wicket Session and threading: http://mail-archives.apache.org/mod_mbox/wicket-users/200801.mbox/thread Eelco Hillenius, in response to Sebastiaan van Erk, wrote: Yes. We try our best to make pages/ components as thread safe as possible... Is there anywhere a small piece on how to deal with threading within Wicket (i.e., what is/is not synchronized in a request/response roundtrip?). I did some quick searching in the mailing list archives and google, but could not find anything related to version 1.3. Pages are synced on pagemaps, which basically relates to browser windows. RequestCycles are separate instances which are not reused, so no sync needed there. Sessions are not synced so you need to sync manually. Though in practice this wouldn't give much trouble to start with. Applications are shared an not synced. During form processing, however, my own pages are *not* synced on their pagemaps (at least not on their monitor locks). I placed this is in my code: assert Thread.holdsLock( /*page*/this.getPageMap() ); This asserts false during the setting of TextField models (Wicket 1.3.2), and false during the call to Form.onSubmit(). How can I ensure thread safety? In other words, if I am coding a model, what can I assume about my client threads? Are they synchronized somewhere, or must I code defensively within the model? Or, from the client side, if I have a thread that accesses a page's components, how can it avoid tangling with the response/request threads? -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Thread-safety-for-components-tp17265324p17266550.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thread safety for components
Like i said: details i am blissfully unaware of :) Thanks for clearing that up Johan. Maurice On Fri, May 16, 2008 at 8:53 AM, Johan Compagner [EMAIL PROTECTED] wrote: It is not sync around session, for one thing the wicket Sessio object is not thread safe.. Same for shared resources those 2 can be hit by multiply rerquest at once. Pages are threadsafe and that is not done by a big sync block, but by placing a barrier. See Session.getPage() there there is code that makes sure that 1 thread at a time gets a page from the session the rest just has to wait On 5/16/08, Maurice Marrink [EMAIL PROTECTED] wrote: wicket synchronizes on the session. So only one request is processed at a time, (except for resources like images etc) So even ajax requests are synchronized. There might be some more details i am not aware of but this is in a nutshell our synchronization. Maurice On Fri, May 16, 2008 at 4:33 AM, Jonathan Locke [EMAIL PROTECTED] wrote: I'm not sure precisely what the current synchronization implementation is and there may be some edge cases that are not perfect, but the overall design is single-threaded, meaning you should not need to provide synchronization. Some requests, like image resources would potentially be handled in parallel, but anything that calls user code ought to be synchronized by Wicket so you don't have to think about it. I suppose there might be complications with asynchronous Ajax events, but I would expect these cases are already handled. Is there some specific problem you have run into? Michael Allan wrote: I'm trying to get a handle on thread-safety for components. I'm new to Wicket. My best information, so far, comes from the previous discussion Wicket Session and threading: http://mail-archives.apache.org/mod_mbox/wicket-users/200801.mbox/thread Eelco Hillenius, in response to Sebastiaan van Erk, wrote: Yes. We try our best to make pages/ components as thread safe as possible... Is there anywhere a small piece on how to deal with threading within Wicket (i.e., what is/is not synchronized in a request/response roundtrip?). I did some quick searching in the mailing list archives and google, but could not find anything related to version 1.3. Pages are synced on pagemaps, which basically relates to browser windows. RequestCycles are separate instances which are not reused, so no sync needed there. Sessions are not synced so you need to sync manually. Though in practice this wouldn't give much trouble to start with. Applications are shared an not synced. During form processing, however, my own pages are *not* synced on their pagemaps (at least not on their monitor locks). I placed this is in my code: assert Thread.holdsLock( /*page*/this.getPageMap() ); This asserts false during the setting of TextField models (Wicket 1.3.2), and false during the call to Form.onSubmit(). How can I ensure thread safety? In other words, if I am coding a model, what can I assume about my client threads? Are they synchronized somewhere, or must I code defensively within the model? Or, from the client side, if I have a thread that accesses a page's components, how can it avoid tangling with the response/request threads? -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Thread-safety-for-components-tp17265324p17266550.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Thread safety for components
Does that mean that under heavy load, hitting the index page for instance, I can expect clients to block as each request is processed? Have anyone tested this on a site with heavy traffic? - Brill -Original Message- From: Johan Compagner [mailto:[EMAIL PROTECTED] Sent: Friday, May 16, 2008 2:53 AM To: users@wicket.apache.org Subject: Re: Thread safety for components It is not sync around session, for one thing the wicket Sessio object is not thread safe.. Same for shared resources those 2 can be hit by multiply rerquest at once. Pages are threadsafe and that is not done by a big sync block, but by placing a barrier. See Session.getPage() there there is code that makes sure that 1 thread at a time gets a page from the session the rest just has to wait On 5/16/08, Maurice Marrink [EMAIL PROTECTED] wrote: wicket synchronizes on the session. So only one request is processed at a time, (except for resources like images etc) So even ajax requests are synchronized. There might be some more details i am not aware of but this is in a nutshell our synchronization. Maurice On Fri, May 16, 2008 at 4:33 AM, Jonathan Locke [EMAIL PROTECTED] wrote: I'm not sure precisely what the current synchronization implementation is and there may be some edge cases that are not perfect, but the overall design is single-threaded, meaning you should not need to provide synchronization. Some requests, like image resources would potentially be handled in parallel, but anything that calls user code ought to be synchronized by Wicket so you don't have to think about it. I suppose there might be complications with asynchronous Ajax events, but I would expect these cases are already handled. Is there some specific problem you have run into? Michael Allan wrote: I'm trying to get a handle on thread-safety for components. I'm new to Wicket. My best information, so far, comes from the previous discussion Wicket Session and threading: http://mail-archives.apache.org/mod_mbox/wicket-users/200801.mbox/th read Eelco Hillenius, in response to Sebastiaan van Erk, wrote: Yes. We try our best to make pages/ components as thread safe as possible... Is there anywhere a small piece on how to deal with threading within Wicket (i.e., what is/is not synchronized in a request/response roundtrip?). I did some quick searching in the mailing list archives and google, but could not find anything related to version 1.3. Pages are synced on pagemaps, which basically relates to browser windows. RequestCycles are separate instances which are not reused, so no sync needed there. Sessions are not synced so you need to sync manually. Though in practice this wouldn't give much trouble to start with. Applications are shared an not synced. During form processing, however, my own pages are *not* synced on their pagemaps (at least not on their monitor locks). I placed this is in my code: assert Thread.holdsLock( /*page*/this.getPageMap() ); This asserts false during the setting of TextField models (Wicket 1.3.2), and false during the call to Form.onSubmit(). How can I ensure thread safety? In other words, if I am coding a model, what can I assume about my client threads? Are they synchronized somewhere, or must I code defensively within the model? Or, from the client side, if I have a thread that accesses a page's components, how can it avoid tangling with the response/request threads? -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Thread-safety-for-components-tp17265324p1726655 0.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thread safety for components
On Fri, May 16, 2008 at 7:50 PM, Brill Pappin [EMAIL PROTECTED] wrote: Does that mean that under heavy load, hitting the index page for instance, I can expect clients to block as each request is processed? Yes, requests to pages/ components that belong to the same pagemap in a session are handled synchronously. Images and other resources like javascript and css files are handled asynchronously. Different clients never block each other. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Thread safety for components
Ahh... I was getting worried that it synchronous per page-resource (as opposed to per client), the last person could be waiting for a while! So essentially it's single threaded per client (or session) which is pretty much par for the course, and not a problem that I can see :) - Brill Pappin -Original Message- From: Eelco Hillenius [mailto:[EMAIL PROTECTED] Sent: Saturday, May 17, 2008 1:03 AM To: users@wicket.apache.org Subject: Re: Thread safety for components On Fri, May 16, 2008 at 7:50 PM, Brill Pappin [EMAIL PROTECTED] wrote: Does that mean that under heavy load, hitting the index page for instance, I can expect clients to block as each request is processed? Yes, requests to pages/ components that belong to the same pagemap in a session are handled synchronously. Images and other resources like javascript and css files are handled asynchronously. Different clients never block each other. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Thread safety for components
I wouldn't spend too much time worrying about the possibility of a mistake that big at this point! There are 20 programmers on this project at this point and almost all of them are architects with many years of experience. Wicket is being used by many thousands of users on hundreds if not thousands of projects. We used it at a venture funded startup called thoof to create a fully scalable website with benchmarks you can read about here: http://blog.thoof.com/index.php/geekery/build-to-scale-our-web-architecture/ I know of several Fortune 500 companies using Wicket and even one website with millions of users that is converting to Wicket to save on maintenance costs. While Wicket is not stateless, it is quite efficient for a stateful framework with an excellent programming model. My expectation is that stateful frameworks with good programming models will win in the end. Even today, Wicket applications spend most of their time waiting for databases and services. As hardware improves, this equation will only favor Wicket more and more. Brill Pappin wrote: Ahh... I was getting worried that it synchronous per page-resource (as opposed to per client), the last person could be waiting for a while! So essentially it's single threaded per client (or session) which is pretty much par for the course, and not a problem that I can see :) - Brill Pappin -Original Message- From: Eelco Hillenius [mailto:[EMAIL PROTECTED] Sent: Saturday, May 17, 2008 1:03 AM To: users@wicket.apache.org Subject: Re: Thread safety for components On Fri, May 16, 2008 at 7:50 PM, Brill Pappin [EMAIL PROTECTED] wrote: Does that mean that under heavy load, hitting the index page for instance, I can expect clients to block as each request is processed? Yes, requests to pages/ components that belong to the same pagemap in a session are handled synchronously. Images and other resources like javascript and css files are handled asynchronously. Different clients never block each other. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Thread-safety-for-components-tp17265324p17288470.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Thread safety for components
I'm trying to get a handle on thread-safety for components. I'm new to Wicket. My best information, so far, comes from the previous discussion Wicket Session and threading: http://mail-archives.apache.org/mod_mbox/wicket-users/200801.mbox/thread Eelco Hillenius, in response to Sebastiaan van Erk, wrote: Yes. We try our best to make pages/ components as thread safe as possible... Is there anywhere a small piece on how to deal with threading within Wicket (i.e., what is/is not synchronized in a request/response roundtrip?). I did some quick searching in the mailing list archives and google, but could not find anything related to version 1.3. Pages are synced on pagemaps, which basically relates to browser windows. RequestCycles are separate instances which are not reused, so no sync needed there. Sessions are not synced so you need to sync manually. Though in practice this wouldn't give much trouble to start with. Applications are shared an not synced. During form processing, however, my own pages are *not* synced on their pagemaps (at least not on their monitor locks). I placed this is in my code: assert Thread.holdsLock( /*page*/this.getPageMap() ); This asserts false during the setting of TextField models (Wicket 1.3.2), and false during the call to Form.onSubmit(). How can I ensure thread safety? In other words, if I am coding a model, what can I assume about my client threads? Are they synchronized somewhere, or must I code defensively within the model? Or, from the client side, if I have a thread that accesses a page's components, how can it avoid tangling with the response/request threads? -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Thread safety for components
I'm not sure precisely what the current synchronization implementation is and there may be some edge cases that are not perfect, but the overall design is single-threaded, meaning you should not need to provide synchronization. Some requests, like image resources would potentially be handled in parallel, but anything that calls user code ought to be synchronized by Wicket so you don't have to think about it. I suppose there might be complications with asynchronous Ajax events, but I would expect these cases are already handled. Is there some specific problem you have run into? Michael Allan wrote: I'm trying to get a handle on thread-safety for components. I'm new to Wicket. My best information, so far, comes from the previous discussion Wicket Session and threading: http://mail-archives.apache.org/mod_mbox/wicket-users/200801.mbox/thread Eelco Hillenius, in response to Sebastiaan van Erk, wrote: Yes. We try our best to make pages/ components as thread safe as possible... Is there anywhere a small piece on how to deal with threading within Wicket (i.e., what is/is not synchronized in a request/response roundtrip?). I did some quick searching in the mailing list archives and google, but could not find anything related to version 1.3. Pages are synced on pagemaps, which basically relates to browser windows. RequestCycles are separate instances which are not reused, so no sync needed there. Sessions are not synced so you need to sync manually. Though in practice this wouldn't give much trouble to start with. Applications are shared an not synced. During form processing, however, my own pages are *not* synced on their pagemaps (at least not on their monitor locks). I placed this is in my code: assert Thread.holdsLock( /*page*/this.getPageMap() ); This asserts false during the setting of TextField models (Wicket 1.3.2), and false during the call to Form.onSubmit(). How can I ensure thread safety? In other words, if I am coding a model, what can I assume about my client threads? Are they synchronized somewhere, or must I code defensively within the model? Or, from the client side, if I have a thread that accesses a page's components, how can it avoid tangling with the response/request threads? -- Michael Allan Toronto, 647-436-4521 http://zelea.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/Thread-safety-for-components-tp17265324p17266550.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
