Re: Wicket clustering without web server clustering

[Martin Grotzke]

Hi Dmitry,

I'm cc'ing the memcached-session-manager list so that we could take this
thread over to this list...

On Sun, 2010-05-30 at 15:38 -0700, DmitryM wrote:
> Martin,
> 
> Thanks a lot for the reply.
> Actually, I would appreciate if you helped me.
> I tried your tomcat session manager with my wicket app.
> I followed the configuration instructions for Tomcat you listed on the
> session manager page.
Can you post the actual configuration please?

> But it didn't seem to work for ajax requests.
> I believe I used sticky haproxy configuration (to add  session id to the
> request) but it still blew up with PageExpiredException on ajax requests.
To be sure that you're sticky you can also test with just one tomcat.

Do you see anything in the logs that's helpful?

Please can you add this to $CATALINA_HOME/conf/logging.properties and
provide some log output?
de.javakaffee.web.msm.MemcachedBackupSessionManager.level = FINEST
de.javakaffee.web.msm.SessionIdFormat.level = FINEST
de.javakaffee.web.msm.NodeAvailabilityCache.level = FINEST

Btw. you should tell haproxy to consider only a part of the session-id,
as the session-id contains the memcached node encoded (like the
jvm-route), like this:
602F7397FBE4D9932E59A9D0E52FE178-n1
or
602F7397FBE4D9932E59A9D0E52FE178-n1.tc1
if you have configured a jvmroute.

Perhaps haproxy allows to set a pattern, or also the length to use
should be possible (default sessionid length is configurable in tomcat
IIRC).


> 
> And there is even more significant issue: the protocol will eventually be
> secured (https) and haproxy (used in production) wouldn't be able to support
> sticky sessions in that case.
For this you should do SSL offloading in front of haproxy (stunnel?).
Are you forced to use haproxy btw? Some time ago I also looked for
alternatives to the usual suspects, and got good results with nginx
(also with SSL and sticky sessions IIRC).

Cheers,
Martin

> 
> I can verify one more time my configuration (to make sure I use sticky
> sessions, sync session storage/retrieval, same request renderng etc.) and
> will let you know if it worked for me or not.
> 
> Thanks,
> Dmitry



signature.asc
Description: This is a digitally signed message part

Re: Wicket clustering without web server clustering

[Martin Grotzke]

Hi Dmitry,

the memcached-session-manager
(http://code.google.com/p/memcached-session-manager/ ) is a tomcat
session manager that was created with two major goals in mind: minimal
impact on performance + scalability.

Optimal performance: can only be reached if you don't do any I/O for a
request.

Scalability: Just put more tomcat/memcached nodes and that's all for
scaling out.

The solution for the performance goal was, that when a request is
handled, the local (in memory) session should be used, and when the
request is finished the session is sent asynchronously to memcached
(actually you can also do this sync). This solution was appropriate, as
wicket is told to work best with sticky sessions.

Still, technically it's possible to use the memcached-session-manager
(msm) with a non-sticky configuration, so that the session is pulled
from memcached for each request (that accesses the session). You just
should tell msm to store sessions synchronously at the end of the
request.

For non-sticky sessions of course you need to keep concurrent session
access (ajax requests, multiple windows etc.) in mind. Also, be aware
that you can't use wicket's default mode REDIRECT_TO_BUFFER. Perhaps
you'd want to ask others here on the list what their experiences are
with non-stickyness + wicket.

Cheers,
Martin



On Thu, 2010-05-27 at 20:40 -0700, DmitryM wrote:
> Hello, guys
> 
> I need your advice for the following case.
> The Wicket application I'm working on is supposed to be deployed to Amazon
> EC2 cloud. This way standard Tomcat (used as a webapp container) clustering
> won't work (cloud doesn't accept multicasts). There is a third-party session
> manager available for Tomcat but it still needs sticky sessions from the
> load balancer (which is not conceptually good for app scaling).
if you're referring to the memcached-session-manager here
(http://code.google.com/p/memcached-session-manager/ ), I have to say
that it turned out that you should be able to use this even with
non-sticky sessions.

> I tried Hazelcast distributed data support (which allows for TCP unicasts)
> as a PageStore implementation (thanks this blog post:
> http://wicketbyexample.com/apache-wicket-clustering-with-multiple-options/)
> It works fine but needs session clustering (though Hazelcast makes PageStore
> available for each webapp instance already which seems to be an overhead.
> And I would like to use Hazelcast alone for this kind of 'clustering').
> 
> My question is about non-sticky sessions w/o clustering. I can try to extend
> SecondLevelCacheSessionStore to get the PageStore/page map etc. from
> Hazelcast and stick it to a newly created session (when load balancer
> forwards a request to the server which is different from the session's
> original server).
> 
> But do I need to try to transfer something else except for the PageMap to
> the fresh session (the webapp doesn't store anything in the Http session
> directly)?
> 
> I mean, does Wicket store anything else for its functional purposes in the
> Http Session (which I may need to distribute via Hazelcast)?
> 
> Thanks,
> Dmitry

-- 
Martin Grotzke
http://twitter.com/martin_grotzke


signature.asc
Description: This is a digitally signed message part

Re: root context, IE, home page is not found

[Martin Grotzke]

Hi,

we also just experienced issues with this, and the fix of WICKET-2600
still causes problems (as already described in this post):

For the redirect to "." tomcat produces a Location header like
http://www.example.org/. (notice the trailing dot), which causes IE to
do request exactly this url, for which no page ist mounted. Therefore
the 404 page not found.

Is there a special reason why "." was chosen here?

What do you think about an alternative handling like this:

if (redirectUrl.startsWith("./")) {
  if (redirectUrl.length() == 2)) {
WebRequest request = (WebRequest) requestCycle.getRequest();
String contextPath = request.getHttpServletRequest().getContextPath(); // 
e.g. "/myapp"
String servletPath = request.getServletPath(); // e.g. "/"
redirectUrl = contextPath + servletPath;
  }
  else {
redirectUrl.substring( 2 )
  }
}

Cheers,
Martin


On Sat, 2010-05-01 at 10:47 +0200, Erik van Oosten wrote:
> This might be related to https://issues.apache.org/jira/browse/WICKET-2600?
> 
> Regards,
>  Erik.
> 
> 
> Op 29-04-10 16:57, Jimi wrote:
> > I would also like to know if there is any solution (bug fix or workaround) 
> > to
> > this bug. Currently each time a IE-user logs out from my web application he
> > gets this ugly 404-error page, stating "The requested resource (/.) is not
> > available".
> >
> > I use Wicket 1.4.7 and the web application is deployed as ROOT context on
> > Tomcat 6.0.26.
> >
> > Is there no solution for this?
> >
> > Regards
> > /Jimi
> >
> 
> 

-- 
Martin Grotzke
http://www.javakaffee.de/blog/


signature.asc
Description: This is a digitally signed message part

Re: WicketTester fails with a custom WebRequestCodingStrategy

[Martin Grotzke]

Hi,

no feedback so far. It would be really nice if s.o. familiar with
WicketTester could a look at this.

Thanx && cheers,
Martin


On Thu, 2010-04-22 at 21:21 +0200, Martin Grotzke wrote:
> Hi,
> 
> I have an issue with a simple app working fine when run in the app
> server, but where the test (using WicketTester) that simulates the
> performed behaviour fails.
> 
> Here are the details:
> 
> I have a custom RequestCycleProcessor with a custom
> WebRequestCodingStrategy that mounts a page (for e.g. a shopping cart
> item) to a url like
>   /myapp/myitem-id42.html
> and knows according to the url pattern ( + "-id" +  +
> ".html") that the item details page is to be resolved.
> 
> This item details page also contains a stateless form with a button that
> adds the item to the shopping basket.
> 
> This works fine when it's run within the app: I can submit the form, the
> item is added to the basket and I'm shown the details page again.
> (the urls requested are shown at the end of the email [2])
> 
> Unfortunately, when I test this behaviour using WicketTester this fails,
> as it cannot create the item details page when the form is submitted.
> 
> This is my test (it can also be found at github [1]):
> 
> private WicketTester _tester;
> 
> @BeforeMethod
> public void setUp() {
> _tester = new WicketTester( new WicketApplication() );
> }
> 
> @Test
> public void testSubmitChoice() {
> _tester.startPage( DetailsPage.class, DetailsPage.pageParametersFor( 
> WicketApplication.MAKES_DB.get( 0 ) ) );
> _tester.assertRenderedPage( DetailsPage.class );
> final FormTester formTester = _tester.newFormTester( "form", false );
> formTester.submit( "submit" ); // --> this fails
> _tester.assertRenderedPage( DetailsPage.class );
> }
> 
> The test fails with an assertion on valid, provided page params in the
> items detail page:
> 
> ...
> Caused by: java.lang.NullPointerException: No valid make provided!
> (params: :submit = "marked")
> at 
> de.javakaffee.misc.wicket.ccs.DetailsPage.(DetailsPage.java:58)
> 
> (remember that this does not happen when run in the app server!)
> 
> 
> The complete example project can be found at github:
> http://github.com/magro/misc/tree/master/wicket-tester-custom-coding-strategy/
> the short link to the relevant classes (is actually a long link :-)):
> http://github.com/magro/misc/tree/master/wicket-tester-custom-coding-strategy/src/main/java/de/javakaffee/misc/wicket/ccs
> 
> 
> Can anyone help with this? Is this an issue of the request cycle
> processor / coding strategy (in combination with WicketTester), or is
> this an issue of WicketTester?
> 
> Thanx in advance,
> cheers,
> Martin
> 
> 
> [1] 
> http://github.com/magro/misc/blob/master/wicket-tester-custom-coding-strategy/src/test/java/de/javakaffee/misc/wicket/ccs/TestDetailsPage.java
> [2] -- urls requested:
> 
> 1) GET item details page:
>   - GET http://localhost:8080/Cadillac-i1.html
> -> 200 OK
> 2) Submit form, add item to basket
>   - POST 
> http://localhost:8080/Cadillac-i1.html?wicket:interface=:0:form::IFormSubmitListener::
> -> 302 Found (Location ...)
>   - GET http://localhost:8080/Cadillac-i1.html
> 
> 



signature.asc
Description: This is a digitally signed message part

WicketTester fails with a custom WebRequestCodingStrategy

[Martin Grotzke]

Hi,

I have an issue with a simple app working fine when run in the app
server, but where the test (using WicketTester) that simulates the
performed behaviour fails.

Here are the details:

I have a custom RequestCycleProcessor with a custom
WebRequestCodingStrategy that mounts a page (for e.g. a shopping cart
item) to a url like
  /myapp/myitem-id42.html
and knows according to the url pattern ( + "-id" +  +
".html") that the item details page is to be resolved.

This item details page also contains a stateless form with a button that
adds the item to the shopping basket.

This works fine when it's run within the app: I can submit the form, the
item is added to the basket and I'm shown the details page again.
(the urls requested are shown at the end of the email [2])

Unfortunately, when I test this behaviour using WicketTester this fails,
as it cannot create the item details page when the form is submitted.

This is my test (it can also be found at github [1]):

private WicketTester _tester;

@BeforeMethod
public void setUp() {
_tester = new WicketTester( new WicketApplication() );
}

@Test
public void testSubmitChoice() {
_tester.startPage( DetailsPage.class, DetailsPage.pageParametersFor( 
WicketApplication.MAKES_DB.get( 0 ) ) );
_tester.assertRenderedPage( DetailsPage.class );
final FormTester formTester = _tester.newFormTester( "form", false );
formTester.submit( "submit" ); // --> this fails
_tester.assertRenderedPage( DetailsPage.class );
}

The test fails with an assertion on valid, provided page params in the
items detail page:

...
Caused by: java.lang.NullPointerException: No valid make provided!
(params: :submit = "marked")
at de.javakaffee.misc.wicket.ccs.DetailsPage.(DetailsPage.java:58)

(remember that this does not happen when run in the app server!)


The complete example project can be found at github:
http://github.com/magro/misc/tree/master/wicket-tester-custom-coding-strategy/
the short link to the relevant classes (is actually a long link :-)):
http://github.com/magro/misc/tree/master/wicket-tester-custom-coding-strategy/src/main/java/de/javakaffee/misc/wicket/ccs


Can anyone help with this? Is this an issue of the request cycle
processor / coding strategy (in combination with WicketTester), or is
this an issue of WicketTester?

Thanx in advance,
cheers,
Martin


[1] 
http://github.com/magro/misc/blob/master/wicket-tester-custom-coding-strategy/src/test/java/de/javakaffee/misc/wicket/ccs/TestDetailsPage.java
[2] -- urls requested:

1) GET item details page:
  - GET http://localhost:8080/Cadillac-i1.html
-> 200 OK
2) Submit form, add item to basket
  - POST 
http://localhost:8080/Cadillac-i1.html?wicket:interface=:0:form::IFormSubmitListener::
-> 302 Found (Location ...)
  - GET http://localhost:8080/Cadillac-i1.html




signature.asc
Description: This is a digitally signed message part

Re: Don't increment the Session.pageIdCounter for stateless pages?

[Martin Grotzke]

What about using the @StatelessComponent (moving it from devutils into
wicket) as an indicator, that pages are intended to be stateless (_must_
be stateless)? Or introduce a new annotation @StatelessPage?

When a page that is intented to be stateless turns to be stateful, it's
always an issue (small or big one). Probably there are cases where pages
*should* be stateless and it doesn't really matter if they get stateful,
but there are also other cases, where pages *must* be stateless, e.g.
due to high load.

The @Stateless annotation would target the latter cases, where pages
*must* be stateless. And in this case, the pageIdCounter should also not
be modified.

What do you think?

Cheers,
Martin


On Sun, 2010-03-14 at 00:18 +0100, Martin Grotzke wrote:
> There are cases where pages are intended to be stateless (and might get
> annotated with @StatelessComponent). At least for these pages the page
> id should not be incremented, even if the session already has been
> bound.
> 
> Cheers,
> Martin
> 
> 
> On Sat, 2010-03-13 at 22:58 +0100, Matej Knopp wrote:
> > I'm not sure about all this.
> > 
> > If the session has not been bound the page id will always be 0. If the
> > session has been bound, I don't think we shouldn't increment page Id.
> > Stateless page can became stateful any time, not incrementing the id
> > can have sideeffects.
> > 
> > -Matej
> > 
> > On Sat, Mar 13, 2010 at 10:55 PM, Martin Grotzke
> >  wrote:
> > > Hi,
> > >
> > > just submitted this as
> > > https://issues.apache.org/jira/browse/WICKET-2782
> > >
> > > I tried incrementing the pageId when the page's numericId is first
> > > accessed, but soon realized, that this does happen rather often (also
> > > e.g. to construct bookmarkable page links) ;-) Seems to be not as easy
> > > as I thought. Still, it would be really cool if this could be
> > > implemented!
> > >
> > > Cheers,
> > > Martin
> > >
> > >
> > > On Wed, 2010-03-10 at 08:49 -0800, Igor Vaynberg wrote:
> > >> i think we can do this in 1.5
> > >>
> > >> i would rather not mess with 1.4 because i think there is a lot of
> > >> code there that depends on the fact that the id is available right
> > >> away.
> > >>
> > >> please create a jira issue for this
> > >>
> > >> -igor
> > >>
> > >> On Mon, Mar 8, 2010 at 4:30 PM, Martin Grotzke
> > >>  wrote:
> > >> > Hi,
> > >> >
> > >> > the Page.init(PageMap) invokes setNextAvailableId(), which invokes
> > >> > getSession().nextPageId() if isPageIdUniquePerSession is set.
> > >> >
> > >> > getSession().nextPageId() modifies the Session.pageIdCounter.
> > >> >
> > >> > When I have a session and afterwards access a stateless page, the
> > >> > Session.pageIdCounter is the only data that is changed in the session
> > >> > AFAICS, everything else is the same as in the request before.
> > >> >
> > >> > Is it possible _not_ to modify the Session.pageIdCounter if the page is
> > >> > really stateless (or just don't invoke Page.setNextAvailableId())?
> > >> >
> > >> > I'm interested in this, as I'm just implementing a feature for the
> > >> > memcached-session-manager ([1], memcached based session replication),
> > >> > which checks if session data has changed and replicates sessions only 
> > >> > if
> > >> > this is provided. If session data did not change, the replication is
> > >> > omitted. Therefore, if the Session.pageIdCounter would be left 
> > >> > unchanged
> > >> > for stateless pages, this would allow to make use of this feature in
> > >> > wicket apps.
> > >> >
> > >> > Thanx && cheers,
> > >> > Martin
> > >> >
> > >> >
> > >> > [1] http://code.google.com/p/memcached-session-manager/
> > >> >
> > >> >
> > >> >
> > >>
> > >> -
> > >> 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
> > 
> 



signature.asc
Description: This is a digitally signed message part

Re: Don't increment the Session.pageIdCounter for stateless pages?

[Martin Grotzke]

There are cases where pages are intended to be stateless (and might get
annotated with @StatelessComponent). At least for these pages the page
id should not be incremented, even if the session already has been
bound.

Cheers,
Martin


On Sat, 2010-03-13 at 22:58 +0100, Matej Knopp wrote:
> I'm not sure about all this.
> 
> If the session has not been bound the page id will always be 0. If the
> session has been bound, I don't think we shouldn't increment page Id.
> Stateless page can became stateful any time, not incrementing the id
> can have sideeffects.
> 
> -Matej
> 
> On Sat, Mar 13, 2010 at 10:55 PM, Martin Grotzke
>  wrote:
> > Hi,
> >
> > just submitted this as
> > https://issues.apache.org/jira/browse/WICKET-2782
> >
> > I tried incrementing the pageId when the page's numericId is first
> > accessed, but soon realized, that this does happen rather often (also
> > e.g. to construct bookmarkable page links) ;-) Seems to be not as easy
> > as I thought. Still, it would be really cool if this could be
> > implemented!
> >
> > Cheers,
> > Martin
> >
> >
> > On Wed, 2010-03-10 at 08:49 -0800, Igor Vaynberg wrote:
> >> i think we can do this in 1.5
> >>
> >> i would rather not mess with 1.4 because i think there is a lot of
> >> code there that depends on the fact that the id is available right
> >> away.
> >>
> >> please create a jira issue for this
> >>
> >> -igor
> >>
> >> On Mon, Mar 8, 2010 at 4:30 PM, Martin Grotzke
> >>  wrote:
> >> > Hi,
> >> >
> >> > the Page.init(PageMap) invokes setNextAvailableId(), which invokes
> >> > getSession().nextPageId() if isPageIdUniquePerSession is set.
> >> >
> >> > getSession().nextPageId() modifies the Session.pageIdCounter.
> >> >
> >> > When I have a session and afterwards access a stateless page, the
> >> > Session.pageIdCounter is the only data that is changed in the session
> >> > AFAICS, everything else is the same as in the request before.
> >> >
> >> > Is it possible _not_ to modify the Session.pageIdCounter if the page is
> >> > really stateless (or just don't invoke Page.setNextAvailableId())?
> >> >
> >> > I'm interested in this, as I'm just implementing a feature for the
> >> > memcached-session-manager ([1], memcached based session replication),
> >> > which checks if session data has changed and replicates sessions only if
> >> > this is provided. If session data did not change, the replication is
> >> > omitted. Therefore, if the Session.pageIdCounter would be left unchanged
> >> > for stateless pages, this would allow to make use of this feature in
> >> > wicket apps.
> >> >
> >> > Thanx && cheers,
> >> > Martin
> >> >
> >> >
> >> > [1] http://code.google.com/p/memcached-session-manager/
> >> >
> >> >
> >> >
> >>
> >> -
> >> 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
> 



signature.asc
Description: This is a digitally signed message part

Re: Don't increment the Session.pageIdCounter for stateless pages?

[Martin Grotzke]

Hi,

just submitted this as
https://issues.apache.org/jira/browse/WICKET-2782

I tried incrementing the pageId when the page's numericId is first
accessed, but soon realized, that this does happen rather often (also
e.g. to construct bookmarkable page links) ;-) Seems to be not as easy
as I thought. Still, it would be really cool if this could be
implemented!

Cheers,
Martin


On Wed, 2010-03-10 at 08:49 -0800, Igor Vaynberg wrote:
> i think we can do this in 1.5
> 
> i would rather not mess with 1.4 because i think there is a lot of
> code there that depends on the fact that the id is available right
> away.
> 
> please create a jira issue for this
> 
> -igor
> 
> On Mon, Mar 8, 2010 at 4:30 PM, Martin Grotzke
>  wrote:
> > Hi,
> >
> > the Page.init(PageMap) invokes setNextAvailableId(), which invokes
> > getSession().nextPageId() if isPageIdUniquePerSession is set.
> >
> > getSession().nextPageId() modifies the Session.pageIdCounter.
> >
> > When I have a session and afterwards access a stateless page, the
> > Session.pageIdCounter is the only data that is changed in the session
> > AFAICS, everything else is the same as in the request before.
> >
> > Is it possible _not_ to modify the Session.pageIdCounter if the page is
> > really stateless (or just don't invoke Page.setNextAvailableId())?
> >
> > I'm interested in this, as I'm just implementing a feature for the
> > memcached-session-manager ([1], memcached based session replication),
> > which checks if session data has changed and replicates sessions only if
> > this is provided. If session data did not change, the replication is
> > omitted. Therefore, if the Session.pageIdCounter would be left unchanged
> > for stateless pages, this would allow to make use of this feature in
> > wicket apps.
> >
> > Thanx && cheers,
> > Martin
> >
> >
> > [1] http://code.google.com/p/memcached-session-manager/
> >
> >
> >
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 



signature.asc
Description: This is a digitally signed message part

AW: Re: Don't increment the Session.pageIdCounter for stateless pages?

[martin . grotzke]

>From my basic understanding I'd say that for stateless pages nothing should 
>depend on the pageId. What do you think about incrementing the pageId when 
>it's first accessed? I'd like to create a patch for it to see if this works.

Cheers,
Martin 

-- Urspr. Mitt. --
Betreff: Re: Don't increment the Session.pageIdCounter for stateless pages?
Von: Igor Vaynberg 
Datum: 10.03.2010 17:50

i think we can do this in 1.5

i would rather not mess with 1.4 because i think there is a lot of
code there that depends on the fact that the id is available right
away.

please create a jira issue for this

-igor

On Mon, Mar 8, 2010 at 4:30 PM, Martin Grotzke
 wrote:
> Hi,
>
> the Page.init(PageMap) invokes setNextAvailableId(), which invokes
> getSession().nextPageId() if isPageIdUniquePerSession is set.
>
> getSession().nextPageId() modifies the Session.pageIdCounter.
>
> When I have a session and afterwards access a stateless page, the
> Session.pageIdCounter is the only data that is changed in the session
> AFAICS, everything else is the same as in the request before.
>
> Is it possible _not_ to modify the Session.pageIdCounter if the page is
> really stateless (or just don't invoke Page.setNextAvailableId())?
>
> I'm interested in this, as I'm just implementing a feature for the
> memcached-session-manager ([1], memcached based session replication),
> which checks if session data has changed and replicates sessions only if
> this is provided. If session data did not change, the replication is
> omitted. Therefore, if the Session.pageIdCounter would be left unchanged
> for stateless pages, this would allow to make use of this feature in
> wicket apps.
>
> Thanx && cheers,
> Martin
>
>
> [1] http://code.google.com/p/memcached-session-manager/
>
>
>

-
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

Don't increment the Session.pageIdCounter for stateless pages?

[Martin Grotzke]

Hi,

the Page.init(PageMap) invokes setNextAvailableId(), which invokes
getSession().nextPageId() if isPageIdUniquePerSession is set.

getSession().nextPageId() modifies the Session.pageIdCounter.

When I have a session and afterwards access a stateless page, the
Session.pageIdCounter is the only data that is changed in the session
AFAICS, everything else is the same as in the request before.

Is it possible _not_ to modify the Session.pageIdCounter if the page is
really stateless (or just don't invoke Page.setNextAvailableId())?

I'm interested in this, as I'm just implementing a feature for the
memcached-session-manager ([1], memcached based session replication),
which checks if session data has changed and replicates sessions only if
this is provided. If session data did not change, the replication is
omitted. Therefore, if the Session.pageIdCounter would be left unchanged
for stateless pages, this would allow to make use of this feature in
wicket apps.

Thanx && cheers,
Martin


[1] http://code.google.com/p/memcached-session-manager/




signature.asc
Description: This is a digitally signed message part

Re: tomcat session replication

[Martin Grotzke]

During deserialization, memcached-session-manager's xml/javolution based
serialization strategy just ignores fields that are no longer existing
in new classes. Of course one needs to be careful with renaming fields,
but I'd also like to have some mechanism to provide specific upgrade
handlers.

Cheers,
Martin


On Fri, 2010-03-05 at 20:16 -0800, Douglas Ferguson wrote:
> So as long as the serial I'd is the same the classlader won't care the  
> fields don't match?
> 
> Douglas Ferguson
> 512-293-7279
> Sent from my iPhone
> 
> On Mar 5, 2010, at 3:37 PM, "Igor Vaynberg"   
> wrote:
> 
> > in the wicket code we override serial ids to 1, you should do the same
> > in your code.
> >
> > -igor
> >
> > On Fri, Mar 5, 2010 at 12:15 PM, Douglas Ferguson
> >  wrote:
> >> I'm  considering a 0 downtime deployment but am concerned with the  
> >> amount of state in the wicket session.
> >>
> >> This is the scenario that concerns me.
> >>
> >> 1) There are 2 tomcats running
> >> 2) A change is made to a serializable object and the serial version  
> >> id is updated
> >> 3) 1 tomcat instance is taken down for updating
> >> 4) tomcat instance comes back up with new object and now tries to  
> >> update state from other tomcat and the wicket session has a  
> >> reference to the old version of the serializable.
> >>
> >> On Mar 5, 2010, at 12:18 PM, Igor Vaynberg wrote:
> >>
> >>> yes
> >>>
> >>> -igor
> >>>
> >>> On Fri, Mar 5, 2010 at 10:02 AM, Douglas Ferguson
> >>>  wrote:
> >>>> Has anybody had success with wicket using tomcat's session  
> >>>> replication?
> >>>>
> >>>> D/
> >>>>
> >>>> --- 
> >>>> --
> >>>> 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
> >>
> >>
> >
> > -
> > 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
> 

-- 
Martin Grotzke
http://www.javakaffee.de/blog/


signature.asc
Description: This is a digitally signed message part

Re: tomcat session replication

[Martin Grotzke]

Hi Douglas,

you might have a look at memcached-session-manager [1] which is a tomcat
session manager that stores sessions additionally in memcached (sessions
are still kept in and read from local memory for best performance).

The session serialization is pluggable and there's an xml based
serialization strategy (using javolution) to support code upgrade - of
course you still have to keep track of code changes so that "old"
session data structures can be deserialized to new data structures (have
a look at [2] for serialization strategies).

Btw, what I wonder: tomcat's session replication requires a
session.setAttribute to detect a session modification and trigger a
replication - is this requirement met by wicket? And apart from wicket,
to me this seems to be a rather hard requirement for web applications.
Who can guarantee, that nobody is getting a session attribute and
modifying it without invoking session.setAttribute afterwards...?

Right now I'm implementing a feature so that sessions are only sent to
memcached if the session data changed. This is completely transparent,
so that you might retrieve a complex session attribute, change some
property of it and this change will be detected so that the session will
be updated in memcached (more details on this can be found at [3]).

Cheers,
Martin


[1] http://code.google.com/p/memcached-session-manager/
[2] 
http://code.google.com/p/memcached-session-manager/wiki/SerializationStrategies
[3] http://code.google.com/p/memcached-session-manager/issues/detail?id=36


On Fri, 2010-03-05 at 12:15 -0800, Douglas Ferguson wrote:
> I'm  considering a 0 downtime deployment but am concerned with the amount of 
> state in the wicket session.
> 
> This is the scenario that concerns me.
> 
> 1) There are 2 tomcats running
> 2) A change is made to a serializable object and the serial version id is 
> updated
> 3) 1 tomcat instance is taken down for updating
> 4) tomcat instance comes back up with new object and now tries to update 
> state from other tomcat and the wicket session has a reference to the old 
> version of the serializable.
> 
> On Mar 5, 2010, at 12:18 PM, Igor Vaynberg wrote:
> 
> > yes
> > 
> > -igor
> > 
> > On Fri, Mar 5, 2010 at 10:02 AM, Douglas Ferguson
> >  wrote:
> >> Has anybody had success with wicket using tomcat's session replication?
> >> 
> >> D/
> 
> ---------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 

-- 
Martin Grotzke
http://www.javakaffee.de/blog/


signature.asc
Description: This is a digitally signed message part

Re: test for dropdownchoice with ajax - response is homepage always

[Martin Grotzke]

Great, it's working now. I didn't use exactly the same formTester which
was used for selecting the second dropdown before, that was the reason
why it didn't work.

Thanx for your help,
cheers,
Martin


On Tue, 2009-12-01 at 16:03 +0200, Martin Makundi wrote:
> > However, I already had tested this and it doesn't make any difference -
> > the test still fails with the same error.
> 
> I am not sure what you are doing. Do like this
> 
> {
>   // Operation 1
>   FormTester f1 = tester.newFormTester (...);
>   f1.setValue
>   tester.execute ...
> }
> 
> {
>   // Operation 2
>   FormTester f1 = tester.newFormTester (...);
>   f1.setValue
>   f1.submit
> }
> 
> 
> **
> Martin
> 
> >
> > Thanx && cheers,
> > Martin
> >
> >
> >>
> >> **
> >> Martin
> >>
> >> 2009/12/1 Martin Grotzke :
> >> > On Tue, 2009-12-01 at 11:44 +0200, Martin Makundi wrote:
> >> >> > Thanx for your feedback! Did you have a look at http://is.gd/58mq3 
> >> >> > which
> >> >> > shows the test?
> >> >>
> >> >> Ofcourse I didn't look ;)
> >> >>
> >> >> Now, having looked at it your bug is that FORMTESTER CAN BE SUBMITTED 
> >> >> ONLY ONCE!
> >> >>
> >> >> If you want to use it another time, you need to call newFormTester 
> >> >> again.
> >> > Thanx, this fixed the issue!
> >> >
> >> > Now I extended the test to make sure that the previously selected make
> >> > and model are still selected after the final submit - and this fails
> >> > with the second drop down (the model): this returns null from
> >> > dropDown.getDefaultModelObject. I pushed this, so http://is.gd/58mq3
> >> > shows these changes.
> >> >
> >> > Is there another thing that needs to be changed in the test?
> >> >
> >> > Cheers,
> >> > Martin
> >> >
> >> >
> >> >>
> >> >> **
> >> >> Martin
> >> >> >
> >> >> >
> >> >> >>
> >> >> >> **
> >> >> >> Martin
> >> >> >>
> >> >> >> >
> >> >> >> > This issue was already reported some time ago without a final 
> >> >> >> > result:
> >> >> >> > http://old.nabble.com/unit-test-for-dropdownchoice-with-ajax-td21141772.html
> >> >> >> >
> >> >> >> >
> >> >> >> > I created an example project that shows this issue:
> >> >> >> > http://github.com/magro/misc/tree/master/wicket-tester-drop-downs/
> >> >> >> >
> >> >> >> > This is the short link to the failing test case (on github): 
> >> >> >> > http://is.gd/58mq3
> >> >> >> > This is the tested page class: http://is.gd/58mDm
> >> >> >> >
> >> >> >> > I'm using wicket 1.4.3.
> >> >> >> >
> >> >> >> > Is there any error in the test? Can I do anything to work around 
> >> >> >> > this,
> >> >> >> > or is it a bug?
> >> >> >> >
> >> >> >> > Thanx && cheers,
> >> >> >> > Martin
> >> >> >> >
> >> >> >> > --
> >> >> >> > Martin Grotzke
> >> >> >> > http://www.javakaffee.de/blog/
> >> >> >> >
> >> >> >>
> >> >> >> -
> >> >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> >> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >> >> >>
> >> >> > --
> >> >> > Martin Grotzke
> >> >> > http://www.javakaffee.de/blog/
> >> >> >
> >> >>
> >> >> -
> >> >> 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
> 


signature.asc
Description: This is a digitally signed message part

Re: test for dropdownchoice with ajax - response is homepage always

[Martin Grotzke]

On Tue, 2009-12-01 at 15:46 +0200, Martin Makundi wrote:
> Line 63 you are re-using the same formTester. Cannot work.
Wow, really fast! :)

However, I already had tested this and it doesn't make any difference -
the test still fails with the same error.

FWIW, I updated and pushed the test so that you can see what I actually
changed.

Thanx && cheers,
Martin


> 
> **
> Martin
> 
> 2009/12/1 Martin Grotzke :
> > On Tue, 2009-12-01 at 11:44 +0200, Martin Makundi wrote:
> >> > Thanx for your feedback! Did you have a look at http://is.gd/58mq3 which
> >> > shows the test?
> >>
> >> Ofcourse I didn't look ;)
> >>
> >> Now, having looked at it your bug is that FORMTESTER CAN BE SUBMITTED ONLY 
> >> ONCE!
> >>
> >> If you want to use it another time, you need to call newFormTester again.
> > Thanx, this fixed the issue!
> >
> > Now I extended the test to make sure that the previously selected make
> > and model are still selected after the final submit - and this fails
> > with the second drop down (the model): this returns null from
> > dropDown.getDefaultModelObject. I pushed this, so http://is.gd/58mq3
> > shows these changes.
> >
> > Is there another thing that needs to be changed in the test?
> >
> > Cheers,
> > Martin
> >
> >
> >>
> >> **
> >> Martin
> >> >
> >> >
> >> >>
> >> >> **
> >> >> Martin
> >> >>
> >> >> >
> >> >> > This issue was already reported some time ago without a final result:
> >> >> > http://old.nabble.com/unit-test-for-dropdownchoice-with-ajax-td21141772.html
> >> >> >
> >> >> >
> >> >> > I created an example project that shows this issue:
> >> >> > http://github.com/magro/misc/tree/master/wicket-tester-drop-downs/
> >> >> >
> >> >> > This is the short link to the failing test case (on github): 
> >> >> > http://is.gd/58mq3
> >> >> > This is the tested page class: http://is.gd/58mDm
> >> >> >
> >> >> > I'm using wicket 1.4.3.
> >> >> >
> >> >> > Is there any error in the test? Can I do anything to work around this,
> >> >> > or is it a bug?
> >> >> >
> >> >> > Thanx && cheers,
> >> >> > Martin
> >> >> >
> >> >> > --
> >> >> > Martin Grotzke
> >> >> > http://www.javakaffee.de/blog/
> >> >> >
> >> >>
> >> >> -
> >> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >> >>
> >> > --
> >> > Martin Grotzke
> >> > http://www.javakaffee.de/blog/
> >> >
> >>
> >> -
> >> 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
> 


signature.asc
Description: This is a digitally signed message part

Re: test for dropdownchoice with ajax - response is homepage always

[Martin Grotzke]

On Tue, 2009-12-01 at 11:44 +0200, Martin Makundi wrote:
> > Thanx for your feedback! Did you have a look at http://is.gd/58mq3 which
> > shows the test?
> 
> Ofcourse I didn't look ;)
> 
> Now, having looked at it your bug is that FORMTESTER CAN BE SUBMITTED ONLY 
> ONCE!
> 
> If you want to use it another time, you need to call newFormTester again.
Thanx, this fixed the issue!

Now I extended the test to make sure that the previously selected make
and model are still selected after the final submit - and this fails
with the second drop down (the model): this returns null from
dropDown.getDefaultModelObject. I pushed this, so http://is.gd/58mq3
shows these changes.

Is there another thing that needs to be changed in the test?

Cheers,
Martin


> 
> **
> Martin
> >
> >
> >>
> >> **
> >> Martin
> >>
> >> >
> >> > This issue was already reported some time ago without a final result:
> >> > http://old.nabble.com/unit-test-for-dropdownchoice-with-ajax-td21141772.html
> >> >
> >> >
> >> > I created an example project that shows this issue:
> >> > http://github.com/magro/misc/tree/master/wicket-tester-drop-downs/
> >> >
> >> > This is the short link to the failing test case (on github): 
> >> > http://is.gd/58mq3
> >> > This is the tested page class: http://is.gd/58mDm
> >> >
> >> > I'm using wicket 1.4.3.
> >> >
> >> > Is there any error in the test? Can I do anything to work around this,
> >> > or is it a bug?
> >> >
> >> > Thanx && cheers,
> >> > Martin
> >> >
> >> > --
> >> > Martin Grotzke
> >> > http://www.javakaffee.de/blog/
> >> >
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >>
> > --
> > Martin Grotzke
> > http://www.javakaffee.de/blog/
> >
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 


signature.asc
Description: This is a digitally signed message part

Re: test for dropdownchoice with ajax - response is homepage always

[Martin Grotzke]

On Tue, 2009-12-01 at 08:32 +0200, Martin Makundi wrote:
> Hi!
> 
> > When I test a page like this
> > http://www.wicket-library.com/wicket-examples/ajax/choice
> > with wicket tester and submit the form, the response page is the
> > HomePage instead of the expected page (ChoicePage).
> 
> Do you use a formtester? The wicket tester executeajax does not
> properly submit the form values so what we do is we create a dummy
> formtester before calling executeajaxevent. That might help.
Thanx for your feedback! Did you have a look at http://is.gd/58mq3 which
shows the test?

Yes, I'm using a formTester. What is your actual advice how to work
around? I didn't get this :)

Cheers,
Martin


> 
> **
> Martin
> 
> >
> > This issue was already reported some time ago without a final result:
> > http://old.nabble.com/unit-test-for-dropdownchoice-with-ajax-td21141772.html
> >
> >
> > I created an example project that shows this issue:
> > http://github.com/magro/misc/tree/master/wicket-tester-drop-downs/
> >
> > This is the short link to the failing test case (on github): 
> > http://is.gd/58mq3
> > This is the tested page class: http://is.gd/58mDm
> >
> > I'm using wicket 1.4.3.
> >
> > Is there any error in the test? Can I do anything to work around this,
> > or is it a bug?
> >
> > Thanx && cheers,
> > Martin
> >
> > --
> > Martin Grotzke
> > http://www.javakaffee.de/blog/
> >
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 
-- 
Martin Grotzke
http://www.javakaffee.de/blog/


signature.asc
Description: This is a digitally signed message part

test for dropdownchoice with ajax - response is homepage always

[Martin Grotzke]

Hi,

When I test a page like this
http://www.wicket-library.com/wicket-examples/ajax/choice
with wicket tester and submit the form, the response page is the
HomePage instead of the expected page (ChoicePage).

This issue was already reported some time ago without a final result:
http://old.nabble.com/unit-test-for-dropdownchoice-with-ajax-td21141772.html


I created an example project that shows this issue:
http://github.com/magro/misc/tree/master/wicket-tester-drop-downs/

This is the short link to the failing test case (on github): http://is.gd/58mq3
This is the tested page class: http://is.gd/58mDm

I'm using wicket 1.4.3.

Is there any error in the test? Can I do anything to work around this,
or is it a bug?

Thanx && cheers,
Martin

-- 
Martin Grotzke
http://www.javakaffee.de/blog/


signature.asc
Description: This is a digitally signed message part

Close ModalWindow on ESC key pressed

[Martin Grotzke]

Hi,

I want to close a modal window when the user presses the ESC key.

Right now I have overridden the show method in our ModalWindow subclass
and added the keypress event listener (using jquery), the javascript
close function is just copied from the ModalWindow.

Opening the modal window and closing it with ESC works once,
unfortunately, I cannot open any more the modal window after that.

Can anyone hint on what's the problem here, or perhaps someone already
has a working solution?

This is the implementation of the show method:

@Override
public void show(final AjaxRequestTarget target) {
if (!isShown()) {
final AppendingStringBuffer buffer = new AppendingStringBuffer(500);
buffer.append("function mwClose(ev) {\n" +
"var code = ev.keyCode || ev.which;\n" +
"if (code == 27) { " +
getCloseJavascript() +
"};" +
"}");
buffer.append("jQuery(document).keypress(mwClose);\n");
target.appendJavascript(buffer.toString());
}
super.show(target);
}

The getCloseJavascript method (copied from ModalWindow, as it's private 
therein):

/**
 * @return javascript that closes current modal window
 */
private static String getCloseJavacript() {
return "var win;\n" //
+ "try {\n"
+ " win = window.parent.Wicket.Window;\n"
+ "} catch (ignore) {\n"
+ "}\n"
+ "if (typeof(win) == \"undefined\" || typeof(win.current) == 
\"undefined\") {\n"
+ "  try {\n"
+ " win = window.Wicket.Window;\n"
+ "  } catch (ignore) {\n"
+ "  }\n"
+ "}\n"
+ "if (typeof(win) != \"undefined\" && typeof(win.current) != 
\"undefined\") {\n"
+ " var close = function(w) { w.setTimeout(function() {\n"
+ " win.current.close();\n"
+ " }, 0);  } \n"
+ " try { close(window.parent); } catch (ignore) { close(window); 
};\n" + "}";
}

Thanx for your help,
cheers,
Martin



signature.asc
Description: This is a digitally signed message part

Re: Lazy loading via AJAX on stateless pages?

[Martin Grotzke]

Hi,

reposting - can somebody help with this?

Thanx in advance,
cheers,
Martin


On Mon, 2009-04-20 at 00:33 +0200, Martin Grotzke wrote:
> Now in the default constructor of my page I added a behavior linking to
> the page with page parameters and I added such a constructor taking
> parameters. In this constructor, I set a new AjaxRequestTarget on the
> request cycle and add some component to the target.
> 
> When I request my page, I see the ajax request coming in (using
> firebug), but the response is empty and contains the header
> Ajax-Location which triggers a redirect (javascript location update).
> Why does this "redirect" occur?
> 
> A part of the default constructor looks like this:
> 
> final Label label = new Label("info", " + urlFor( AbstractDefaultAjaxBehavior.INDICATOR ) + "\"/>");
> 
> add( label.setOutputMarkupId( true ).setEscapeModelStrings(false) );
> 
> label.add( new AbstractDefaultAjaxBehavior() {
> 
> @Override
> protected void respond( AjaxRequestTarget target ) {
> throw new UnsupportedOperationException();
> }
> 
> @Override
> public void renderHead( IHeaderResponse response ) {
> super.renderHead( response );
> response.renderOnDomReadyJavascript( 
> getCallbackScript().toString() );
> }
> 
> @Override
> public CharSequence getCallbackUrl( boolean onlyTargetActivePage ) {
> final PageParameters parameters = new PageParameters();
> parameters.add( "foo", "bar" );
> return urlFor( Index.class, parameters );
> }
> 
> });
> 
> The constructor taking page parameters looks like this:
> 
> public Index( PageParameters pageParameters ) {
> final AjaxRequestTarget target = new AjaxRequestTarget( this );
> WebRequestCycle.get().setRequestTarget( target );
> 
> final Label lazyLabel = new Label( "info", pageParameters.getString( 
> "foo" ) );
> target.addComponent( lazyLabel.setOutputMarkupId( true ) );
> }
> 
> 
> What's wrong with this? Can the page when invoked via ajax with request
> params output the necessary xml?
> 
> Thanx && cheers,
> Martin
> 
> 
> 
> On Sat, 2009-04-18 at 19:05 -0500, Jeremy Thomerson wrote:
> > Using urlFor(...) generates a stateful, session-relative link - unless you
> > call urlFor(Class, PageParameters) - which is stateless because it encodes
> > the class and parameters in the URL.  In the other URLs, the state is stored
> > in the session, and the URL is basically a map to navigate the component
> > tree to get back to the component that generated the URL.
> > 
> > --
> > Jeremy Thomerson
> > http://www.wickettraining.com
> > 
> > 
> > 
> > On Sat, Apr 18, 2009 at 4:27 PM, Martin Grotzke <
> > martin.grot...@javakaffee.de> wrote:
> > 
> > > What exactly causes the page to be stateful when urlFor(Component,
> > > Interface) is invoked?
> > >
> > > I would like to make only minimal changes compared to original wicket
> > > ajax handling and would really like to reuse as much as possible of
> > > wicket ajax handling (e.g. adding components to be updated to the
> > > AjaxRequestTarget).
> > >
> > > Do you think it would be possible to create a Behavior that uses a
> > > callback url which links to a (stateless) page with page parameters.
> > > This page provides a constructor taking parameters and sets an
> > > AjaxRequestTarget on the RequestCycle. It creates and adds all
> > > components which shall be changed to the target.
> > >
> > > What do you think? Can you imagine other ways of being as close as
> > > possible to wicket?
> > >
> > > Thanx && cheers,
> > > Martin
> > >
> > >
> > >
> > > On Fri, 2009-04-17 at 15:40 -0700, Igor Vaynberg wrote:
> > > > sure, you can use behaviors and requesttargets of whatever kind. just
> > > > make sure nothing on your page calls urlfor(component, interface) -
> > > > this is what causes the page to be stateful.
> > > >
> > > > -igor
> > > >
> > > > On Fri, Apr 17, 2009 at 3:14 PM, Martin Grotzke
> > > >  wrote:
> > > > > Wow, very fast response!
> > > > >
> > > > > Is it possible to use wicket concepts like RequestTarget and Behavior
> > > on
> > > > > t

Re: New site developed in wicket - WWW.FITCOMPLEX.SK

[Martin Grotzke]

Congrats! A nice site and really fast!

You're mentioning stateless ajax with jquery: can you give some pointers
how you did this?

Cheers,
Martin


On Mon, 2009-04-20 at 18:22 +0200, Stefan Simik wrote:
> New site about health, nutrition, exercise and life
> style
> 
> We are using stateless pages for public interface, and stateful ajaxified
> pages for admin interface.
> Stateless ajax in public is developed using jquery + wicket.
> 
> The site is running on:
> 
>- *Wicket *1.4rc2
>- *Web server*: Jetty 6.1.14  (with Apache front-end)
>- *Db*: mysql (ehcache + hibernate)
>- *OS*: Ubuntu 8.04 (Hardy Heron)
> 
> 
> *Wicket performance* is very good - the slowest element is mysql database.
> It's able to serve up to ~130 pages /sec on modern notebook (2Ghz Montevina,
> 5400 rpm, 3GB RAM).
> On server we haven't tested, but it should be much more.
> 
> *Thanks to the community for patiently answering many questions and for all
> the support.*
> 
> Štefan Šimík
> www.fitcomplex.sk


signature.asc
Description: This is a digitally signed message part

Re: Lazy loading via AJAX on stateless pages?

[Martin Grotzke]

Now in the default constructor of my page I added a behavior linking to
the page with page parameters and I added such a constructor taking
parameters. In this constructor, I set a new AjaxRequestTarget on the
request cycle and add some component to the target.

When I request my page, I see the ajax request coming in (using
firebug), but the response is empty and contains the header
Ajax-Location which triggers a redirect (javascript location update).
Why does this "redirect" occur?

A part of the default constructor looks like this:

final Label label = new Label("info", "");

add( label.setOutputMarkupId( true ).setEscapeModelStrings(false) );

label.add( new AbstractDefaultAjaxBehavior() {

@Override
protected void respond( AjaxRequestTarget target ) {
throw new UnsupportedOperationException();
}

@Override
public void renderHead( IHeaderResponse response ) {
super.renderHead( response );
response.renderOnDomReadyJavascript( getCallbackScript().toString() 
);
}

@Override
public CharSequence getCallbackUrl( boolean onlyTargetActivePage ) {
final PageParameters parameters = new PageParameters();
parameters.add( "foo", "bar" );
return urlFor( Index.class, parameters );
}

});

The constructor taking page parameters looks like this:

public Index( PageParameters pageParameters ) {
final AjaxRequestTarget target = new AjaxRequestTarget( this );
WebRequestCycle.get().setRequestTarget( target );

final Label lazyLabel = new Label( "info", pageParameters.getString( 
"foo" ) );
target.addComponent( lazyLabel.setOutputMarkupId( true ) );
}


What's wrong with this? Can the page when invoked via ajax with request
params output the necessary xml?

Thanx && cheers,
Martin



On Sat, 2009-04-18 at 19:05 -0500, Jeremy Thomerson wrote:
> Using urlFor(...) generates a stateful, session-relative link - unless you
> call urlFor(Class, PageParameters) - which is stateless because it encodes
> the class and parameters in the URL.  In the other URLs, the state is stored
> in the session, and the URL is basically a map to navigate the component
> tree to get back to the component that generated the URL.
> 
> --
> Jeremy Thomerson
> http://www.wickettraining.com
> 
> 
> 
> On Sat, Apr 18, 2009 at 4:27 PM, Martin Grotzke <
> martin.grot...@javakaffee.de> wrote:
> 
> > What exactly causes the page to be stateful when urlFor(Component,
> > Interface) is invoked?
> >
> > I would like to make only minimal changes compared to original wicket
> > ajax handling and would really like to reuse as much as possible of
> > wicket ajax handling (e.g. adding components to be updated to the
> > AjaxRequestTarget).
> >
> > Do you think it would be possible to create a Behavior that uses a
> > callback url which links to a (stateless) page with page parameters.
> > This page provides a constructor taking parameters and sets an
> > AjaxRequestTarget on the RequestCycle. It creates and adds all
> > components which shall be changed to the target.
> >
> > What do you think? Can you imagine other ways of being as close as
> > possible to wicket?
> >
> > Thanx && cheers,
> > Martin
> >
> >
> >
> > On Fri, 2009-04-17 at 15:40 -0700, Igor Vaynberg wrote:
> > > sure, you can use behaviors and requesttargets of whatever kind. just
> > > make sure nothing on your page calls urlfor(component, interface) -
> > > this is what causes the page to be stateful.
> > >
> > > -igor
> > >
> > > On Fri, Apr 17, 2009 at 3:14 PM, Martin Grotzke
> > >  wrote:
> > > > Wow, very fast response!
> > > >
> > > > Is it possible to use wicket concepts like RequestTarget and Behavior
> > on
> > > > the serverside? I'd like to have this integrated with wicket as much as
> > > > possible.
> > > >
> > > > Cheers,
> > > > Martin
> > > >
> > > >
> > > > On Fri, 2009-04-17 at 14:55 -0700, Igor Vaynberg wrote:
> > > >> you cannot use wicket ajax facilities as they are designed for
> > > >> stateful pages - the link that wicket uses for ajax callback is
> > > >> inherently stateful.
> > > >>
> > > >> what you can do is write javascript yourself using jquery, or
> > > >> something else to perform an ajax callback to some url you control and
> > > >> then replace some markup on 

Re: Lazy loading via AJAX on stateless pages?

[Martin Grotzke]

What exactly causes the page to be stateful when urlFor(Component,
Interface) is invoked?

I would like to make only minimal changes compared to original wicket
ajax handling and would really like to reuse as much as possible of
wicket ajax handling (e.g. adding components to be updated to the
AjaxRequestTarget).

Do you think it would be possible to create a Behavior that uses a
callback url which links to a (stateless) page with page parameters.
This page provides a constructor taking parameters and sets an
AjaxRequestTarget on the RequestCycle. It creates and adds all
components which shall be changed to the target.

What do you think? Can you imagine other ways of being as close as
possible to wicket?

Thanx && cheers,
Martin



On Fri, 2009-04-17 at 15:40 -0700, Igor Vaynberg wrote:
> sure, you can use behaviors and requesttargets of whatever kind. just
> make sure nothing on your page calls urlfor(component, interface) -
> this is what causes the page to be stateful.
> 
> -igor
> 
> On Fri, Apr 17, 2009 at 3:14 PM, Martin Grotzke
>  wrote:
> > Wow, very fast response!
> >
> > Is it possible to use wicket concepts like RequestTarget and Behavior on
> > the serverside? I'd like to have this integrated with wicket as much as
> > possible.
> >
> > Cheers,
> > Martin
> >
> >
> > On Fri, 2009-04-17 at 14:55 -0700, Igor Vaynberg wrote:
> >> you cannot use wicket ajax facilities as they are designed for
> >> stateful pages - the link that wicket uses for ajax callback is
> >> inherently stateful.
> >>
> >> what you can do is write javascript yourself using jquery, or
> >> something else to perform an ajax callback to some url you control and
> >> then replace some markup on your page with returned markup.
> >>
> >> -igor
> >>
> >> On Fri, Apr 17, 2009 at 2:52 PM, Martin Grotzke
> >>  wrote:
> >> > Hello,
> >> >
> >> > can somebody help with this?
> >> >
> >> > Thanx && cheers,
> >> > Martin
> >> >
> >> >
> >> > On Mon, 2009-04-13 at 12:16 +0200, martin.grot...@javakaffee.de wrote:
> >> >> Hi,
> >> >>
> >> >> I'm currently evaluating how it's possible to have stateless pages with
> >> >> some information loaded asynchronously via AJAX.
> >> >>
> >> >> I found these postings that are somehow related to this
> >> >> http://www.nabble.com/Stateless-AJAX-links-td20031309.html
> >> >> http://www.nabble.com/Directions-for-Stateless-Ajax-td17518987.html
> >> >>
> >> >> but I'm not sure what exactly has to be done to achieve what I want.
> >> >>
> >> >> Basically I have a simple page where I added an AjaxBehavior to a label
> >> >> that shall get replaced via AJAX:
> >> >>
> >> >> final Label label = new Label( "info", "foo" );
> >> >> add( label.setOutputMarkupId( true ) );
> >> >> label.add(new AbstractDefaultAjaxBehavior() {
> >> >>
> >> >> @Override
> >> >> protected void respond( AjaxRequestTarget target ) {
> >> >> final Label lazyLabel = new Label( "info", "loaded 
> >> >> asynchronously" );
> >> >> Index.this.replace( lazyLabel.setOutputMarkupId( true ) );
> >> >> target.addComponent( lazyLabel );
> >> >> }
> >> >>
> >> >> @Override
> >> >> public void renderHead( IHeaderResponse response ) {
> >> >> super.renderHead( response );
> >> >> response.renderOnDomReadyJavascript( 
> >> >> getCallbackScript().toString() );
> >> >> }
> >> >>
> >> >> } );
> >> >>
> >> >> This turns the previously statelesss page to stateful, AFAICS because of
> >> >>   getStatelessHint( Component component )
> >> >> returning false for the label.
> >> >>
> >> >> When I change this to return true, wicket says the page is expired on 
> >> >> the AJAX request...
> >> >>
> >> >> Can anybody say what had to be done?
> >> >>
> >> >> Btw: I'm using wicket-1.4-SNAPSHOT.
> >> >>
> >> >> Thanx in advance,
> >> >> cheers,
> >> >> Martin
> >> >>
> >> >>
> >> >> -
> >> >> 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
> 


signature.asc
Description: This is a digitally signed message part

Re: Lazy loading via AJAX on stateless pages?

[Martin Grotzke]

Wow, very fast response!

Is it possible to use wicket concepts like RequestTarget and Behavior on
the serverside? I'd like to have this integrated with wicket as much as
possible.

Cheers,
Martin


On Fri, 2009-04-17 at 14:55 -0700, Igor Vaynberg wrote:
> you cannot use wicket ajax facilities as they are designed for
> stateful pages - the link that wicket uses for ajax callback is
> inherently stateful.
> 
> what you can do is write javascript yourself using jquery, or
> something else to perform an ajax callback to some url you control and
> then replace some markup on your page with returned markup.
> 
> -igor
> 
> On Fri, Apr 17, 2009 at 2:52 PM, Martin Grotzke
>  wrote:
> > Hello,
> >
> > can somebody help with this?
> >
> > Thanx && cheers,
> > Martin
> >
> >
> > On Mon, 2009-04-13 at 12:16 +0200, martin.grot...@javakaffee.de wrote:
> >> Hi,
> >>
> >> I'm currently evaluating how it's possible to have stateless pages with
> >> some information loaded asynchronously via AJAX.
> >>
> >> I found these postings that are somehow related to this
> >> http://www.nabble.com/Stateless-AJAX-links-td20031309.html
> >> http://www.nabble.com/Directions-for-Stateless-Ajax-td17518987.html
> >>
> >> but I'm not sure what exactly has to be done to achieve what I want.
> >>
> >> Basically I have a simple page where I added an AjaxBehavior to a label
> >> that shall get replaced via AJAX:
> >>
> >> final Label label = new Label( "info", "foo" );
> >> add( label.setOutputMarkupId( true ) );
> >> label.add(new AbstractDefaultAjaxBehavior() {
> >>
> >> @Override
> >> protected void respond( AjaxRequestTarget target ) {
> >> final Label lazyLabel = new Label( "info", "loaded asynchronously" 
> >> );
> >> Index.this.replace( lazyLabel.setOutputMarkupId( true ) );
> >> target.addComponent( lazyLabel );
> >> }
> >>
> >> @Override
> >> public void renderHead( IHeaderResponse response ) {
> >> super.renderHead( response );
> >> response.renderOnDomReadyJavascript( 
> >> getCallbackScript().toString() );
> >> }
> >>
> >> } );
> >>
> >> This turns the previously statelesss page to stateful, AFAICS because of
> >>   getStatelessHint( Component component )
> >> returning false for the label.
> >>
> >> When I change this to return true, wicket says the page is expired on the 
> >> AJAX request...
> >>
> >> Can anybody say what had to be done?
> >>
> >> Btw: I'm using wicket-1.4-SNAPSHOT.
> >>
> >> Thanx in advance,
> >> cheers,
> >> Martin
> >>
> >>
> >> -
> >> 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
> 


signature.asc
Description: This is a digitally signed message part

Re: Lazy loading via AJAX on stateless pages?

[Martin Grotzke]

Hello,

can somebody help with this?

Thanx && cheers,
Martin


On Mon, 2009-04-13 at 12:16 +0200, martin.grot...@javakaffee.de wrote:
> Hi,
> 
> I'm currently evaluating how it's possible to have stateless pages with
> some information loaded asynchronously via AJAX.
> 
> I found these postings that are somehow related to this
> http://www.nabble.com/Stateless-AJAX-links-td20031309.html
> http://www.nabble.com/Directions-for-Stateless-Ajax-td17518987.html
> 
> but I'm not sure what exactly has to be done to achieve what I want.
> 
> Basically I have a simple page where I added an AjaxBehavior to a label
> that shall get replaced via AJAX:
> 
> final Label label = new Label( "info", "foo" );
> add( label.setOutputMarkupId( true ) );
> label.add(new AbstractDefaultAjaxBehavior() {
> 
> @Override
> protected void respond( AjaxRequestTarget target ) {
> final Label lazyLabel = new Label( "info", "loaded asynchronously" );
> Index.this.replace( lazyLabel.setOutputMarkupId( true ) );
> target.addComponent( lazyLabel );
> }
> 
> @Override
> public void renderHead( IHeaderResponse response ) {
> super.renderHead( response );
> response.renderOnDomReadyJavascript( getCallbackScript().toString() );
> }
> 
> } );
> 
> This turns the previously statelesss page to stateful, AFAICS because of
>   getStatelessHint( Component component )
> returning false for the label.
> 
> When I change this to return true, wicket says the page is expired on the 
> AJAX request...
> 
> Can anybody say what had to be done?
> 
> Btw: I'm using wicket-1.4-SNAPSHOT.
> 
> Thanx in advance,
> cheers,
> Martin
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 


signature.asc
Description: This is a digitally signed message part

Lazy loading via AJAX on stateless pages?

[martin . grotzke]

Hi,

I'm currently evaluating how it's possible to have stateless pages with
some information loaded asynchronously via AJAX.

I found these postings that are somehow related to this
http://www.nabble.com/Stateless-AJAX-links-td20031309.html
http://www.nabble.com/Directions-for-Stateless-Ajax-td17518987.html

but I'm not sure what exactly has to be done to achieve what I want.

Basically I have a simple page where I added an AjaxBehavior to a label
that shall get replaced via AJAX:

final Label label = new Label( "info", "foo" );
add( label.setOutputMarkupId( true ) );
label.add(new AbstractDefaultAjaxBehavior() {

@Override
protected void respond( AjaxRequestTarget target ) {
final Label lazyLabel = new Label( "info", "loaded asynchronously" );
Index.this.replace( lazyLabel.setOutputMarkupId( true ) );
target.addComponent( lazyLabel );
}

@Override
public void renderHead( IHeaderResponse response ) {
super.renderHead( response );
response.renderOnDomReadyJavascript( getCallbackScript().toString() );
}

} );

This turns the previously statelesss page to stateful, AFAICS because of
  getStatelessHint( Component component )
returning false for the label.

When I change this to return true, wicket says the page is expired on the AJAX 
request...

Can anybody say what had to be done?

Btw: I'm using wicket-1.4-SNAPSHOT.

Thanx in advance,
cheers,
Martin


-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org

Re: Caching of rendered panels

[Martin Grotzke]

Hi,

I also thought about s.th. like this because we'll have very complex
component graphs that have to be composed dynamically based on the
language of the user and ~3 other things. I thought about caching
complete component instances, but didn't come so far that I thought
about how this could be integrated into wicket - perhaps dead simple via
some
  _cacheService.getReallyComplexComponentCached( "complexComponent", userInfo )

I don't know how cheap exactly rendering of our complex component
structure will be, but if this would take more than say 10 millis we
would also try to cache already rendered markup.

Cheers,
Martin


On Fri, 2009-03-27 at 16:49 +0100, Daniel Frisk wrote:
> I have a situation where I have some panels which I want to render say  
> at most once a minute and during that period they should be "static".  
> I tried a few approches which hasn't really worked out for me so I  
> wanted to know if somebody has created such a thing or how this could  
> be done. Ideas are also welcome...
> 
> // Daniel Frisk
> jalbum.net
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 


signature.asc
Description: This is a digitally signed message part

Re: Client-side models for zero-state scalability

[Martin Grotzke]

Hi Matej,

sounds interesting, also the approach with PageParametersAware (and
PageParametersForm). Do you thought about writing a short description of
how this approach works? This would be really helpful, as I don't see
the whole picture until now.

Cheers,
Martin


On Tue, 2009-03-24 at 12:04 +0100, Matej Knopp wrote:
> http://code.google.com/p/brix-cms/source/browse/trunk/brix-demo/src/main/java/brix/demo/web/tile/stockquote/stateless/StatelessStockQuotePanel.java
> 
> -Matej
> 
> On Tue, Mar 24, 2009 at 12:01 PM, Alex Objelean  
> wrote:
> >
> > Matej, thank you for your reply!
> > Could you provide some examples (links) where I can see how it works?
> >
> > Thank you!
> >
> > Alex
> >
> >
> > Matej Knopp-2 wrote:
> >>
> >> Well, there possibly will be extended support for stateless
> >> application - something like we implemented in brix. So in a way the
> >> statement is true. But there is no timeline for it.
> >>
> >> -Matej
> >>
> >> On Tue, Mar 24, 2009 at 11:47 AM, Alex Objelean 
> >> wrote:
> >>>
> >>> After reviewing the Wicket feature list, I accidentally noticed the
> >>> following
> >>> statement:
> >>> "The next version of Wicket will support client-side models for
> >>> zero-state
> >>> scalability". I am wondering if this feature will be indeed implemented
> >>> in
> >>> (which?) next version or this is just some feature which sounds great for
> >>> marketability and will never by implemented?
> >>>
> >>> Thank you!
> >>>
> >>> Alex
> >>> --
> >>> View this message in context:
> >>> http://www.nabble.com/Client-side-models-for-zero-state-scalability-tp22677847p22677847.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
> >>>
> >>>
> >>
> >> -
> >> 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/Client-side-models-for-zero-state-scalability-tp22677847p22678056.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
> >
> >
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 


signature.asc
Description: This is a digitally signed message part

Re: Wicket WebBeans Project...

[Martin Grotzke]

On Thu, 2009-03-19 at 11:53 -0400, James Carman wrote:
> On Thu, Mar 19, 2009 at 11:51 AM, Martin Grotzke
>  wrote:
> > Just for consideration: this would create a jar like "webbeans-1.4.jar"
> > which would be confusing...
> 
> Right, that's why I stuck with wicket-webbeans.  :)
(Y) :)


> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 


signature.asc
Description: This is a digitally signed message part

Re: Wicket WebBeans Project...

[Martin Grotzke]

On Thu, 2009-03-19 at 10:01 -0500, Jeremy Thomerson wrote:
> If the original WWB project isn't active - I don't think it would be a
> problem to take over the name.
> 
> If there is a problem with doing that, what about wicket-openwebbeans?
> 
> Or, in wicketstuff-core, we have removed the "wicket-" from all names
> because it was redundant.  Make your groupId "org.wicketstuff" and your
> artifactId "webbeans".
Just for consideration: this would create a jar like "webbeans-1.4.jar"
which would be confusing...

Cheers,
Martin


> 
> --
> Jeremy Thomerson
> http://www.wickettraining.com
> 
> 
> 
> On Thu, Mar 19, 2009 at 9:53 AM, Leszek Gawron  wrote:
> 
> > James Carman wrote:
> >
> >> All,
> >>
> >> I've run into a problem.  I'd like to start up a project to integrate
> >> the new WebBeans Specification (JSR-299) based on the Apache
> >> OpenWebBeans project
> >> (http://incubator.apache.org/openwebbeans/1.0.0-SNAPSHOT/index.html)
> >> in the Apache Incubator.  Unfortunately, there already exists a
> >> project called wicketwebbeans.  It's not an "official" Wicket project,
> >> but I don't want to step on anyone's toes.  What would you folks
> >> suggest here?  The name of the spec is WebBeans, so the name
> >> wicket-webbeans (the packages is javax.webbeans) does fit.  The other
> >> project's actual name is wicketwebbeans, so it's not an exact match,
> >> but it's close enough to cause some confusion.
> >>
> >
> > you could call it wicket-jsr299, but that might be a little bit too cryptic
> > for some users...
> >
> > Is wicketwebbeans project active currently? It looks like it's still using
> > wicket 1.3...
> >
> > --
> > Leszek Gawron
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
> >


signature.asc
Description: This is a digitally signed message part

Re: memcached session store

[Martin Grotzke]

On Wed, 2009-03-11 at 12:06 -0700, Victor Igumnov wrote:
> I had issues when running non-sticky sessions with ONE_PASS_RENDERER,  
> the results were mixed. Responses came back as a mixed bag, sometimes  
> it worked or not. Expired sessions did happen from time to time with  
> no rhyme or reason. Sticky sessions  is a must on wicket.
Hmm, this does not improve confidence - at least not in the
implementation/handling of ONE_PASS_RENDERER. Did you address this issue
somehow on the users/dev mailing list or via the issue tracker? Also I
would cross the fingers that REDIRECT_TO_RENDER does not produce the
same issues.

> 
> I hate to say this but, if your writing a stateless oriented site,  
> wicket might not be the best choice. Your fighting an uphill battle.
Our goal is to defer session creation as long as it's possible -
probably this is until the user submits the first form. With this we
asume we don't need any PageMap (0 versioned pages).

Provided we use sticky sessions and REDIRECT_TO_BUFFER, would you say
there will be problems with this approach (statelessness as long as it's
possible and no pagemaps)?

Thanx && cheers,
Martin


> 
> On Mar 11, 2009, at 10:17 AM, Martin Grotzke wrote:
> 
> > Hi,
> >
> > One would need to handle this on the client side, by disabling
> > buttons/links when they are clicked. Also AJAX communicatoin has to be
> > handled, as this is also often a candidate that triggers multiple
> > requests running in parallel.
> >
> > Cheers,
> > Martin
> >
> >
> > On Wed, 2009-03-11 at 17:45 +0100, Johan Compagner wrote:
> >> In my point of view none sticky sessions are just broken or can be  
> >> broken
> >> very easily
> >> I dont know exactly how all the implementations work but does this  
> >> example
> >> all ways work?
> >>
> >> a user clicks on a button
> >> that button click does take some time and in the mean time a user  
> >> clicks on
> >> the same or another button
> >>
> >> In  a sticky session configuration this works fine. Wicket makes  
> >> sure that
> >> they are synced and a page wont be altered by 2 threads at the same  
> >> time\
> >>
> >> But how does a none sticky configuration work? Will the second  
> >> request go to
> >> another server? And just alter there the page state?
> >> It can do that because our sync block doesnt work then ofcourse.
> >>
> >> But if this happens, what happens after that? now the same page  
> >> instance is
> >> altered on both places.. Which one takes precedence ?
> >> Because it is impossible for the container to merge the objects. So  
> >> it
> >> should take 1 or the other..
> >> So the first click that took longer then the second click will  
> >> overwrite the
> >> second click page. But that now overwritten page is now shown to  
> >> the user
> >> So if you then click on something that was on the page of the  
> >> second click
> >> but wasnt on the page of the first click. Then you will get an page  
> >> expired
> >> or something like that..
> >>
> >> maybe somehow containers do some synching across concurrent request  
> >> of 1
> >> session (hopefully the will send them to the same server)
> >> But i dont know. Synching over servers is very expensive.. then the  
> >> whole
> >> usage of having none sticky sessions is completely gone in my eyes.
> >>
> >> johan
> >>
> >> On Tue, Mar 10, 2009 at 10:49, Martin Grotzke
> >> wrote:
> >>
> >>> On Mon, 2009-03-09 at 22:54 -0700, Victor Igumnov wrote:
> >>>> Even if you have the memcached store in place, wicket still  
> >>>> requires
> >>>> session affinity. Wicket buffers redirect responses locally so the
> >>>> client needs to go to the same server twice or the client will  
> >>>> receive
> >>>> an expired session. Wicket is a stateful framework, session  
> >>>> affinity
> >>>> is a must.
> >>> Are there other things (besides the buffered response when doing a
> >>> redirect-after-post with the REDIRECT_TO_BUFFER setting) that  
> >>> require
> >>> sticky sessions?
> >>>
> >>> We'd like to use wicket in a stateless mode and defer session  
> >>> creation
> >>> as long as it's possible for a user. Even if wicket is made with a
> >>> statefull programm

Re: memcached session store

[Martin Grotzke]

On Wed, 2009-03-11 at 20:09 +0100, Johan Compagner wrote:
> thats impossible to do completely
> A refresh of a browser is for example 1
Ok, from a technical/academical point of view this is valid. However,
GET requests should not modify any data. For POST-requests the user also
has to confirm that form data is resent. Also users pressing F5 (and
confirming resending of data) all the time are not as common as the well
known double-clickers...

Did you really had issues with this? What was the setup/conditions in
this case?

> 
> And that would be quite annoying that you have to do that because you have
> some kind of configuration on the serverside
What do you want to say with this? I don't understand this.

Cheers,
Martin


> 
> johan
> 
> 
> On Wed, Mar 11, 2009 at 18:17, Martin Grotzke
> wrote:
> 
> > Hi,
> >
> > One would need to handle this on the client side, by disabling
> > buttons/links when they are clicked. Also AJAX communicatoin has to be
> > handled, as this is also often a candidate that triggers multiple
> > requests running in parallel.
> >
> > Cheers,
> > Martin
> >
> >
> > On Wed, 2009-03-11 at 17:45 +0100, Johan Compagner wrote:
> > > In my point of view none sticky sessions are just broken or can be broken
> > > very easily
> > > I dont know exactly how all the implementations work but does this
> > example
> > > all ways work?
> > >
> > > a user clicks on a button
> > > that button click does take some time and in the mean time a user clicks
> > on
> > > the same or another button
> > >
> > > In  a sticky session configuration this works fine. Wicket makes sure
> > that
> > > they are synced and a page wont be altered by 2 threads at the same time\
> > >
> > > But how does a none sticky configuration work? Will the second request go
> > to
> > > another server? And just alter there the page state?
> > > It can do that because our sync block doesnt work then ofcourse.
> > >
> > > But if this happens, what happens after that? now the same page instance
> > is
> > > altered on both places.. Which one takes precedence ?
> > > Because it is impossible for the container to merge the objects. So it
> > > should take 1 or the other..
> > > So the first click that took longer then the second click will overwrite
> > the
> > > second click page. But that now overwritten page is now shown to the user
> > > So if you then click on something that was on the page of the second
> > click
> > > but wasnt on the page of the first click. Then you will get an page
> > expired
> > > or something like that..
> > >
> > > maybe somehow containers do some synching across concurrent request of 1
> > > session (hopefully the will send them to the same server)
> > > But i dont know. Synching over servers is very expensive.. then the whole
> > > usage of having none sticky sessions is completely gone in my eyes.
> > >
> > > johan
> > >
> > > On Tue, Mar 10, 2009 at 10:49, Martin Grotzke
> > > wrote:
> > >
> > > > On Mon, 2009-03-09 at 22:54 -0700, Victor Igumnov wrote:
> > > > > Even if you have the memcached store in place, wicket still requires
> > > > > session affinity. Wicket buffers redirect responses locally so the
> > > > > client needs to go to the same server twice or the client will
> > receive
> > > > > an expired session. Wicket is a stateful framework, session affinity
> > > > > is a must.
> > > > Are there other things (besides the buffered response when doing a
> > > > redirect-after-post with the REDIRECT_TO_BUFFER setting) that require
> > > > sticky sessions?
> > > >
> > > > We'd like to use wicket in a stateless mode and defer session creation
> > > > as long as it's possible for a user. Even if wicket is made with a
> > > > statefull programming model in mind we think there are still many
> > > > advantages over other (non-component-based) frameworks. Also we need a
> > > > dynamic structure which would be rather hard to realize/simulate with
> > > > some other component oriented frameworks ;)
> > > >
> > > > Cheers,
> > > > Martin
> > > >
> > > >
> > > > >
> > > > >
> > > > > On Mar 9, 2009, at 7:03 AM, Martin Grotzke wrote:
> > > > >
> > > > > > On Mon, 

Re: memcached session store

[Martin Grotzke]

Hi,

One would need to handle this on the client side, by disabling
buttons/links when they are clicked. Also AJAX communicatoin has to be
handled, as this is also often a candidate that triggers multiple
requests running in parallel.

Cheers,
Martin


On Wed, 2009-03-11 at 17:45 +0100, Johan Compagner wrote:
> In my point of view none sticky sessions are just broken or can be broken
> very easily
> I dont know exactly how all the implementations work but does this example
> all ways work?
> 
> a user clicks on a button
> that button click does take some time and in the mean time a user clicks on
> the same or another button
> 
> In  a sticky session configuration this works fine. Wicket makes sure that
> they are synced and a page wont be altered by 2 threads at the same time\
> 
> But how does a none sticky configuration work? Will the second request go to
> another server? And just alter there the page state?
> It can do that because our sync block doesnt work then ofcourse.
> 
> But if this happens, what happens after that? now the same page instance is
> altered on both places.. Which one takes precedence ?
> Because it is impossible for the container to merge the objects. So it
> should take 1 or the other..
> So the first click that took longer then the second click will overwrite the
> second click page. But that now overwritten page is now shown to the user
> So if you then click on something that was on the page of the second click
> but wasnt on the page of the first click. Then you will get an page expired
> or something like that..
> 
> maybe somehow containers do some synching across concurrent request of 1
> session (hopefully the will send them to the same server)
> But i dont know. Synching over servers is very expensive.. then the whole
> usage of having none sticky sessions is completely gone in my eyes.
> 
> johan
> 
> On Tue, Mar 10, 2009 at 10:49, Martin Grotzke
> wrote:
> 
> > On Mon, 2009-03-09 at 22:54 -0700, Victor Igumnov wrote:
> > > Even if you have the memcached store in place, wicket still requires
> > > session affinity. Wicket buffers redirect responses locally so the
> > > client needs to go to the same server twice or the client will receive
> > > an expired session. Wicket is a stateful framework, session affinity
> > > is a must.
> > Are there other things (besides the buffered response when doing a
> > redirect-after-post with the REDIRECT_TO_BUFFER setting) that require
> > sticky sessions?
> >
> > We'd like to use wicket in a stateless mode and defer session creation
> > as long as it's possible for a user. Even if wicket is made with a
> > statefull programming model in mind we think there are still many
> > advantages over other (non-component-based) frameworks. Also we need a
> > dynamic structure which would be rather hard to realize/simulate with
> > some other component oriented frameworks ;)
> >
> > Cheers,
> > Martin
> >
> >
> > >
> > >
> > > On Mar 9, 2009, at 7:03 AM, Martin Grotzke wrote:
> > >
> > > > On Mon, 2009-03-09 at 13:07 +0100, Martijn Dashorst wrote:
> > > >> Starts to sound like a form of premature optimization. If you are new
> > > >> to Wicket, why do you want to implement a memcached session store?
> > > >> What is the usecase?
> > > > We're starting a new project (the relaunch of a big ecommerce system)
> > > > and want to be able to scale out (just throw in new hardware when
> > > > traffic grows). Additionally we have the requirement of session
> > > > failover, both in standard operations and for deployments.
> > > >
> > > > We're discussing non-sticky vs. sticky sessions here and for non-
> > > > sticky
> > > > sessions memcached (as caching layer in addition to sessions stored
> > > > in a
> > > > database) is a good candidate, as you don't replicate the changed
> > > > session to all other nodes, but only to the primary node for this
> > > > session id. This is an important aspect for beeing able to scale out.
> > > >
> > > > Concerning non-sticky/sticky/memcached/whatever we're not decided yet,
> > > > still running in evaluation mode :)
> > > >
> > > > Cheers,
> > > > Martin
> > > >
> > > >
> > > >>
> > > >> Martijn
> > > >>
> > > >> On Mon, Mar 9, 2009 at 9:56 AM, Martin Grotzke
> > > >>  wrote:
> > > >>> On Sun, 2009-03-08 at 16

Re: memcached session store

[Martin Grotzke]

On Wed, 2009-03-11 at 09:31 -0700, Eelco Hillenius wrote: 
> > Just to be complete, even if this is not really an option for us: with
> > ONE_PASS_RENDER clustering with wicket would be fine, no further state
> > management issues, right?
> 
> Right. And there is back button support (access to older pages/
> previous renderings) to consider,
I asume you are referring to the PageMap storing versioned pages...

> which without session affinity
> you'll have to distribute throughout your cluster (though you might
> want to do that anyway to support fall over).
Right now we plan to run Wicket without a PageMap (or 0 versioned
pages), REDIRECT_TO_RENDER and only LoadableDetachableModel with all
required information in the URL. Do you think there are problems with
this approach?

Would you say REDIRECT_TO_RENDER has other disadvantages besides
fetching entities twice?

Cheers,
Martin

> 
> Eelco
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 


signature.asc
Description: This is a digitally signed message part

Re: memcached session store

[Martin Grotzke]

On Mon, 2009-03-09 at 22:54 -0700, Victor Igumnov wrote:
> Even if you have the memcached store in place, wicket still requires  
> session affinity. Wicket buffers redirect responses locally so the  
> client needs to go to the same server twice or the client will receive  
> an expired session. Wicket is a stateful framework, session affinity  
> is a must.
Are there other things (besides the buffered response when doing a
redirect-after-post with the REDIRECT_TO_BUFFER setting) that require
sticky sessions?

We'd like to use wicket in a stateless mode and defer session creation
as long as it's possible for a user. Even if wicket is made with a
statefull programming model in mind we think there are still many
advantages over other (non-component-based) frameworks. Also we need a
dynamic structure which would be rather hard to realize/simulate with
some other component oriented frameworks ;)

Cheers,
Martin


> 
> 
> On Mar 9, 2009, at 7:03 AM, Martin Grotzke wrote:
> 
> > On Mon, 2009-03-09 at 13:07 +0100, Martijn Dashorst wrote:
> >> Starts to sound like a form of premature optimization. If you are new
> >> to Wicket, why do you want to implement a memcached session store?
> >> What is the usecase?
> > We're starting a new project (the relaunch of a big ecommerce system)
> > and want to be able to scale out (just throw in new hardware when
> > traffic grows). Additionally we have the requirement of session
> > failover, both in standard operations and for deployments.
> >
> > We're discussing non-sticky vs. sticky sessions here and for non- 
> > sticky
> > sessions memcached (as caching layer in addition to sessions stored  
> > in a
> > database) is a good candidate, as you don't replicate the changed
> > session to all other nodes, but only to the primary node for this
> > session id. This is an important aspect for beeing able to scale out.
> >
> > Concerning non-sticky/sticky/memcached/whatever we're not decided yet,
> > still running in evaluation mode :)
> >
> > Cheers,
> > Martin
> >
> >
> >>
> >> Martijn
> >>
> >> On Mon, Mar 9, 2009 at 9:56 AM, Martin Grotzke
> >>  wrote:
> >>> On Sun, 2009-03-08 at 16:56 -0700, Victor Igumnov wrote:
> >>>> I wrote a memcached session manager store for jetty, that our  
> >>>> wicket
> >>>> app utilizes. Works well, except I can't open source it,
> >>>> since it was created on the company's dime ;-(
> >>> Well, most interesting things are not so simple to realize that  
> >>> one can
> >>> do it in its spare time. But the good point is that we can do such
> >>> interesting things in our job :)
> >>>
> >>>>
> >>>> Here is my opinion on memcached as a session store.
> >>>>
> >>>> Memcached will not work well as a wicket session store, due to 1mb
> >>>> size limits.
> >>> Good to know, I wasn't aware of this restriction (I still need to  
> >>> read
> >>> more about this for details). So one is forced to handle resources
> >>> eating much memory (e.g. fileupload) not via session, which is the  
> >>> case
> >>> even without this 1 mb  size limit :)
> >>>
> >>> Do you have a case where this limit is important especially for  
> >>> wicket?
> >>>
> >>>> You honestly don't want to serialize anything past 100kb
> >>>> in size due to performance reasons.
> >>> Right.
> >>>
> >>>> That said,  It works best if you
> >>>> use memcached as a container httpsessionstore with the wicket
> >>>> secondlevelcache diskpagestore. The only thing you need to  
> >>>> serialize
> >>>> is the last pagemap which should only be 50kb in size max. You  
> >>>> still
> >>>> get fail over since the last page map is distributed.
> >>> And I have to read about page maps (I'm really new to wicket as you
> >>> see :)). AFAIK page maps store a configurable numer of versioned  
> >>> pages
> >>> for back-button support and versioned pages.
> >>>
> >>>>
> >>>> One thing you need to be careful with is not referencing anything  
> >>>> that
> >>>> got stored on disk from your active pagemap, it will spiral into a
> >>>> stack overflow.
> >>>>
> >>>> https://issues.apache.org

Re: memcached session store

[Martin Grotzke]

Just to be complete, even if this is not really an option for us: with
ONE_PASS_RENDER clustering with wicket would be fine, no further state
management issues, right?

Thanx && cheers,
Martin


On Mon, 2009-03-09 at 17:15 +0100, Martijn Dashorst wrote:
> Non-sticky would be rather bad for Wicket performance/programming model.
> 
> The default of wicket is to redirect after an event to a get request
> which renders a buffered response. The buffered response is only
> available on the jvm that handled the original request. If the
> buffered response is not available, it would require rendering all
> content again, requiring fetching all entities, etc. from the
> database.
> 
> Martijn
> 
> 
> On Mon, Mar 9, 2009 at 3:03 PM, Martin Grotzke
>  wrote:
> > On Mon, 2009-03-09 at 13:07 +0100, Martijn Dashorst wrote:
> >> Starts to sound like a form of premature optimization. If you are new
> >> to Wicket, why do you want to implement a memcached session store?
> >> What is the usecase?
> > We're starting a new project (the relaunch of a big ecommerce system)
> > and want to be able to scale out (just throw in new hardware when
> > traffic grows). Additionally we have the requirement of session
> > failover, both in standard operations and for deployments.
> >
> > We're discussing non-sticky vs. sticky sessions here and for non-sticky
> > sessions memcached (as caching layer in addition to sessions stored in a
> > database) is a good candidate, as you don't replicate the changed
> > session to all other nodes, but only to the primary node for this
> > session id. This is an important aspect for beeing able to scale out.
> >
> > Concerning non-sticky/sticky/memcached/whatever we're not decided yet,
> > still running in evaluation mode :)
> >
> > Cheers,
> > Martin
> >
> >
> >>
> >> Martijn
> >>
> >> On Mon, Mar 9, 2009 at 9:56 AM, Martin Grotzke
> >>  wrote:
> >> > On Sun, 2009-03-08 at 16:56 -0700, Victor Igumnov wrote:
> >> >> I wrote a memcached session manager store for jetty, that our wicket
> >> >> app utilizes. Works well, except I can't open source it,
> >> >> since it was created on the company's dime ;-(
> >> > Well, most interesting things are not so simple to realize that one can
> >> > do it in its spare time. But the good point is that we can do such
> >> > interesting things in our job :)
> >> >
> >> >>
> >> >> Here is my opinion on memcached as a session store.
> >> >>
> >> >> Memcached will not work well as a wicket session store, due to 1mb
> >> >> size limits.
> >> > Good to know, I wasn't aware of this restriction (I still need to read
> >> > more about this for details). So one is forced to handle resources
> >> > eating much memory (e.g. fileupload) not via session, which is the case
> >> > even without this 1 mb  size limit :)
> >> >
> >> > Do you have a case where this limit is important especially for wicket?
> >> >
> >> >> You honestly don't want to serialize anything past 100kb
> >> >> in size due to performance reasons.
> >> > Right.
> >> >
> >> >> That said,  It works best if you
> >> >> use memcached as a container httpsessionstore with the wicket
> >> >> secondlevelcache diskpagestore. The only thing you need to serialize
> >> >> is the last pagemap which should only be 50kb in size max. You still
> >> >> get fail over since the last page map is distributed.
> >> > And I have to read about page maps (I'm really new to wicket as you
> >> > see :)). AFAIK page maps store a configurable numer of versioned pages
> >> > for back-button support and versioned pages.
> >> >
> >> >>
> >> >> One thing you need to be careful with is not referencing anything that
> >> >> got stored on disk from your active pagemap, it will spiral into a
> >> >> stack overflow.
> >> >>
> >> >> https://issues.apache.org/jira/browse/WICKET-2138
> >> > Thanx! We would need to setup tests to be sure that this won't happen.
> >> >
> >> > Thanx for your input,
> >> > cheers,
> >> > Martin
> >> >
> >> >
> >> >>
> >> >>
> >> >> -Victor
> >> >>
> >> >> On Mar 8, 20

Re: memcached session store

[Martin Grotzke]

On Mon, 2009-03-09 at 17:15 +0100, Martijn Dashorst wrote:
> Non-sticky would be rather bad for Wicket performance/programming model.
> 
> The default of wicket is to redirect after an event to a get request
> which renders a buffered response. The buffered response is only
> available on the jvm that handled the original request. 
Probably you are referring to IRequestCycleSettings.renderStrategy set
to REDIRECT_TO_BUFFER. This is a good point to consider, thanx!

> If the
> buffered response is not available, it would require rendering all
> content again, requiring fetching all entities, etc. from the
> database.
I asume you are referring to the REDIRECT_TO_RENDER strategy. With this
entities have to be fetched again, but rendering only should occur once
- in the GET request following the redirect. I asume that it's possible
to reduce redirect-after-post to form submits only, right?

In respect to fetching entities twice during a redirect-after-post, we'd
try to keep the session very lightweight in either way and only store
entity ids therein, so for us this wouldn't make much difference.

Are there other things to consider when using REDIRECT_TO_RENDER in
wicket?

Cheers,
Martin


> 
> Martijn
> 
> 
> On Mon, Mar 9, 2009 at 3:03 PM, Martin Grotzke
>  wrote:
> > On Mon, 2009-03-09 at 13:07 +0100, Martijn Dashorst wrote:
> >> Starts to sound like a form of premature optimization. If you are new
> >> to Wicket, why do you want to implement a memcached session store?
> >> What is the usecase?
> > We're starting a new project (the relaunch of a big ecommerce system)
> > and want to be able to scale out (just throw in new hardware when
> > traffic grows). Additionally we have the requirement of session
> > failover, both in standard operations and for deployments.
> >
> > We're discussing non-sticky vs. sticky sessions here and for non-sticky
> > sessions memcached (as caching layer in addition to sessions stored in a
> > database) is a good candidate, as you don't replicate the changed
> > session to all other nodes, but only to the primary node for this
> > session id. This is an important aspect for beeing able to scale out.
> >
> > Concerning non-sticky/sticky/memcached/whatever we're not decided yet,
> > still running in evaluation mode :)
> >
> > Cheers,
> > Martin
> >
> >
> >>
> >> Martijn
> >>
> >> On Mon, Mar 9, 2009 at 9:56 AM, Martin Grotzke
> >>  wrote:
> >> > On Sun, 2009-03-08 at 16:56 -0700, Victor Igumnov wrote:
> >> >> I wrote a memcached session manager store for jetty, that our wicket
> >> >> app utilizes. Works well, except I can't open source it,
> >> >> since it was created on the company's dime ;-(
> >> > Well, most interesting things are not so simple to realize that one can
> >> > do it in its spare time. But the good point is that we can do such
> >> > interesting things in our job :)
> >> >
> >> >>
> >> >> Here is my opinion on memcached as a session store.
> >> >>
> >> >> Memcached will not work well as a wicket session store, due to 1mb
> >> >> size limits.
> >> > Good to know, I wasn't aware of this restriction (I still need to read
> >> > more about this for details). So one is forced to handle resources
> >> > eating much memory (e.g. fileupload) not via session, which is the case
> >> > even without this 1 mb  size limit :)
> >> >
> >> > Do you have a case where this limit is important especially for wicket?
> >> >
> >> >> You honestly don't want to serialize anything past 100kb
> >> >> in size due to performance reasons.
> >> > Right.
> >> >
> >> >> That said,  It works best if you
> >> >> use memcached as a container httpsessionstore with the wicket
> >> >> secondlevelcache diskpagestore. The only thing you need to serialize
> >> >> is the last pagemap which should only be 50kb in size max. You still
> >> >> get fail over since the last page map is distributed.
> >> > And I have to read about page maps (I'm really new to wicket as you
> >> > see :)). AFAIK page maps store a configurable numer of versioned pages
> >> > for back-button support and versioned pages.
> >> >
> >> >>
> >> >> One thing you need to be careful with is not referencing anything that
> >> >> got stored on disk from your active pagemap, 

Re: memcached session store

[Martin Grotzke]

On Mon, 2009-03-09 at 13:07 +0100, Martijn Dashorst wrote:
> Starts to sound like a form of premature optimization. If you are new
> to Wicket, why do you want to implement a memcached session store?
> What is the usecase?
We're starting a new project (the relaunch of a big ecommerce system)
and want to be able to scale out (just throw in new hardware when
traffic grows). Additionally we have the requirement of session
failover, both in standard operations and for deployments.

We're discussing non-sticky vs. sticky sessions here and for non-sticky
sessions memcached (as caching layer in addition to sessions stored in a
database) is a good candidate, as you don't replicate the changed
session to all other nodes, but only to the primary node for this
session id. This is an important aspect for beeing able to scale out.

Concerning non-sticky/sticky/memcached/whatever we're not decided yet,
still running in evaluation mode :)

Cheers,
Martin


> 
> Martijn
> 
> On Mon, Mar 9, 2009 at 9:56 AM, Martin Grotzke
>  wrote:
> > On Sun, 2009-03-08 at 16:56 -0700, Victor Igumnov wrote:
> >> I wrote a memcached session manager store for jetty, that our wicket
> >> app utilizes. Works well, except I can't open source it,
> >> since it was created on the company's dime ;-(
> > Well, most interesting things are not so simple to realize that one can
> > do it in its spare time. But the good point is that we can do such
> > interesting things in our job :)
> >
> >>
> >> Here is my opinion on memcached as a session store.
> >>
> >> Memcached will not work well as a wicket session store, due to 1mb
> >> size limits.
> > Good to know, I wasn't aware of this restriction (I still need to read
> > more about this for details). So one is forced to handle resources
> > eating much memory (e.g. fileupload) not via session, which is the case
> > even without this 1 mb  size limit :)
> >
> > Do you have a case where this limit is important especially for wicket?
> >
> >> You honestly don't want to serialize anything past 100kb
> >> in size due to performance reasons.
> > Right.
> >
> >> That said,  It works best if you
> >> use memcached as a container httpsessionstore with the wicket
> >> secondlevelcache diskpagestore. The only thing you need to serialize
> >> is the last pagemap which should only be 50kb in size max. You still
> >> get fail over since the last page map is distributed.
> > And I have to read about page maps (I'm really new to wicket as you
> > see :)). AFAIK page maps store a configurable numer of versioned pages
> > for back-button support and versioned pages.
> >
> >>
> >> One thing you need to be careful with is not referencing anything that
> >> got stored on disk from your active pagemap, it will spiral into a
> >> stack overflow.
> >>
> >> https://issues.apache.org/jira/browse/WICKET-2138
> > Thanx! We would need to setup tests to be sure that this won't happen.
> >
> > Thanx for your input,
> > cheers,
> > Martin
> >
> >
> >>
> >>
> >> -Victor
> >>
> >> On Mar 8, 2009, at 3:25 PM, Martijn Dashorst wrote:
> >>
> >> > You can check the TIM integration work from the Terracotta guys. That
> >> > should make things easier, and you could even try it out, perhaps
> >> > saving a memcached implementation completely :)
> >> >
> >> > Martijn
> >> >
> >> > On Sun, Mar 8, 2009 at 11:01 PM, Martin Grotzke
> >> >  wrote:
> >> >> Hi,
> >> >>
> >> >> we're just thinking about a session store using memcached. I just
> >> >> want
> >> >> to ask if somebody already implemented this (and wants to share)
> >> >> before
> >> >> we implement this.
> >> >>
> >> >> Btw, is there some documentation about ISessionStore semantics, in
> >> >> addition to javadocs? I would be interested in the order in which the
> >> >> different methods would be invoked.
> >> >>
> >> >> Thanx && cheers,
> >> >> Martin
> >> >>
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > 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
> >> >
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >>
> >
> 
> 
> 


signature.asc
Description: This is a digitally signed message part

Re: memcached session store

[Martin Grotzke]

On Sun, 2009-03-08 at 16:56 -0700, Victor Igumnov wrote:
> I wrote a memcached session manager store for jetty, that our wicket  
> app utilizes. Works well, except I can't open source it,
> since it was created on the company's dime ;-(
Well, most interesting things are not so simple to realize that one can
do it in its spare time. But the good point is that we can do such
interesting things in our job :)

> 
> Here is my opinion on memcached as a session store.
> 
> Memcached will not work well as a wicket session store, due to 1mb  
> size limits. 
Good to know, I wasn't aware of this restriction (I still need to read
more about this for details). So one is forced to handle resources
eating much memory (e.g. fileupload) not via session, which is the case
even without this 1 mb  size limit :)

Do you have a case where this limit is important especially for wicket?

> You honestly don't want to serialize anything past 100kb  
> in size due to performance reasons. 
Right.

> That said,  It works best if you  
> use memcached as a container httpsessionstore with the wicket  
> secondlevelcache diskpagestore. The only thing you need to serialize  
> is the last pagemap which should only be 50kb in size max. You still  
> get fail over since the last page map is distributed.
And I have to read about page maps (I'm really new to wicket as you
see :)). AFAIK page maps store a configurable numer of versioned pages
for back-button support and versioned pages.

> 
> One thing you need to be careful with is not referencing anything that  
> got stored on disk from your active pagemap, it will spiral into a  
> stack overflow.
> 
> https://issues.apache.org/jira/browse/WICKET-2138
Thanx! We would need to setup tests to be sure that this won't happen.

Thanx for your input,
cheers,
Martin


> 
> 
> -Victor
> 
> On Mar 8, 2009, at 3:25 PM, Martijn Dashorst wrote:
> 
> > You can check the TIM integration work from the Terracotta guys. That
> > should make things easier, and you could even try it out, perhaps
> > saving a memcached implementation completely :)
> >
> > Martijn
> >
> > On Sun, Mar 8, 2009 at 11:01 PM, Martin Grotzke
> >  wrote:
> >> Hi,
> >>
> >> we're just thinking about a session store using memcached. I just  
> >> want
> >> to ask if somebody already implemented this (and wants to share)  
> >> before
> >> we implement this.
> >>
> >> Btw, is there some documentation about ISessionStore semantics, in
> >> addition to javadocs? I would be interested in the order in which the
> >> different methods would be invoked.
> >>
> >> Thanx && cheers,
> >> Martin
> >>
> >>
> >
> >
> >
> > -- 
> > 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
> >
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
> 


signature.asc
Description: This is a digitally signed message part

Re: memcached session store

[Martin Grotzke]

Hi,

sounds interesting. What would you say are the advantages of terracotta
over memcached? I'd say in terms of scalability terracotty has the same
disadvantages like local (in-jvm) caches - replication has to be done to
all other nodes.

Thanx for your thoughts,
cheers,
Martin


On Sun, 2009-03-08 at 23:25 +0100, Martijn Dashorst wrote:
> You can check the TIM integration work from the Terracotta guys. That
> should make things easier, and you could even try it out, perhaps
> saving a memcached implementation completely :)
> 
> Martijn
> 
> On Sun, Mar 8, 2009 at 11:01 PM, Martin Grotzke
>  wrote:
> > Hi,
> >
> > we're just thinking about a session store using memcached. I just want
> > to ask if somebody already implemented this (and wants to share) before
> > we implement this.
> >
> > Btw, is there some documentation about ISessionStore semantics, in
> > addition to javadocs? I would be interested in the order in which the
> > different methods would be invoked.
> >
> > Thanx && cheers,
> > Martin
> >
> >
> 
> 
> 


signature.asc
Description: This is a digitally signed message part

memcached session store

[Martin Grotzke]

Hi,

we're just thinking about a session store using memcached. I just want
to ask if somebody already implemented this (and wants to share) before
we implement this.

Btw, is there some documentation about ISessionStore semantics, in
addition to javadocs? I would be interested in the order in which the
different methods would be invoked.

Thanx && cheers,
Martin



signature.asc
Description: This is a digitally signed message part