Hello, Could you please only use serviceStartTime in McastServiceImpl, since serviceStartTime in MemberImpl has a comment "For the local member only"? Maybe the latter one is not designed to be used as you do now.
2009/5/21 <bugzi...@apache.org> > https://issues.apache.org/bugzilla/show_bug.cgi?id=47234 > > Summary: serviceStartTime is different in MemberImpl from > McastServiceImpl > Product: Tomcat 6 > Version: unspecified > Platform: PC > OS/Version: Linux > Status: NEW > Severity: critical > Priority: P2 > Component: Cluster > AssignedTo: dev@tomcat.apache.org > ReportedBy: arieland...@hotmail.com > > > Hi, > I'm using the tribes cluster module in my own application (which has > nothing to > do with tomcat) and I'm using the member alive time value to sort all the > cluster members. > This bug produces the following: > I have 2 nodes that were started almost at the same time and both nodes > claim > that the other node was started before them > > NODE1: > Remote members: (-52.63.57.110:4001 ready=true suspect=false failing=false > aliveTime=1526) > Local member: (-52.63.57.109:4000 ready=true suspect=false failing=false > aliveTime=1236) > > > NODE2: > Remote members: (-52.63.57.109:4000 ready=true suspect=false failing=false > aliveTime=2021) > Local member: (-52.63.57.110:4001 ready=true suspect=false failing=false > aliveTime=1069) > > > My code do the following: > Member[] members = groupChannel.getMembers(); > printRemote(members); > Member localMember = groupChannel.getLocalMember(true); > printLocal(localMember); > > > In that code (due to timing issues) it should possible the other way around > (that every node claim to be started before the other) but not that case. > > The issue occurs because when the McastService is started, it assigns a > start > time to the local member. > public class McastService .... { > public void start(int level) { > .... > localMember.setServiceStartTime(System.currentTimeMillis()); > .... > impl = new McastServiceImpl(localMember, ....); > impl.start(level); > } > } > But, then it creates and starts a McastServiceImpl which also stores a new > serviceStartTime :-( > > public class McastServiceImpl { > protected long serviceStartTime; > public void start(int level) { > .... > serviceStartTime = System.currentTimeMillis(); > .... > } > } > > So, we have 2 different start times. Unfortunately both times are used: > To get the local member, the impl.getServiceStartTime() is used: > > public class McastService .... { > public Member getLocalMember(boolean alive) { > if ( alive && localMember != null && impl != null) > > > localMember.setMemberAliveTime(System.currentTimeMillis()-impl.getServiceStartTime()); > return localMember; > } > } > > But, when the member is transmited throw the network, the > MemberImpl.getServiceStartTime() is used. > public class MemberImpl .... { > public byte[] getData(boolean getalive, boolean reset) { > if ( reset ) dataPkg = null; > //look in cache first > if ( dataPkg!=null ) { > if ( getalive ) { > //you'd be surprised, but System.currentTimeMillis > //shows up on the profiler > long alive=System.currentTimeMillis()-getServiceStartTime(); > XByteBuffer.toBytes( (long) alive, dataPkg, > TRIBES_MBR_BEGIN.length+4); > } > return dataPkg; > } > ...... > } > > That produces that weird behaviour. > IMHO, the fix should be setting the same "serviceStartTime" to both > components. > > This issue is affecting seriously my code. I would appreciate if you could > fix > it asap. > I've verified that the same code is present in trunk repository. > > Regards, > Ariel > > -- > Configure bugmail: > https://issues.apache.org/bugzilla/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You are the assignee for the bug. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > > -- Sincerely yours and Best Regards, Xie Xiaodong
