Hey Koen, 1. We update the page every 1 second. The table have 60 rows and 25 columns of Wtext. Most of the time, the browser is stuck (when loading - and loading take at least half a second). 2.just for checking I decided to emit the signal with the Wtimer - I wanted to check if the context is the problem - but apperantly not. Of course this is not the way I want it to run. I want that the cyclic thread will emit it with no use of the Wtimer. 3. I use windows. Because our company is a close network, we don't update the version very often and the version 2.2.3 is still goog for us (unless something was fixed). 4. How can I check that the lock doesn't protect me? Why does the signal of the Wtimer works fine and mine not? 5. The only difference I see between my application and SimpleChat example is that the signal is a member of a member of the widget and in my application the signal is a member of an outer class. And also the signal is emitted when a button is pushed in your example and in my application the signal is emitted periodically. Do I have to get the lock when I emit the signal? (I don't do that now and it doesn't seem logical to do so).
Thanks, Hadas -----Original Message----- From: Koen Deforche [mailto:[email protected]] Sent: Thursday, January 14, 2010 1:40 PM To: [email protected] Subject: Re: [Wt-interest] server push problems Hey Hadass, 2010/1/14 HADASS YAARI <[email protected]>: > I use to update my dynamic pages with WTimer. I have 3 dynamic pages > with very big tables. On timer tick I clear the table content and fill > in new elements. Apparently the tables were very big and update time > was too long so the browser window stucked until the refresh. Out of curiosity: you mean that the application was not responsive for a too long time? Or really that there some kind of timeout? How long did the update last then? > So I decided to change the method to server push. > I have a cyclic thread that emits the signal whenever needed. The > pages register the signal in the Ctr. the errors are different: > - vector subscript out of range (call stuck: WContainerWidget:: updateDom() > --> server::connection::handleReadyBody()). > - map/set iterator incompatible. > - sometimes a popup appears with : "wt internal error : [object > error], code undefined, description, object required" > > I suppose there is parallel access to a member of the application. I > take the application lock before updating and use triggerUpdate when I > finish. the update contains clearing 2 tables and filling in them with > new elements. I do the same as in the SimpleChat example. As I wrote > last time, I use the same method with the WTimer and it works fine. Those errors do indicate a concurrency problem indeed. I cannot recall any bug that was fixed since 2.2.3 w.r.t. the update lock, and, the simplechat example never had any issue also with 2.2.3 ? > I also tried to use the WTimer to just emit the signal and it works > fine. This way would have pleased me, but strangely it works slow too > - I suppose that when it emits the signal there is a context switch > before the method of the WTimer returns (maybe because of high > priority of handling signal). I'm not sure I understand this: you are using a timer which does not really have any callback associated with it, while still manipulating the application widget state with another thread ? I.e. the server push scenario without server push but with a WTimer ? In that case, yes, the actual rendering will only happen when the timer event is received, and this may be the time consuming step if you have a really big table. > Again, I know it is not very informative, but please think how to > guide me what to do in order to solve it. If you are developing with Linux, you could use valgrind to confirm that indeed you have a corruption because of concurrent access, and it will also show you the stracktraces of the concurrent access. Other than that, I cannot imagine why the UpdateLock would not protect you: it really is a simple lock on the mutex that protects the session which is also used by the WebSession to handle requests. Regards, koen ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest ********************************************************************************************** This message (including any attachments) issued by RAFAEL- ADVANCED DEFENSE SYSTEMS LTD. (hereinafter "RAFAEL") contains confidential information intended for a specific individual and purpose, may constitute information that is privileged or confidential or otherwise protected from disclosure. If you are not the intended recipient, you should contact us immediately and thereafter delete this message from your system. You are hereby notified that any disclosure, copying, dissemination, distribution or forwarding of this message, or the taking of any action based on it, is strictly prohibited. If you have received this e-mail in error, please notify us immediately by e-mail mailto:[email protected] and completely delete or destroy any and all electronic or other copies of the original message and any attachments thereof. ********************************************************************************************** ------------------------------------------------------------------------------ Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
