[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment
by Joey Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ]
Joey Wang edited comment on WFLY-6173 at 9/2/16 12:49 AM:
----------------------------------------------------------
[~mkouba], thanks for the fix.
Unfortunately I found some other memory leak after undeployment. Please try to deploy [^memory-leak_New.zip] to Wildfly 10.1.0.Final, access url http://[WF host]/memoryLeak/webresources/user. Undeploy the application, found class instances of 'person.joey.test.UserType' still in memory.
I used SQL Server 2014 as DB server to reproduce this issue, but I guess it doesn't matter which DB server is used. Please let me know if you need more information.
was (Author: joeydaowang):
Unfortunately I found some other memory leak after undeployment. Please try to deploy [^memory-leak_New.zip] to Wildfly 10.1.0.Final, access url http://[WF host]/memoryLeak/webresources/user. Undeploy the application, found class instances of 'person.joey.test.UserType' still in memory.
I used SQL Server 2014 as DB server to reproduce this issue, but I guess it doesn't matter which DB server is used. Please let me know if you need more information.
> Classes not unloaded after undeployment
> ---------------------------------------
>
> Key: WFLY-6173
> URL: https://issues.jboss.org/browse/WFLY-6173
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Reporter: Joey Wang
> Assignee: Martin Kouba
> Priority: Blocker
> Attachments: memory-leak.zip, memory-leak_New.zip
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded.
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment
by Joey Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ]
Joey Wang edited comment on WFLY-6173 at 9/2/16 12:48 AM:
----------------------------------------------------------
Unfortunately I found some other memory leak after undeployment. Please try to deploy [^memory-leak_New.zip] to Wildfly 10.1.0.Final, access url http://[WF host]/memoryLeak/webresources/user. Undeploy the application, found class instances of 'person.joey.test.UserType' still in memory.
I used SQL Server 2014 as DB server to reproduce this issue, but I guess it doesn't matter which DB server is used. Please let me know if you need more information.
was (Author: joeydaowang):
Unfortunately I found some other memory leak after undeployment. Please try to deploy [^memory-leak_New.zip] to Wildfly 10.1.0.Final, access url http://[WF host]/memoryLeak/webresources/user. Undeploy the application, found class instances of 'person.joey.test.UserType' still in memory.
I used SQL Server 2014 as DB server to reproduce this issue, but I guess it doesn't matter which DB server is used. Please let me know if you need more information.
> Classes not unloaded after undeployment
> ---------------------------------------
>
> Key: WFLY-6173
> URL: https://issues.jboss.org/browse/WFLY-6173
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Reporter: Joey Wang
> Assignee: Martin Kouba
> Priority: Blocker
> Attachments: memory-leak.zip, memory-leak_New.zip
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded.
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment
by Joey Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ]
Joey Wang updated WFLY-6173:
----------------------------
Attachment: memory-leak_New.zip
Unfortunately I found some othe[^memory-leak_New.zip]r memory leak after undeployment. Please try to deploy to Wildfly 10.1.0.Final, access url http://[WF host]/memoryLeak/webresources/user. Undeploy the application, found class instances of 'person.joey.test.UserType' still in memory.
I used SQL Server 2014 as DB server to reproduce this issue, but I guess it doesn't matter which DB server is used. Please let me know if you need more information.
> Classes not unloaded after undeployment
> ---------------------------------------
>
> Key: WFLY-6173
> URL: https://issues.jboss.org/browse/WFLY-6173
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Reporter: Joey Wang
> Assignee: Martin Kouba
> Priority: Blocker
> Attachments: memory-leak.zip, memory-leak_New.zip
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded.
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-6173) Classes not unloaded after undeployment
by Joey Wang (JIRA)
[ https://issues.jboss.org/browse/WFLY-6173?page=com.atlassian.jira.plugin.... ]
Joey Wang edited comment on WFLY-6173 at 9/2/16 12:47 AM:
----------------------------------------------------------
Unfortunately I found some other memory leak after undeployment. Please try to deploy [^memory-leak_New.zip] to Wildfly 10.1.0.Final, access url http://[WF host]/memoryLeak/webresources/user. Undeploy the application, found class instances of 'person.joey.test.UserType' still in memory.
I used SQL Server 2014 as DB server to reproduce this issue, but I guess it doesn't matter which DB server is used. Please let me know if you need more information.
was (Author: joeydaowang):
Unfortunately I found some othe[^memory-leak_New.zip]r memory leak after undeployment. Please try to deploy to Wildfly 10.1.0.Final, access url http://[WF host]/memoryLeak/webresources/user. Undeploy the application, found class instances of 'person.joey.test.UserType' still in memory.
I used SQL Server 2014 as DB server to reproduce this issue, but I guess it doesn't matter which DB server is used. Please let me know if you need more information.
> Classes not unloaded after undeployment
> ---------------------------------------
>
> Key: WFLY-6173
> URL: https://issues.jboss.org/browse/WFLY-6173
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.2.0.Final, 10.0.0.Final
> Reporter: Joey Wang
> Assignee: Martin Kouba
> Priority: Blocker
> Attachments: memory-leak.zip, memory-leak_New.zip
>
>
> I deployed a small web application with one single JSF and one managed bean, accessed the page and then undeployed the application. I found the classes of this application had never been unloaded via monitoring with Java VistualVM, also using '-XX:+TraceClassUnloading' JVM option proved the classes not unloaded.
> Then checking the heap dump of it, I found there were instance for each enum item (the managed bean has one enum type field, which is always initialized when the managed bean constructed) and one array instance including these enum instances.
> Please refer to the attachment for the same application. I started to verify the classloader memory leak issue because we found hot redeployment of our real application swallow some memory each time, then after lots of redeployment the server was short of memories.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFLY-7032) Optimize distributed web session creation
by Paul Ferraro (JIRA)
Paul Ferraro created WFLY-7032:
----------------------------------
Summary: Optimize distributed web session creation
Key: WFLY-7032
URL: https://issues.jboss.org/browse/WFLY-7032
Project: WildFly
Issue Type: Enhancement
Components: Clustering
Affects Versions: 10.1.0.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
Fix For: 11.0.0.Alpha1
Following session ID generation, we currently validate that the session ID is not already in use, in which case, we generate a new ID. This is not only racey, but requires a call to Cache.containsKey(...). This is potentially a costly call, since we need to search both memory and the cache store - particularly costly when using a remote cache store. We eventually add the new session via Cache.putIfAbsent(...), which already atomically ensures no session with that ID already exists.
Additionally, when creating the dependent cache entries for a session (i.e. access meta data, session attributes), we don't need putIfAbsent semantics - a AdvancedCache.withFlags(Flags.IGNORE_RETURN_VALUES).put(...) will suffice.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used
by Neal Dillman (JIRA)
[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ]
Neal Dillman commented on JGRP-2098:
------------------------------------
I believe that discovery should be limited to finding the coordinator. IP address mapping, logical names, what have you, can all be put into a separate, optional protocol.
Further, I am not convinced that discovery is even really needed in the manner in which it is currently done. For example, if one were to listen for sendInfo() messages from MERGE3, one would be able to determine who the coordinator is and act upon that. In other words, I believe we may wish to handle discovery as a byproduct of another protocol.
> Discovery: reduce messages when IpAddressUUID is used
> -----------------------------------------------------
>
> Key: JGRP-2098
> URL: https://issues.jboss.org/browse/JGRP-2098
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase.
> Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID.
> Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used
by Neal Dillman (JIRA)
[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ]
Neal Dillman edited comment on JGRP-2098 at 9/1/16 5:16 PM:
------------------------------------------------------------
In our implementation we created:
{{public class LESS_PING extends PING
{
@Override
public void findMembers( List<Address> members, boolean initial_discovery, Responses responses )
{
// no discovery except for the initial request
if ( initial_discovery )
{
try
{
sendDiscoveryRequest( cluster_name, members );
}
catch ( InterruptedIOException ie )
{
;
}
catch ( InterruptedException ex )
{
;
}
catch ( Throwable ex )
{
log.error( Util.getMessage( "FailedSendingDiscoveryRequest" ), ex );
}
}
}
protected void sendDiscoveryResponse(Address logical_addr, PhysicalAddress physical_addr,
String logical_name, final Address sender, boolean coord) {
final PingData data=new PingData(logical_addr, is_server, logical_name, physical_addr).coord(coord);
final Message rsp_msg=new Message(sender).setFlag(Message.Flag.INTERNAL, Message.Flag.OOB,
Message.Flag.DONT_BUNDLE)
.putHeader(this.id, new PingHeader(PingHeader.GET_MBRS_RSP)).setBuffer(marshal(data));
if(stagger_timeout > 0) {
int view_size=view != null? view.size() : 10;
int rank=Util.getRank(view, local_addr); // returns 0 if view or local_addr are null
if( rank > 5 )
{
// there will be plenty of responders
log.trace("%s: received GET_MBRS_REQ from %s, skipping response due to rank %d > max allowed of %d",
local_addr, sender, rank, max_rank_for_response );
}
else
{
long sleep_time = rank == 0 ? Util.random( stagger_timeout )
: stagger_timeout * rank / view_size - (stagger_timeout / view_size);
timer.schedule( new Runnable()
{
@Override
public void run()
{
log.trace( "%s: received GET_MBRS_REQ from %s, sending staggered response %s", local_addr, sender,
data );
down_prot.down( new Event( Event.MSG, rsp_msg ) );
}
}, sleep_time, TimeUnit.MILLISECONDS );
}
}
else
{
log.trace( "%s: received GET_MBRS_REQ from %s, sending response %s", local_addr, sender, data );
down_prot.down( new Event( Event.MSG, rsp_msg ) );
}
}
}
}}
This in effect limits discovery to initial discovery. In addition, discovery only responds if the rank < 5. Both of these changes work together to most eliminate discovery from the channel (because we have the IP address in the UUID)
was (Author: ndillman):
In our implementation we created:
public class LESS_PING extends PING
{
@Override
public void findMembers( List<Address> members, boolean initial_discovery, Responses responses )
{
// no discovery except for the initial request
if ( initial_discovery )
{
try
{
sendDiscoveryRequest( cluster_name, members );
}
catch ( InterruptedIOException ie )
{
;
}
catch ( InterruptedException ex )
{
;
}
catch ( Throwable ex )
{
log.error( Util.getMessage( "FailedSendingDiscoveryRequest" ), ex );
}
}
}
protected void sendDiscoveryResponse(Address logical_addr, PhysicalAddress physical_addr,
String logical_name, final Address sender, boolean coord) {
final PingData data=new PingData(logical_addr, is_server, logical_name, physical_addr).coord(coord);
final Message rsp_msg=new Message(sender).setFlag(Message.Flag.INTERNAL, Message.Flag.OOB,
Message.Flag.DONT_BUNDLE)
.putHeader(this.id, new PingHeader(PingHeader.GET_MBRS_RSP)).setBuffer(marshal(data));
if(stagger_timeout > 0) {
int view_size=view != null? view.size() : 10;
int rank=Util.getRank(view, local_addr); // returns 0 if view or local_addr are null
if( rank > 5 )
{
// there will be plenty of responders
log.trace("%s: received GET_MBRS_REQ from %s, skipping response due to rank %d > max allowed of %d",
local_addr, sender, rank, max_rank_for_response );
}
else
{
long sleep_time = rank == 0 ? Util.random( stagger_timeout )
: stagger_timeout * rank / view_size - (stagger_timeout / view_size);
timer.schedule( new Runnable()
{
@Override
public void run()
{
log.trace( "%s: received GET_MBRS_REQ from %s, sending staggered response %s", local_addr, sender,
data );
down_prot.down( new Event( Event.MSG, rsp_msg ) );
}
}, sleep_time, TimeUnit.MILLISECONDS );
}
}
else
{
log.trace( "%s: received GET_MBRS_REQ from %s, sending response %s", local_addr, sender, data );
down_prot.down( new Event( Event.MSG, rsp_msg ) );
}
}
}
This in effect limits discovery to initial discovery. In addition, discovery only responds if the rank < 5. Both of these changes work together to most eliminate discovery from the channel (because we have the IP address in the UUID)
> Discovery: reduce messages when IpAddressUUID is used
> -----------------------------------------------------
>
> Key: JGRP-2098
> URL: https://issues.jboss.org/browse/JGRP-2098
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase.
> Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID.
> Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (JGRP-2098) Discovery: reduce messages when IpAddressUUID is used
by Neal Dillman (JIRA)
[ https://issues.jboss.org/browse/JGRP-2098?page=com.atlassian.jira.plugin.... ]
Neal Dillman commented on JGRP-2098:
------------------------------------
In our implementation we created:
public class LESS_PING extends PING
{
@Override
public void findMembers( List<Address> members, boolean initial_discovery, Responses responses )
{
// no discovery except for the initial request
if ( initial_discovery )
{
try
{
sendDiscoveryRequest( cluster_name, members );
}
catch ( InterruptedIOException ie )
{
;
}
catch ( InterruptedException ex )
{
;
}
catch ( Throwable ex )
{
log.error( Util.getMessage( "FailedSendingDiscoveryRequest" ), ex );
}
}
}
protected void sendDiscoveryResponse(Address logical_addr, PhysicalAddress physical_addr,
String logical_name, final Address sender, boolean coord) {
final PingData data=new PingData(logical_addr, is_server, logical_name, physical_addr).coord(coord);
final Message rsp_msg=new Message(sender).setFlag(Message.Flag.INTERNAL, Message.Flag.OOB,
Message.Flag.DONT_BUNDLE)
.putHeader(this.id, new PingHeader(PingHeader.GET_MBRS_RSP)).setBuffer(marshal(data));
if(stagger_timeout > 0) {
int view_size=view != null? view.size() : 10;
int rank=Util.getRank(view, local_addr); // returns 0 if view or local_addr are null
if( rank > 5 )
{
// there will be plenty of responders
log.trace("%s: received GET_MBRS_REQ from %s, skipping response due to rank %d > max allowed of %d",
local_addr, sender, rank, max_rank_for_response );
}
else
{
long sleep_time = rank == 0 ? Util.random( stagger_timeout )
: stagger_timeout * rank / view_size - (stagger_timeout / view_size);
timer.schedule( new Runnable()
{
@Override
public void run()
{
log.trace( "%s: received GET_MBRS_REQ from %s, sending staggered response %s", local_addr, sender,
data );
down_prot.down( new Event( Event.MSG, rsp_msg ) );
}
}, sleep_time, TimeUnit.MILLISECONDS );
}
}
else
{
log.trace( "%s: received GET_MBRS_REQ from %s, sending response %s", local_addr, sender, data );
down_prot.down( new Event( Event.MSG, rsp_msg ) );
}
}
}
This in effect limits discovery to initial discovery. In addition, discovery only responds if the rank < 5. Both of these changes work together to most eliminate discovery from the channel (because we have the IP address in the UUID)
> Discovery: reduce messages when IpAddressUUID is used
> -----------------------------------------------------
>
> Key: JGRP-2098
> URL: https://issues.jboss.org/browse/JGRP-2098
> Project: JGroups
> Issue Type: Feature Request
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 4.0
>
>
> Since IpAddressUUID already contains the physical address, we don't need to exchange physical addresses in the discovery phase.
> Investigate whether this leads to reduced messaging in discovery, ie. only the coords might send a response. Once the new member has the view, it automatically knows the IP addresses and ports of all members, as the addresses in the view are of type IpAddressUUID.
> Also investigate whether address:logical_name associations should be done in a separate protocol, e.g. NAMING.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months
[JBoss JIRA] (WFCORE-952) Use WildFly Common for null param checks
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-952?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-952:
-----------------------------------------
Sure, or just feel free to schedule it again for whenever. As part of releasing Alpha7 I went through all the JIRAs scheduled for it that just seemed to be rolling from release to release and tried to clean some of those out. My previous comment is generic one that I pasted into all of them.
> Use WildFly Common for null param checks
> ----------------------------------------
>
> Key: WFCORE-952
> URL: https://issues.jboss.org/browse/WFCORE-952
> Project: WildFly Core
> Issue Type: Task
> Reporter: David Lloyd
> Priority: Minor
>
> For each module, do the following:
> * Locate any/all null param check methods in the log msg
> * Replace them with calls to org.wildfly.common.Assert#checkNotNullParam or related method as needed
> * Replace the old null param check method with a comment that reserves the ID and shows that it was previously used for that purpose
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 10 months