Re: Possible memory leak with Tomcat?
Hi Sven,
I'm having trouble replicating locally. We just saw it in production and
then had to roll back as it was effecting customers. The log is full of
these:
May 16, 2019 6:39:39 AM org.apache.catalina.session.StandardSession
setAttribute
SEVERE: Session binding event listener threw exception
java.lang.NullPointerException
at
org.apache.wicket.page.PageStoreManager$SessionEntry.clear(PageStoreManager.java:351)
at
org.apache.wicket.page.PageStoreManager$SessionEntry.valueUnbound(PageStoreManager.java:340)
at
org.apache.catalina.session.StandardSession.setAttribute(StandardSession.java:1496)
at
org.redisson.tomcat.RedissonSession.superSetAttribute(RedissonSession.java:257)
at
org.redisson.tomcat.RedissonSessionManager$2.onMessage(RedissonSessionManager.java:284)
at
org.redisson.tomcat.RedissonSessionManager$2.onMessage(RedissonSessionManager.java:251)
at
org.redisson.PubSubMessageListener.onMessage(PubSubMessageListener.java:79)
at
org.redisson.client.RedisPubSubConnection.onMessage(RedisPubSubConnection.java:78)
at
org.redisson.client.handler.CommandPubSubDecoder.lambda$enqueueMessage$0(CommandPubSubDecoder.java:184)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.lang.Thread.run(Thread.java:745)
Then about 2 hours later a huge number of these started to appear in the
logs:
2019-05-16 08:52:47,851 ERROR - Wicket-PageSavingThread
org.apache.wicket.pageStore.DiskDataStore$SessionEntry.getFileChannel(DiskDataStore.java:434)
434 DiskDataStore -
/ec/var/tomcat/gc1/work2/ROOT/wicket.hub-filestore/5168/1931/547BB9E7E255B16D5B2864F42B4F9C28.gc1/data
(No such file or directory)
java.io.FileNotFoundException:
/ec/var/tomcat/gc1/work2/ROOT/wicket.hub-filestore/5168/1931/547BB9E7E255B16D5B2864F42B4F9C28.gc1/data
(No such file or directory)
at java.io.RandomAccessFile.open0(Native Method)
at java.io.RandomAccessFile.open(RandomAccessFile.java:316)
at java.io.RandomAccessFile.(RandomAccessFile.java:243)
at
org.apache.wicket.pageStore.DiskDataStore$SessionEntry.getFileChannel(DiskDataStore.java:428)
at
org.apache.wicket.pageStore.DiskDataStore$SessionEntry.savePage(DiskDataStore.java:346)
at
org.apache.wicket.pageStore.DiskDataStore.storeData(DiskDataStore.java:185)
at
org.apache.wicket.pageStore.AsynchronousDataStore$PageSavingRunnable.run(AsynchronousDataStore.java:355)
at java.lang.Thread.run(Thread.java:745)
Whats odd is that it effected some user but not others at all. When we
rollback to 7.8.0 these go away. I'm not sure how I'm going to get the the
bottom of this
On Fri, May 17, 2019 at 11:03 PM Sven Meier wrote:
> Hi,
>
> WICKET-6564 was about applications explicitly calling #clear() on the
> PageStoreManager.
> This doesn't has anything to do with session expiration.
>
> Could you please explain what issues you're facing? A quickstart would
> be perfect, or at least some explanations how we're able to reproduce
> the problem.
>
> Regards
> Sven
>
>
> Am 17.05.19 um 13:23 schrieb Wayne W:
> > Hello Sven,
> >
> > the fix you did for WICKET-6564 (
> >
> https://git-wip-us.apache.org/repos/asf?p=wicket.git;a=commitdiff;h=7665dc5;hp=3a1602d308a366e00948dbf91dbd96bc40cae167
> )
> > doesn't work for us. Its causing lots of issues. We use redisson for
> > managing our sessions in tomcat, so that we can failover without loosing
> > user session.
> >
> > When a session attribute is updated redisson calls setAttribute on the
> > session. Looking at the code for
> > org.apache.catalina.session.StandardSession.setAttribute I see:
> >
> > // Replace or add this attribute
> >
> > Object unbound = attributes.put(name, value);
> >
> >
> > // Call the valueUnbound() method if necessary
> >
> > *if* (notify && (unbound != *null*) && (unbound != value) &&
> >
> > (unbound *instanceof* HttpSessionBindingListener)) {
> >
> > *try* {
> >
> > ((HttpSessionBindingListener) unbound).valueUnbound
> >
> > (*new* HttpSessionBindingEvent(getSession(), name));
> >
> > } *catch* (Throwable t) {
> >
> > ExceptionUtils.*handleThrowable*(t);
> >
> > manager.getContext().getLogger().error
> >
> > (*sm*.getString("standardSession.bindingEvent"), t);
> >
> > }
> >
> > }
> >
> > The valueUnbound is call to notify the object its no longer in the
> session.
> > However looking at the change you did for
> > PageStoreManager.valueUnbound its actually
> > removing the session by calling clear()
> >
> > Doesn't seem correct?? or am I missing something?
> >
> >
> >
> > On Fri, May 10, 2019 at 1:43 PM Wayne W
> wrote:
> >
> >> Thanks Sven.
> >>
> >> On Thu, May 9, 2019 at 8:24 PM Sven Meier wrote:
> >>
> >>> Hi,
> >>>
> >>> we've had two
Re: Kendo window adds up in DOM
Hi Manfred, Are you using a FormWindow? Because it is designed to prevent this behavior. https://github.com/sebfz1/wicket-jquery-ui/blob/wicket8.x/wicket-kendo-ui/src/main/java/com/googlecode/wicket/kendo/ui/widget/window/FormWindow.java#L192 Otherwise please create a quickstart so I can have a better look... Thanks in advance, Sebastien. On Mon, May 20, 2019 at 4:13 PM Bergmann Manfred wrote: > Hi. > > I have the following problem. > We have a Kendo `Window` which we use as confirmation window with form and > checkbox. > After the first successful submit (checkbox verification OK) of the window > form any new spawned window submits ‚value=on‘ even though the checkbox is > not ‚checked‘. > > The window is part of an inner container that is part of an outer > container. > The outer container creates new inner containers depending on a navigation. > So basically a new window is created each time for the same WicketId. > > What appears to happen is that whenever an inner container is created that > contains a window, a new window is added in the DOM, under body. > Any previous window is not removed. > > I have tried to create a stripped down version of this in a simple page > but can’t reproduce the issue there. > In this stipped down version the windows are removed from DOM. > > I’m assuming (couldn’t really verify this yet) that after a successful > submit (checkbox checked) some listeners are not completely cleaned up and > a new window uses some old data, or the OK button of the new Window > actually triggers a listener of some old window which contained the checked > checkbox, hence the ‚value=on‘ is transmitted. > > After a browser ‚refresh‘ this behavior is gone and a new window works > properly, once. > > > Anyone has an idea about what happens here? > > > > Regards, > Manfred > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
AW: Wicket DropDown Change event
Hi,
use "change" instead of "onchange".
dropdown.add(new AjaxFormComponentUpdatingBehavior("change") {
This works for me on Wicket 8.4.0
Greetings Matthias
-Ursprüngliche Nachricht-
Von: Sibgha Nazir
Gesendet: Montag, 20. Mai 2019 16:14
An: users@wicket.apache.org
Betreff: Wicket DropDown Change event
Hi,
I am not able to trigger the on change event of the drop down in the wicket.
In the class DPanel,java, I am simply trying to print on the console when the
change event has occured.
dropdown.add(*new* AjaxFormComponentUpdatingBehavior("onchange") {
/**
*
*/
*private* *static* *final* *long* *serialVersionUID* =
-6744838136235652577L;
*protected* *void* onUpdate(AjaxRequestTarget target) {
System.*out*.println("Changed");
}
});
Need Help. Following is my quick start application.
https://github.com/Sibgha360/dropdownexample.git
Thanks
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket DropDown Change event
Look at OnChangeAjaxBehavior
On Mon, May 20, 2019 at 4:13 PM Sibgha Nazir wrote:
> Hi,
>
> I am not able to trigger the on change event of the drop down in the
> wicket.
>
> In the class DPanel,java, I am simply trying to print on the console when
> the change event has occured.
>
> dropdown.add(*new* AjaxFormComponentUpdatingBehavior("onchange") {
>
> /**
>
> *
>
> */
>
> *private* *static* *final* *long* *serialVersionUID* =
> -6744838136235652577L;
>
>
> *protected* *void* onUpdate(AjaxRequestTarget target) {
>
> System.*out*.println("Changed");
>
>
> }
>
> });
>
> Need Help. Following is my quick start application.
> https://github.com/Sibgha360/dropdownexample.git
>
> Thanks
>
--
Regards - Ernesto Reinaldo Barreiro
Wicket DropDown Change event
Hi,
I am not able to trigger the on change event of the drop down in the
wicket.
In the class DPanel,java, I am simply trying to print on the console when
the change event has occured.
dropdown.add(*new* AjaxFormComponentUpdatingBehavior("onchange") {
/**
*
*/
*private* *static* *final* *long* *serialVersionUID* =
-6744838136235652577L;
*protected* *void* onUpdate(AjaxRequestTarget target) {
System.*out*.println("Changed");
}
});
Need Help. Following is my quick start application.
https://github.com/Sibgha360/dropdownexample.git
Thanks
Kendo window adds up in DOM
Hi. I have the following problem. We have a Kendo `Window` which we use as confirmation window with form and checkbox. After the first successful submit (checkbox verification OK) of the window form any new spawned window submits ‚value=on‘ even though the checkbox is not ‚checked‘. The window is part of an inner container that is part of an outer container. The outer container creates new inner containers depending on a navigation. So basically a new window is created each time for the same WicketId. What appears to happen is that whenever an inner container is created that contains a window, a new window is added in the DOM, under body. Any previous window is not removed. I have tried to create a stripped down version of this in a simple page but can’t reproduce the issue there. In this stipped down version the windows are removed from DOM. I’m assuming (couldn’t really verify this yet) that after a successful submit (checkbox checked) some listeners are not completely cleaned up and a new window uses some old data, or the OK button of the new Window actually triggers a listener of some old window which contained the checked checkbox, hence the ‚value=on‘ is transmitted. After a browser ‚refresh‘ this behavior is gone and a new window works properly, once. Anyone has an idea about what happens here? Regards, Manfred - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
