On Thu, Apr 13, 2017 at 12:27 AM, Wayne W
wrote:
> Hi Martin,
>
> Ok I've opened a ticket. I did some more debugging and I've described it to
> the best of my understanding. I could try and make a patch but its complex
> code and I don't want to mess anything up!! - not very confident with
> Wick
Hi Martin,
Ok I've opened a ticket. I did some more debugging and I've described it to
the best of my understanding. I could try and make a patch but its complex
code and I don't want to mess anything up!! - not very confident with
Wicket.
https://issues.apache.org/jira/browse/WICKET-6356
thanks
Hi,
On Thu, Mar 30, 2017 at 11:21 PM, Wayne W
wrote:
> Please ignore my last email I have done a lot more debugging and I *think*
> I understand why replication does not work for us:
>
>
> Whenever a stateful pages is used (touched) the SessionEntry is updated,
> > i.e. the page is put into it.
Please ignore my last email I have done a lot more debugging and I *think*
I understand why replication does not work for us:
Whenever a stateful pages is used (touched) the SessionEntry is updated,
> i.e. the page is put into it.
> The SessionEntry is stored as an attribute in the HTTP Session.
On Thu, Mar 30, 2017 at 4:09 PM, Martin Grigorov
wrote:
>
>
> Whenever a stateful pages is used (touched) the SessionEntry is updated,
> i.e. the page is put into it.
>
Yes I can see that happening in PageStoreManager.storeTouchedPages()
> The SessionEntry is stored as an attribute in the HTTP
On Thu, Mar 30, 2017 at 5:00 PM, Wayne W
wrote:
> Hi Martin,
>
> yes we are on 6. I've just spent the day upgrading to 7 and got it running
> ok. I've been debugging and I'm confused to one aspect:
>
> The PageManager is stored in the Application. The page manger has the
> RequestAdaptor/PageStor
Hi Martin,
yes we are on 6. I've just spent the day upgrading to 7 and got it running
ok. I've been debugging and I'm confused to one aspect:
The PageManager is stored in the Application. The page manger has the
RequestAdaptor/PageStoreManager stored within that holds the pages and
components. I
Hi,
Did you mention already which version of Wicket you use ?
There was an improvement related to reusing the page parameters when
constructing a new page instance in 7.0.0.
I have the feeling you are using 6.x. Am I correct ?
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtg
Hello Martin,
so I've been trying to still get to the bottom of this days later. So my
understanding is getting better and it appears that the session itself is
replicated fine. However I've tracked my issue down to the following:
- If I have a page that has 2 links at the top. Link A is a Bookma
Hi,
On Fri, Mar 24, 2017 at 1:31 PM, Wayne W
wrote:
> Thanks Martin,
>
> I have a theory what this is, perhaps you could confirm?
>
> What I observe is the following with the replication: If I visit page A and
> then visit page B, then kill the instance I am on the session is
> successfully fail
Thanks Martin,
I have a theory what this is, perhaps you could confirm?
What I observe is the following with the replication: If I visit page A and
then visit page B, then kill the instance I am on the session is
successfully failed over to the other node. Now I'm still looking at page B
in the b
Hi,
Once the http session is replicated this method should be executed on the
node that did not process the request
org.apache.wicket.page.PageStoreManager.SessionEntry#readObject().
Here Wicket will either store the page(s) on the disk or will schedule them
for storing.
There is no much usage of
If I put the AbstractDefaultAjaxBehavior back in, it always fails. If I
remove the AbstractDefaultAjaxBehavior most of the time it works, but every
now and then it fails to replicate. Its really inconsistent.
I have no idea how to get to the bottom of this. Any pointers or help is
much appreciated
So it seems the homepage is not the only page. However removing the
AbstractDefaultAjaxBehavior
makes no difference I still get the same issues. Just don;t know where to
start with this one. Is there a way I can turn on the logging around
replication in wicket?
On Thu, Mar 23, 2017 at 4:27 PM, Way
Hi Martin,
no - I still get the ComponentNotFoundException in the new instance. :-/
On Thu, Mar 23, 2017 at 3:57 PM, Martin Grigorov
wrote:
> Hi,
>
> On Thu, Mar 23, 2017 at 4:20 PM, Wayne W
> wrote:
>
> > Hi Martin,
> >
> > that was a typo on my part. I've been doing a lot more testing before
Hi,
On Thu, Mar 23, 2017 at 4:20 PM, Wayne W
wrote:
> Hi Martin,
>
> that was a typo on my part. I've been doing a lot more testing before I
> replied to make sure things are as I say. This is what I am observing:
>
>
>- I have a 2 node tomcat cluster setup with apache balancing between
>
Hi Martin,
that was a typo on my part. I've been doing a lot more testing before I
replied to make sure things are as I say. This is what I am observing:
- I have a 2 node tomcat cluster setup with apache balancing between
them locally on my machine.
- Testing with a very simple Wicket
Hi,
"I can stop one of the instances and I'm not logged in"
This statement says that you don't really have a properly configured
failover.
If those two Tomcat instances are in a cluster then the http sessions
should be replicated and you should stay logged in no matter which one is
serving the req
18 matches
Mail list logo