[
https://issues.apache.org/jira/browse/PROTON-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16456671#comment-16456671
]
ASF GitHub Bot commented on PROTON-1831:
----------------------------------------
Github user alanconway commented on the issue:
https://github.com/apache/qpid-proton/pull/142
On Fri, Apr 27, 2018 at 4:57 AM, Robbie Gemmell <[email protected]>
wrote:
> The use of "invalid-field" for the error feels like it is maybe a little
> off. Its possible/likely there is nothing wrong with the information in
the
> fields of the attach, as none of it is really actually checked (e.g
whether
> its the same remote handle, itself a session:handle-in-use error) other
> than someone got there previously with the name. Perhaps "illegal-state"
> might be more applicable given the actual check being done?
>
> That said though, its not actually 100% clear it is an illegal state. The
> spec covers attaching an active link a second time as resulting in the
> first attachment being detached with the "stolen" link error. Its
described
> for handling across different connections (something proton thus cant
> actually do on its own) e.g during reconnect, but its not clear that
> precludes it being the case on a single session or connection. However, it
> does seem far more likely to be in result of an error for the situation to
> ever occur on a single session/connection so perhaps treating it as such
is
> the way to go in the end (plus any alternative would I guess be much
harder
> to achieve, so maybe its the only choice for now).
>
Thanks - I didn't know about stolen. I think we could implement what the
spec says on the server side - close the old link/handle with "stolen" and
create a new link under the new handle. That would fix the crash, which was
because of multiple handles to the same link object - we'd have a seprate
link object for each handle, all but one of which are closed with "stolen".
I think on the client side its always an error to try to attach if you
already have a link with same name an a handle. After disconnect all
handles are cleared, so it is OK an error to re-attach during reconnect. I
want to fix the client to refuse to create a link at all in this case. That
would prevent this happening on the wire and give more immediate feedback
to code that is mistakenly trying to double-attach. The fix is not trivial
due to proton's batch-processing madness or I'd have done it first.
Does that sound right?
Cheers,
Alan.
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/apache/qpid-proton/pull/142#issuecomment-384909833>,
> or mute the thread
>
<https://github.com/notifications/unsubscribe-auth/AHa6XkfJqlyZLxyGacl_EEvpcsQVuXAvks5tst1zgaJpZM4TkKfO>
> .
>
> [C++ binding] Nested complex types fail compilation with "incomplete type"
> error
> --------------------------------------------------------------------------------
>
> Key: PROTON-1831
> URL: https://issues.apache.org/jira/browse/PROTON-1831
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
> Reporter: Kim van der Riet
> Assignee: Alan Conway
> Priority: Major
>
> When using nested complex types (for example, a list of maps or an array of
> lists), the compiler fails to compile. For example, the following code
> snippet (saved as {{ctt.cpp}}):
> {noformat}
> #include <map>
> #include <vector>
> #include <proton/types.hpp>
> int main(int, char**) {
> std::map<proton::value, proton::value> m1 = {{uint8_t(0), "zero"},
> {uint8_t(1), "one"}};
> std::map<proton::value, proton::value> m2 = {{true, "true"}, {false,
> "false"}};
> std::vector<std::map<proton::value, proton::value> > am = {m1, m2};
> proton::value pv = am;
> }{noformat}
> fails compilation with the following error:
> {noformat}
> In file included from install/include/proton/types.hpp:47:0,
> from ctt.cpp:3:
> install/include/proton/./codec/vector.hpp: In instantiation of
> ‘proton::codec::encoder& proton::codec::operator<<(proton::codec::encoder&,
> const std::vector<_Tp, _Alloc>&) [with T = std::map<proton::value,
> proton::value>; A = std::allocator<std::map<proton::value, proton::value> >]’:
> install/include/proton/./value.hpp:84:11: required from ‘typename
> proton::value::assignable<T, proton::value&>::type
> proton::value::operator=(const T&) [with T =
> std::vector<std::map<proton::value, proton::value> >; typename
> proton::value::assignable<T, proton::value&>::type = proton::value&]’
> install/include/proton/./value.hpp:79:85: required from
> ‘proton::value::value(const T&, typename proton::value::assignable<T>::type*)
> [with T = std::vector<std::map<proton::value, proton::value> >; typename
> proton::value::assignable<T>::type = void]’
> ctt.cpp:9:24: required from here
> install/include/proton/./codec/vector.hpp:39:31: error: incomplete type
> ‘proton::internal::type_id_of<std::map<proton::value, proton::value> >’ used
> in nested name specifier
> return e << encoder::array(x, internal::type_id_of<T>::value);
> ~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
