----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/33300/#review80598 -----------------------------------------------------------
Ship it! I suspect at some point we might need to revisit this area for detach/reattach semantics, but we can cross that bridge when we come to it. - Rafael Schloming On April 17, 2015, 11:24 a.m., Gordon Sim wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/33300/ > ----------------------------------------------------------- > > (Updated April 17, 2015, 11:24 a.m.) > > > Review request for qpid and Rafael Schloming. > > > Repository: qpid-proton-git > > > Description > ------- > > If a link is created with the same name as an existing link on the same > session, the new link object will never get into the open state, even if the > previous link has been closed. This is because in processing the attach, the > links on the session are iterated over until one is found with a matching > name (and type). However in this case the old link, now in the closed state > is returned. While an explicit freeing of the old link before creating the > new link avoids this, that is hard to control from e.g. python. > > The proposed solution adds an additional check on endpoint state when trying > to find the object to whcih an incoming attach refers. > > > Diffs > ----- > > proton-c/src/transport/transport.c 62d4742 > > Diff: https://reviews.apache.org/r/33300/diff/ > > > Testing > ------- > > All existing tests pass, original reproducers for PRTON-850 and QPID-6320 > also pass. > > > Thanks, > > Gordon Sim > >
