Re: DO problems
Re: DO problems
- Subject: Re: DO problems
- From: Guy Meyer <email@hidden>
- Date: Tue, 27 May 2008 22:08:08 +0300
Welcome to the Leopard club. Yes there is DO code that works fine with
Tiger and faults on Leopard. The issue described below refers to
remote DO (i.e. socketports) as opposed to local DO.
What I have found (after spending many hours on the issue) is that if
there are multiple DO connections between the same addresses and one
of them is invalidated/ closed the result is that all of them are
faulting.
The reason for this behavior is that when an nsconnection dies the
socketport (which is also used by all other nsconnections to same
address - in order to save resources) is getting released twice !!!
( and on Tiger once). When the count reach zero the port is
invalidated/deallocated and all other nsconnections using said
socketport fail. Because of that the bug is not always reproducible
and appears to behave randomly - a nightmare.
It seems that on Leopard (as opposed to Tiger) the socketport is
observing the nsconnection and when it is closed and dies the
socketport receives a notification and its reference count is
decreased, beside some other code that decreases the count.
The solution is unbelievable simple (and I have found that there are
no memory management issues with this solution - but better test for
yourself). You should cancel the port observation of
NSConnectionDidDieNotification, just after creating the port, as
follows:
clientPort = (NSPort *)[[NSSocketPort alloc]
initRemoteWithProtocolFamily:PF_INET socketType:SOCK_STREAM
protocol:IPPROTO_TCP address:serverAddress];
[[NSNotificationCenter defaultCenter] removeObserver:clientPort
name:NSConnectionDidDieNotification object:nil];
The above code does not create a problem on Tiger as the socketport is
not observing NSConnectionDidDieNotification.
A bug was opened by ADC on my behalf in January <radr: //5706866>
It is a shame that a bug like this (which is neither fixed nor
publicly published) causes so many people to waste their time, but
this is a discussion for another list, I guess.
Update me if it works for you.
Guy Meyer
On May 27, 2008, at 2:41 AM, Ben Einstein wrote:
I, too, have encountered this nasty little problem on Leopard. Works
fine on Tiger, but I see this error followed by a nice crash about
10% of time on my DO servers with Leopard. I have no idea what's
going on and why it's fine 80% of the time and not the other.
Alex/Aurélien, have you found a solution?
Thanks,
Ben Einstein
On Mar 25, 2008, at 9:12 AM, Aurélien Hugelé wrote:
I encountered this very same problem with DO since Leopard.
I noticed that a large part of the DO backend has been rewritten in
Leopard.
If you know how to fix/reproduce the problem, I'll be glad to know.
I suggest trying your program on a Tiger/Tiger configuration.. I'm
pretty sure it will work as expected.
Aurélien,
Objective Decision Team
On 19 mars 08, at 01:58, Alexander Cohen wrote:
Hi, i have a server and client communication through DO.
Connections are all set up then the client send a message to the
server with itself as the first argument. The server should then
just reply right away to the client using the first argument as
the proxy. Problem is, im getting the error below when trying to
send the response form the server back to the client. Any ideas
what might be happening?
server received hello
*** NSDistantObject initWithCoder: 0x2 not given away for conn
0x171a62f0
exceptionHandler:shouldHandleException:
-[NSConcretePortCoder decodeInvocation]: no local target
thanks
AC
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden