[JBoss JIRA] (AS7-6428) Using Session Scope CDI bean does not work in a HttpSessionListener
by Alexis Hassler (JIRA)
[ https://issues.jboss.org/browse/AS7-6428?page=com.atlassian.jira.plugin.s... ]
Alexis Hassler edited comment on AS7-6428 at 2/5/13 3:08 AM:
-------------------------------------------------------------
I've reproduced your bug on several AS7 versions (7.1.2, 7.1.3, 7.1.4-SNAPSHOT) and EAP versions (6.0.0, 6.0.1).
My sample code (with an Arquillian test) is on github : https://github.com/hasalex/jboss-samples/tree/master/session-listener
was (Author: sewatech):
I've reproduced your bug on several AS7 versions (7.1.2, 7.1.3, 7.1.4-SNAPSHOT) and EAP versions (6.0.0, 6.0.1).
My sample code (with an Arquillian test) is on github : https://github.com/hasalex/jboss-samples/tree/master/sessionlistener
> Using Session Scope CDI bean does not work in a HttpSessionListener
> -------------------------------------------------------------------
>
> Key: AS7-6428
> URL: https://issues.jboss.org/browse/AS7-6428
> Project: Application Server 7
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 7.1.1.Final
> Environment: linux 64bits, win7 64 bits
> Reporter: nicolas marchais
> Assignee: Stuart Douglas
> Fix For: No Release
>
>
> JBoss AS 7.1.x has a bug with using session bean scope in a HttpSessionListener.
> When i inject a session scope bean in a HttpSessionListener and i try to populate attribute in sessionCreated() method many HttpSession are created by JBoss AS. Is it normal the a web server create many Http session for the same request ?
> Normally, this behaviour should work. See : http://docs.jboss.org/cdi/api/1.1-PRD/javax/enterprise/context/SessionSco...
> I did a light Web Project to explain the problem with 1 JSP, 1 SessionScope bean and 1 HttpSessionListener.
> Here is the code.
> JSP page :
> <%@ page language="java" contentType="text/html; charset=UTF-8"
> pageEncoding="UTF-8"%>
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
> <html>
> <head>
> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
> <title>Insert title here</title>
> </head>
> <body>
> </body>
> </html>
> SessionScope bean :
> @Named
> @SessionScoped
> public class UserState implements Serializable {
> private int state;
> public int getState() {
> return state;
> }
> public void setState(int state) {
> this.state = state;
> }
> }
> HttpSessionListener :
> @WebListener
> public class SessionListener implements HttpSessionListener {
> @Inject private UserState userState;
>
> @Override
> public void sessionCreated(HttpSessionEvent event) {
> System.out.println("New HTTP Session created : " + event.getSession().getId());
> userState.setState(2);
> }
> @Override
> public void sessionDestroyed(HttpSessionEvent event) {}
> }
> After execution, you can read in the console at least 2 http session creation like this :
> New HTTP Session created : zvlF6vGLP1AaXM-rzFU02wAJ.undefined
> New HTTP Session created : TlrmmA8Eu4v32SHDT0QBBZza.undefined
> The first session seams to be the one which is used by the client. There is one more problem : The polutated attributes of the session scope bean are ignored after HttpSessionListener execution. At the end all session scope attributes are null.
--
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
13 years, 5 months
[JBoss JIRA] (AS7-6428) Using Session Scope CDI bean does not work in a HttpSessionListener
by Alexis Hassler (JIRA)
[ https://issues.jboss.org/browse/AS7-6428?page=com.atlassian.jira.plugin.s... ]
Alexis Hassler edited comment on AS7-6428 at 2/5/13 3:05 AM:
-------------------------------------------------------------
I've reproduced your bug on several AS7 versions (7.1.2, 7.1.3, 7.1.4-SNAPSHOT) and EAP versions (6.0.0, 6.0.1).
My sample code (with an Arquillian test) is on github : https://github.com/hasalex/jboss-samples/tree/master/sessionlistener
was (Author: sewatech):
I've reproduced your bug on several AS7 versions (7.1.2, 7.1.3, 7.1.4-SNAPSHOT) and EAP versions (6.0.0, 6.0.1).
My sample code is on github : https://github.com/hasalex/jboss-samples/tree/master/sessionlistener
> Using Session Scope CDI bean does not work in a HttpSessionListener
> -------------------------------------------------------------------
>
> Key: AS7-6428
> URL: https://issues.jboss.org/browse/AS7-6428
> Project: Application Server 7
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 7.1.1.Final
> Environment: linux 64bits, win7 64 bits
> Reporter: nicolas marchais
> Assignee: Stuart Douglas
> Fix For: No Release
>
>
> JBoss AS 7.1.x has a bug with using session bean scope in a HttpSessionListener.
> When i inject a session scope bean in a HttpSessionListener and i try to populate attribute in sessionCreated() method many HttpSession are created by JBoss AS. Is it normal the a web server create many Http session for the same request ?
> Normally, this behaviour should work. See : http://docs.jboss.org/cdi/api/1.1-PRD/javax/enterprise/context/SessionSco...
> I did a light Web Project to explain the problem with 1 JSP, 1 SessionScope bean and 1 HttpSessionListener.
> Here is the code.
> JSP page :
> <%@ page language="java" contentType="text/html; charset=UTF-8"
> pageEncoding="UTF-8"%>
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
> <html>
> <head>
> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
> <title>Insert title here</title>
> </head>
> <body>
> </body>
> </html>
> SessionScope bean :
> @Named
> @SessionScoped
> public class UserState implements Serializable {
> private int state;
> public int getState() {
> return state;
> }
> public void setState(int state) {
> this.state = state;
> }
> }
> HttpSessionListener :
> @WebListener
> public class SessionListener implements HttpSessionListener {
> @Inject private UserState userState;
>
> @Override
> public void sessionCreated(HttpSessionEvent event) {
> System.out.println("New HTTP Session created : " + event.getSession().getId());
> userState.setState(2);
> }
> @Override
> public void sessionDestroyed(HttpSessionEvent event) {}
> }
> After execution, you can read in the console at least 2 http session creation like this :
> New HTTP Session created : zvlF6vGLP1AaXM-rzFU02wAJ.undefined
> New HTTP Session created : TlrmmA8Eu4v32SHDT0QBBZza.undefined
> The first session seams to be the one which is used by the client. There is one more problem : The polutated attributes of the session scope bean are ignored after HttpSessionListener execution. At the end all session scope attributes are null.
--
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
13 years, 5 months
[JBoss JIRA] (AS7-6428) Using Session Scope CDI bean does not work in a HttpSessionListener
by Alexis Hassler (JIRA)
[ https://issues.jboss.org/browse/AS7-6428?page=com.atlassian.jira.plugin.s... ]
Alexis Hassler edited comment on AS7-6428 at 2/5/13 2:56 AM:
-------------------------------------------------------------
I've reproduced your bug on several AS7 versions (7.1.2, 7.1.3, 7.1.4-SNAPSHOT) and EAP versions (6.0.0, 6.0.1).
My sample code is on github : https://github.com/hasalex/jboss-samples/tree/master/sessionlistener
was (Author: sewatech):
I've reproduced your bug on several AS7 versions. It's working on one single version : AS 7.1.2. The bug has been reintroduced in 7.1.3 (and EAP 6.0.1).
My sample code is on github : https://github.com/hasalex/jboss-samples/tree/master/sessionlistener
> Using Session Scope CDI bean does not work in a HttpSessionListener
> -------------------------------------------------------------------
>
> Key: AS7-6428
> URL: https://issues.jboss.org/browse/AS7-6428
> Project: Application Server 7
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 7.1.1.Final
> Environment: linux 64bits, win7 64 bits
> Reporter: nicolas marchais
> Assignee: Stuart Douglas
> Fix For: No Release
>
>
> JBoss AS 7.1.x has a bug with using session bean scope in a HttpSessionListener.
> When i inject a session scope bean in a HttpSessionListener and i try to populate attribute in sessionCreated() method many HttpSession are created by JBoss AS. Is it normal the a web server create many Http session for the same request ?
> Normally, this behaviour should work. See : http://docs.jboss.org/cdi/api/1.1-PRD/javax/enterprise/context/SessionSco...
> I did a light Web Project to explain the problem with 1 JSP, 1 SessionScope bean and 1 HttpSessionListener.
> Here is the code.
> JSP page :
> <%@ page language="java" contentType="text/html; charset=UTF-8"
> pageEncoding="UTF-8"%>
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
> <html>
> <head>
> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
> <title>Insert title here</title>
> </head>
> <body>
> </body>
> </html>
> SessionScope bean :
> @Named
> @SessionScoped
> public class UserState implements Serializable {
> private int state;
> public int getState() {
> return state;
> }
> public void setState(int state) {
> this.state = state;
> }
> }
> HttpSessionListener :
> @WebListener
> public class SessionListener implements HttpSessionListener {
> @Inject private UserState userState;
>
> @Override
> public void sessionCreated(HttpSessionEvent event) {
> System.out.println("New HTTP Session created : " + event.getSession().getId());
> userState.setState(2);
> }
> @Override
> public void sessionDestroyed(HttpSessionEvent event) {}
> }
> After execution, you can read in the console at least 2 http session creation like this :
> New HTTP Session created : zvlF6vGLP1AaXM-rzFU02wAJ.undefined
> New HTTP Session created : TlrmmA8Eu4v32SHDT0QBBZza.undefined
> The first session seams to be the one which is used by the client. There is one more problem : The polutated attributes of the session scope bean are ignored after HttpSessionListener execution. At the end all session scope attributes are null.
--
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
13 years, 5 months
[JBoss JIRA] (JGRP-1564) TP: passing messages up in batches (part I)
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1564?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1564 at 2/5/13 2:57 AM:
--------------------------------------------------------
The first part is done. A quick perf test showed:
MPerf (fast.xml):
-----------------
(requests/sec/node, 1000)
||Nodes||2||4||6||8||
|old|111|143|107|101|
|new|113|148|117|115|
UnicastTestRpc (fast.xml):
--------------------------
||Node||2||
|old|111|
|new|111|
UPerf (fast.xml):
-----------------
(requests/sec/node)
||Node||4||8||
|old|6'818|5'352|
|new|7'607|6'211|
was (Author: belaban):
The first part is done. A quick perf test showed:
MPerf (fast.xml):
-----------------
(requests/sec/node, 1000)
||Nodes||2||4||6||8||
|old|111|143|107|101|
|new|113|148|117|115|
UnicastTestPerf (fast.xml)
--------------------------
||Node||2||
|old|111|
|new|111|
UPerf (fast.xml):
-----------------
(requests/sec/node)
||Node||4||8||
|old|6'818|5'352|
|new|7'607|6'211|
> TP: passing messages up in batches (part I)
> -------------------------------------------
>
> Key: JGRP-1564
> URL: https://issues.jboss.org/browse/JGRP-1564
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> When B receives a batch of 5 messages from A (unicast or multicast), then B uses the *same thread* to send the 5 messages up (this isn't the case for OOB messages).
> It would be more efficient to either have different threads passing the 5 messages up, or use a new *message batch event type* to pass all 5 messages up in one go.
> The advantage of different threads is that all 5 threads add their message to the window, but only 1 removes them and passes them up, rather than each thread adding and removing its own message (fewer lock acquisitions).
> We could try moving the unmarshalling of messages and message batches into TP.receive(). If a batch was received, that code could unmarshal the 5 messages and pass them to corresponding thread pools to send them up.
> The unmarshalling shouldn't take long, so TP.receive() should return quickly.
> This approach would allow us to send OOB messages in message batches, too (currently not allowed).
> The advantage of a message batch is that we pass *one* event up the stack, passing only *once* through all protocols from TP to UNICAST/2 and NAKACK/2, and not 5 times. Also, adding 5 messages to the window under the same lock is more eficient than acquiring the lock 5 times. Ditto for removal.
> The disadvantage is that we now need to handle a different event type (all protocols under UNICAST/NAKACK), e.g. ENCRYPT, SIZE, FRAG(2) (if placed under UNICAST/NAKACK), COMPRESS etc. However, we could add another up(Batch) method, which by default (in Protocol):
> - removes all messages for a given protocol P (by P.ID)
> and calls up(Event.MSG, msg) for all messages in the batch
> - calls up_prot.up(batch) if the batch is not empty
> This would allow for all current protocols to continue working and only the protocols which don't check for headers and/or need special processing (such as UNICAST and NAKACK) would have to implement up(Batch).
> This solution would be better than introducing another event type MSG_BATCH, as not every protocol overriding up(Event) calls super.up(Event).
> However, this solution is not symmetric, ie. messages are batched at the transport level, and should be unbatched at the transport level of the receiver(s) as well...
--
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
13 years, 5 months
[JBoss JIRA] (AS7-5967) Naming lookup intermittently fails on IBM JDK due to org.jboss.remoting3.NotOpenException: Endpoint is not open.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-5967?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-5967:
----------------------------------------------
Carlo de Wolf <cdewolf(a)redhat.com> made a comment on [bug 901231|https://bugzilla.redhat.com/show_bug.cgi?id=901231]
> Naming lookup intermittently fails on IBM JDK due to org.jboss.remoting3.NotOpenException: Endpoint is not open.
> ----------------------------------------------------------------------------------------------------------------
>
> Key: AS7-5967
> URL: https://issues.jboss.org/browse/AS7-5967
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Naming, Test Suite
> Affects Versions: 7.1.3.Final (EAP), 7.2.0.Alpha1
> Environment: IBM JDK 6 (build 20110203_074623)
> IBM JDK 7 (build 20120809_118929)
> Reporter: Ivo Studensky
> Attachments: endpoint_is_not_open_2012-11-26.xml, failed_with_status_cancelled_2012-11-26.xml, test_output_with_trace_logging_in_EndpointCache.xml
>
>
> RemoteNamingTestCase intermittently fails when running on IBM JDK. According to logs the remoting channel had been closed before the endpoint tried to connect to it. Unfortunately, when I was trying to debug this issue the tests always nicely passed.
> test.log snippet:
> {noformat}
> 13:16:31,115 DEBUG [org.xnio.nio] (Remoting "config-based-naming-client-endpoint" read-1) Started channel thread 'Remoting "config-based-naming-client-endpoint" read-1', selector sun.nio.ch.EPollSelectorImpl@345642e1
> 13:16:31,115 DEBUG [org.xnio.nio] (Remoting "config-based-naming-client-endpoint" write-1) Started channel thread 'Remoting "config-based-naming-client-endpoint" write-1', selector sun.nio.ch.EPollSelectorImpl@1dc68cf2
> 13:16:31,121 DEBUG [org.jboss.naming.remote.client.InitialContextFactory] (main) jboss.naming.client.connect.options. has the following options {org.xnio.Options.SASL_POLICY_NOPLAINTEXT=>false}
> 13:16:31,191 ERROR [org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1] (Remoting "config-based-naming-client-endpoint" task-1) Channel end notification received, closing channel Channel ID d1f17196 (outbound) of Remoting connection fd3dcedc to /127.0.0.1:4447
> 13:16:31,204 DEBUG [org.jboss.naming.remote.client.HaRemoteNamingStore] (main) Failed to connect to server remote://127.0.0.1:4447: org.jboss.remoting3.NotOpenException: Endpoint is not open
> at org.jboss.remoting3.EndpointImpl.resourceUntick(EndpointImpl.java:182)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:261)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
> at org.jboss.naming.remote.client.EndpointCache$EndpointWrapper.connect(EndpointCache.java:105)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:179)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:117)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:223)
> at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:79)
> at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:83)
> at javax.naming.InitialContext.lookup(InitialContext.java:422)
> at org.jboss.as.test.integration.naming.remote.simple.RemoteNamingTestCase.testRemoteLookup(RemoteNamingTestCase.java:74)
> {noformat}
> server.log snippet:
> {noformat}
> 13:16:31,025 INFO [org.jboss.as.server] (management-handler-thread - 3) JBAS018559: Deployed "test.jar"
> 13:16:31,163 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" task-3) Channel Opened - Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to /127.0.0.1:46866
> 13:16:31,176 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" task-4) Chosen version 0x01
> 13:16:31,189 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" read-1) Channel Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to /127.0.0.1:46866 closed.
> 13:16:31,193 INFO [org.jboss.as.naming] (Remoting "thinkpax" task-1) JBAS011806: Channel end notification received, closing channel Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to null
> {noformat}
--
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
13 years, 5 months
[JBoss JIRA] (AS7-5967) Naming lookup intermittently fails on IBM JDK due to org.jboss.remoting3.NotOpenException: Endpoint is not open.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/AS7-5967?page=com.atlassian.jira.plugin.s... ]
RH Bugzilla Integration commented on AS7-5967:
----------------------------------------------
Carlo de Wolf <cdewolf(a)redhat.com> made a comment on [bug 901231|https://bugzilla.redhat.com/show_bug.cgi?id=901231]
> Naming lookup intermittently fails on IBM JDK due to org.jboss.remoting3.NotOpenException: Endpoint is not open.
> ----------------------------------------------------------------------------------------------------------------
>
> Key: AS7-5967
> URL: https://issues.jboss.org/browse/AS7-5967
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Naming, Test Suite
> Affects Versions: 7.1.3.Final (EAP), 7.2.0.Alpha1
> Environment: IBM JDK 6 (build 20110203_074623)
> IBM JDK 7 (build 20120809_118929)
> Reporter: Ivo Studensky
> Attachments: endpoint_is_not_open_2012-11-26.xml, failed_with_status_cancelled_2012-11-26.xml, test_output_with_trace_logging_in_EndpointCache.xml
>
>
> RemoteNamingTestCase intermittently fails when running on IBM JDK. According to logs the remoting channel had been closed before the endpoint tried to connect to it. Unfortunately, when I was trying to debug this issue the tests always nicely passed.
> test.log snippet:
> {noformat}
> 13:16:31,115 DEBUG [org.xnio.nio] (Remoting "config-based-naming-client-endpoint" read-1) Started channel thread 'Remoting "config-based-naming-client-endpoint" read-1', selector sun.nio.ch.EPollSelectorImpl@345642e1
> 13:16:31,115 DEBUG [org.xnio.nio] (Remoting "config-based-naming-client-endpoint" write-1) Started channel thread 'Remoting "config-based-naming-client-endpoint" write-1', selector sun.nio.ch.EPollSelectorImpl@1dc68cf2
> 13:16:31,121 DEBUG [org.jboss.naming.remote.client.InitialContextFactory] (main) jboss.naming.client.connect.options. has the following options {org.xnio.Options.SASL_POLICY_NOPLAINTEXT=>false}
> 13:16:31,191 ERROR [org.jboss.naming.remote.protocol.v1.RemoteNamingStoreV1] (Remoting "config-based-naming-client-endpoint" task-1) Channel end notification received, closing channel Channel ID d1f17196 (outbound) of Remoting connection fd3dcedc to /127.0.0.1:4447
> 13:16:31,204 DEBUG [org.jboss.naming.remote.client.HaRemoteNamingStore] (main) Failed to connect to server remote://127.0.0.1:4447: org.jboss.remoting3.NotOpenException: Endpoint is not open
> at org.jboss.remoting3.EndpointImpl.resourceUntick(EndpointImpl.java:182)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:261)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:251)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:349)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:333)
> at org.jboss.naming.remote.client.EndpointCache$EndpointWrapper.connect(EndpointCache.java:105)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.failOverSequence(HaRemoteNamingStore.java:179)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.namingOperation(HaRemoteNamingStore.java:117)
> at org.jboss.naming.remote.client.HaRemoteNamingStore.lookup(HaRemoteNamingStore.java:223)
> at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:79)
> at org.jboss.naming.remote.client.RemoteContext.lookup(RemoteContext.java:83)
> at javax.naming.InitialContext.lookup(InitialContext.java:422)
> at org.jboss.as.test.integration.naming.remote.simple.RemoteNamingTestCase.testRemoteLookup(RemoteNamingTestCase.java:74)
> {noformat}
> server.log snippet:
> {noformat}
> 13:16:31,025 INFO [org.jboss.as.server] (management-handler-thread - 3) JBAS018559: Deployed "test.jar"
> 13:16:31,163 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" task-3) Channel Opened - Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to /127.0.0.1:46866
> 13:16:31,176 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" task-4) Chosen version 0x01
> 13:16:31,189 DEBUG [org.jboss.naming.remote.server.RemoteNamingService] (Remoting "thinkpax" read-1) Channel Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to /127.0.0.1:46866 closed.
> 13:16:31,193 INFO [org.jboss.as.naming] (Remoting "thinkpax" task-1) JBAS011806: Channel end notification received, closing channel Channel ID 51f17196 (inbound) of Remoting connection b9da2788 to null
> {noformat}
--
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
13 years, 5 months
[JBoss JIRA] (JGRP-1564) TP: passing messages up in batches (part I)
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1564?page=com.atlassian.jira.plugin.... ]
Bela Ban resolved JGRP-1564.
----------------------------
Resolution: Done
The first part is done. A quick perf test showed:
MPerf (fast.xml):
-----------------
(requests/sec/node, 1000)
||Nodes||2||4||6||8||
|old|111|143|107|101|
|new|113|148|117|115|
UnicastTestPerf (fast.xml)
--------------------------
||Node||2||
|old|111|
|new|111|
UPerf (fast.xml):
-----------------
(requests/sec/node)
||Node||4||8||
|old|6'818|5'352|
|new|7'607|6'211|
> TP: passing messages up in batches (part I)
> -------------------------------------------
>
> Key: JGRP-1564
> URL: https://issues.jboss.org/browse/JGRP-1564
> Project: JGroups
> Issue Type: Enhancement
> Reporter: Bela Ban
> Assignee: Bela Ban
> Fix For: 3.3
>
>
> When B receives a batch of 5 messages from A (unicast or multicast), then B uses the *same thread* to send the 5 messages up (this isn't the case for OOB messages).
> It would be more efficient to either have different threads passing the 5 messages up, or use a new *message batch event type* to pass all 5 messages up in one go.
> The advantage of different threads is that all 5 threads add their message to the window, but only 1 removes them and passes them up, rather than each thread adding and removing its own message (fewer lock acquisitions).
> We could try moving the unmarshalling of messages and message batches into TP.receive(). If a batch was received, that code could unmarshal the 5 messages and pass them to corresponding thread pools to send them up.
> The unmarshalling shouldn't take long, so TP.receive() should return quickly.
> This approach would allow us to send OOB messages in message batches, too (currently not allowed).
> The advantage of a message batch is that we pass *one* event up the stack, passing only *once* through all protocols from TP to UNICAST/2 and NAKACK/2, and not 5 times. Also, adding 5 messages to the window under the same lock is more eficient than acquiring the lock 5 times. Ditto for removal.
> The disadvantage is that we now need to handle a different event type (all protocols under UNICAST/NAKACK), e.g. ENCRYPT, SIZE, FRAG(2) (if placed under UNICAST/NAKACK), COMPRESS etc. However, we could add another up(Batch) method, which by default (in Protocol):
> - removes all messages for a given protocol P (by P.ID)
> and calls up(Event.MSG, msg) for all messages in the batch
> - calls up_prot.up(batch) if the batch is not empty
> This would allow for all current protocols to continue working and only the protocols which don't check for headers and/or need special processing (such as UNICAST and NAKACK) would have to implement up(Batch).
> This solution would be better than introducing another event type MSG_BATCH, as not every protocol overriding up(Event) calls super.up(Event).
> However, this solution is not symmetric, ie. messages are batched at the transport level, and should be unbatched at the transport level of the receiver(s) as well...
--
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
13 years, 5 months