[JBoss JIRA] Created: (JGRP-1084) MessageDispatched to have marshalling callback after real_dest have been calculated
10:44 a.m.
MessageDispatched to have marshalling callback after real_dest have been calculated
-----------------------------------------------------------------------------------
Key: JGRP-1084
URL: https://jira.jboss.org/jira/browse/JGRP-1084
Project: JGroups
Issue Type: Feature Request
Reporter: Galder Zamarreno
Assignee: Bela Ban
Fix For: 2.9
A week ago filled I ISPN-237 jira in order for dist commands that should only affect the
local machine not to go remove. While investigating your stress test, I've found out
that JGroups' MessageDispatcher.castMessage already does that!
if(tmp != null &&
tmp.getOpt(Channel.LOCAL).equals(Boolean.FALSE)) {
if(local_addr == null) {
local_addr=tmp.getAddress();
}
if(local_addr != null) {
real_dests.removeElement(local_addr);
}
}
That code empties the real_dests if the target is the local address. So, you're
probably wondering why I filled ISPN-237? It's because marshalling happens before the
code above gets executed. In fact, it happens at the beginning of ReplicationTask.call()
and the JGroups optimization happens when castMessage() is called from
ReplicationTask.call().
So, I think my fix for https://jira.jboss.org/jira/browse/ISPN-237 is not optimal. JGroups
already knows when the call should stay local, so ISPN should need to do this calculation
again, it's wasteful code. The real fix would be to somehow be able to do marshalling
only if the code in MessageDispatcher.castMessage() said that real_dests was not empty.
Bela, do you think JGroups could be enhanced to have a callback after the code shown above
where we can invoke marshalling?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:44 a.m.
New subject: [JBoss JIRA] Updated: (JGRP-1084) MessageDispatched to have marshalling callback after real_dest have been calculated
[
https://jira.jboss.org/jira/browse/JGRP-1084?page=com.atlassian.jira.plug...
]
Galder Zamarreno updated JGRP-1084:
-----------------------------------
Description:
A week ago filled I ISPN-237 jira in order for dist commands that should only affect the
local machine not to go remove. While investigating your stress test, I've found out
that JGroups' MessageDispatcher.castMessage already does that!
if(tmp != null &&
tmp.getOpt(Channel.LOCAL).equals(Boolean.FALSE)) {
if(local_addr == null) {
local_addr=tmp.getAddress();
}
if(local_addr != null) {
real_dests.removeElement(local_addr);
}
}
That code empties the real_dests if the target is the local address. So, you're
probably wondering why I filled ISPN-237? It's because marshalling happens before the
code above gets executed. In fact, it happens at the beginning of ReplicationTask.call()
and the JGroups optimization happens when castMessage() is called from
ReplicationTask.call().
So, I think my fix for ISPN-237 is not optimal. JGroups already knows when the call should
stay local, so ISPN should need to do this calculation again, it's wasteful code. The
real fix would be to somehow be able to do marshalling only if the code in
MessageDispatcher.castMessage() said that real_dests was not empty.
Bela, do you think JGroups could be enhanced to have a callback after the code shown above
where we can invoke marshalling?
was:
A week ago filled I ISPN-237 jira in order for dist commands that should only affect the
local machine not to go remove. While investigating your stress test, I've found out
that JGroups' MessageDispatcher.castMessage already does that!
if(tmp != null &&
tmp.getOpt(Channel.LOCAL).equals(Boolean.FALSE)) {
if(local_addr == null) {
local_addr=tmp.getAddress();
}
if(local_addr != null) {
real_dests.removeElement(local_addr);
}
}
That code empties the real_dests if the target is the local address. So, you're
probably wondering why I filled ISPN-237? It's because marshalling happens before the
code above gets executed. In fact, it happens at the beginning of ReplicationTask.call()
and the JGroups optimization happens when castMessage() is called from
ReplicationTask.call().
So, I think my fix for https://jira.jboss.org/jira/browse/ISPN-237 is not optimal. JGroups
already knows when the call should stay local, so ISPN should need to do this calculation
again, it's wasteful code. The real fix would be to somehow be able to do marshalling
only if the code in MessageDispatcher.castMessage() said that real_dests was not empty.
Bela, do you think JGroups could be enhanced to have a callback after the code shown above
where we can invoke marshalling?
MessageDispatched to have marshalling callback after real_dest have
been calculated
-----------------------------------------------------------------------------------
Key: JGRP-1084
URL: https://jira.jboss.org/jira/browse/JGRP-1084
Project: JGroups
Issue Type: Feature Request
Reporter: Galder Zamarreno
Assignee: Bela Ban
Fix For: 2.9
A week ago filled I ISPN-237 jira in order for dist commands that should only affect the
local machine not to go remove. While investigating your stress test, I've found out
that JGroups' MessageDispatcher.castMessage already does that!
if(tmp != null &&
tmp.getOpt(Channel.LOCAL).equals(Boolean.FALSE)) {
if(local_addr == null) {
local_addr=tmp.getAddress();
}
if(local_addr != null) {
real_dests.removeElement(local_addr);
}
}
That code empties the real_dests if the target is the local address. So, you're
probably wondering why I filled ISPN-237? It's because marshalling happens before the
code above gets executed. In fact, it happens at the beginning of ReplicationTask.call()
and the JGroups optimization happens when castMessage() is called from
ReplicationTask.call().
So, I think my fix for ISPN-237 is not optimal. JGroups already knows when the call
should stay local, so ISPN should need to do this calculation again, it's wasteful
code. The real fix would be to somehow be able to do marshalling only if the code in
MessageDispatcher.castMessage() said that real_dests was not empty.
Bela, do you think JGroups could be enhanced to have a callback after the code shown
above where we can invoke marshalling?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:50 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-1084) MessageDispatched to have marshalling callback after real_dest have been calculated
[
https://jira.jboss.org/jira/browse/JGRP-1084?page=com.atlassian.jira.plug...
]
Bela Ban commented on JGRP-1084:
--------------------------------
Possible solution: addition of getRealDests() which is called *before* marshalling and
returns immediately if the current member is the only member in the group
MessageDispatched to have marshalling callback after real_dest have
been calculated
-----------------------------------------------------------------------------------
Key: JGRP-1084
URL: https://jira.jboss.org/jira/browse/JGRP-1084
Project: JGroups
Issue Type: Feature Request
Reporter: Galder Zamarreno
Assignee: Bela Ban
Fix For: 2.9
A week ago filled I ISPN-237 jira in order for dist commands that should only affect the
local machine not to go remove. While investigating your stress test, I've found out
that JGroups' MessageDispatcher.castMessage already does that!
if(tmp != null &&
tmp.getOpt(Channel.LOCAL).equals(Boolean.FALSE)) {
if(local_addr == null) {
local_addr=tmp.getAddress();
}
if(local_addr != null) {
real_dests.removeElement(local_addr);
}
}
That code empties the real_dests if the target is the local address. So, you're
probably wondering why I filled ISPN-237? It's because marshalling happens before the
code above gets executed. In fact, it happens at the beginning of ReplicationTask.call()
and the JGroups optimization happens when castMessage() is called from
ReplicationTask.call().
So, I think my fix for ISPN-237 is not optimal. JGroups already knows when the call
should stay local, so ISPN should need to do this calculation again, it's wasteful
code. The real fix would be to somehow be able to do marshalling only if the code in
MessageDispatcher.castMessage() said that real_dests was not empty.
Bela, do you think JGroups could be enhanced to have a callback after the code shown
above where we can invoke marshalling?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
8:11 a.m.
New subject: [JBoss JIRA] Assigned: (JGRP-1084) MessageDispatched to have marshalling callback after real_dest have been calculated
[
https://jira.jboss.org/jira/browse/JGRP-1084?page=com.atlassian.jira.plug...
]
Bela Ban reassigned JGRP-1084:
------------------------------
Assignee: Vladimir Blagojevic (was: Bela Ban)
MessageDispatched to have marshalling callback after real_dest have
been calculated
-----------------------------------------------------------------------------------
Key: JGRP-1084
URL: https://jira.jboss.org/jira/browse/JGRP-1084
Project: JGroups
Issue Type: Feature Request
Reporter: Galder Zamarreno
Assignee: Vladimir Blagojevic
Fix For: 2.9
A week ago filled I ISPN-237 jira in order for dist commands that should only affect the
local machine not to go remove. While investigating your stress test, I've found out
that JGroups' MessageDispatcher.castMessage already does that!
if(tmp != null &&
tmp.getOpt(Channel.LOCAL).equals(Boolean.FALSE)) {
if(local_addr == null) {
local_addr=tmp.getAddress();
}
if(local_addr != null) {
real_dests.removeElement(local_addr);
}
}
That code empties the real_dests if the target is the local address. So, you're
probably wondering why I filled ISPN-237? It's because marshalling happens before the
code above gets executed. In fact, it happens at the beginning of ReplicationTask.call()
and the JGroups optimization happens when castMessage() is called from
ReplicationTask.call().
So, I think my fix for ISPN-237 is not optimal. JGroups already knows when the call
should stay local, so ISPN should need to do this calculation again, it's wasteful
code. The real fix would be to somehow be able to do marshalling only if the code in
MessageDispatcher.castMessage() said that real_dests was not empty.
Bela, do you think JGroups could be enhanced to have a callback after the code shown
above where we can invoke marshalling?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:44 a.m.
New subject: [JBoss JIRA] Updated: (JGRP-1084) MessageDispatched to have marshalling callback after real_dest have been calculated
[
https://jira.jboss.org/jira/browse/JGRP-1084?page=com.atlassian.jira.plug...
]
Bela Ban updated JGRP-1084:
---------------------------
Fix Version/s: 2.10
(was: 2.9)
MessageDispatched to have marshalling callback after real_dest have
been calculated
-----------------------------------------------------------------------------------
Key: JGRP-1084
URL: https://jira.jboss.org/jira/browse/JGRP-1084
Project: JGroups
Issue Type: Feature Request
Reporter: Galder Zamarreno
Assignee: Vladimir Blagojevic
Fix For: 2.10
A week ago filled I ISPN-237 jira in order for dist commands that should only affect the
local machine not to go remove. While investigating your stress test, I've found out
that JGroups' MessageDispatcher.castMessage already does that!
if(tmp != null &&
tmp.getOpt(Channel.LOCAL).equals(Boolean.FALSE)) {
if(local_addr == null) {
local_addr=tmp.getAddress();
}
if(local_addr != null) {
real_dests.removeElement(local_addr);
}
}
That code empties the real_dests if the target is the local address. So, you're
probably wondering why I filled ISPN-237? It's because marshalling happens before the
code above gets executed. In fact, it happens at the beginning of ReplicationTask.call()
and the JGroups optimization happens when castMessage() is called from
ReplicationTask.call().
So, I think my fix for ISPN-237 is not optimal. JGroups already knows when the call
should stay local, so ISPN should need to do this calculation again, it's wasteful
code. The real fix would be to somehow be able to do marshalling only if the code in
MessageDispatcher.castMessage() said that real_dests was not empty.
Bela, do you think JGroups could be enhanced to have a callback after the code shown
above where we can invoke marshalling?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12:02 a.m.
New subject: [JBoss JIRA] Updated: (JGRP-1084) MessageDispatched to have marshalling callback after real_dest have been calculated
[
https://jira.jboss.org/jira/browse/JGRP-1084?page=com.atlassian.jira.plug...
]
Bela Ban updated JGRP-1084:
---------------------------
Fix Version/s: 2.9
(was: 2.10)
MessageDispatched to have marshalling callback after real_dest have
been calculated
-----------------------------------------------------------------------------------
Key: JGRP-1084
URL: https://jira.jboss.org/jira/browse/JGRP-1084
Project: JGroups
Issue Type: Feature Request
Reporter: Galder Zamarreno
Assignee: Vladimir Blagojevic
Fix For: 2.9
A week ago filled I ISPN-237 jira in order for dist commands that should only affect the
local machine not to go remove. While investigating your stress test, I've found out
that JGroups' MessageDispatcher.castMessage already does that!
if(tmp != null &&
tmp.getOpt(Channel.LOCAL).equals(Boolean.FALSE)) {
if(local_addr == null) {
local_addr=tmp.getAddress();
}
if(local_addr != null) {
real_dests.removeElement(local_addr);
}
}
That code empties the real_dests if the target is the local address. So, you're
probably wondering why I filled ISPN-237? It's because marshalling happens before the
code above gets executed. In fact, it happens at the beginning of ReplicationTask.call()
and the JGroups optimization happens when castMessage() is called from
ReplicationTask.call().
So, I think my fix for ISPN-237 is not optimal. JGroups already knows when the call
should stay local, so ISPN should need to do this calculation again, it's wasteful
code. The real fix would be to somehow be able to do marshalling only if the code in
MessageDispatcher.castMessage() said that real_dests was not empty.
Bela, do you think JGroups could be enhanced to have a callback after the code shown
above where we can invoke marshalling?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
10:44 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-1084) MessageDispatched to have marshalling callback after real_dest have been calculated
[
https://jira.jboss.org/jira/browse/JGRP-1084?page=com.atlassian.jira.plug...
]
Bela Ban commented on JGRP-1084:
--------------------------------
Is this really needed ? IIRC, Infinispan's CommandAwareDispatcher passes a list of
target addresses, but removes the local address before that...
MessageDispatched to have marshalling callback after real_dest have
been calculated
-----------------------------------------------------------------------------------
Key: JGRP-1084
URL: https://jira.jboss.org/jira/browse/JGRP-1084
Project: JGroups
Issue Type: Feature Request
Reporter: Galder Zamarreno
Assignee: Vladimir Blagojevic
Fix For: 2.9
A week ago filled I ISPN-237 jira in order for dist commands that should only affect the
local machine not to go remove. While investigating your stress test, I've found out
that JGroups' MessageDispatcher.castMessage already does that!
if(tmp != null &&
tmp.getOpt(Channel.LOCAL).equals(Boolean.FALSE)) {
if(local_addr == null) {
local_addr=tmp.getAddress();
}
if(local_addr != null) {
real_dests.removeElement(local_addr);
}
}
That code empties the real_dests if the target is the local address. So, you're
probably wondering why I filled ISPN-237? It's because marshalling happens before the
code above gets executed. In fact, it happens at the beginning of ReplicationTask.call()
and the JGroups optimization happens when castMessage() is called from
ReplicationTask.call().
So, I think my fix for ISPN-237 is not optimal. JGroups already knows when the call
should stay local, so ISPN should need to do this calculation again, it's wasteful
code. The real fix would be to somehow be able to do marshalling only if the code in
MessageDispatcher.castMessage() said that real_dests was not empty.
Bela, do you think JGroups could be enhanced to have a callback after the code shown
above where we can invoke marshalling?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:04 a.m.
New subject: [JBoss JIRA] Updated: (JGRP-1084) MessageDispatched to have marshalling callback after real_dest have been calculated
[
https://jira.jboss.org/jira/browse/JGRP-1084?page=com.atlassian.jira.plug...
]
Bela Ban updated JGRP-1084:
---------------------------
Fix Version/s: 2.10
(was: 2.9)
Priority: Minor (was: Major)
Moved to 2.10
MessageDispatched to have marshalling callback after real_dest have
been calculated
-----------------------------------------------------------------------------------
Key: JGRP-1084
URL: https://jira.jboss.org/jira/browse/JGRP-1084
Project: JGroups
Issue Type: Feature Request
Reporter: Galder Zamarreno
Assignee: Vladimir Blagojevic
Priority: Minor
Fix For: 2.10
A week ago filled I ISPN-237 jira in order for dist commands that should only affect the
local machine not to go remove. While investigating your stress test, I've found out
that JGroups' MessageDispatcher.castMessage already does that!
if(tmp != null &&
tmp.getOpt(Channel.LOCAL).equals(Boolean.FALSE)) {
if(local_addr == null) {
local_addr=tmp.getAddress();
}
if(local_addr != null) {
real_dests.removeElement(local_addr);
}
}
That code empties the real_dests if the target is the local address. So, you're
probably wondering why I filled ISPN-237? It's because marshalling happens before the
code above gets executed. In fact, it happens at the beginning of ReplicationTask.call()
and the JGroups optimization happens when castMessage() is called from
ReplicationTask.call().
So, I think my fix for ISPN-237 is not optimal. JGroups already knows when the call
should stay local, so ISPN should need to do this calculation again, it's wasteful
code. The real fix would be to somehow be able to do marshalling only if the code in
MessageDispatcher.castMessage() said that real_dests was not empty.
Bela, do you think JGroups could be enhanced to have a callback after the code shown
above where we can invoke marshalling?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:19 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-1084) MessageDispatched to have marshalling callback after real_dest have been calculated
[
https://jira.jboss.org/jira/browse/JGRP-1084?page=com.atlassian.jira.plug...
]
Galder Zamarreno commented on JGRP-1084:
----------------------------------------
Bela, let me verify this.
MessageDispatched to have marshalling callback after real_dest have
been calculated
-----------------------------------------------------------------------------------
Key: JGRP-1084
URL: https://jira.jboss.org/jira/browse/JGRP-1084
Project: JGroups
Issue Type: Feature Request
Reporter: Galder Zamarreno
Assignee: Vladimir Blagojevic
Priority: Minor
Fix For: 2.10
A week ago filled I ISPN-237 jira in order for dist commands that should only affect the
local machine not to go remove. While investigating your stress test, I've found out
that JGroups' MessageDispatcher.castMessage already does that!
if(tmp != null &&
tmp.getOpt(Channel.LOCAL).equals(Boolean.FALSE)) {
if(local_addr == null) {
local_addr=tmp.getAddress();
}
if(local_addr != null) {
real_dests.removeElement(local_addr);
}
}
That code empties the real_dests if the target is the local address. So, you're
probably wondering why I filled ISPN-237? It's because marshalling happens before the
code above gets executed. In fact, it happens at the beginning of ReplicationTask.call()
and the JGroups optimization happens when castMessage() is called from
ReplicationTask.call().
So, I think my fix for ISPN-237 is not optimal. JGroups already knows when the call
should stay local, so ISPN should need to do this calculation again, it's wasteful
code. The real fix would be to somehow be able to do marshalling only if the code in
MessageDispatcher.castMessage() said that real_dests was not empty.
Bela, do you think JGroups could be enhanced to have a callback after the code shown
above where we can invoke marshalling?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:49 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-1084) MessageDispatched to have marshalling callback after real_dest have been calculated
[
https://jira.jboss.org/jira/browse/JGRP-1084?page=com.atlassian.jira.plug...
]
Galder Zamarreno commented on JGRP-1084:
----------------------------------------
From a pure performance perspective and limited to the single owner
scenario, it's good that we have ISPN-237 in place because it figures out when
there's a single owner and when the target of the call is local.
However, looking at CommandAwareDispatcher, it does indeed remove the local address. I
think we should revisit this later on, when CommandAwareDispatcher implementation has
stabilized.
MessageDispatched to have marshalling callback after real_dest have
been calculated
-----------------------------------------------------------------------------------
Key: JGRP-1084
URL: https://jira.jboss.org/jira/browse/JGRP-1084
Project: JGroups
Issue Type: Feature Request
Reporter: Galder Zamarreno
Assignee: Vladimir Blagojevic
Priority: Minor
Fix For: 2.10
A week ago filled I ISPN-237 jira in order for dist commands that should only affect the
local machine not to go remove. While investigating your stress test, I've found out
that JGroups' MessageDispatcher.castMessage already does that!
if(tmp != null &&
tmp.getOpt(Channel.LOCAL).equals(Boolean.FALSE)) {
if(local_addr == null) {
local_addr=tmp.getAddress();
}
if(local_addr != null) {
real_dests.removeElement(local_addr);
}
}
That code empties the real_dests if the target is the local address. So, you're
probably wondering why I filled ISPN-237? It's because marshalling happens before the
code above gets executed. In fact, it happens at the beginning of ReplicationTask.call()
and the JGroups optimization happens when castMessage() is called from
ReplicationTask.call().
So, I think my fix for ISPN-237 is not optimal. JGroups already knows when the call
should stay local, so ISPN should need to do this calculation again, it's wasteful
code. The real fix would be to somehow be able to do marshalling only if the code in
MessageDispatcher.castMessage() said that real_dests was not empty.
Bela, do you think JGroups could be enhanced to have a callback after the code shown
above where we can invoke marshalling?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
9:56 a.m.
New subject: [JBoss JIRA] Commented: (JGRP-1084) MessageDispatched to have marshalling callback after real_dest have been calculated
[
https://jira.jboss.org/jira/browse/JGRP-1084?page=com.atlassian.jira.plug...
]
Galder Zamarreno commented on JGRP-1084:
----------------------------------------
Note that CommandAwareDispatcher removes the local address after the request has been
marshalled, so we still need ISPN-237 in place, otherwise single owner scenarios where
target is local would still be marshalled. CommandAwareDispatcher probably needs enhancing
so that marshalling only happens when we know for sure that the call will go remote.
Right now, the first thing CommandAwareRpcDispatcher$ReplicationTask.call() does is the
marshalling and if ISPN-237 was not in place, it'd be trying to marshall something
wastefully. I don't know right now whether there're other scenarios where we might
be marshalling wasterfully. Manik/Mircea, since you've been working on the
CommandAwareRpcDispatcher lately, you might wanna check this out and make sure marshalling
is moved to part of call() code where you know for sure that the call will go remotely.
MessageDispatched to have marshalling callback after real_dest have
been calculated
-----------------------------------------------------------------------------------
Key: JGRP-1084
URL: https://jira.jboss.org/jira/browse/JGRP-1084
Project: JGroups
Issue Type: Feature Request
Reporter: Galder Zamarreno
Assignee: Vladimir Blagojevic
Priority: Minor
Fix For: 2.10
A week ago filled I ISPN-237 jira in order for dist commands that should only affect the
local machine not to go remove. While investigating your stress test, I've found out
that JGroups' MessageDispatcher.castMessage already does that!
if(tmp != null &&
tmp.getOpt(Channel.LOCAL).equals(Boolean.FALSE)) {
if(local_addr == null) {
local_addr=tmp.getAddress();
}
if(local_addr != null) {
real_dests.removeElement(local_addr);
}
}
That code empties the real_dests if the target is the local address. So, you're
probably wondering why I filled ISPN-237? It's because marshalling happens before the
code above gets executed. In fact, it happens at the beginning of ReplicationTask.call()
and the JGroups optimization happens when castMessage() is called from
ReplicationTask.call().
So, I think my fix for ISPN-237 is not optimal. JGroups already knows when the call
should stay local, so ISPN should need to do this calculation again, it's wasteful
code. The real fix would be to somehow be able to do marshalling only if the code in
MessageDispatcher.castMessage() said that real_dests was not empty.
Bela, do you think JGroups could be enhanced to have a callback after the code shown
above where we can invoke marshalling?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5:39 a.m.
New subject: [JBoss JIRA] Updated: (JGRP-1084) MessageDispatched to have marshalling callback after real_dest have been calculated
[
https://jira.jboss.org/jira/browse/JGRP-1084?page=com.atlassian.jira.plug...
]
Bela Ban updated JGRP-1084:
---------------------------
Fix Version/s: 3.x
(was: 2.10)
Moved to 3.x. Seems this can be solved entirely on the Infinispan side
MessageDispatched to have marshalling callback after real_dest have
been calculated
-----------------------------------------------------------------------------------
Key: JGRP-1084
URL: https://jira.jboss.org/jira/browse/JGRP-1084
Project: JGroups
Issue Type: Feature Request
Reporter: Galder Zamarreno
Assignee: Vladimir Blagojevic
Priority: Minor
Fix For: 3.x
A week ago filled I ISPN-237 jira in order for dist commands that should only affect the
local machine not to go remove. While investigating your stress test, I've found out
that JGroups' MessageDispatcher.castMessage already does that!
if(tmp != null &&
tmp.getOpt(Channel.LOCAL).equals(Boolean.FALSE)) {
if(local_addr == null) {
local_addr=tmp.getAddress();
}
if(local_addr != null) {
real_dests.removeElement(local_addr);
}
}
That code empties the real_dests if the target is the local address. So, you're
probably wondering why I filled ISPN-237? It's because marshalling happens before the
code above gets executed. In fact, it happens at the beginning of ReplicationTask.call()
and the JGroups optimization happens when castMessage() is called from
ReplicationTask.call().
So, I think my fix for ISPN-237 is not optimal. JGroups already knows when the call
should stay local, so ISPN should need to do this calculation again, it's wasteful
code. The real fix would be to somehow be able to do marshalling only if the code in
MessageDispatcher.castMessage() said that real_dests was not empty.
Bela, do you think JGroups could be enhanced to have a callback after the code shown
above where we can invoke marshalling?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
5387
days inactive
5493
days old
11 comments
2 participants
participants (2)
-
Bela Ban (JIRA) -
Galder Zamarreno (JIRA)