December 2006 - jboss-dev-forums - Jboss List Archives

[Design of POJO Server] - Re: Moving forward with the profile service mgmt api

by adrian＠jboss.org

1.1.8 - I have label decorations turned off for performance reasons. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995894#3995894 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995894

18 years

1
0
0 / 0

[Design of POJO Server] - Re: Moving forward with the profile service mgmt api

by scott.stark＠jboss.org

What version of the svn plugin are you using? Since I switched to the 1.1.8 (now 1.1.9) version for eclipse 3.2.1 I have not seen any issues with not seeing what has been modified. The only workspace that was still showing a problem like that had the label decoration settings disabled in the preferences. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995889#3995889 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995889

18 years

1
0
0 / 0

[Design of POJO Server] - Re: Moving forward with the profile service mgmt api

by weston.price＠jboss.com

This generally occurs because the file attributes in SVN changed in 1.4 and breaks backwards compatibility with the 1.3 and older clients. Either your client is too old, or your plugin is in a wonky state. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995869#3995869 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995869

18 years

1
0
0 / 0

[Design of Messaging on JBoss (Messaging/JBoss)] - Re: XARecovery work merged into TRUNK

by mark.little＠jboss.com

Congrats. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995859#3995859 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995859

18 years

1
0
0 / 0

[Design of POJO Server] - Re: Moving forward with the profile service mgmt api

by adrian＠jboss.org

Thanks for fixing the build. This SVN client in Eclipse is getting really annoying. For some reason it had forgotten that my microcontainer/tools project was managed by SVN? This isn't the only problem with this buggy software. :-( e.g. In the workspace where I'm doing the EJB metadata changes I can't even resynchronise with SVN (it is totally broken). Ironcially, I only started using Eclipse because it told me what I had changed so I didn't break the build with partial checkins. :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995858#3995858 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995858

18 years

1
0
0 / 0

[Design of JBossCache] - Re: Buddy state transfer

by bela＠jboss.com

No, this is just an example: for UDP, if you call RpcDispatcher.callRemoteMethods() with use_anycast=false, I'll use regular multicast. If it is true, I'll use single unicasts *no matter how many members there are in the target list* ! So the decision whether to use anycast or not would be made by JBossCache, possibly based on my previous example. Maybe even configurable ? Although we have already too many attributes... :-) View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995857#3995857 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995857

18 years

1
0
0 / 0

[Design of JBossCache] - Re: Buddy state transfer

by manik.surtani＠jboss.com

"bela(a)jboss.com" wrote : ... With UDP (IP multicasting), it depends on the subset to which you want to send a message, e.g. | 1-3 out of 10: anycast | 4-10 out of 10: multicast | Is "3" a hard coded limit? Or is this something that is configurable? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995851#3995851 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995851

18 years

1
0
0 / 0

[Design of JBossCache] - Re: Buddy state transfer

by manik.surtani＠jboss.com

anonymous wrote : When you talk about dealing with both, do you mean in JGroups or in JBC? In JBC, using whatever support we can get from JG. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995850#3995850 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995850

18 years

1
0
0 / 0

[Design of JBossCache] - Re: Buddy state transfer

by bela＠jboss.com

Another issue I see with the state transfer approach is that we need to run the flush protocol *once* for each state transfer. Unless we can have the coordinator start and stop the flush protocol, this might be quite expensive. Regarding deadlocks: we could wait until JGroups 2.5 is in place; with the threadless stack and parallel and out-of-band processing, deadlocks should not occur anymore. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995809#3995809 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995809

18 years

1
0
0 / 0

[Design of JBossCache] - Re: Buddy state transfer

by bela＠jboss.com

"manik.surtani(a)jboss.com" wrote : | IIRC, if the transport is UDP and multicast is enabled, this is achieved by multicasting and only named recipients accepting the comms (Bela or Vlad, perhaps you could confirm this?). | No, we always use unicasts. It is up to the caller of RpocDispatcher.callRemoteMethods() to decide whether a multicast or multiple unicasts are used. With TCP as transport, of course *always* use anycasting. With UDP (IP multicasting), it depends on the subset to which you want to send a message, e.g. 1-3 out of 10: anycast 4-10 out of 10: multicast View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995807#3995807 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3995807

18 years

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-dev-forums December 2006