Hello Michael,
On 03/07/2012 09:46 AM, Michael Raab wrote:
> 1.) unknown container id:
> - I tried to print all prototypes and its id's both for client and server
> - Up to a certain point they match, but then there are minor differences
> - Here's an example:
>
> Seems that the GlutWindow dependency has shifted server prototype id's by 1...
the cluster code is not relying on type ids being the same on both
client and server. So as long as you are not using a specific type it is
ok to only have it available on one side of the connection.
In you initial mail you said you get a warning: "Can't find FC with
ID:180". My various grep'ing attempts to locate where this warning is
emitted failed, is that the exact spelling of the warning?
You may want to set the env var OSG_LOG_HEADER to 114 (==
LOG_TYPE_HEADER | LOG_FILE_HEADER | LOG_LINE_HEADER | LOG_FUNCNAME_HEADER).
> Any ideas how to avoid that behavior? Or do I need to add GLutWindow
> dependency to our client, I hope not ;)
>
> 2.) Your patch has fixed the light node sync problems. Thanks for that.
> Unfortunately the crash has shifted to another place. There seems to be a
> NullFC pointer in some NodeChildren MF. Before the crash I get another
> warning about an unknown container id, so this problem may be related the
> issue above...
Thanks for testing! It sounds as if somehow a container is lost (or
incorrectly deleted) on the server. I'm hoping to get some clue from the
point where the warning is emitted.
Cheers,
Carsten
------------------------------------------------------------------------------
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
