|
»
StressTest: Can JGroups provide a callback to do marshalling after real_dests have been calculated?
|
View:
New views
6 Messages
—
Rating Filter:
Alert me
|
 |
StressTest: Can JGroups provide a callback to do marshalling after real_dests have been calculated?
by Galder Zamarreno-8
::
Rate this Message:
Hi Bela & co,
While investigating your stress test, I've found a few interesting things. I'm gonna split in 2 emails: 1.- First of all, a week ago filled https://jira.jboss.org/jira/browse/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 https://jira.jboss.org/jira/browse/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? Cheers, -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Javagroups-development mailing list |
|
|
Re: [infinispan-dev] StressTest: Can JGroups provide a callback to do marshalling after real_dests have been calculated?
by Manik Surtani-2
::
Rate this Message:
Good point, Galder.
On 29 Oct 2009, at 10:19, Galder Zamarreno wrote: > Hi Bela & co, > > While investigating your stress test, I've found a few interesting > things. I'm gonna split in 2 emails: > > 1.- First of all, a week ago filled > https://jira.jboss.org/jira/browse/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 > https://jira.jboss.org/jira/browse/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? > > Cheers, > -- > Galder Zamarreño > Sr. Software Engineer > Infinispan, JBoss Cache > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@... > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik@... Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Javagroups-development mailing list |
|
|
Re: StressTest: Can JGroups provide a callback to do marshalling after real_dests have been calculated?
by Bela Ban-5
::
Rate this Message:
Sure, why don't you create a JIRA (for 2.9) ?
Galder Zamarreno wrote: > Hi Bela & co, > > While investigating your stress test, I've found a few interesting > things. I'm gonna split in 2 emails: > > 1.- First of all, a week ago filled > https://jira.jboss.org/jira/browse/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 > https://jira.jboss.org/jira/browse/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? > > Cheers, > -- Bela Ban Lead JGroups / Clustering Team JBoss ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Javagroups-development mailing list |
|
|
Re: StressTest: Can JGroups provide a callback to do marshalling after real_dests have been calculated?
by Galder Zamarreno-8
::
Rate this Message:
Sure, I'll do it in a sec.
Manik FYI, I'm gonna revert the changes for https://jira.jboss.org/jira/browse/ISPN-237. On 10/29/2009 04:32 PM, Bela Ban wrote: > Sure, why don't you create a JIRA (for 2.9) ? > > Galder Zamarreno wrote: >> Hi Bela & co, >> >> While investigating your stress test, I've found a few interesting >> things. I'm gonna split in 2 emails: >> >> 1.- First of all, a week ago filled >> https://jira.jboss.org/jira/browse/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 >> https://jira.jboss.org/jira/browse/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? >> >> Cheers, > -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Javagroups-development mailing list |
|
|
Re: [infinispan-dev] StressTest: Can JGroups provide a callback to do marshalling after real_dests have been calculated?
by Manik Surtani-2
::
Rate this Message:
I reckon don't revert 237 until we have this implemented in JGroups...
On 29 Oct 2009, at 15:36, Galder Zamarreno wrote: > Sure, I'll do it in a sec. > > Manik FYI, I'm gonna revert the changes for > https://jira.jboss.org/jira/browse/ISPN-237. > > On 10/29/2009 04:32 PM, Bela Ban wrote: >> Sure, why don't you create a JIRA (for 2.9) ? >> >> Galder Zamarreno wrote: >>> Hi Bela & co, >>> >>> While investigating your stress test, I've found a few interesting >>> things. I'm gonna split in 2 emails: >>> >>> 1.- First of all, a week ago filled >>> https://jira.jboss.org/jira/browse/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 >>> https://jira.jboss.org/jira/browse/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? >>> >>> Cheers, >> > > -- > Galder Zamarreño > Sr. Software Engineer > Infinispan, JBoss Cache > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@... > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik@... Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Javagroups-development mailing list |
|
|
Re: [infinispan-dev] StressTest: Can JGroups provide a callback to do marshalling after real_dests have been calculated?
by Galder Zamarreno-7
::
Rate this Message:
Yeah, you're right. I'll add a TODO so that it gets reverted once
https://jira.jboss.org/jira/browse/JGRP-1084 has been implemented. On 10/29/2009 04:47 PM, Manik Surtani wrote: > I reckon don't revert 237 until we have this implemented in JGroups... > > > On 29 Oct 2009, at 15:36, Galder Zamarreno wrote: > >> Sure, I'll do it in a sec. >> >> Manik FYI, I'm gonna revert the changes for >> https://jira.jboss.org/jira/browse/ISPN-237. >> >> On 10/29/2009 04:32 PM, Bela Ban wrote: >>> Sure, why don't you create a JIRA (for 2.9) ? >>> >>> Galder Zamarreno wrote: >>>> Hi Bela& co, >>>> >>>> While investigating your stress test, I've found a few interesting >>>> things. I'm gonna split in 2 emails: >>>> >>>> 1.- First of all, a week ago filled >>>> https://jira.jboss.org/jira/browse/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 >>>> https://jira.jboss.org/jira/browse/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? >>>> >>>> Cheers, >>> >> >> -- >> Galder Zamarreño >> Sr. Software Engineer >> Infinispan, JBoss Cache >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@... >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > -- > Manik Surtani > manik@... > Lead, Infinispan > Lead, JBoss Cache > http://www.infinispan.org > http://www.jbosscache.org > > > > > > ------------------------------------------------------------------------------ > Come build with us! The BlackBerry(R) Developer Conference in SF, CA > is the only developer event you need to attend this year. Jumpstart your > developing skills, take BlackBerry mobile applications to market and stay > ahead of the curve. Join us from November 9 - 12, 2009. Register now! > http://p.sf.net/sfu/devconference > _______________________________________________ > Javagroups-development mailing list > -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ------------------------------------------------------------------------------ Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference _______________________________________________ Javagroups-development mailing list |
| Free embeddable forum powered by Nabble | Forum Help |
