[jira] [Created] (PROTON-733) SASL related updates (wishes)
German Shepherd created PROTON-733:
--
Summary: SASL related updates (wishes)
Key: PROTON-733
URL: https://issues.apache.org/jira/browse/PROTON-733
Project: Qpid Proton
Issue Type: Wish
Components: proton-c
Affects Versions: 0.8
Reporter: German Shepherd
Priority: Minor
Let me add a another set of SASL-related 'wishes':
I'm running ProtonC on a memory constrained environment.
After the SSL is connected, then there is a SASL PLAIN auth taking place.
After the SASL is done doing its thing, it is basically not required any more
(not until the whole connection is dropped and then reopened - this is my case).
So after the dispatch of
{{0 <- sasl-outcome(68) [ code=0, additional-data=b"Welcome!" ]}}
I would like to have the SASL to release all its dynamic memory (the whole
object) and remove itself from {{transport->io_layers[ PN_IO_SASL ];}} (replace
SASL I/O functions with a pass-through functions).
This way, there is a very welcome drop of use of the dynamic memory, as the
actual test of this approach shows.
As a another wish, I would like to get a new global flag (or better yet, a
pn_xxx callback function) added, which the application can query, to see when
the SASL is done - this is somehow crucial for timing of the behavior of the
user application in a memory constrained environment (e.g. do not proceed with
message memory allocations until the connection and SASL is actually done).
Perhaps a better approach might be possible here (so far this particular way
worked well), I'm all ears.
I understand that none of the both request do apply for the 'normal' use of the
ProtonC (where dynamic memory is not the limitation), but yet I would like to
have the option, even if delimited with a {{#ifdef}} configuration.
The amount of work to do this is minimal, yet I would like to get this
discussed and done the official way,
so I won't need to manually update the ProtonC code after downloading it.
thx
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (PROTON-725) pni_parse_url does not properly handle Base64 in URL
[
https://issues.apache.org/jira/browse/PROTON-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
German Shepherd closed PROTON-725.
--
Resolution: Not a Problem
Fix Version/s: 0.8
Let me provide an update.
MS Azure does actually accept the URL-escaped strings as a 'password', so there
is no need to un-escape the values in ProtonC, after the URL is parsed.
It was an issue of the Provisioning, which provided the plain Base64 text for
'password', without escaping it first.
First, I was afraid that MS Azure won't accept the escaped 'password'.
After testing such a setup, I found out that the MS Azure does accept it and
the SASL goes through OK in such case.
Thanks for a discussion, I'm closing the ticket (no need for any ProtonC code
modification due to this ticket).
> pni_parse_url does not properly handle Base64 in URL
>
>
> Key: PROTON-725
> URL: https://issues.apache.org/jira/browse/PROTON-725
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: 0.8
>Reporter: German Shepherd
>Priority: Minor
> Fix For: 0.8
>
>
> Our provisioning system provides us with a password in Base64 format, which
> can actually contain a slash character(s): '/'
> This breaks the ability of {{pni_parse_url()}} to handle such URLs.
> Example of URL string on which the parsing fails:
> {{amqps://0ABCDEF1:/ExlxtfN+UxfExRxuwxIeFxeFzXLxxg+fxPx3x8xxU=@myself.servicebus.windows.net/out/t/Subscriptions/s}}
> Instead of filling up the "user" and "password" variables, it puts the actual
> contents to "host" and "port".
> With the actual code it is a correct behavior - and *it is* also mentioned in
> the comment right in front of the pni_parse_url() function.
> Yet I would need an update to the functionality, to handle the Base64 in
> password properly (anyone on Azure platform might run to this issue, soon or
> later).
> Note. I'm running the SVN rev 1633464 (latest trunk of 10/23/2014) version of
> ProtonC (C / Linux).
> Thanks for looking at this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (PROTON-734) deliveries are not returned in order
Gordon Sim created PROTON-734: - Summary: deliveries are not returned in order Key: PROTON-734 URL: https://issues.apache.org/jira/browse/PROTON-734 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Gordon Sim Assignee: Rafael H. Schloming Priority: Critical If, on a single session, I send e.g. 3 messages on one link, followed by a message on another link, then on the receiving side I expect those to be returned in the order in which they are sent. Although proton-c on the receiving side receives them in the correct order as verified by turning on tracing, the order in which the respective deliveries are returned by pn_work_head()/pn_work_next() is not correct. I get the first message, followed by the last message (i.e. the fourth), then the second and third. If I modify the test to send a fifth message to a third link, then on the receiving side the 5th message is received 3rd. I.e. it appears that the work queue involves taking the first delivery off each link, rather than having a session level ordering(?) In the case where a transaction discharge message is sent *after* some transactional publications, this results in the discharge being processed before all the publications the transaction is supposed to cover. (The sender can of course wait for all the transactional publications to be accepted before it sends the commit, but on a single session this isn't necessary and as far as I can see not required by the spec.) In any case, preserving order is likely to be important in other cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-724) pn_transport_close_head doesn't generate the expected PN_TRANSPORT_HEAD_CLOSED event
[ https://issues.apache.org/jira/browse/PROTON-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-724. Resolution: Fixed Fix Version/s: 0.8 > pn_transport_close_head doesn't generate the expected > PN_TRANSPORT_HEAD_CLOSED event > > > Key: PROTON-724 > URL: https://issues.apache.org/jira/browse/PROTON-724 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Rafael H. Schloming >Assignee: Rafael H. Schloming > Fix For: 0.8 > > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-729) library assers in pn_full_settle
[ https://issues.apache.org/jira/browse/PROTON-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-729. Resolution: Fixed > library assers in pn_full_settle > > > Key: PROTON-729 > URL: https://issues.apache.org/jira/browse/PROTON-729 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.7, 0.8 >Reporter: Michael > Attachments: qpidd.trace.bz2 > > > qProton library asserts in pn_full_settled function in qpidd. I had to create > this issue on advise from Chuck Rolke since it turned out that attachements > are blocked by email list -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Proton release planning
Hey Rafi - thanks for doing this. Can we add support for Python 3 in the timeline? - Original Message - > From: "Rafael Schloming" > To: proton@qpid.apache.org, d...@qpid.apache.org, us...@qpid.apache.org > Sent: Tuesday, October 28, 2014 3:59:53 PM > Subject: Proton release planning > > Hi Everyone, > > I'd like to try to get the proton releases to be a bit more frequent, and > I'm also trying to get a bit more up front planning into them. To that end > I've put together a quick description of what I'd propose for timeline and > scope of the next release here: > > http://qpid.apache.org/proton/development.html > > Please have a look and let me know what you think. > > --Rafael > -- -K
Re: VOTE: Release Proton 0.8 RC5 as 0.8 final
[ X ] Yes, release Proton 0.8 RC5 as 0.8 final I tested 0.8 against the Dispatch trunk. On 10/27/2014 09:51 PM, Rafael Schloming wrote: > Hi Everyone, > > Sorry for the delay, there seemed to be some kind of Nexus outage today, so > I was unable to generate the java binaries until just now. > > I've posted RC5 in the usual places. The only difference from RC4 is a one > line delta that replaces the assertion failure when we receive > out-of-sequence ids with a connection shutdown error. Please have a look > and register your vote. > > Source code can be found here: > > http://people.apache.org/~rhs/qpid-proton-0.8rc5/ > > Java binaries are here: > > https://repository.apache.org/content/repositories/orgapacheqpid-1021 > > [ ] Yes, release Proton 0.8 RC5 as 0.8 final > [ ] No, because ... > > --Rafael >
Re: Proton release planning
Is the plan to keep JMS in a separate project and managed separately as part of qpid? How are the dependencies between Proton and Qpid-JMS going to be addressed? Jack On 10/29/14, 9:13 AM, "Ken Giusti" wrote: >Hey Rafi - thanks for doing this. > >Can we add support for Python 3 in the timeline? > >- Original Message - >> From: "Rafael Schloming" >> To: proton@qpid.apache.org, d...@qpid.apache.org, us...@qpid.apache.org >> Sent: Tuesday, October 28, 2014 3:59:53 PM >> Subject: Proton release planning >> >> Hi Everyone, >> >> I'd like to try to get the proton releases to be a bit more frequent, >>and >> I'm also trying to get a bit more up front planning into them. To that >>end >> I've put together a quick description of what I'd propose for timeline >>and >> scope of the next release here: >> >> http://qpid.apache.org/proton/development.html >> >> Please have a look and let me know what you think. >> >> --Rafael >> > >-- >-K
Re: VOTE: Release Proton 0.8 RC5 as 0.8 final
[X} Yes, release Proton 0.8 RC5 as 0.8 final I tested 0.8 against the HornetQ trunk. Had to rename a few enums (SESSION_OPEN to SESSION_LOCAL_OPEN) but other than that everything worked.
Re: Proton release planning
On Wed, Oct 29, 2014 at 10:13 AM, Ken Giusti wrote: > Hey Rafi - thanks for doing this. > > Can we add support for Python 3 in the timeline? > Without a patch or some exploratory work on it, I'm not really sure where I'd slot it in. --Rafael
[jira] [Commented] (PROTON-723) Proton-c does not support attaching to the transaction coordinator
[ https://issues.apache.org/jira/browse/PROTON-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14188840#comment-14188840 ] ASF subversion and git services commented on PROTON-723: Commit 1635266 from r...@apache.org in branch 'proton/trunk' [ https://svn.apache.org/r1635266 ] PROTON-723: based on gordon's patch, added support for the coordinator target > Proton-c does not support attaching to the transaction coordinator > -- > > Key: PROTON-723 > URL: https://issues.apache.org/jira/browse/PROTON-723 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8 >Reporter: Hiram Chirino >Assignee: Rafael H. Schloming >Priority: Critical > Labels: api, transactions > Attachments: PROTON-723_part2_quick_and_dirty.patch, > quick_and_dirty.patch > > > Though there is a terminus type PN_COORDINATOR defined, setting that seems to > have no effect and indeed the code in pn_process_link_setup always sets the > source to the descriptor code for amqp:source:list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-723) Proton-c does not support attaching to the transaction coordinator
[ https://issues.apache.org/jira/browse/PROTON-723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-723. Resolution: Fixed Fix Version/s: 0.9 > Proton-c does not support attaching to the transaction coordinator > -- > > Key: PROTON-723 > URL: https://issues.apache.org/jira/browse/PROTON-723 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.8 >Reporter: Hiram Chirino >Assignee: Rafael H. Schloming >Priority: Critical > Labels: api, transactions > Fix For: 0.9 > > Attachments: PROTON-723_part2_quick_and_dirty.patch, > quick_and_dirty.patch > > > Though there is a terminus type PN_COORDINATOR defined, setting that seems to > have no effect and indeed the code in pn_process_link_setup always sets the > source to the descriptor code for amqp:source:list. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (PROTON-731) Installing language bindings provides no means to override the install path
[ https://issues.apache.org/jira/browse/PROTON-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce updated PROTON-731: Attachment: 0001-PROTON-731-Installing-Python-requires-Proton-be-inst.patch Changes both CHECK_SYSINSTALL_PYTHON and PYTHON_SITEARCH_PACKAGES to be cached variables that can be overridden from the command line. > Installing language bindings provides no means to override the install path > --- > > Key: PROTON-731 > URL: https://issues.apache.org/jira/browse/PROTON-731 > Project: Qpid Proton > Issue Type: Bug > Components: python-binding >Reporter: Darryl L. Pierce >Assignee: Darryl L. Pierce > Attachments: > 0001-PROTON-731-Installing-Python-requires-Proton-be-inst.patch > > > When performing an install, such as with Fedora or Ubuntu packaging, the > python installation bits use setuptools to build and install the bindings. > However, since the code isn't necessarily installed at that point the install > fails with: > running sdist > running check > warning: sdist: manifest template 'MANIFEST.in' does not exist (using default > file list) > warning: sdist: standard file not found: should have one of README, README.txt > writing manifest file 'MANIFEST' > creating python-qpid-proton-0.8-0 > making hard links in python-qpid-proton-0.8-0... > hard linking cproton.py -> python-qpid-proton-0.8-0 > hard linking cprotonPYTHON_wrap.c -> python-qpid-proton-0.8-0 > hard linking proton.py -> python-qpid-proton-0.8-0 > hard linking setup.py -> python-qpid-proton-0.8-0 > creating dist > Creating tar archive > removing 'python-qpid-proton-0.8-0' (and everything under it) > running install > running build > running build_py > creating build > creating build/lib.linux-x86_64-2.7 > copying proton.py -> build/lib.linux-x86_64-2.7 > copying cproton.py -> build/lib.linux-x86_64-2.7 > running build_ext > building '_cproton' extension > creating build/temp.linux-x86_64-2.7 > gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 > -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 > -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv > -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions > -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 > -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -Itemp/usr/local/include > -I/usr/include/python2.7 -c cprotonPYTHON_wrap.c -o > build/temp.linux-x86_64-2.7/cprotonPYTHON_wrap.o > cprotonPYTHON_wrap.c:3019:24: fatal error: proton/url.h: No such file or > directory > #include > ^ > compilation terminated. > ERROR:root:setup failed! -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: VOTE: Release Proton 0.8 RC5 as 0.8 final
[ x ] Yes, release Proton 0.8 RC5 as 0.8 final Tested on Windows: 32/64 bit, XP/Win8.1 On Monday, October 27, 2014, Rafael Schloming wrote: > Hi Everyone, > > Sorry for the delay, there seemed to be some kind of Nexus outage today, so > I was unable to generate the java binaries until just now. > > I've posted RC5 in the usual places. The only difference from RC4 is a one > line delta that replaces the assertion failure when we receive > out-of-sequence ids with a connection shutdown error. Please have a look > and register your vote. > > Source code can be found here: > > http://people.apache.org/~rhs/qpid-proton-0.8rc5/ > > Java binaries are here: > > https://repository.apache.org/content/repositories/orgapacheqpid-1021 > > [ ] Yes, release Proton 0.8 RC5 as 0.8 final > [ ] No, because ... > > --Rafael >
Re: VOTE: Release Proton 0.8 RC5 as 0.8 final
[ X ] Yes, release Proton 0.8 RC5 as 0.8 final
Tested Windows Server 2012 RC2 host, compiled with Visual Studio {2008, 2010,
2012, 2013} {x86, {x64}
passes ctest(s)
