Hi,
I have some strange effects when running our 1.8 based application in
cluster mode.
When I connect render servers to our application I call
RemoteAspect::createCurrentStateChangeList
<classosg_1_1RemoteAspect.html#a989801f5a7fe8944754797b376e66b91>(ChangeList
<classosg_1_1ChangeList.html> *cl) to provide the full sync to all late
arriving servers. That worked well in the past and can't remember any
major changes to that part of our sytem...
This is what I investigated today:
1.) When the render servers receive the first sync, they print the
following warning: "Can't find FC with ID:180". When debugging into the
our client application I found out that the FC with ID 180 is the
prototype of our MultiDisplayWindow implementation. On server side FC
180 is needed by a Viewport instance as parent field. Which is strange.
The interesting thing is that this is the FC prototype with the highest
ID on client side. Starting at ID 181 I can only see FC instances. That
does not crash our application but I'm not sure if there are hidden side
effects I haven't investigated so far....
2.) If I have a ShadowViewport in the application that has at least one
light node attached and try to connect to a render server, the server
crashes in ShadowViewport::changed() when iterating the list of light
nodes. It seems some/all light nodes do not have a core assigned. That
looks to me probably like a similar sync problems as mentioned above.
I do not have an idea what may cause that behavior. Ideas?
Thanks,
Michael
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Opensg-users mailing list
Opensg-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/opensg-users
