Bug243 Editing
Built from CVS. Running clients now do not seem to contact server. They do not error-out or otherwise report a failure, but server (with tracing/logging) does not show any attempt at pinging the client, or even noticing when the client is started. Don't have time to debug this now, so leaving this record. gcc2.95, omni3, debian unstable.
Small update: changed my omniorb setup slightly, and now it mostly works...if I use the nameserver. This seems like a race condition, which may tie in with bug92 & bug235. Basically fresco-demo3D generally works every time. Use the nameserver, and fresco-demo works the first time you run it, but after that it goes into high-cpu like with bug235. Use ior, and the fresco-demo doesn't work at all. Use ior with logging & tracing and you get a similar failure result - but which suggests a different cause to bug235.
Rebuilt using gcc3.2.2 (debian unstable, but not pre). Now apps run ok if from a different xterm, (100%) and mostly ok if from the same xterm, as the berlin server. However the behaviour I see is just the same as with bug235, not in the trace, but in terms of the server locks up mostly with a high-cpu. If I run with tracing/logging enabled then I don't see this, and logging doesn't help too much.
Oh, I've found something like this at some point. It's Resolve.cc::server_can_be_contacted calling server->_non_existent() which is never returning, or has a five minute timeout or some such. I just "rm -rf /tmp/fresco", kill the processes and try again. I don't know if this is the same bug or not. I'll know when it next happens to me and I check my CPU usage.
BNrkO7 <a href="http://evcanicdydnd.com/">evcanicdydnd</a>, [url=http://cvjtgutmuatd.com/]cvjtgutmuatd[/url], [link=http://dyplizujbfth.com/]dyplizujbfth[/link], http://htwprksdylpk.com/
not logged in
register
Home