Re: Building qpid proton proactor on linux 2.6...
Have you tried the libuv proactor implementation for Proton-C? See qpid-proton/c/CMakeLists.txt. The current release of libuv claims to be fully supported on "Linux >= 2.6.32 with glibc >= 2.12". If libuv works for you, that might be the easiest solution. On Thu, Sep 6, 2018 at 4:26 AM, wrote: > > Hi, > > I am trying to port a project which was implemented using qpid-proton-cpp > from a fairly recent Fedora linux kernel to an older RHEL linux 2.6. > > The older kernel is required because the end user unfortunately only runs the > older linux kernel, and due to company policy they cannot upgrade in the near > future. > > Unfortunately when we try to build on linux kernel 2.6 there are dependency > issues which relate to the older kernel not including support for timerfd > which is used in qpid-proton-proactor. > > We did also encounter some other build issues with some of the cpp templates > in proton-cpp due to bugs in the older GNU compiler version which we fixed > using workarounds, but getting the proactor to work on the older kernel looks > like it will be less than trivial without timerfd. > > I do see what appears to be an older implementation for IO etc named reactor > as opposed to proactor in the proton c implementations, but unfortunately the > cpp container implementation which we are using does not seem to have an > implementation using reactor instead of proactor? > > Is there any way around this - is it possible to use container without having > timerfd support in the kernel? > > Performance isn't important for us in this so a simple socket read loop would > be fine - just I am not sure how to shoehorn that into what we have already > implemented using container...? > > Thanks > N > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
[RESULT] [VOTE] Release Apache Qpid Proton 0.25.0
There were 5 binding +1 votes, and no other votes received. The vote has passed. I will add the files to the dist release repo and create the final tag shortly. The website will be updated after the release has had time to sync to the mirrors. Robbie - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: Building qpid proton proactor on linux 2.6...
timerfd can be fairly easily replaced with a socketpair, where one socket is used in the poll/select and the other is used to signal activation. To wake up the poll/select, write a character into the signal socket. You will need to be sure to read the characters out of the select socket to make sure you don't get a full buffer and back-pressure. -Ted On Thu, Sep 6, 2018 at 7:26 AM, wrote: > > Hi, > > I am trying to port a project which was implemented using qpid-proton-cpp > from a fairly recent Fedora linux kernel to an older RHEL linux 2.6. > > The older kernel is required because the end user unfortunately only runs the > older linux kernel, and due to company policy they cannot upgrade in the near > future. > > Unfortunately when we try to build on linux kernel 2.6 there are dependency > issues which relate to the older kernel not including support for timerfd > which is used in qpid-proton-proactor. > > We did also encounter some other build issues with some of the cpp templates > in proton-cpp due to bugs in the older GNU compiler version which we fixed > using workarounds, but getting the proactor to work on the older kernel looks > like it will be less than trivial without timerfd. > > I do see what appears to be an older implementation for IO etc named reactor > as opposed to proactor in the proton c implementations, but unfortunately the > cpp container implementation which we are using does not seem to have an > implementation using reactor instead of proactor? > > Is there any way around this - is it possible to use container without having > timerfd support in the kernel? > > Performance isn't important for us in this so a simple socket read loop would > be fine - just I am not sure how to shoehorn that into what we have already > implemented using container...? > > Thanks > N > > - > To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org > For additional commands, e-mail: users-h...@qpid.apache.org > - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
qpid-proton-cpp decoder.cpp - possible bug?
Hi,
Around line 180, decoder.cpp has the following:
decoder& decoder::operator>>(scalar& x) {
internal::state_guard sg(*this);
type_id got = pre_get();
if (!type_id_is_scalar(got))
throw conversion_error("expected scalar, found "+type_name(got));
x.set(pn_data_get_atom(pn_object()));
sg.cancel(); // No error, no rewind
return *this;
}
When our client code is talking to a 3rd party system's broker, we find that
the scalar in argument "x" is coming through from the other party as type NULL
in some cases - which causes the throw in the above method to get triggered and
then disconnects us from the broker.
However, if we comment out the if/throw from the code in decoder.cpp,
everything then appears to be workding 100% correctly.
Is there a correct way to do this without removing the throw? - it seems that
if the check is there it must have a purpose, so by removing the check I am
probably opening myself up to some other issues further down the line?
Thanks
N
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
Building qpid proton proactor on linux 2.6...
Hi, I am trying to port a project which was implemented using qpid-proton-cpp from a fairly recent Fedora linux kernel to an older RHEL linux 2.6. The older kernel is required because the end user unfortunately only runs the older linux kernel, and due to company policy they cannot upgrade in the near future. Unfortunately when we try to build on linux kernel 2.6 there are dependency issues which relate to the older kernel not including support for timerfd which is used in qpid-proton-proactor. We did also encounter some other build issues with some of the cpp templates in proton-cpp due to bugs in the older GNU compiler version which we fixed using workarounds, but getting the proactor to work on the older kernel looks like it will be less than trivial without timerfd. I do see what appears to be an older implementation for IO etc named reactor as opposed to proactor in the proton c implementations, but unfortunately the cpp container implementation which we are using does not seem to have an implementation using reactor instead of proactor? Is there any way around this - is it possible to use container without having timerfd support in the kernel? Performance isn't important for us in this so a simple socket read loop would be fine - just I am not sure how to shoehorn that into what we have already implemented using container...? Thanks N - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
