[JBoss JIRA] (WFLY-6046) Suggested defaults for Metasize and Java 8
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFLY-6046?page=com.atlassian.jira.plugin.... ]
Ken Wills updated WFLY-6046:
----------------------------
Description:
Since PermGen is no longer used, and has been replaced by Metasize, we probably need to alter the initial startup values. Current WF is using:
-XX:MaxMetaspaceSize=256m
After some testing with garbage collection logging on (\-verbose:gc \-Xloggc:hcgc.log \-XX:+PrintGCDateStamps \-XX:MetaspaceSize=XX), the GC logs were monitored for at least one occurrence of a full GC due to Metadata threshold (example [Full GC (Metadata GC Threshold) 39592K->20187K). Using this information, minimum levels of Metasize for various configurations were determined.
The numbers below are the values used for \-XX:MetaspaceSize=XXM followed by the number of full GCs triggered at that amount measured during boot of WF10-full:
Standalone:
{quote}
standalone.xml 52MB(1), 53MB(0)
standalone-full.xml 64MB(1), 65MB(0)
standalone-ha.xml 52MB(1), 54MB(0)
standalone-full-ha.xml 79MB(1), 80MB(0)
{quote}
For domain mode, the corresponding values were determined to be:
{quote}
Process Controller: 12MB(1), 13MB(0)
Host Controller: 39MB(1), 40MB(0)
{quote}
In domain mode, a very slight, non-scientifically measure boot time difference was observered (1769ms default Metasize vs 1694ms with 40m MetaSize set for host controller).
The approximate cost of increasing MetaSize over the default is summerized below (using top to collect RSS after server boot):
JBoss AS 7.1.1: (default permgen (-XX:PermSize=256m -XX:MaxPermSize=256m), JDK 7)
{quote}
---------------------------------------
RSS SHR
---------------------------------------
standalone.xml 182,652 21,748
standalone-ha.xml 211,672 21,904
standalone-full.xml 217,636 22,764
standalone-full-ha.xml 289,524 23,136
domain:
Server-one: 227,220 22,560
Server-two: 234,944 22,604
PC: 37,584 13,184
HC: 138,428 19,496
{quote}
was:
Since PermGen is no longer used, and has been replaced by Metasize, we probably need to alter the initial startup values. Current WF is using:
-XX:MaxMetaspaceSize=256m
After some testing with garbage collection logging on (\-verbose:gc \-Xloggc:hcgc.log \-XX:+PrintGCDateStamps \-XX:MetaspaceSize=XX), the GC logs were monitored for at least one occurrence of a full GC due to Metadata threshold (example [Full GC (Metadata GC Threshold) 39592K->20187K). Using this information, minimum levels of Metasize for various configurations were determined.
> Suggested defaults for Metasize and Java 8
> ------------------------------------------
>
> Key: WFLY-6046
> URL: https://issues.jboss.org/browse/WFLY-6046
> Project: WildFly
> Issue Type: Enhancement
> Reporter: Ken Wills
> Assignee: Ken Wills
>
> Since PermGen is no longer used, and has been replaced by Metasize, we probably need to alter the initial startup values. Current WF is using:
> -XX:MaxMetaspaceSize=256m
> After some testing with garbage collection logging on (\-verbose:gc \-Xloggc:hcgc.log \-XX:+PrintGCDateStamps \-XX:MetaspaceSize=XX), the GC logs were monitored for at least one occurrence of a full GC due to Metadata threshold (example [Full GC (Metadata GC Threshold) 39592K->20187K). Using this information, minimum levels of Metasize for various configurations were determined.
> The numbers below are the values used for \-XX:MetaspaceSize=XXM followed by the number of full GCs triggered at that amount measured during boot of WF10-full:
> Standalone:
> {quote}
> standalone.xml 52MB(1), 53MB(0)
> standalone-full.xml 64MB(1), 65MB(0)
> standalone-ha.xml 52MB(1), 54MB(0)
> standalone-full-ha.xml 79MB(1), 80MB(0)
> {quote}
> For domain mode, the corresponding values were determined to be:
> {quote}
> Process Controller: 12MB(1), 13MB(0)
> Host Controller: 39MB(1), 40MB(0)
> {quote}
> In domain mode, a very slight, non-scientifically measure boot time difference was observered (1769ms default Metasize vs 1694ms with 40m MetaSize set for host controller).
> The approximate cost of increasing MetaSize over the default is summerized below (using top to collect RSS after server boot):
> JBoss AS 7.1.1: (default permgen (-XX:PermSize=256m -XX:MaxPermSize=256m), JDK 7)
> {quote}
> ---------------------------------------
> RSS SHR
> ---------------------------------------
> standalone.xml 182,652 21,748
> standalone-ha.xml 211,672 21,904
> standalone-full.xml 217,636 22,764
> standalone-full-ha.xml 289,524 23,136
> domain:
> Server-one: 227,220 22,560
> Server-two: 234,944 22,604
> PC: 37,584 13,184
> HC: 138,428 19,496
> {quote}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6046) Suggested defaults for Metasize and Java 8
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFLY-6046?page=com.atlassian.jira.plugin.... ]
Ken Wills updated WFLY-6046:
----------------------------
Description:
Since PermGen is no longer used, and has been replaced by Metasize, we probably need to alter the initial startup values. Current WF is using:
-XX:MaxMetaspaceSize=256m
After some testing with garbage collection logging on (\-verbose:gc \-Xloggc:hcgc.log \-XX:+PrintGCDateStamps \-XX:MetaspaceSize=XX), the GC logs were monitored for at least one occurrence of a full GC due to Metadata threshold (example [Full GC (Metadata GC Threshold) 39592K->20187K). Using this information, minimum levels of Metasize for various configurations were determined.
was:
Since PermGen is no longer used, and has been replaced by Metasize, we probably need to alter the initial startup values. Current WF is using:
-XX:MaxMetaspaceSize=256m
After some testing with garbage collection logging on (\-verbose:gc \-Xloggc:hcgc.log -XX:+PrintGCDateStamps -XX:MetaspaceSize=XX), the GC logs were monitored for at least one occurrence of a full GC due to Metadata threshold (example [Full GC (Metadata GC Threshold) 39592K->20187K). Using this information, minimum levels of Metasize for various configurations were determined.
> Suggested defaults for Metasize and Java 8
> ------------------------------------------
>
> Key: WFLY-6046
> URL: https://issues.jboss.org/browse/WFLY-6046
> Project: WildFly
> Issue Type: Enhancement
> Reporter: Ken Wills
> Assignee: Ken Wills
>
> Since PermGen is no longer used, and has been replaced by Metasize, we probably need to alter the initial startup values. Current WF is using:
> -XX:MaxMetaspaceSize=256m
> After some testing with garbage collection logging on (\-verbose:gc \-Xloggc:hcgc.log \-XX:+PrintGCDateStamps \-XX:MetaspaceSize=XX), the GC logs were monitored for at least one occurrence of a full GC due to Metadata threshold (example [Full GC (Metadata GC Threshold) 39592K->20187K). Using this information, minimum levels of Metasize for various configurations were determined.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6046) Suggested defaults for Metasize and Java 8
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFLY-6046?page=com.atlassian.jira.plugin.... ]
Ken Wills updated WFLY-6046:
----------------------------
Description:
Since PermGen is no longer used, and has been replaced by Metasize, we probably need to alter the initial startup values. Current WF is using:
-XX:MaxMetaspaceSize=256m
After some testing with garbage collection logging on (\-verbose:gc \-Xloggc:hcgc.log -XX:+PrintGCDateStamps -XX:MetaspaceSize=XX), the GC logs were monitored for at least one occurrence of a full GC due to Metadata threshold (example [Full GC (Metadata GC Threshold) 39592K->20187K). Using this information, minimum levels of Metasize for various configurations were determined.
was:
Since PermGen is no longer used, and has been replaced by Metasize, we probably need to alter the initial startup values. Current WF is using:
-XX:MaxMetaspaceSize=256m
After some testing with garbage collection logging on (-verbose:gc -Xloggc:hcgc.log -XX:+PrintGCDateStamps -XX:MetaspaceSize=XX), the GC logs were monitored for at least one occurrence of a full GC due to Metadata threshold (example [Full GC (Metadata GC Threshold) 39592K->20187K). Using this information, minimum levels of Metasize for various configurations were determined.
> Suggested defaults for Metasize and Java 8
> ------------------------------------------
>
> Key: WFLY-6046
> URL: https://issues.jboss.org/browse/WFLY-6046
> Project: WildFly
> Issue Type: Enhancement
> Reporter: Ken Wills
> Assignee: Ken Wills
>
> Since PermGen is no longer used, and has been replaced by Metasize, we probably need to alter the initial startup values. Current WF is using:
> -XX:MaxMetaspaceSize=256m
> After some testing with garbage collection logging on (\-verbose:gc \-Xloggc:hcgc.log -XX:+PrintGCDateStamps -XX:MetaspaceSize=XX), the GC logs were monitored for at least one occurrence of a full GC due to Metadata threshold (example [Full GC (Metadata GC Threshold) 39592K->20187K). Using this information, minimum levels of Metasize for various configurations were determined.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-6046) Suggested defaults for Metasize and Java 8
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFLY-6046?page=com.atlassian.jira.plugin.... ]
Ken Wills updated WFLY-6046:
----------------------------
Description:
Since PermGen is no longer used, and has been replaced by Metasize, we probably need to alter the initial startup values. Current WF is using:
-XX:MaxMetaspaceSize=256m
After some testing with garbage collection logging on (-verbose:gc -Xloggc:hcgc.log -XX:+PrintGCDateStamps -XX:MetaspaceSize=XX), the GC logs were monitored for at least one occurrence of a full GC due to Metadata threshold (example [Full GC (Metadata GC Threshold) 39592K->20187K). Using this information, minimum levels of Metasize for various configurations were determined.
> Suggested defaults for Metasize and Java 8
> ------------------------------------------
>
> Key: WFLY-6046
> URL: https://issues.jboss.org/browse/WFLY-6046
> Project: WildFly
> Issue Type: Enhancement
> Reporter: Ken Wills
> Assignee: Ken Wills
>
> Since PermGen is no longer used, and has been replaced by Metasize, we probably need to alter the initial startup values. Current WF is using:
> -XX:MaxMetaspaceSize=256m
> After some testing with garbage collection logging on (-verbose:gc -Xloggc:hcgc.log -XX:+PrintGCDateStamps -XX:MetaspaceSize=XX), the GC logs were monitored for at least one occurrence of a full GC due to Metadata threshold (example [Full GC (Metadata GC Threshold) 39592K->20187K). Using this information, minimum levels of Metasize for various configurations were determined.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-2484) Cleanup clustering tests
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2484?page=com.atlassian.jira.plugin.... ]
Radoslav Husar updated WFLY-2484:
---------------------------------
Summary: Cleanup clustering tests (was: Revise clustering tests)
> Cleanup clustering tests
> ------------------------
>
> Key: WFLY-2484
> URL: https://issues.jboss.org/browse/WFLY-2484
> Project: WildFly
> Issue Type: Feature Request
> Components: Clustering
> Affects Versions: 8.0.0.Beta1
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> Paul pointed out that some of the tests are no longer relevant with the new implementation and some were never actually relevant, e.g. duplicate tests.
> We should revise the set of tests to keep the testsuite small and find out missing tests.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1318) Create an Azure equivalent to the S3 variant of Domain Controller discovery
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1318:
----------------------------------------
Summary: Create an Azure equivalent to the S3 variant of Domain Controller discovery
Key: WFCORE-1318
URL: https://issues.jboss.org/browse/WFCORE-1318
Project: WildFly Core
Issue Type: Feature Request
Reporter: Brian Stansberry
WildFly Core includes an analogoue to JGroups's S3_PING discovery protocol that can be used for slave discovery of the DC on Amazon's EC2 cloud. See https://developer.jboss.org/people/fjuma/blog/2013/03/15/a-domain-control... for details.
This JIRA is to create an equivalent for Azure. Should use the same configuration style as what Farah did for S3 (generic classname + module + properties; no strongly typed schema.)
Anyone working on this should contact [~rhusar] early in the process, as he has done work on an Azure equivalent to S3_PING for use in JGroups channels. Ping me too for preliminary discussion.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFCORE-1317) Upgrade undertow to 1.3.15
by Tomaz Cerar (JIRA)
Tomaz Cerar created WFCORE-1317:
-----------------------------------
Summary: Upgrade undertow to 1.3.15
Key: WFCORE-1317
URL: https://issues.jboss.org/browse/WFCORE-1317
Project: WildFly Core
Issue Type: Component Upgrade
Reporter: Tomaz Cerar
Assignee: Stuart Douglas
Priority: Blocker
Fix For: 2.0.8.Final
Upgrade undertow 1.3.15 that includes fix for UNDERTOW-616 / WFLY-6044
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months
[JBoss JIRA] (WFLY-5788) EJB client can fail with CNFE when deserializing EJBException since wrapped cause might not be on classpath such as CacheException
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5788?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on WFLY-5788 at 1/21/16 12:31 PM:
----------------------------------------------------------------
Rejecting pull request, comment to approach removing all RuntimeExceptions before sending over the wire:
The failing tests rely on the wrapped RuntimeExceptions or are throwing RuntimeExceptions form the user code. Typically those would be business exceptions and not RuntimeExceptions.
We will implement this by extending the SPI to keep correct encapsulation to remove CacheExceptions that are not "understood" by the client.
was (Author: rhusar):
Rejecting pull request, comment:
The failing tests rely on the wrapped RuntimeExceptions or are throwing RuntimeExceptions form the user code. Typically those would be business exceptions and not RuntimeExceptions.
We will implement this by extending the SPI to keep correct encapsulation to remove CacheExceptions that are not "understood" by the client.
> EJB client can fail with CNFE when deserializing EJBException since wrapped cause might not be on classpath such as CacheException
> ----------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5788
> URL: https://issues.jboss.org/browse/WFLY-5788
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR5
> Reporter: Michal Vinkler
> Assignee: Radoslav Husar
>
> -RuntimeExceptions thrown when accessing the SFSB cache should be rethrown as an EJBException. Otherwise the client doesn't know how to serialize implementation specific exception classes.-
> This is not correct. The cause is wrapped in the EJBException but it is the cause that cannot be deserialized. Updated the Jira summary and crossed ^ out. --Rado
> Seen in our failover tests for remote stateful EJBs - scenarios.
> After failing a node, client logs these error messages:
> {code}
> 2015/11/27 04:10:03:241 EST [ERROR][Runner - 894] HOST perf17.mw.lab.eng.bos.redhat.com:rootProcess:c - Error getting response. <javax.ejb.EJBException: java.lang.ClassNotFoundException: org.infinispan.statetransfer.OutdatedTopologyException>
> javax.ejb.EJBException: java.lang.ClassNotFoundException: org.infinispan.statetransfer.OutdatedTopologyException
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:238)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:183)
> at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:146)
> at com.sun.proxy.$Proxy2.getSerialAndIncrement(Unknown Source)
> at org.jboss.smartfrog.clustering.ejb3.StatefulSBProcessorFactoryImpl$EJB3RequestProcessor.processRequest(StatefulSBProcessorFactoryImpl.java:84)
> at org.jboss.smartfrog.loaddriver.CompoundRequestProcessorFactoryImpl$CompoundRequestProcessor.processRequest(CompoundRequestProcessorFactoryImpl.java:52)
> at org.jboss.smartfrog.loaddriver.Runner.run(Runner.java:103)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ClassNotFoundException: org.infinispan.statetransfer.OutdatedTopologyException
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at org.jboss.marshalling.AbstractClassResolver.loadClass(AbstractClassResolver.java:131)
> at org.jboss.marshalling.AbstractClassResolver.resolveClass(AbstractClassResolver.java:112)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadClassDescriptor(RiverUnmarshaller.java:948)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1255)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:224)
> at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1745)
> at org.jboss.marshalling.river.RiverObjectInputStream.defaultReadObject(RiverObjectInputStream.java:81)
> at java.lang.Throwable.readObject(Throwable.java:914)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:497)
> at org.jboss.marshalling.reflect.SerializableClass.callReadObject(SerializableClass.java:307)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1637)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1606)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1606)
> at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1606)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1285)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:209)
> at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:41)
> at org.jboss.ejb.client.remoting.InvocationExceptionResponseHandler$MethodInvocationExceptionResultProducer.getResult(InvocationExceptionResponseHandler.java:79)
> at org.jboss.ejb.client.EJBClientInvocationContext$1.run(EJBClientInvocationContext.java:282)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:279)
> at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:290)
> at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:129)
> at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:265)
> at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:453)
> at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:204)
> ... 7 more
> {code}
> Link
> http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover-ejb-e...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 3 months