[JBoss JIRA] (WFLY-2611) Support CDI injection in various JSF artifacts
by Tomas Remes (JIRA)
[ https://issues.jboss.org/browse/WFLY-2611?page=com.atlassian.jira.plugin.... ]
Tomas Remes updated WFLY-2611:
------------------------------
Component/s: JSF
> Support CDI injection in various JSF artifacts
> ----------------------------------------------
>
> Key: WFLY-2611
> URL: https://issues.jboss.org/browse/WFLY-2611
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: CDI / Weld, JSF
> Reporter: Tomas Remes
> Assignee: Stuart Douglas
>
> If I understand correctly to the subchapter "5.4.1
> JSF Managed Classes and Java EE Annotations" of JSF 2.2 specification, there should be opportunity to use a lot of (and not only) CDI annotations in various JSF artifacts (ActionListener, SystemEventListener, etc. - for full list, please see the spec).
> So far I tried locally this (will be filling the table during time):
> ||JSF artifact||CDI Injection||
> |javax.el.ELResolver|works|
> |javax.faces.application.ApplicationFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.application.NavigationHandler|works|
> |javax.faces.application.ResourceHandler|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.application.StateManager|works (however there is question about availability of injected instances in constructor of this custom delegating object|
> |javax.faces.component.visit.VisitContextFactory|works|
> |javax.faces.context.ExceptionHandlerFactory|works|
> |javax.faces.context.ExternalContextFactory|works|
> |javax.faces.context.FacesContextFactory|works|
> |javax.faces.context.FlashFactory|works|
> |javax.faces.context.PartialViewContextFactory|works|
> |javax.faces.event.ActionListener|works only when specified also in faces-config|
> |javax.faces.event.SystemEventListener|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.lifecycle.ClientWindowFactory|works|
> |javax.faces.lifecycle.LifecycleFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.lifecycle.PhaseListener|works|
> |javax.faces.render.RenderKitFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.view.ViewDeclarationLanguageFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.view.facelets.FaceletCacheFactory|works only for ApplicationScoped and Dependent scoped beans - probably reasonable ?|
> |javax.faces.view.facelets.TagHandlerDelegateFactory|works|
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JBWEB-287) Websocket application working with multiple clients (e.g. chat style applications) fails due NullPointerException
by Radim Hatlapatka (JIRA)
[ https://issues.jboss.org/browse/JBWEB-287?page=com.atlassian.jira.plugin.... ]
Radim Hatlapatka updated JBWEB-287:
-----------------------------------
Attachment: byteslounge.war
The test websocket app
> Websocket application working with multiple clients (e.g. chat style applications) fails due NullPointerException
> -----------------------------------------------------------------------------------------------------------------
>
> Key: JBWEB-287
> URL: https://issues.jboss.org/browse/JBWEB-287
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Core
> Reporter: Radim Hatlapatka
> Assignee: Remy Maucherat
> Priority: Critical
> Attachments: byteslounge.war
>
>
> When trying to run websocket application with jbossweb 7.4.0.Beta1 (with EAP 6.2.0), websocket connection is successfully established but upon a message sent NullPointerException is thrown:
> {noformat}
> 11:47:27,176 ERROR [org.apache.catalina.core.StandardWrapperValve] (http-localhost.localdomain/127.0.0.1:8080-25) JBWEB000374: IO listener processing for servlet default threw exception: java.lang.NullPointerException
> at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.onWritePossible(WsRemoteEndpointImplServer.java:92) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsWriteListener.onWritePossible(WsHttpUpgradeHandler.java:232) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:603) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:247) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:228) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:230) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:917) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> 11:47:27,177 ERROR [org.apache.tomcat.websocket.pojo.PojoEndpointBase] (http-localhost.localdomain/127.0.0.1:8080-25) JBWEB008809: No error handling configured for [com.byteslounge.websockets.WebSocketTest] and the following error occurred: java.io.EOFException
> at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:553) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:247) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:237) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:230) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:917) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> 11:47:27,178 ERROR [org.apache.tomcat.websocket.pojo.PojoEndpointBase] (http-localhost.localdomain/127.0.0.1:8080-25) JBWEB008809: No error handling configured for [com.byteslounge.websockets.WebSocketTest] and the following error occurred: java.io.EOFException
> at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:553) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:247) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:237) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:230) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:917) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
> {noformat}
> The same application correctly works with Tomcat 7
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JBWEB-287) Websocket application working with multiple clients (e.g. chat style applications) fails due NullPointerException
by Radim Hatlapatka (JIRA)
Radim Hatlapatka created JBWEB-287:
--------------------------------------
Summary: Websocket application working with multiple clients (e.g. chat style applications) fails due NullPointerException
Key: JBWEB-287
URL: https://issues.jboss.org/browse/JBWEB-287
Project: JBoss Web
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Core
Reporter: Radim Hatlapatka
Assignee: Remy Maucherat
Priority: Critical
When trying to run websocket application with jbossweb 7.4.0.Beta1 (with EAP 6.2.0), websocket connection is successfully established but upon a message sent NullPointerException is thrown:
{noformat}
11:47:27,176 ERROR [org.apache.catalina.core.StandardWrapperValve] (http-localhost.localdomain/127.0.0.1:8080-25) JBWEB000374: IO listener processing for servlet default threw exception: java.lang.NullPointerException
at org.apache.tomcat.websocket.server.WsRemoteEndpointImplServer.onWritePossible(WsRemoteEndpointImplServer.java:92) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.tomcat.websocket.server.WsHttpUpgradeHandler$WsWriteListener.onWritePossible(WsHttpUpgradeHandler.java:232) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:603) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:247) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:228) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:230) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:917) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
11:47:27,177 ERROR [org.apache.tomcat.websocket.pojo.PojoEndpointBase] (http-localhost.localdomain/127.0.0.1:8080-25) JBWEB008809: No error handling configured for [com.byteslounge.websockets.WebSocketTest] and the following error occurred: java.io.EOFException
at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:553) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:247) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:237) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:230) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:917) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
11:47:27,178 ERROR [org.apache.tomcat.websocket.pojo.PojoEndpointBase] (http-localhost.localdomain/127.0.0.1:8080-25) JBWEB008809: No error handling configured for [com.byteslounge.websockets.WebSocketTest] and the following error occurred: java.io.EOFException
at org.apache.catalina.core.StandardWrapperValve.async(StandardWrapperValve.java:553) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.catalina.core.StandardWrapperValve.event(StandardWrapperValve.java:350) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.catalina.core.StandardContextValve.event(StandardContextValve.java:171) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.catalina.core.StandardHostValve.event(StandardHostValve.java:247) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.catalina.valves.ValveBase.event(ValveBase.java:185) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.catalina.core.StandardEngineValve.event(StandardEngineValve.java:121) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.catalina.connector.CoyoteAdapter.event(CoyoteAdapter.java:237) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.coyote.http11.Http11NioProcessor.event(Http11NioProcessor.java:230) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.coyote.http11.Http11NioProtocol$Http11ConnectionHandler.event(Http11NioProtocol.java:818) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at org.apache.tomcat.util.net.NioEndpoint$ChannelProcessor.run(NioEndpoint.java:917) [jbossweb-7.4.0.Beta1.jar:7.4.0.Beta1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45]
at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45]
{noformat}
The same application correctly works with Tomcat 7
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (WFLY-2456) Using add-user.bat for initial admin user results in "JBAS015234: No mgmt-groups.properties files found"
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2456?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-2456:
-----------------------------------
Fix Version/s: 9.0.0.CR1
(was: 8.0.0.Final)
> Using add-user.bat for initial admin user results in "JBAS015234: No mgmt-groups.properties files found"
> --------------------------------------------------------------------------------------------------------
>
> Key: WFLY-2456
> URL: https://issues.jboss.org/browse/WFLY-2456
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Scripts
> Affects Versions: 8.0.0.Beta1
> Environment: Windows 7, 32-bit, jdk1.7.0_45
> Reporter: John Lusk
> Assignee: Darran Lofthouse
> Fix For: 9.0.0.CR1
>
>
> Just getting started w/Wildfly after a long absence from Java. Fresh download, trying to hit admin console, got instructed to use add-user to add an admin user.
> c:\usr\local\wildfly-8.0.0.Beta1\bin>.\add-user.bat
> What type of user do you wish to add?
> a) Management User (mgmt-users.properties)
> b) Application User (application-users.properties)
> (a): a
> * Error *
> JBAS015234: No mgmt-groups.properties files found.
> Press any key to continue . . .
> c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %JBOSS_HOME%
> C:\usr\local\wildfly-8.0.0.Beta1
> c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %JAVA_HOME%
> C:\java\jdk1.7.0_45
> c:\usr\local\wildfly-8.0.0.Beta1\bin>echo %M2_HOME%
> C:\usr\local\Maven\3.1.1
> c:\usr\local\wildfly-8.0.0.Beta1\bin>mvn -version
> Apache Maven 3.1.1 (0728685237757ffbf44136acec0402957f723d9a; 2013-09-17 11:22:2
> 2-0400)
> Maven home: C:\usr\local\Maven\3.1.1
> Java version: 1.7.0_45, vendor: Oracle Corporation
> Java home: C:\java\jdk1.7.0_45\jre
> Default locale: en_US, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
> c:\usr\local\wildfly-8.0.0.Beta1\bin>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JGRP-1717) Bundling reduces performance in scenario mimicking Inifinispan
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1717?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1717 at 1/6/14 5:19 AM:
--------------------------------------------------------
Comments:
* DONT_BUNDLE is ignored when sending a message *except for SSWT*
** That's why SSWT -B is slow: messages are not bundled
* SSWT had quite a high variation between runs
* SS is slow with only 1 sender thread
** With 2 threads SS (-B/+B) achived ~ 118
* TQ achieved the highest perf regardless of the number of senders. Note that 120'000 msgs/sec ~= 120MB/sec, that's close to the max throughput of 1Gbps ethernet of 125MB/sec
was (Author: belaban):
Comments:
* DONT_BUNDLE is ignored when sending a message *except for SSWT*
** That's why SSWT -B is slow: messages are not bundled
* SSWT had quite a high variation between runs
* SS is slow with only 1 sender thread
** With 2 threads SS (-B/+B) achived ~ 118
> Bundling reduces performance in scenario mimicking Inifinispan
> --------------------------------------------------------------
>
> Key: JGRP-1717
> URL: https://issues.jboss.org/browse/JGRP-1717
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance.
> See attached configurations and results.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JGRP-1717) Bundling reduces performance in scenario mimicking Inifinispan
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1717?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1717 at 1/6/14 5:17 AM:
--------------------------------------------------------
Tested perf with UnicastTest (measures throughput *not* latency)
Environment:
- cluster-xx lab, 1Gbps network (~125MB/sec)
- 2 nodes: sender on cluster01 and receiver on cluster02
- fast.xml with ip_ttl=1
-- ignore_dont_bundle=true (default)
- Sending 100'000 1K messages
Perf was measured with bundler_type
* {{sender-sends-with-timer}} (SSWT)
* {{transfer-queue}} (TQ)
* {{sender-sends}} (SS)
* Using {{DONT_BUNDLE}} (+B) or off (-B)
The results are (in 1000 msgs/sec):
|| sender threads || SSWT (-B) || SSWT (+B) || TQ (-B) || TQ (+B) || SS (-B) || SS (+B) ||
| 1 | 70 | 120 | 120 | 120 | 73 | 73 |
| 4 | 77 | 112 | 120 | 120 | 120 | 120 |
| 10 | 75 | 108 | 120 | 120 | 120 | 120 |
| 25 | 75 | 100 | 120 | 120 | 120 | 120 |
was (Author: belaban):
Tested perf with UnicastTest (measures throughput *not* latency)
Environment:
- cluster-xx lab, 1Gbps network (~125MB/sec)
- 2 nodes: sender on cluster01 and receiver on cluster02
- fast.xml with ip_ttl=1
-- ignore_dont_bundle=true (default)
- Sending 100'000 1K messages
Perf was measured with bundler_type
* {{sender-sends-with-timer}} (SSWT)
* {{transfer-queue}} (TQ)
* {{sender-sends}} (SS)
* Using {{DONT_BUNDLE}} (+B) or off (-B)
|| sender threads || SSWT (-B) || SSWT (+B) || TQ (-B) || TQ (+B) || SS (-B) || SS (+B) ||
| 1 | 70 | 120 | 120 | 120 | 73 | 73 |
| 4 | 77 | 112 | 120 | 120 | 120 | 120 |
| 10 | 75 | 108 | 120 | 120 | 120 | 120 |
| 25 | 75 | 100 | 120 | 120 | 120 | 120 |
> Bundling reduces performance in scenario mimicking Inifinispan
> --------------------------------------------------------------
>
> Key: JGRP-1717
> URL: https://issues.jboss.org/browse/JGRP-1717
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance.
> See attached configurations and results.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JGRP-1717) Bundling reduces performance in scenario mimicking Inifinispan
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1717?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1717:
--------------------------------
Comments:
* DONT_BUNDLE is ignored when sending a message *except for SSWT*
** That's why SSWT -B is slow: messages are not bundled
* SSWT had quite a high variation between runs
* SS is slow with only 1 sender thread
** With 2 threads SS (-B/+B) achived ~ 118
> Bundling reduces performance in scenario mimicking Inifinispan
> --------------------------------------------------------------
>
> Key: JGRP-1717
> URL: https://issues.jboss.org/browse/JGRP-1717
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance.
> See attached configurations and results.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months
[JBoss JIRA] (JGRP-1717) Bundling reduces performance in scenario mimicking Inifinispan
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1717?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1717:
--------------------------------
Tested perf with UnicastTest (measures throughput *not* latency)
Environment:
- cluster-xx lab, 1Gbps network (~125MB/sec)
- 2 nodes: sender on cluster01 and receiver on cluster02
- fast.xml with ip_ttl=1
-- ignore_dont_bundle=true (default)
- Sending 100'000 1K messages
Perf was measured with bundler_type
* {{sender-sends-with-timer}} (SSWT)
* {{transfer-queue}} (TQ)
* {{sender-sends}} (SS)
* Using {{DONT_BUNDLE}} (+B) or off (-B)
|| sender threads || SSWT (-B) || SSWT (+B) || TQ (-B) || TQ (+B) || SS (-B) || SS (+B) ||
| 1 | 70 | 120 | 120 | 120 | 73 | 73 |
| 4 | 77 | 112 | 120 | 120 | 120 | 120 |
| 10 | 75 | 108 | 120 | 120 | 120 | 120 |
| 25 | 75 | 100 | 120 | 120 | 120 | 120 |
> Bundling reduces performance in scenario mimicking Inifinispan
> --------------------------------------------------------------
>
> Key: JGRP-1717
> URL: https://issues.jboss.org/browse/JGRP-1717
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 3.3
> Reporter: Radim Vansa
> Assignee: Bela Ban
> Fix For: 3.5
>
> Attachments: benchmark-jgroups.xml, jgroups-udp.pdf, jgroups-udp.xml
>
>
> In Radargun benchmark of JGroups mimicking the behaviour of Infinispan we can see that performance with bundling on actually reduces the performance.
> See attached configurations and results.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 4 months