Re: Best practice for session handling - high availability
I mean, don't get me wrong. I'm in favour of session stickiness and I can't understand why this is not preferred. But anyway. If we have aTCP load-balancer that switches on a timely basis every 200ms then session replication doesn't really work, or? -- Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Best practice for session handling - high availability
Thanks for you reply. I'm wondering to what extend saving the session and session replication will really work if the load-balancer really switches x times per second on a request with various JavaScript lazy load requests. So the session replication must be blazingly fast. Can Ignite really do that? Regards, Manfred Andrea Del Bene-3 wrote > Hi, > > session is something that lives on server side, so there's no chance to > persist it on client. Besides, client solutions like cookies and > localStorage have size limits. What you should try to do is to adopt a > third solution that makes session clustering possible without needing > stickiness. > For example Apache Ignite: > > https://apacheignite-mix.readme.io/docs/web-session-clustering > > If you go for such kind of solution you should also choose to save page > instances directly into HttpSession, so everything can be cached into > Ignite: > > https://ci.apache.org/projects/wicket/guide/8.x/single.html#_httpsessiondatastore > > On Wed, Jul 3, 2019 at 11:15 AM Bergmann Manfred < > mb@ > > > wrote: > >> Hi. >> >> I know a few points, like using LoadableDetachableModel’s to keep session >> size low. >> As it has to be replicated in some way between server nodes in a cluster, >> or stored in a database. >> Session stickiness is probably how most deployments work. >> >> But what about offloading the session into one or more cookies (which are >> encrypted) and such. >> Is that something that is actually being done in practice? >> It basically would not require session replication in the background and >> could work without session stickiness. >> >> Session size. In middle sized web applications with a JavaScript enabled >> components. >> Or actually generally, what is a session size that is ideal, or good to >> replicate? >> >> What is your experience? >> >> >> >> Regards, >> Manfred >> >> >> - >> To unsubscribe, e-mail: > users-unsubscribe@.apache >> For additional commands, e-mail: > users-help@.apache >> >> > > -- > Andrea Del Bene. > Apache Wicket committer. -- Sent from: http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Best practice for session handling - high availability
Hi, session is something that lives on server side, so there's no chance to persist it on client. Besides, client solutions like cookies and localStorage have size limits. What you should try to do is to adopt a third solution that makes session clustering possible without needing stickiness. For example Apache Ignite: https://apacheignite-mix.readme.io/docs/web-session-clustering If you go for such kind of solution you should also choose to save page instances directly into HttpSession, so everything can be cached into Ignite: https://ci.apache.org/projects/wicket/guide/8.x/single.html#_httpsessiondatastore On Wed, Jul 3, 2019 at 11:15 AM Bergmann Manfred wrote: > Hi. > > I know a few points, like using LoadableDetachableModel’s to keep session > size low. > As it has to be replicated in some way between server nodes in a cluster, > or stored in a database. > Session stickiness is probably how most deployments work. > > But what about offloading the session into one or more cookies (which are > encrypted) and such. > Is that something that is actually being done in practice? > It basically would not require session replication in the background and > could work without session stickiness. > > Session size. In middle sized web applications with a JavaScript enabled > components. > Or actually generally, what is a session size that is ideal, or good to > replicate? > > What is your experience? > > > > Regards, > Manfred > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Andrea Del Bene. Apache Wicket committer.
Best practice for session handling - high availability
Hi. I know a few points, like using LoadableDetachableModel’s to keep session size low. As it has to be replicated in some way between server nodes in a cluster, or stored in a database. Session stickiness is probably how most deployments work. But what about offloading the session into one or more cookies (which are encrypted) and such. Is that something that is actually being done in practice? It basically would not require session replication in the background and could work without session stickiness. Session size. In middle sized web applications with a JavaScript enabled components. Or actually generally, what is a session size that is ideal, or good to replicate? What is your experience? Regards, Manfred - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: WebSockets and Page serialization, oddity.
On Tue, 2 Jul 2019 at 16:00, Martin Grigorov wrote:
> Hi,
>
> Here are the logs:
>
> [qtp1722023916-27] INFO com.mycompany.StartWebSocketPage - onClose
> [Wicket-AsyncPageStore-PageSavingThread] INFO
> com.mycompany.WicketApplication - ===serialize class
> com.mycompany.StartWebSocketPage 0
> [qtp1722023916-16] INFO com.mycompany.WicketApplication - ---deserialize
> class com.mycompany.BackgroundWorkPage 1
> [qtp1722023916-16] INFO com.mycompany.BackgroundWorkPage - onEvent other
> org.apache.wicket.protocol.ws.api.event.WebSocketConnectedPayload@232150f0
> [qtp1722023916-16] INFO com.mycompany.BackgroundWorkPage - onConnect
> [qtp1722023916-16] INFO com.mycompany.BackgroundWorkPage - Broadcasting
> com.mycompany.pushmessages.WebSocketConnected@d0ec7a9
> [qtp1722023916-16] INFO com.mycompany.WicketApplication - ---deserialize
> class com.mycompany.BackgroundWorkPage 1
> [qtp1722023916-16] INFO com.mycompany.BackgroundWorkPage - onEvent
> websocketpushpayload
> [qtp1722023916-16] INFO com.mycompany.BackgroundWorkPage -
> onWebSocketMessage: class com.mycompany.BackgroundWorkPage,
> com.mycompany.pushmessages.WebSocketConnected@d0ec7a9
> [qtp1722023916-16] INFO com.mycompany.BackgroundWorkPage - received
> WebSocketConnected
>
> The problem is in WebSocketPage#onInitialize():
>
> add(new WebSocketBehavior() {
>
> @Override
> protected void onConnect(ConnectedMessage message) {
> super.onConnect(message);
> log.info("onConnect");
>
> connectedMessage = message;
> broadcast(new WebSocketConnected());
> }
>
> broadcast() uses new
> WebSocketPushBroadcaster(webSocketSettings.getConnectionRegistry()) to
> broadcast the event.
> But since the caller is #onInitialize() the current page instance is not
> yet saved into the page store and the registry loads the previous version
> of BackgroundWorkPage id=1 (the one stored by AjaxLink#onClick() call to
> setResponsePage()).
> So the looked up page instance by WebSocket's connection registry does not
> see the new state (connectedMessage)
>
>
> Below is a diff with the changes I've made locally to debug it:
>
> diff --git pom.xml pom.xml
> index b49937f..202d6f2 100644
> --- pom.xml
> +++ pom.xml
> @@ -41,7 +41,7 @@
>
>
>
> - 8.5.0
> + 8.6.0-SNAPSHOT
>9.4.18.v20190429
>1.7.26
>4.12
> @@ -63,13 +63,6 @@
>${wicket.version}
>
> -
> - org.apache.wicket
> - wicket-native-websocket-core
> - ${wicket.version}
> -
> -
> -
>
>
>
>
> diff --git src/main/java/com/mycompany/BackgroundWorkPage.java
> src/main/java/com/mycompany/BackgroundWorkPage.java
> index 76d84be..4bd7b84 100644
> --- src/main/java/com/mycompany/BackgroundWorkPage.java
> +++ src/main/java/com/mycompany/BackgroundWorkPage.java
> @@ -23,7 +23,6 @@ public class BackgroundWorkPage extends WebSocketPage {
> super(parameters);
> }
> -
> @Override
> protected void onInitialize() {
> super.onInitialize();
> @@ -61,7 +60,7 @@ public class BackgroundWorkPage extends WebSocketPage {
> });
> future.exceptionally(ex->{
> - log.error("big caclulation failed", ex);
> + log.error("big calculation failed", ex);
> return null;
> });
> diff --git src/main/java/com/mycompany/StartWebSocketPage.java
> src/main/java/com/mycompany/StartWebSocketPage.java
> index 56d1a99..5d1d9f6 100644
> --- src/main/java/com/mycompany/StartWebSocketPage.java
> +++ src/main/java/com/mycompany/StartWebSocketPage.java
> @@ -1,12 +1,10 @@
> package com.mycompany;
> import com.mycompany.pushmessages.WebSocketConnected;
> -import org.apache.wicket.Component;
> -import org.apache.wicket.Page;
> +
> import org.apache.wicket.ajax.AjaxRequestTarget;
> import org.apache.wicket.ajax.markup.html.AjaxLink;
> import org.apache.wicket.markup.html.link.BookmarkablePageLink;
> -import org.apache.wicket.model.Model;
> import org.apache.wicket.protocol.ws.api.WebSocketRequestHandler;
> import org.apache.wicket.protocol.ws.api.message.IWebSocketPushMessage;
> import org.apache.wicket.request.mapper.parameter.PageParameters;
> @@ -39,7 +37,7 @@ public class StartWebSocketPage extends WebSocketPage {
> setEnabled(isWebSocketConnected());
> }
> };
> - btn.setOutputMarkupId(true);
> + btn.setOutputMarkupPlaceholderTag(true);
> add(btn);
> @@ -50,7 +48,7 @@ public class StartWebSocketPage extends WebSocketPage {
> setEnabled(isWebSocketConnected());
> }
> };
> - worksBtn.setOutputMarkupId(true);
> + worksBtn.setOutputMarkupPlaceholderTag(true);
> add(worksBtn);
> }
> diff --git src/main/java/com/mycompany/WebSocketPage.java
> src/main/java/com/mycompany/WebSocketPage.java
> index bdcb47b..f6118fe 100644
> --- src/main/java/com/mycompany/WebSocketPage.java
> +++ src/main/java/com/mycompany/WebSocketPage.java
> @@ -16,7 +16,7 @@ import org.slf4j.LoggerFactory;
> public class WebSocketPage extends WebPage {
> - static Logger log = LoggerFactory.getLogger(WebSocketPage.class);
> + Logger log = LoggerFactory.getLogger
