gt;>>
>>>> Hi Leonardo,
>>>>
>>>> writing you since you are MyFaces core project lead and want to ask about
>>>> a possible issue in MyFaces 2.2.10 regarding not released viewscope beans.
>>>>
>>>> I have seen on Internet that there was mu
t that there was multiple such issues reported for
>> mojarra&myfaces in the past and Red Hat did some fix in their EAP 6.1.1 or
>> so (in the mojarra module) to solve this issue.
>>
>> Problem for us is that we came from using tomcat and went on top of Red
>> Hat E
n their EAP 6.1.1 or
> so (in the mojarra module) to solve this issue.
>
> Problem for us is that we came from using tomcat and went on top of Red
> Hat EAP with JBossWeb and wanted to keep MyFaces (since it provided us with
> best performance and configuration options) but we are hit by
ng.ThreadLocal] (value
>> [java.lang.ThreadLocal@1529c06]) and a value of type
>> [org.apache.myfaces.context.servlet.ServletExternalContextImpl] (value
>> [org.apache.myfaces.context.servlet.ServletExternalContextImpl@fd6c78])
>> but failed to remove it when the web application was stopped. Threads
>> are going to b
ewed over time to try and avoid a probable memory
> leak.
>
> Message is repeated several times. The more I use the JSF application,
> the more messages I see.
>
> Is there a way how can I fix it?
>
> Thanks,
> Regards
> Pavel
Hi,
I did, but I didn't find anything about ThreadLocal and
ServletExternalContextImpl.
Tomcat's memory leak protection is described at
http://wiki.apache.org/tomcat/MemoryLeakProtection and code is at
http://svn.apache.org/repos/asf/tomcat/tc7.0.x/trunk/java/org/apache/catal
Hello,
I always have the same and I can't say I see any memory leak anymore.
Even after weeks of intensive running the memory does not increase.
I vaguely remember that it is no issue. Did you search StackExchange?
MAG,
Milo
On Thu, 2012-07-12 at 21:26 +0200, Pavel Arnošt wrote:
> Hi
renewed over time to try and avoid a probable memory
leak.
Message is repeated several times. The more I use the JSF application,
the more messages I see.
Is there a way how can I fix it?
Thanks,
Regards
Pavel
Sorry, the reason of memory leak is not the Orchestra.
The incorrect configuration of second level Hibernate cache is the reason: i
use it to cache the entities with composite id. Such a composite id keeps
the references to a huge object tree.
alsha wrote:
>
> Hi *,
>
> I'
as no chance to close persistent context
(Hibernate session in my case). Conversation timeout works correct, in
opposite. I think that this is the reason for memory leak in my application.
Is it a desired behaviour or a bug?
Thanks a lot,
Alexey
--
View this message in context:
http://www.nabbl
Hi,
dushyant agarwal schrieb:
Hi,
I found an issue on the thread
-https://issues.apache.org/jira/browse/MYFACES-1658
Also
at-http://www.mail-archive.com/users@myfaces.apache.org/msg50352.html
The problem is that of memory leak. In my implementation I am
using
Hi,
I found an issue on the thread
-https://issues.apache.org/jira/browse/MYFACES-1658
Also at-http://www.mail-archive.com/users@myfaces.apache.org/msg50352.html
The problem is that of memory leak. In my implementation I am using server side
state saving until now.As well as I am implementing
Hi David,
That's a pretty old version. In fact it is so old there doesn't even appear to
be a tag for it in the myfaces repository any more.
But from a quick look at an oldish class version I would think it is the
_valueBindingCache variable. This is a cache for all the different EL
expression
David <[EMAIL PROTECTED]> schrieb:
> Hi,
>
> We are profiling a myfaces application which uses client state saving and we
> have detected a collection growing continouslly but not quickly (arround
> 5000 objects in four hours). The collection is
> org.apache.myfaces.application.ApplicationImp
Hi,
We are profiling a myfaces application which uses client state saving and we
have detected a collection growing continouslly but not quickly (arround
5000 objects in four hours). The collection is
org.apache.myfaces.application.ApplicationImpl$1. Is this the expected
behaviour for this class?
production we are observing memory leak scenarios
possibly due to the MyFaces JSPStateManagerImpl / it's handling of the
internal SerializedViewCollection objects or it's interaction with the
Apache Commons library.
What we observed on heapdumps is that the MyFaces JSPStateManagerImpl takes
a huge
t; occur due to errors in the handling of sessions,
> (aka objects being pushed into the session and not
> removed)
> I would look along those lines.
>
>
> Anyway, if you want to be sure that component tree handling is not the
> cause of all this switch for a little bit of
h is
rolled back in case
of a back button case, this is done due to the fact
that the back button needs to perform consistently on the client and server.
Following:
I do not think this is a memory leak, but you simply run into an out of
memory condition, due to the back button history saving the li
little bit of profiling and debugging
into client side state saving and check if the memory leak is gone.
I rather doubt it that it will be gone, but then you can be sure
that the component tree handlingn on your server is not the cause of this.
If it is still there
(In case of JSF I really doub
t; When using the saveState, will it keep referencing the beans that it
>> pointed
>> to ?
>> if yes, will this cause a memory leak coz the pointed bean should be died
>> and GC after the server method finished.
>> However, as someone is pointing to it (by saveState), so
t; Hi all,
>>I am new to myFaces and I think a little bit confusing on the
>> saveState
>> option.
>> When using the saveState, will it keep referencing the beans that it
>> pointed
>> to ?
>> if yes, will this cause a memory leak coz the pointe
Dellee wrote:
Hi all,
I am new to myFaces and I think a little bit confusing on the saveState
option.
When using the saveState, will it keep referencing the beans that it pointed
to ?
if yes, will this cause a memory leak coz the pointed bean should be died
and GC after the server method
e beans that it
> pointed to ?
> if yes, will this cause a memory leak coz the pointed bean should be died
> and GC after the server method finished.
> However, as someone is pointing to it (by saveState), so it still alive
> and won't be collected when GC start.
> what
Hi all,
I am new to myFaces and I think a little bit confusing on the saveState
option.
When using the saveState, will it keep referencing the beans that it pointed
to ?
if yes, will this cause a memory leak coz the pointed bean should be died
and GC after the server method finished
Dellee schrieb:
> Hi all,
>I am new to myFaces and I think a little bit confusing on the saveState
> option.
> When using the saveState, will it keep referencing the beans that it pointed
> to ?
> if yes, will this cause a memory leak coz the pointed bean should be died
wn EL implementation from Glassfish... but MyFaces
> has explicit code dependencies on Commons EL, so switching is not
> trivial...
>
> Alex
>
> -Original Message-
> From: Wayne Fay [mailto:[EMAIL PROTECTED]
> Sent: Sunday, January 21, 2007 9:13 PM
> To: MyFaces Dis
.. but MyFaces
has explicit code dependencies on Commons EL, so switching is not
trivial...
Alex
-Original Message-
From: Wayne Fay [mailto:[EMAIL PROTECTED]
Sent: Sunday, January 21, 2007 9:13 PM
To: MyFaces Discussion
Subject: Re: Memory leak
Good question... Anyone know a Commons EL substi
: Re: Memory leak
Good question... Anyone know a Commons EL substitution? Hopefully
something that is still in active development.
Wayne
On 1/19/07, Mick Knutson <[EMAIL PROTECTED]> wrote:
> What can you use instead of commons EL?
>
>
> On 1/19/07, Wayne Fay <[EMAIL PROTECTE
/07, phtan <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > We have a memory leak problem when running MyFaces 1.1.3 on Websphere
6.1. We
> > used a tool provided by IBM call Memory Dump Diagnostic to compare 2
heap dumps
> > or when we get a core dump due to out of memory.
te this bug, as discussed in that Sun.com bug report.
Wayne
On 1/19/07, phtan <[EMAIL PROTECTED]> wrote:
> Hi,
>
> We have a memory leak problem when running MyFaces 1.1.3 on Websphere
6.1. We
> used a tool provided by IBM call Memory Dump Diagnostic to compare 2
heap dumps
>
ROTECTED]> wrote:
Hi,
We have a memory leak problem when running MyFaces 1.1.3 on Websphere 6.1. We
used a tool provided by IBM call Memory Dump Diagnostic to compare 2 heap dumps
or when we get a core dump due to out of memory. The leak candidate shown by
the tool is almost always the BeanInf
Hi,
We have a memory leak problem when running MyFaces 1.1.3 on Websphere 6.1. We
used a tool provided by IBM call Memory Dump Diagnostic to compare 2 heap dumps
or when we get a core dump due to out of memory. The leak candidate shown by
the tool is almost always the BeanInfoManager in apache
32 matches
Mail list logo
