Re: Possible memory leak with Tomcat?

2019-05-17 Thread Sven Meier

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 fixed related to page stores (WICKET-6457, WICKET-6564) so
please upgrade to 7.13.0 first.

Have fun
Sven


Am 09.05.19 um 21:10 schrieb Wayne W:

Hi,

I've take a memory dump of one of our production instances and I'm

seeing

about 500MB of memory consumed just by the DiskDataStore which doesn't

seem

correct to me. Here is a screen shot:


https://customerservices.glasscubes.com/share/s/qmvnvrdtm36amme6sdrqg4dp2g

I've highlighted the item - 524,288 items doesn't seem correct for ~500
http sessions?. It seems to me that removeData(*final* String

sessionId) is

probably not being called and clearing up the sessionEntryMap. Looking

at

the call hierarchy I can see how Jetty calls it but I cannot see how

tomcat

is calling it.

Any ideas whats happening?
Wicket 7.8.0, Tomcat 8.0.32

Thanks


-
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



Re: Possible memory leak with Tomcat?

2019-05-17 Thread 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 fixed related to page stores (WICKET-6457, WICKET-6564) so
>> please upgrade to 7.13.0 first.
>>
>> Have fun
>> Sven
>>
>>
>> Am 09.05.19 um 21:10 schrieb Wayne W:
>> > Hi,
>> >
>> > I've take a memory dump of one of our production instances and I'm
>> seeing
>> > about 500MB of memory consumed just by the DiskDataStore which doesn't
>> seem
>> > correct to me. Here is a screen shot:
>> >
>> https://customerservices.glasscubes.com/share/s/qmvnvrdtm36amme6sdrqg4dp2g
>> >
>> > I've highlighted the item - 524,288 items doesn't seem correct for ~500
>> > http sessions?. It seems to me that removeData(*final* String
>> sessionId) is
>> > probably not being called and clearing up the sessionEntryMap. Looking
>> at
>> > the call hierarchy I can see how Jetty calls it but I cannot see how
>> tomcat
>> > is calling it.
>> >
>> > Any ideas whats happening?
>> > Wicket 7.8.0, Tomcat 8.0.32
>> >
>> > Thanks
>> >
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
>> For additional commands, e-mail: users-h...@wicket.apache.org
>>
>>


Travel Assistance for ApacheCon NA Las Vegas 2019 now open.

2019-05-17 Thread Maxim Solodovnik
The Travel Assistance Committee (TAC) are pleased to announce that travel
assistance applications for ApacheCon NA 2019 are now open!

We will be supporting ApacheCon NA Las Vegas, Nevada on 9th - 12th
September 2019

 TAC exists to help those that would like to attend ApacheCon events, but
are unable to do so for financial reasons.
For more info on this years applications and qualifying criteria, please
visit the TAC website at < http://www.apache.org/travel/ <
http://www.apache.org/travel/> >. Applications opened today and will close
around the 21st June.

Important: Applications close on June 21st, 2019. Applicants have until the
closing date above to submit their applications (which should contain as
much supporting material as required to efficiently and accurately process
their request), this will enable TAC to announce successful awards shortly
afterwards.

As usual, TAC expects to deal with a range of applications from a diverse
range of backgrounds. We therefore encourage (as always) anyone thinking
about sending in an application to do so ASAP.
We look forward to greeting many of you in Las Vegas!

Kind Regards,
Gavin - (On behalf of the Travel Assistance Committee)

-- 
WBR
Maxim aka solomax