DatePicker uses wrong date format
Hi wicketians, after updating to wicket 1.4.7 the DatePicker does not use the date format i passed to DateTextField any more: form.add(new DateTextField(dateFilter.from, new PropertyModel(dateFilter, from), dd.MM.).setRequired(true).add(new DatePicker())); Instead of dd.MM. the DatePicker uses dd.MM.yy, only 2 digits for the year. Regards __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com
Background-Thread blocking Wicket-App
Hi All, we've got a page which does time consuming tasks. Because of that, every time a user calls the page a new background-thread is started (only if not running already) and the user is informed that the task is running and the page will be updated with fresh data as quickly as the thread has finished. We've realized that the WHOLE application is blocked until the background-thread finishes. That is no other page can be called by the user who has started the thraed. The app is also not responding to other users as long as the thread is running. The background thread class i'm using is a simple thread extending the thread class and retrieving data from a very very big database in its run method. I'm using Wicket 1.3.5 on Tomcat6.0.18 Any ideas?
AW: Background-Thread blocking Wicket-App
Thanks you and Jonas for the feedbacks.
You reminded me of the kind of usage of the Connection object. On first request
after the application has started, a permanent connection is established and
used by all following requests.
I've forgotten to change this after the first development steps :-(
Thank you for reminding me of this.
The code looks like:
public class ConnectionFactory {
private static Connection conn = null;
private ConnectionFactory() {
}
public static Connection getConnection() throws Exception {
if (conn == null) {
...
conn = DriverManager.getConnection(url, user, password);
}
return conn;
}
}
Von: Russell Simpkins russellsimpk...@hotmail.com
An: users@wicket.apache.org
Gesendet: Freitag, den 17. Juli 2009, 12:15:06 Uhr
Betreff: RE: Background-Thread blocking Wicket-App
Running a thread should not block the entire application - are you using
connection pooling with more than one max active connection? Maybe you should
send the code you use to kick off the thread. If you have any code that is
synchronized on a shared resource, that might block others.
Russ
Date: Fri, 17 Jul 2009 09:24:10 +
From: toka...@yahoo.de
Subject: Background-Thread blocking Wicket-App
To: users@wicket.apache.org
Hi All,
we've got a page which does time consuming tasks.
Because of that, every time a user calls the page a new background-thread is
started (only if not running already) and
the user is informed that the task is running and the page will be updated
with fresh data as quickly as the thread has finished.
We've realized that the WHOLE application is blocked until the
background-thread finishes. That is no other page can be called
by the user who has started the thraed. The app is also not responding to
other users as long as the thread is running.
The background thread class i'm using is a simple thread extending the thread
class and retrieving data from a very very big database in its run method.
I'm using Wicket 1.3.5 on Tomcat6.0.18
Any ideas?
_
Hotmail® has ever-growing storage! Don’t worry about storage limits.
http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage_062009
AW: How to get context path of Application
To locate the file use MyClass.class.getResource() Von: Gerald Fernando gerald.anto.ferna...@gmail.com An: users@wicket.apache.org Gesendet: Freitag, den 17. Juli 2009, 12:50:39 Uhr Betreff: Re: How to get context path of Application if i do this webRequest cannot be resolved to a type and RequestCycle cannot be resolved what can i do ThanksRegards, Gerald A On Fri, Jul 17, 2009 at 2:53 PM, Linda van der Pal lvd...@heritageagenturen.nl wrote: Well I guess Alex already gave the answer. ((WebRequest)RequestCycle.get().getRequest()).getHttpServletRequest().getContextPath() Alex Objelean Linda Gerald Fernando wrote: Hi Linda, Actually my page need to call a XML file.I have stored that file in my web content .error shows that the system could not find the file.but i give a absolute path it is working so i need to get my tomcat path to access that file. How can i access that file?Is there any other way. am expecting your reply urgent. Thanksregards, Gerald A On Fri, Jul 17, 2009 at 1:12 PM, Linda van der Pal lvd...@heritageagenturen.nl wrote: What is it exactly you are trying to do? Linda Gerald Fernando wrote: How to get context path of Application Thanks7Regards, Gerald A No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.375 / Virus Database: 270.13.17/2242 - Release Date: 07/16/09 18:00:00 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.375 / Virus Database: 270.13.17/2242 - Release Date: 07/16/09 18:00:00 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
AjaxSelfUpdatingTimerBehavior: Leaving page not possible
Hi Wicketians, i have a problem with AjaxSelfUpdatingTimerBehavior. I have added an AjaxSelfUpdatingTimerBehavior to a page, because of a background-thread running very long and the page checks (an AjaxSelfUpdatingTimerBehavior with 10 sec interval added at thread start to page) for the termination of the thread and showing the results of thread. It is in theory possible to leave the page while the background thread is running and come back to it at a later time. But in practice it isn't possible to leave it, the behavior reloads the page again and again until the thread ends and the behavior is removed from the page. Any idea how to solve this problem? Thank you in advance.
AW: AjaxSelfUpdatingTimerBehavior: Leaving page not possible
Thank you Martin for your quick answer. I think the problem is caused by the background-thread. I do start the thread with a low priority and as daemon but the application seems still waiting for the termination of the started thread. Very strange Von: Martin Funk mafulaf...@googlemail.com An: users@wicket.apache.org Gesendet: Montag, den 29. Juni 2009, 11:10:51 Uhr Betreff: Re: AjaxSelfUpdatingTimerBehavior: Leaving page not possible Am 29.06.2009 um 10:22 schrieb Tokalak Ahmet: Hi Wicketians, i have a problem with AjaxSelfUpdatingTimerBehavior. I have added an AjaxSelfUpdatingTimerBehavior to a page, because of a background-thread running very long and the page checks (an AjaxSelfUpdatingTimerBehavior with 10 sec interval added at thread start to page) for the termination of the thread and showing the results of thread. It is in theory possible to leave the page while the background thread is running and come back to it at a later time. But in practice it isn't possible to leave it, the behavior reloads the page again and again until the thread ends and the behavior is removed from the page. In theory, practice is always easy :-) Though I don't quite understand your problem. The ASUTB generates some JavaScript that instructs the Browser to fire an AjaxRequest right back to that Behavior on the Server. If the user leaves the page (on the browser) this JavaScript is disabled, no more calls to the browser. If the user comes back to that page, even if it is loaded from the browser cache, those Ajax-calls start again. Look at the clock example of the ajax examples in the wicket examples. Also the AjaxRequest doesn't reload the whole page, it just reloads the components that are added to the target in the overridden 'onTimer' method. To stop the Timer a removal is not needed, a call to its 'stop()' method does the same trick. Hopefully this helps, if not, come back, mf Any idea how to solve this problem? Thank you in advance. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Pagemap locking issue
Hi all, i'm developing a wicket application, in which i have to lookup mutiple tables with millions of datasets depending of the user inputs. Any operation on these tables is very time consuming not to talk about join operations ... (A request can take a few seconds or some minutes to complete) Since we have changed to production mode we are facing very often with pagemap locking errors which is big annoyance. I have increased the timeout value using getRequestCycleSettings().setTimeout(Duration.minutes(10)), which isn't a solution. The problem ist that long running requests block new requests (some requests running undefinitely long?). In our application we see that long running time consuming requests are blocking the whole application (tomcat). I think that long running request should be aborted after the timeout. This is a severe problem for us and could lead to the decision to give up Wicket. Does anybody has any idea to solve this problem? Thanks in advance.
AW: Pagemap locking issue
Thanks for your feedback Martijn. Yes, you're right. I will solve this issue using threads. Von: Martijn Dashorst martijn.dasho...@gmail.com An: users@wicket.apache.org Gesendet: Donnerstag, den 23. April 2009, 10:59:39 Uhr Betreff: Re: Pagemap locking issue Why would you want your users to wait for 1 minute to get results? On what planet and time/space continuum do you expect users to wait for that? Don't do the computation in the request thread. Compute the stuff in a separate thread, process or whatever and subscribe the user's session/page/whatever to a future outcome of that thread, and then rendering that directly. Sounds more like an application design issue than anything related to wicket. Martijn On Thu, Apr 23, 2009 at 10:06 AM, Tokalak Ahmet toka...@yahoo.de wrote: Hi all, i'm developing a wicket application, in which i have to lookup mutiple tables with millions of datasets depending of the user inputs. Any operation on these tables is very time consuming not to talk about join operations ... (A request can take a few seconds or some minutes to complete) Since we have changed to production mode we are facing very often with pagemap locking errors which is big annoyance. I have increased the timeout value using getRequestCycleSettings().setTimeout(Duration.minutes(10)), which isn't a solution. The problem ist that long running requests block new requests (some requests running undefinitely long?). In our application we see that long running time consuming requests are blocking the whole application (tomcat). I think that long running request should be aborted after the timeout. This is a severe problem for us and could lead to the decision to give up Wicket. Does anybody has any idea to solve this problem? Thanks in advance. -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.5 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
