[JBoss JIRA] (WFCORE-1150) Include -XX:MetaspaceSize in our default vm settings
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1150?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1150:
-------------------------------------
Description:
JDK 8 no longer has a perm gen, but it does have a "Metaspace" area of native memory where it stores some of the types of data previously stored in perm gen, class metadata in particular.
The default size of this is, I believe 21MB on a 64 bit VM. Full WildFly uses over 50MB, excluding apps. The VM will increase the size once it gets over a certain percentage full, but it will do a full, stop-the-world GC before increasing. This means full WildFly has two full GCs as part of boot.
The -XX:MetaspaceSize JVM option allows the minimum size to be set. Using a reasonable value for this will help avoid unnecessary full GCs.
I'm not sure the best value to use. A minimum of 80MB was enough to avoid a full GC during a boot of standalone-full-ha.xml. But then any sort of deployments will trigger a full GC. OTOH, our host.xml jvm elements have historically included a -XX:PermSize setting of 256M, so that's another possible value. Perm Gen and Metaspace aren't completely equivalent (e.g. before JDK 7 perm gen included stuff like interned strings, which are now in the heap.)
was:
JDK 8 no longer has a perm gen, but it does have a "Metaspace" area of native memory where it stores some of the types of data previously stored in perm gen, class metadata in particular.
The default size of this are is, I believe 21MB on a 64 bit VM. Full WildFly uses over 50MB, excluding apps. The VM will increase the size once it gets over a certain percentage full, but it will do a full, stop-the-world GC before increasing. This means full WildFly has two full GCs as part of boot.
The -XX:MetaspaceSize JVM option allows the minimum size to be set. Using a reasonable value for this will help avoid unnecessary full GCs.
I'm not sure the best value to use. A minimum of 80MB was enough to avoid a full GC during a boot of standalone-full-ha.xml. But then any sort of deployments will trigger a full GC. OTOH, our host.xml jvm elements have historically included a -XX:PermSize setting of 256M, so that's another possible value. Perm Gen and Metaspace aren't completely equivalent (e.g. before JDK 7 perm gen included stuff like interned strings, which are now in the heap.)
> Include -XX:MetaspaceSize in our default vm settings
> ----------------------------------------------------
>
> Key: WFCORE-1150
> URL: https://issues.jboss.org/browse/WFCORE-1150
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Server
> Reporter: Brian Stansberry
> Fix For: 3.0.0.Alpha1
>
>
> JDK 8 no longer has a perm gen, but it does have a "Metaspace" area of native memory where it stores some of the types of data previously stored in perm gen, class metadata in particular.
> The default size of this is, I believe 21MB on a 64 bit VM. Full WildFly uses over 50MB, excluding apps. The VM will increase the size once it gets over a certain percentage full, but it will do a full, stop-the-world GC before increasing. This means full WildFly has two full GCs as part of boot.
> The -XX:MetaspaceSize JVM option allows the minimum size to be set. Using a reasonable value for this will help avoid unnecessary full GCs.
> I'm not sure the best value to use. A minimum of 80MB was enough to avoid a full GC during a boot of standalone-full-ha.xml. But then any sort of deployments will trigger a full GC. OTOH, our host.xml jvm elements have historically included a -XX:PermSize setting of 256M, so that's another possible value. Perm Gen and Metaspace aren't completely equivalent (e.g. before JDK 7 perm gen included stuff like interned strings, which are now in the heap.)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1150) Include -XX:MetaspaceSize in our default vm settings
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1150:
----------------------------------------
Summary: Include -XX:MetaspaceSize in our default vm settings
Key: WFCORE-1150
URL: https://issues.jboss.org/browse/WFCORE-1150
Project: WildFly Core
Issue Type: Enhancement
Components: Server
Reporter: Brian Stansberry
Fix For: 3.0.0.Alpha1
JDK 8 no longer has a perm gen, but it does have a "Metaspace" area of native memory where it stores some of the types of data previously stored in perm gen, class metadata in particular.
The default size of this are is, I believe 21MB on a 64 bit VM. Full WildFly uses over 50MB, excluding apps. The VM will increase the size once it gets over a certain percentage full, but it will do a full, stop-the-world GC before increasing. This means full WildFly has two full GCs as part of boot.
The -XX:MetaspaceSize JVM option allows the minimum size to be set. Using a reasonable value for this will help avoid unnecessary full GCs.
I'm not sure the best value to use. A minimum of 80MB was enough to avoid a full GC during a boot of standalone-full-ha.xml. But then any sort of deployments will trigger a full GC. OTOH, our host.xml jvm elements have historically included a -XX:PermSize setting of 256M, so that's another possible value. Perm Gen and Metaspace aren't completely equivalent (e.g. before JDK 7 perm gen included stuff like interned strings, which are now in the heap.)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1149) DomainApiGenericOperationHandler doesn't handle auto-closing streams
by James Perkins (JIRA)
James Perkins created WFCORE-1149:
-------------------------------------
Summary: DomainApiGenericOperationHandler doesn't handle auto-closing streams
Key: WFCORE-1149
URL: https://issues.jboss.org/browse/WFCORE-1149
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Reporter: James Perkins
Assignee: James Perkins
The {{DomainApiGenericOperationHandler}} needs to ensure any input streams it attaches to an operation are closed. In the case of a content upload two streams are attached and only one is closed during the add of the content in the operation step handler.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5673) Equals signs in cookies configuration is not working in Domain mode
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5673?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-5673:
------------------------------
Affects Version/s: 8.1.0.Final
> Equals signs in cookies configuration is not working in Domain mode
> -------------------------------------------------------------------
>
> Key: WFLY-5673
> URL: https://issues.jboss.org/browse/WFLY-5673
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Web (Undertow)
> Affects Versions: 8.1.0.Final
> Reporter: Boominathan Shanmugam
> Assignee: Tomaz Cerar
>
> The property that allows WILDFLY 8.1 in standalone mode to have = in cookie values
> <subsystem xmlns="urn:jboss:domain:undertow:1.1">
> <buffer-cache name="default"/>
> <server name="default-server">
> <http-listener name="default" socket-binding="http" allow-equals-in-cookie-value="true"/>
> The issue we are seeing is that setting that to true, via CLI, in domain mode does not make the code behave the same way as it does in standalone. Could be that there are more changes required in domain mode than just setting this setting, but I could not find anything. Could also be that caching is somehow not letting the new value in, tho I did restart the entire system, including the DC (even deleted the /tmp folder on both nodes and on DC).
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5710) AS doesn't compile with oracle java 1.8.0_25
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-5710?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-5710:
-----------------------------------
That is bug in java compiler.
I would say that jdk8u40 should be minimum for building the app server.
> AS doesn't compile with oracle java 1.8.0_25
> --------------------------------------------
>
> Key: WFLY-5710
> URL: https://issues.jboss.org/browse/WFLY-5710
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 10.0.0.CR4
> Reporter: Martin Choma
> Priority: Minor
>
> Adding this issue mainly for reference as on latest java 1.8.0_66 works fine again.
> Whole affected java version is
> {code}
> java version "1.8.0_25"
> Java(TM) SE Runtime Environment (build 1.8.0_25-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
> {code}
> Whole compilation error is
> {code}
> [ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project wildfly-clustering-common: Compilation failure
> [ERROR] /home/mchoma/workspace/git-repositories/wildfly/clustering/common/src/main/java/org/jboss/as/clustering/controller/ExecutionHandler.java:[54,48] no suitable method found for collect(java.util.stream.Collector<E,capture#1 of ?,java.util.Map<java.lang.String,java.lang.Object>>)
> [ERROR] method java.util.stream.Stream.<R>collect(java.util.function.Supplier<R>,java.util.function.BiConsumer<R,? super capture#2 of ? extends E>,java.util.function.BiConsumer<R,R>) is not applicable
> [ERROR] (cannot infer type-variable(s) R
> [ERROR] (actual and formal argument lists differ in length))
> [ERROR] method java.util.stream.Stream.<R,A>collect(java.util.stream.Collector<? super capture#2 of ? extends E,A,R>) is not applicable
> [ERROR] (cannot infer type-variable(s) capture#3 of ?,T,K,U,T
> [ERROR] (argument mismatch; java.util.function.Function<capture#2 of ? extends E,capture#2 of ? extends E> cannot be converted to java.util.function.Function<? super capture#2 of ? extends E,? extends capture#2 of ? extends E>))
> {code}
> Works ok on
> {code}
> java version "1.8.0_05"
> Java(TM) SE Runtime Environment (build 1.8.0_05-b13)
> Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode)
> {code}
> {code}
> java version "1.8.0_66"
> Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
> Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5621) Cleanup HornetQ xsd files in "docs/schema" directory
by Wolfgang Knauf (JIRA)
[ https://issues.jboss.org/browse/WFLY-5621?page=com.atlassian.jira.plugin.... ]
Wolfgang Knauf edited comment on WFLY-5621 at 11/20/15 4:11 PM:
----------------------------------------------------------------
Just for the records: a sample for JBoss 7 including a "...hornetq-jms.xml" file can be found [here|http://www.cs.hs-rm.de/~knauf/JavaEE6/mdb/Message.ear]
The error on deployment is:
{noformat}
2015-11-20 22:02:35,414 INFO [org.jboss.as.repository] (DeploymentScanner-threads - 1) WFLYDR0001: Content added at location C:\Temp\wildfly-10.0.0.CR4\standalone\data\content\f0\1dbd9a8585584cfd36607ba9fc0b068557c36e\content
2015-11-20 22:02:35,429 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "Message.ear" (runtime-name: "Message.ear")
2015-11-20 22:02:35,601 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0207: Starting subdeployment (runtime-name: "MessageClient.jar")
2015-11-20 22:02:35,601 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0207: Starting subdeployment (runtime-name: "MessageEJB.jar")
2015-11-20 22:02:35,632 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.subunit."Message.ear"."MessageEJB.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."Message.ear"."MessageEJB.jar".PARSE: WFLYSRV0153: Failed to process phase PARSE of subdeployment "MessageEJB.jar" of deployment "Message.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: org.jboss.msc.service.ServiceNotFoundException: Service service jboss.ejb.default-resource-adapter-name-service not found
at org.jboss.msc.service.ServiceContainerImpl.getRequiredService(ServiceContainerImpl.java:669)
at org.jboss.as.ejb3.deployment.processors.MessageDrivenComponentDescriptionFactory.getDefaultResourceAdapterName(MessageDrivenComponentDescriptionFactory.java:274)
at org.jboss.as.ejb3.deployment.processors.MessageDrivenComponentDescriptionFactory.processMessageBeans(MessageDrivenComponentDescriptionFactory.java:154)
at org.jboss.as.ejb3.deployment.processors.MessageDrivenComponentDescriptionFactory.processAnnotations(MessageDrivenComponentDescriptionFactory.java:81)
at org.jboss.as.ejb3.deployment.processors.AnnotatedEJBComponentDescriptionDeploymentUnitProcessor.processAnnotations(AnnotatedEJBComponentDescriptionDeploymentUnitProcessor.java:57)
at org.jboss.as.ejb3.deployment.processors.AbstractDeploymentUnitProcessor.deploy(AbstractDeploymentUnitProcessor.java:76)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
... 5 more
2015-11-20 22:02:35,648 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "Message.ear")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.subunit.\"Message.ear\".\"MessageEJB.jar\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"Message.ear\".\"MessageEJB.jar\".PARSE: WFLYSRV0153: Failed to process phase PARSE of subdeployment \"MessageEJB.jar\" of deployment \"Message.ear\"
Caused by: org.jboss.msc.service.ServiceNotFoundException: Service service jboss.ejb.default-resource-adapter-name-service not found"}}
2015-11-20 22:02:35,695 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0010: Deployed "Message.ear" (runtime-name : "Message.ear")
2015-11-20 22:02:35,695 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) WFLYCTL0183: Service status report
WFLYCTL0186: Services which failed to start: service jboss.deployment.subunit."Message.ear"."MessageEJB.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."Message.ear"."MessageEJB.jar".PARSE: WFLYSRV0153: Failed to process phase PARSE of subdeployment "MessageEJB.jar" of deployment "Message.ear"
{noformat}
was (Author: wolfgangknauf):
Just for the records: a sample for JBoss 7 including a "...hornetq-jms.xml" file can be found here[link here|http://www.cs.hs-rm.de/~knauf/JavaEE6/mdb/Message.ear]
The error on deployment is:
{noformat}
2015-11-20 22:02:35,414 INFO [org.jboss.as.repository] (DeploymentScanner-threads - 1) WFLYDR0001: Content added at location C:\Temp\wildfly-10.0.0.CR4\standalone\data\content\f0\1dbd9a8585584cfd36607ba9fc0b068557c36e\content
2015-11-20 22:02:35,429 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "Message.ear" (runtime-name: "Message.ear")
2015-11-20 22:02:35,601 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0207: Starting subdeployment (runtime-name: "MessageClient.jar")
2015-11-20 22:02:35,601 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0207: Starting subdeployment (runtime-name: "MessageEJB.jar")
2015-11-20 22:02:35,632 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.subunit."Message.ear"."MessageEJB.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."Message.ear"."MessageEJB.jar".PARSE: WFLYSRV0153: Failed to process phase PARSE of subdeployment "MessageEJB.jar" of deployment "Message.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: org.jboss.msc.service.ServiceNotFoundException: Service service jboss.ejb.default-resource-adapter-name-service not found
at org.jboss.msc.service.ServiceContainerImpl.getRequiredService(ServiceContainerImpl.java:669)
at org.jboss.as.ejb3.deployment.processors.MessageDrivenComponentDescriptionFactory.getDefaultResourceAdapterName(MessageDrivenComponentDescriptionFactory.java:274)
at org.jboss.as.ejb3.deployment.processors.MessageDrivenComponentDescriptionFactory.processMessageBeans(MessageDrivenComponentDescriptionFactory.java:154)
at org.jboss.as.ejb3.deployment.processors.MessageDrivenComponentDescriptionFactory.processAnnotations(MessageDrivenComponentDescriptionFactory.java:81)
at org.jboss.as.ejb3.deployment.processors.AnnotatedEJBComponentDescriptionDeploymentUnitProcessor.processAnnotations(AnnotatedEJBComponentDescriptionDeploymentUnitProcessor.java:57)
at org.jboss.as.ejb3.deployment.processors.AbstractDeploymentUnitProcessor.deploy(AbstractDeploymentUnitProcessor.java:76)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
... 5 more
2015-11-20 22:02:35,648 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "Message.ear")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.subunit.\"Message.ear\".\"MessageEJB.jar\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"Message.ear\".\"MessageEJB.jar\".PARSE: WFLYSRV0153: Failed to process phase PARSE of subdeployment \"MessageEJB.jar\" of deployment \"Message.ear\"
Caused by: org.jboss.msc.service.ServiceNotFoundException: Service service jboss.ejb.default-resource-adapter-name-service not found"}}
2015-11-20 22:02:35,695 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0010: Deployed "Message.ear" (runtime-name : "Message.ear")
2015-11-20 22:02:35,695 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) WFLYCTL0183: Service status report
WFLYCTL0186: Services which failed to start: service jboss.deployment.subunit."Message.ear"."MessageEJB.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."Message.ear"."MessageEJB.jar".PARSE: WFLYSRV0153: Failed to process phase PARSE of subdeployment "MessageEJB.jar" of deployment "Message.ear"
{noformat}
> Cleanup HornetQ xsd files in "docs/schema" directory
> ----------------------------------------------------
>
> Key: WFLY-5621
> URL: https://issues.jboss.org/browse/WFLY-5621
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR4
> Reporter: Wolfgang Knauf
> Assignee: Jeff Mesnil
> Priority: Minor
>
> The download zip for WildFly 10.0CR4 contains the xsd files for HornetQ messaging configurations in "docs/schema". Those are obsoleted by ActiveMQ and should be removed.
> -jboss-as-messaging-deployment_1_0.xsd (deployment of a "-jms.xml" file according to this old schema will fail with an error anyway), replaced by "wildfly-messaging-activemq-deployment_1_0.xsd")
> -jboss-as-messaging_x_y.xsd (server configuration files, replaced by "wildfly-messaging-activemq_1_0.xsd").
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5621) Cleanup HornetQ xsd files in "docs/schema" directory
by Wolfgang Knauf (JIRA)
[ https://issues.jboss.org/browse/WFLY-5621?page=com.atlassian.jira.plugin.... ]
Wolfgang Knauf commented on WFLY-5621:
--------------------------------------
Just for the records: a sample for JBoss 7 including a "...hornetq-jms.xml" file can be found here[link here|http://www.cs.hs-rm.de/~knauf/JavaEE6/mdb/Message.ear]
The error on deployment is:
{noformat}
2015-11-20 22:02:35,414 INFO [org.jboss.as.repository] (DeploymentScanner-threads - 1) WFLYDR0001: Content added at location C:\Temp\wildfly-10.0.0.CR4\standalone\data\content\f0\1dbd9a8585584cfd36607ba9fc0b068557c36e\content
2015-11-20 22:02:35,429 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "Message.ear" (runtime-name: "Message.ear")
2015-11-20 22:02:35,601 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0207: Starting subdeployment (runtime-name: "MessageClient.jar")
2015-11-20 22:02:35,601 INFO [org.jboss.as.server.deployment] (MSC service thread 1-7) WFLYSRV0207: Starting subdeployment (runtime-name: "MessageEJB.jar")
2015-11-20 22:02:35,632 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.subunit."Message.ear"."MessageEJB.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."Message.ear"."MessageEJB.jar".PARSE: WFLYSRV0153: Failed to process phase PARSE of subdeployment "MessageEJB.jar" of deployment "Message.ear"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: org.jboss.msc.service.ServiceNotFoundException: Service service jboss.ejb.default-resource-adapter-name-service not found
at org.jboss.msc.service.ServiceContainerImpl.getRequiredService(ServiceContainerImpl.java:669)
at org.jboss.as.ejb3.deployment.processors.MessageDrivenComponentDescriptionFactory.getDefaultResourceAdapterName(MessageDrivenComponentDescriptionFactory.java:274)
at org.jboss.as.ejb3.deployment.processors.MessageDrivenComponentDescriptionFactory.processMessageBeans(MessageDrivenComponentDescriptionFactory.java:154)
at org.jboss.as.ejb3.deployment.processors.MessageDrivenComponentDescriptionFactory.processAnnotations(MessageDrivenComponentDescriptionFactory.java:81)
at org.jboss.as.ejb3.deployment.processors.AnnotatedEJBComponentDescriptionDeploymentUnitProcessor.processAnnotations(AnnotatedEJBComponentDescriptionDeploymentUnitProcessor.java:57)
at org.jboss.as.ejb3.deployment.processors.AbstractDeploymentUnitProcessor.deploy(AbstractDeploymentUnitProcessor.java:76)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
... 5 more
2015-11-20 22:02:35,648 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "Message.ear")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.deployment.subunit.\"Message.ear\".\"MessageEJB.jar\".PARSE" => "org.jboss.msc.service.StartException in service jboss.deployment.subunit.\"Message.ear\".\"MessageEJB.jar\".PARSE: WFLYSRV0153: Failed to process phase PARSE of subdeployment \"MessageEJB.jar\" of deployment \"Message.ear\"
Caused by: org.jboss.msc.service.ServiceNotFoundException: Service service jboss.ejb.default-resource-adapter-name-service not found"}}
2015-11-20 22:02:35,695 INFO [org.jboss.as.server] (DeploymentScanner-threads - 1) WFLYSRV0010: Deployed "Message.ear" (runtime-name : "Message.ear")
2015-11-20 22:02:35,695 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 1) WFLYCTL0183: Service status report
WFLYCTL0186: Services which failed to start: service jboss.deployment.subunit."Message.ear"."MessageEJB.jar".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.subunit."Message.ear"."MessageEJB.jar".PARSE: WFLYSRV0153: Failed to process phase PARSE of subdeployment "MessageEJB.jar" of deployment "Message.ear"
{noformat}
> Cleanup HornetQ xsd files in "docs/schema" directory
> ----------------------------------------------------
>
> Key: WFLY-5621
> URL: https://issues.jboss.org/browse/WFLY-5621
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Affects Versions: 10.0.0.CR4
> Reporter: Wolfgang Knauf
> Assignee: Jeff Mesnil
> Priority: Minor
>
> The download zip for WildFly 10.0CR4 contains the xsd files for HornetQ messaging configurations in "docs/schema". Those are obsoleted by ActiveMQ and should be removed.
> -jboss-as-messaging-deployment_1_0.xsd (deployment of a "-jms.xml" file according to this old schema will fail with an error anyway), replaced by "wildfly-messaging-activemq-deployment_1_0.xsd")
> -jboss-as-messaging_x_y.xsd (server configuration files, replaced by "wildfly-messaging-activemq_1_0.xsd").
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (DROOLS-987) Errors in Phreak under heavy and multi threaded load
by Jose Cavieres (JIRA)
[ https://issues.jboss.org/browse/DROOLS-987?page=com.atlassian.jira.plugin... ]
Jose Cavieres updated DROOLS-987:
---------------------------------
Attachment: jbpm-bussinesruletask-concurrent-6-3-NEW.tgz
There was a problem with the old project.
Please use this instead.
> Errors in Phreak under heavy and multi threaded load
> -----------------------------------------------------
>
> Key: DROOLS-987
> URL: https://issues.jboss.org/browse/DROOLS-987
> Project: Drools
> Issue Type: Bug
> Components: core engine
> Affects Versions: 6.3.0.Final
> Environment: linux
> Java 7
> kernel 3.16
> Reporter: Jose Cavieres
> Assignee: Mario Fusco
> Attachments: jbpm-bussinesruletask-concurrent-6-3-NEW.tgz, jbpm-bussinesruletask-concurrent-6-3.tgz
>
>
> Several threads are started, each one starts 1 jbpm process containing rule(s) task(s).
> If the threads are few, everything works fine. Under heavy load nullPointerExceptions are thown most of the time, less frequently fireAllRules never ends and CPU remains at 100%.
> Aparently the setFocus method used by rule tasks is related to the problem.
> The most comon error is:
> Caused by: java.lang.NullPointerException
> at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)
> at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteSegmentMemory(LeftInputAdapterNode.java:295)
> at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteObject(LeftInputAdapterNode.java:266)
> at org.drools.core.reteoo.LeftInputAdapterNode.retractLeftTuple(LeftInputAdapterNode.java:361)
> at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:334)
> at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:317)
> at org.drools.core.reteoo.EntryPointNode.propagateRetract(EntryPointNode.java:358)
> at org.drools.core.phreak.PropagationEntry$Delete.execute(PropagationEntry.java:172)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69)
> at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (DROOLS-987) Errors in Phreak under heavy and multi threaded load
by Jose Cavieres (JIRA)
Jose Cavieres created DROOLS-987:
------------------------------------
Summary: Errors in Phreak under heavy and multi threaded load
Key: DROOLS-987
URL: https://issues.jboss.org/browse/DROOLS-987
Project: Drools
Issue Type: Bug
Components: core engine
Affects Versions: 6.3.0.Final
Environment: linux
Java 7
kernel 3.16
Reporter: Jose Cavieres
Assignee: Mario Fusco
Attachments: jbpm-bussinesruletask-concurrent-6-3.tgz
Several threads are started, each one starts 1 jbpm process containing rule(s) task(s).
If the threads are few, everything works fine. Under heavy load nullPointerExceptions are thown most of the time, less frequently fireAllRules never ends and CPU remains at 100%.
Aparently the setFocus method used by rule tasks is related to the problem.
The most comon error is:
Caused by: java.lang.NullPointerException
at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)
at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80)
at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteSegmentMemory(LeftInputAdapterNode.java:295)
at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteObject(LeftInputAdapterNode.java:266)
at org.drools.core.reteoo.LeftInputAdapterNode.retractLeftTuple(LeftInputAdapterNode.java:361)
at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:334)
at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:317)
at org.drools.core.reteoo.EntryPointNode.propagateRetract(EntryPointNode.java:358)
at org.drools.core.phreak.PropagationEntry$Delete.execute(PropagationEntry.java:172)
at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69)
at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5719) Using Kerberos as login module results in LoginException: unable to find LoginModule class
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-5719?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-5719:
----------------------------------------
I would say in your case you probably would not gain by using it, the changes we added were more in relation to manipulating the Subject that is used for outbound database connections where Kerberos is used for authentication and also where we have delegated credentials - if you are not doing any of that it is just a very thin wrapper that selects the module based on availability.
> Using Kerberos as login module results in LoginException: unable to find LoginModule class
> ------------------------------------------------------------------------------------------
>
> Key: WFLY-5719
> URL: https://issues.jboss.org/browse/WFLY-5719
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 9.0.2.Final, 10.0.0.CR4
> Environment: Windows Server 2012 R2, Java 8 update 40
> Reporter: Brett Prucha
> Assignee: Darran Lofthouse
>
> When using <login-module code="Kerberos" flag="required">, the following exception is thrown:
> javax.security.auth.login.LoginException: unable to find LoginModule class: org.jboss.security.negotiation.KerberosLoginModule
> When replacing the login module with the one provided by the JVM:
> <login-module code="com.sun.security.auth.module.Krb5LoginModule" flag="required">
> no exception is thrown and authentication works as expected.
> The Kerberos login module works in Wildfly 8.2.0. It appears the class loading or something similar has changed in 9.x onwards to cause this to stop working.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months