What can I do to speed up wicket initialization?
Hi there: I know it's not THAT slow, and every presentation framework has it's "loading time", but in my case this is affecting me in a much worse way and there's no other solution for now. Can any wicket expert tell me what can I do (anything: pre-compile something, do something lazily, avoid something, etc) to speed up wicket initialization? In GAE environment it takes up to 10 seconds from the moment I see the log entry "Started Wicket in deployment mode". I provide more details about my problem below. Thanks, Esteban My Problem: I'm using GAE and currently there's a problem that when your app gets few traffic, it gets "cycled out" (kicked out of the jvm) after a few minutes of not being accessed by anyone. So when your app (as mine) gets few visits, almost every visit takes up to 10 seconds because wicket initializes every time. There has been a number of solutions proposed: - Run a cron job to visit the app so it's kept "warm". This is discouraged from Google guys, as it would take all of us to the Tragedy of the Commons ( http://groups.google.com/group/google-appengine/browse_thread/thread/22692895421825cb/) - Pay to reserve a JVM (not available yet, http://code.google.com/p/googleappengine/issues/detail?id=2456 ) - Do anything you can to optimize your initialization code (here I am!)
Re: Page instantiated twice
Hi there. I'm bringing to life this old thread to ask whether this issue was
solved and how, because I'm experiencing something alike, which makes
session messsages to get lost ("consummed" by the first instance of the
page), and consecuently not shown by the second page instance.
Thanks,
Esteban
Vinayak Borkar wrote:
>
> Martijn,
>
> Ok. I set the getStatelessHint() to return false.
>
> Now I get java.lang.IllegalStateException: No SessionHandler or
> SessionManager
>
> What is the reason that wicket needs to instantiate the page twice? I
> can understand the second instantiation, but my guess is that the first
> instantiation is not to render the HTML.
>
> If I am correct about my analysis above, is there some way I can know
> that the instantiation does not need to populate all the components?
>
> Thanks,
>
> Vinayak
>
> Martijn Dashorst wrote:
>> Your page is stateless, which is a holy grail for most to attend. Be
>> happy :)
>>
>> Since it is stateless, Wicket has to construct the page with each
>> request, until it is no longer stateless.
>>
>> If you have a form, override its getstatelesshint method and return
>> false.
>>
>> Martijn
>>
>> On Tue, Mar 31, 2009 at 8:36 AM, Vinayak Borkar wrote:
>>> Jeremy,
>>>
>>> I did that. The first time it is
>>>
>>> at
>>> org.apache.wicket.request.target.component.BookmarkableListenerInterfaceRequestTarget.processEvents(BookmarkableListenerInterfaceRequestTarget.java:127)
>>>
>>> and the second time it is
>>>
>>> at
>>> org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.processEvents(BookmarkablePageRequestTarget.java:223)
>>>
>>>
>>> Does that help?
>>>
>>> Thanks,
>>> Vinayak
>>>
>>>
>>> Jeremy Thomerson wrote:
Run it in debug mode, put a breakpoint in your constructor and see
what's
instantiating each. A lot of times it is your own code (a bad link,
etc).
--
Jeremy Thomerson
http://www.wickettraining.com
On Tue, Mar 31, 2009 at 1:30 AM, Vinayak Borkar
wrote:
> Hello,
>
>
> I have a form that performs a search and shows a page with results.
> The
> result page also has the same form to do a repeat search. I noticed
> that
> the
> SearchPage is instantiated twice when I do a search from the form on
> the
> result page. Is there a way to make sure that does not happen? The
> search
> page ends up doing the search twice.
>
> Thanks,
> Vinayak
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>>> For additional commands, e-mail: users-h...@wicket.apache.org
>>>
>>>
>>
>>
>>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
>
--
View this message in context:
http://www.nabble.com/Page-instantiated-twice-tp22799162p25982806.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Old instances of a page remain in memory (apparently) forever
Thanks for the quick answer!
After doing some exhaustive testing, I've just found out that, just before
seeing your answer. The problem was that it wasn't until the 20th instance
that finally the garbage collector decided to free up some memmory (I tried
calling it explicitly but apparently the memmory wasn't too occupied so it
did nothing).
On Thu, Sep 24, 2009 at 12:14 AM, Igor Vaynberg wrote:
> the instances are held in memory until the jvm runs the garbage collector.
>
> -igor
>
> On Wed, Sep 23, 2009 at 8:09 PM, Esteban Ignacio Masoero
> wrote:
> > Hi:
> > I'm not sure whether this behavior is normal or not, so I'm going to
> > describe it and I hope someone can tell me if I'm doing something wrong
> or
> > if there's just nothing wrong!
> >
> > In my app I found out that each time a request is made, old instances of
> a
> > page remain in memory, and get accumulated in time (I noticed this
> behavior
> > by looking at the "All instances" feature from eclipse debug's
> perspective).
> > I searched the code for bad practices like anonyomus Model classes, but I
> > didn't find those kind of thins. So finally I created a new simple
> project
> > to test whether this behaviour repeated there too, and I found out that
> it
> > did!
> >
> > Here's the new simple project code (wicket 1.3.5, tomcat 6, eclipse
> > galileo):
> >
> > public class MyApp extends WebApplication {
> > @Override
> > public Class getHomePage() {
> > return MyPage.class;
> > }
> > }
> >
> > public class MyPage extends WebPage {
> > private String text;
> > public MyPage() {
> > this("");
> > }
> > public MyPage(String textt) {
> > super();
> > this.text = textt;
> > Form form = new Form("form"){
> > private static final long serialVersionUID = -3566834353426372805L;
> > @Override
> > protected void onSubmit() {
> > setResponsePage(new MyPage2(text));
> > }
> > };
> > form.add(new TextField("text", new PropertyModel(this, "text")));
> > form.add(new Button("accept"));
> > this.add(form);
> > }
> > }
> >
> > > response page.>
> >
> > When debugging (with a breakpoint in MyPage's constructor), every time a
> new
> > page is instanciated, I see that the old instances of that page remains
> in
> > memory. Using the "All references" feature I "walked" through the
> > reference-path, and I reached a weakReference to this page from a
> > "SerializedPagesCache$SerializedPageWithSession" instance (I had to stop
> > there because it was driving me crazy). (Of course I have no idea whether
> > this is normal or not, I'm just giving more info)
> >
> > Anyway, can anyone tell me what's wrong? Or is this a expected behavior
> and
> > sometime later this old instances will be eliminated from the jvm?
> >
> > Thanks in advance,
> >
> > Esteban
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
Old instances of a page remain in memory (apparently) forever
Hi:
I'm not sure whether this behavior is normal or not, so I'm going to
describe it and I hope someone can tell me if I'm doing something wrong or
if there's just nothing wrong!
In my app I found out that each time a request is made, old instances of a
page remain in memory, and get accumulated in time (I noticed this behavior
by looking at the "All instances" feature from eclipse debug's perspective).
I searched the code for bad practices like anonyomus Model classes, but I
didn't find those kind of thins. So finally I created a new simple project
to test whether this behaviour repeated there too, and I found out that it
did!
Here's the new simple project code (wicket 1.3.5, tomcat 6, eclipse
galileo):
public class MyApp extends WebApplication {
@Override
public Class getHomePage() {
return MyPage.class;
}
}
public class MyPage extends WebPage {
private String text;
public MyPage() {
this("");
}
public MyPage(String textt) {
super();
this.text = textt;
Form form = new Form("form"){
private static final long serialVersionUID = -3566834353426372805L;
@Override
protected void onSubmit() {
setResponsePage(new MyPage2(text));
}
};
form.add(new TextField("text", new PropertyModel(this, "text")));
form.add(new Button("accept"));
this.add(form);
}
}
When debugging (with a breakpoint in MyPage's constructor), every time a new
page is instanciated, I see that the old instances of that page remains in
memory. Using the "All references" feature I "walked" through the
reference-path, and I reached a weakReference to this page from a
"SerializedPagesCache$SerializedPageWithSession" instance (I had to stop
there because it was driving me crazy). (Of course I have no idea whether
this is normal or not, I'm just giving more info)
Anyway, can anyone tell me what's wrong? Or is this a expected behavior and
sometime later this old instances will be eliminated from the jvm?
Thanks in advance,
Esteban
