[JBoss JIRA] (WFLY-5835) Mean response times in soak test exceed 1000 milliseconds
by Michal Vinkler (JIRA)
[ https://issues.jboss.org/browse/WFLY-5835?page=com.atlassian.jira.plugin.... ]
Michal Vinkler commented on WFLY-5835:
--------------------------------------
ER5 run: results with dist-ASYNC settings:
http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-clustering-soa...
example: Nodes: 4, Sessions: 2000, response min: 0 ms, mean: 1 ms, max: 238 ms, sampling errors: 0, unhealthy samples: 0, valid samples: 706629 (100%)
Mean response times are back to 1 ms!
> Mean response times in soak test exceed 1000 milliseconds
> ---------------------------------------------------------
>
> Key: WFLY-5835
> URL: https://issues.jboss.org/browse/WFLY-5835
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.0.0.CR4
> Reporter: Michal Vinkler
> Assignee: Paul Ferraro
>
> The responses in soak test reach really high values (hundreds of ms) compared to EAP 6 (max 10 ms). Also number of unhealthy samples (samples which arrive later than in 3 seconds) is really high in EAP7 run compared to 0 unhealthy samples in EAP6 run.
> EAP7 run also logs few sampling errors in almost each iteration, EAP6 did not.
> Compare these results:
> EAP7: [performance.txt|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7...]
> (example:
> response min: 0 ms, mean: 965 ms, max: 16034 ms, sampling errors: 5, unhealthy samples: 86209)
> EAP6: [performance.txt|http://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-6...]
> (example:
> response min: 0 ms, mean: 6 ms, max: 1053 ms, sampling errors: 0, unhealthy samples: 0)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (DROOLS-1053) Change date formats for JSON representations used in the REST API
by William Siqueira (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1053?page=com.atlassian.jira.plugi... ]
William Siqueira commented on DROOLS-1053:
------------------------------------------
Hello Maciej, I was not aware of this system parameter, thanks! It seems enough to me, I was just afraid that it could be a problem when generating requests to the server. Regarding changing the actual pattern, I have prepared a PR for this (to save you some time), it is not a problem at all if you want to refuse it:
https://github.com/droolsjbpm/droolsjbpm-integration/pull/289
Thanks again and sorry for not checking upstream, I had only checked 6.3.x :-)
> Change date formats for JSON representations used in the REST API
> -----------------------------------------------------------------
>
> Key: DROOLS-1053
> URL: https://issues.jboss.org/browse/DROOLS-1053
> Project: Drools
> Issue Type: Feature Request
> Components: kie server
> Affects Versions: 6.3.0.Final
> Environment: jBPM 6.3 running on Wildfly 8.2
> Reporter: William Siqueira
> Assignee: Maciej Swiderski
>
> The format for dates are are using milliseconds form, for example:
> {code:javascript}
> {
> "request-instance-id" : 4,
> "request-status" : "QUEUED",
> "request-message" : "Ready to execute",
> "request-retries" : 3,
> "request-executions" : 0,
> "request-command" : "org.jbpm.executor.commands.PrintOutCommand",
> "request-scheduled-date" : 1455069600000
> }
> {code}
> The problem with this format is that it is not readable and might confuse users using other ways to communicate with the kie server than using its REST API.
> The suggested solution is use a Jackson object mapper to configure the desired date format. This is better explained in this article:
> http://wiki.fasterxml.com/JacksonFAQDateHandling
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6147) Potential NPE when using database backed timers
by Stuart Douglas (JIRA)
Stuart Douglas created WFLY-6147:
------------------------------------
Summary: Potential NPE when using database backed timers
Key: WFLY-6147
URL: https://issues.jboss.org/browse/WFLY-6147
Project: WildFly
Issue Type: Bug
Components: EJB
Reporter: Stuart Douglas
Assignee: Stuart Douglas
{code}
at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: java.lang.NullPointerException
at org.jboss.as.ejb3.timerservice.TimerServiceImpl.getActivePersistentTimers(TimerServiceImpl.java:961)
at org.jboss.as.ejb3.timerservice.TimerServiceImpl.restoreTimers(TimerServiceImpl.java:699)
at org.jboss.as.ejb3.timerservice.TimerServiceImpl.activate(TimerServiceImpl.java:226)
at org.jboss.as.ejb3.component.EJBComponent.start(EJBComponent.java:543)
at org.jboss.as.ejb3.component.stateless.StatelessSessionComponent.start(StatelessSessionComponent.java:114)
at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
... 6 more
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6146) Potential NPE when using database backed timers
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-6146?page=com.atlassian.jira.plugin.... ]
Stuart Douglas updated WFLY-6146:
---------------------------------
Description:
{code}
at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at org.jboss.threads.JBossThread.run(JBossThread.java:320)
Caused by: java.lang.NullPointerException
at org.jboss.as.ejb3.timerservice.TimerServiceImpl.getActivePersistentTimers(TimerServiceImpl.java:961)
at org.jboss.as.ejb3.timerservice.TimerServiceImpl.restoreTimers(TimerServiceImpl.java:699)
at org.jboss.as.ejb3.timerservice.TimerServiceImpl.activate(TimerServiceImpl.java:226)
at org.jboss.as.ejb3.component.EJBComponent.start(EJBComponent.java:543)
at org.jboss.as.ejb3.component.stateless.StatelessSessionComponent.start(StatelessSessionComponent.java:114)
at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
... 6 more
{code}
> Potential NPE when using database backed timers
> -----------------------------------------------
>
> Key: WFLY-6146
> URL: https://issues.jboss.org/browse/WFLY-6146
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
>
> {code}
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:57)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> Caused by: java.lang.NullPointerException
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.getActivePersistentTimers(TimerServiceImpl.java:961)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.restoreTimers(TimerServiceImpl.java:699)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.activate(TimerServiceImpl.java:226)
> at org.jboss.as.ejb3.component.EJBComponent.start(EJBComponent.java:543)
> at org.jboss.as.ejb3.component.stateless.StatelessSessionComponent.start(StatelessSessionComponent.java:114)
> at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> ... 6 more
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6145) Wildfly 10.0.0.Final duplitates contents of <jsp-config><include-prelude> or <include-coda> directives in web.xml
by Stuart Douglas (JIRA)
Stuart Douglas created WFLY-6145:
------------------------------------
Summary: Wildfly 10.0.0.Final duplitates contents of <jsp-config><include-prelude> or <include-coda> directives in web.xml
Key: WFLY-6145
URL: https://issues.jboss.org/browse/WFLY-6145
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 10.0.0.Final
Environment: Ubuntu Linux 14.04 amd64
Reporter: Juanm Manuel Enrique Muñido
Assignee: Stuart Douglas
I have been successfully deploying an application on WildFly 8.2.1 and WildFly 9.0.2 versions with the following <jsp-config> directives in web.xml deployment descriptor:
<jsp-config>
<jsp-property-group>
<description>header and footer settings</description>
<url-pattern>/WEB-INF/view/*</url-pattern>
<url-pattern>/WEB-INF/error/*</url-pattern>
<include-prelude>/WEB-INF/jspf/header.jspf</include-prelude>
<include-coda>/WEB-INF/jspf/footer.jspf</include-coda>
</jsp-property-group>
</jsp-config>
This code fragment includes the contents of /WEB-INF/jspf/header.jspf at the beginning of each .jsp file and <include-coda>/WEB-INF/jspf/footer.jspf</include-coda> at the end of each .jsp file that matches the <url-pattern>.
But when I try to deploy this application with the same deployment descriptor in WildFly 10.0.0.Final, the contents of /WEB-INF/jspf/header.jspf and /WEB-INF/jspf/footer.jspf are included twice in each .jsp file that matches the <url-pattern>.
If I add another <url-pattern> line, then the contents of /WEB-INF/jspf/header.jspf and /WEB-INF/jspf/footer.jspf are included three times, and so on.
Any suggestion about this issue?
Is this a deployment descriptor issue or a configuration issue in the standalone.xml of WildFly 10.0.0.Final version?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (JGRP-2014) FILE_PING destination file name can include File.separator characters
by Alan Field (JIRA)
Alan Field created JGRP-2014:
--------------------------------
Summary: FILE_PING destination file name can include File.separator characters
Key: JGRP-2014
URL: https://issues.jboss.org/browse/JGRP-2014
Project: JGroups
Issue Type: Bug
Reporter: Alan Field
Assignee: Bela Ban
I was attempting to use FILE_PING as the discovery protocol with Infinispan server and the following configuration:
{noformat}
<protocol type="FILE_PING">
<property name="location">${jgroups.file.dir:/Users/afield/Documents}</property>
</protocol>
{noformat}
However, the following exceptions occur when I try to start the server:
{noformat}
15:34:41,662 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-11) ISPN000078: Starting JGroups Channel
15:34:41,675 ERROR [org.jgroups.protocols.FILE_PING] (MSC service thread 1-11) attempt to write data failed at clustered : clustered.list: java.io.FileNotFoundException: /Users/afield/Documents/clustered/3e5f03c6-c297-474a-cb72-1ca0841f8e5c.afield-osx/clustered.list (No such file or directory)
at java.io.FileOutputStream.open0(Native Method) [rt.jar:1.8.0_72]
at java.io.FileOutputStream.open(FileOutputStream.java:270) [rt.jar:1.8.0_72]
at java.io.FileOutputStream.<init>(FileOutputStream.java:213) [rt.jar:1.8.0_72]
at java.io.FileOutputStream.<init>(FileOutputStream.java:162) [rt.jar:1.8.0_72]
at org.jgroups.protocols.FILE_PING.write(FILE_PING.java:294) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
at org.jgroups.protocols.FILE_PING.findMembers(FILE_PING.java:116) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
at org.jgroups.protocols.Discovery.findMembers(Discovery.java:240) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
at org.jgroups.protocols.Discovery.down(Discovery.java:380) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
at org.jgroups.protocols.FILE_PING.down(FILE_PING.java:107) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
at org.jgroups.protocols.MERGE3.down(MERGE3.java:255) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
at org.jgroups.protocols.FD_SOCK.down(FD_SOCK.java:360) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
at org.jgroups.protocols.FD_ALL.down(FD_ALL.java:233) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
at org.jgroups.protocols.VERIFY_SUSPECT.down(VERIFY_SUSPECT.java:92) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
at org.jgroups.protocols.pbcast.NAKACK2.down(NAKACK2.java:589) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
at org.jgroups.protocols.UNICAST3.down(UNICAST3.java:669) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
at org.jgroups.protocols.pbcast.STABLE.down(STABLE.java:347) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
at org.jgroups.protocols.pbcast.ClientGmsImpl.joinInternal(ClientGmsImpl.java:76) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
at org.jgroups.protocols.pbcast.ClientGmsImpl.join(ClientGmsImpl.java:41) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
at org.jgroups.protocols.pbcast.GMS.down(GMS.java:1087) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
at org.jgroups.protocols.FlowControl.down(FlowControl.java:353) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
at org.jgroups.protocols.FRAG2.down(FRAG2.java:136) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
at org.jgroups.stack.ProtocolStack.down(ProtocolStack.java:1038) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
at org.jgroups.JChannel.down(JChannel.java:791) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
at org.jgroups.JChannel._connect(JChannel.java:564) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
at org.jgroups.JChannel.connect(JChannel.java:294) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
at org.jgroups.JChannel.connect(JChannel.java:279) [jgroups-3.6.3.Final-redhat-4.jar:3.6.3.Final-redhat-4]
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.startJGroupsChannelIfNeeded(JGroupsTransport.java:208) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
at org.infinispan.remoting.transport.jgroups.JGroupsTransport.start(JGroupsTransport.java:199) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [rt.jar:1.8.0_72]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [rt.jar:1.8.0_72]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [rt.jar:1.8.0_72]
at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_72]
at org.infinispan.commons.util.ReflectionUtil.invokeAccessibly(ReflectionUtil.java:176) [infinispan-commons-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
at org.infinispan.factories.AbstractComponentRegistry$PrioritizedMethod.invoke(AbstractComponentRegistry.java:870) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
at org.infinispan.factories.AbstractComponentRegistry.invokeStartMethods(AbstractComponentRegistry.java:639) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
at org.infinispan.factories.AbstractComponentRegistry.internalStart(AbstractComponentRegistry.java:628) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
at org.infinispan.factories.AbstractComponentRegistry.start(AbstractComponentRegistry.java:531) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
at org.infinispan.factories.GlobalComponentRegistry.start(GlobalComponentRegistry.java:238) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
at org.infinispan.manager.DefaultCacheManager.wireAndStartCache(DefaultCacheManager.java:583) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
at org.infinispan.manager.DefaultCacheManager.createCache(DefaultCacheManager.java:549) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:420) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
at org.infinispan.manager.DefaultCacheManager.getCache(DefaultCacheManager.java:434) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:89) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
at org.jboss.as.clustering.infinispan.DefaultEmbeddedCacheManager.getCache(DefaultEmbeddedCacheManager.java:80) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
at org.infinispan.server.infinispan.SecurityActions$4.run(SecurityActions.java:105) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
at org.infinispan.server.infinispan.SecurityActions$4.run(SecurityActions.java:102) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
at org.infinispan.security.Security.doPrivileged(Security.java:76) [infinispan-core-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
at org.infinispan.server.infinispan.SecurityActions.doPrivileged(SecurityActions.java:49) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
at org.infinispan.server.infinispan.SecurityActions.startCache(SecurityActions.java:110) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
at org.jboss.as.clustering.infinispan.subsystem.CacheService.start(CacheService.java:85) [infinispan-server-infinispan-6.4.0.Final-redhat-4.jar:6.4.0.Final-redhat-4]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_72]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_72]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_72]
{noformat}
>From looking at the code, FILE_PING creates the {{/Users/afield/Documents/clustered}} directory, but the problem is that the {{local_addr}} for the host is {{afield-osx/clustered}}, so {{destination}} is defined as {{75b5c5b8-014d-26ff-c400-5398a96ad3f4.afield-osx/clustered.list}} when {{addressToFilename()}} is called and then the subsequent write fails. File.separator need to be removed or replaced in the {{destination}} variable.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months