On Thu, Sep 17, 2009 at 5:12 PM, Andy Spitzer <[email protected]> wrote:
> Woof! > > On Thu, 17 Sep 2009 12:33:12 -0400, M. Ranganathan <[email protected]> > wrote: > > sipXrelay is not set up to deal with this form of re-entrancy. i.e. it >> cannot deal with multiple outstanding requests from a single client. >> However, that can be changed if needed. >> > > That would be the correct answer. Making assumptions about what the client > will do is never a good idea. Someday another client may come along. > Protect the server side, even with one honking "one request at a time" type > mutex. > > I agree. I can change the code in 4.2 for "handle level" (i.e. connection level) locking so as to guard against such clients.That would be the better solution. But for 4.0.3, we should probably follow the approach of least disruption. I would go for the big hunking lock but that would couple clients fate. The right solution is a "handle level" lock. Bob said it might be easier to accomplish a lock in the proxy server since this is really only happening for the one case during initialization. It apparently is well behaved there after. The other client (sipxbridge) does its own locking and there is only ever one outstanding request per connection . > Would the same problem occur if two different clients made a request at the > same time? If so, there's obviously no locking the clients can do to > synchronize with each other, so it's a server problem and needs to be > addressed there. > > No it would not happen if two different clients make a request at the same time. --Woof! > -- M. Ranganathan
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
