Hi Patrick, Gabriel is working with us and I might be able to help with this a little since he is out for the day. You may be right in that the renderWindow() routine is stuck in a loop. I can't imagine why, but will dig into it a little. Actually, it's quite strange since we don't see any unnecessary blocking behavior with OpenSG's clustering when using a single computer VRJ configuration...only when using a VRJ clustered configuration.
Thanks for the advice, and I'll let you know if the renderWindow turns up anything. E. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick Hartling Sent: Friday, June 08, 2007 11:29 To: [email protected] Subject: Re: [Opensg-users] OpenSG VRJuggler cluster conflict Gabriel Cirio wrote: > Hello, > > we are trying to set up an OpenSG cluster system on top of VRJuggler, to > use on a cluster of 4 rendering nodes plus 1 control computer. The > OpensSG cluster seems to be working (in its initialization phase and > syncing of changelists), but the servers (rendering nodes) block after > VRJuggler's draw routine (where the OpenSG syncing and rendering is > done). There is no VRJuggler barrier (syncing point) after the draw > routine, and the servers should go to their contextPostDraw routine > immediately after the draw routine, but they block after the last line > of code of the draw routine. I don't understand what you mean here. The code can't be blocking on returning from the vrj::OpenSGApp::draw() function. Based on how you describe the situation, it's either stuck in vrj::GlPipe::renderWindow() or some OpenSG function called from vrj::OpenSGApp::draw() isn't returning. > The client (control computer), however, > goes to contextPostDraw after draw, and then to postFrame, which has a > VRJuggler syncing point, and therefore blocks there since it is waiting > for the servers to reach that same point and sync. > > This happens when VRJuggler is launched on cluster mode. In standalone > mode (no VRJuggler cluster), the application works fine, and we can > control what is being rendered through the control computer (thanks to > the OpenSG cluster). In VRJuggler's cluster mode, the only frame that we > should be seeing (before the servers blocking) is not even rendered. > > We are using a ClusterWindow on the client side, and a ClusterServer on > the server side, with a PassiveWindow, PassiveViewport and > PassiveBackground, since VRJuggler takes care of window and context > creation. > > Does anybody have any idea of why this is happening? Have you found exactly what is hanging on the client side (using "client" in the OpenSG context) and causing the deadlock? It sounds like something is waiting on network communication to come from the servers. However, if vrj::GlPipe::renderWindow() were stuck in an infinite loop trying to render the viewports of the window, that would account for it, too. -Patrick -- Patrick L. Hartling VP Engineering, Infiscape Corp. http://www.infiscape.com/ ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
