Re: landing events branch
I wasn't able to run the tests via cmake or maven after updating and doing
a clean build, getting complaint: AttributeError: type object
'org.apache.qpid.proton.engine.Event$Category' has no attribute 'PROTOCOL'
As I saw that the CI job completed ok and knew that this was an area being
changed in the latest comits, I figured that there must be some erroneous
stale files left in my checkout since the main difference is Jenkins being
set to clear away such files before updating to the latest revision. A
little git-clean usage showed that to be the case, with various .pyc and
py.class files lying around in the tests dir particularly.
To do a git-clean dry run and see the files/dirs that would be removed:
git clean -n -d -x -e *.classpath -e *.project -e *.settings .
To actually remove them:
git clean -f -d -x -e *.classpath -e *.project -e *.settings .
The -e options are just making it ignore some IDE related files/dirs from
being nuked after the -x makes it consider things it normally ignores, so
update or remove the -e flags according to your own needs.
After cleanup, running the tests worked fine. I can only presume this
happened due to leaving stale files around after playing around on branches
previously. Perhaps the tests module needs updated to clear away such files
when doing a clean build.
Robbie
On 17 July 2014 21:07, Rafael Schloming r...@alum.mit.edu wrote:
FYI, the events branch is now landed on trunk. Please let me know if you
run into any issues.
--Rafael
On Thu, Jul 10, 2014 at 2:10 PM, Božo Dragojevič bo...@digiverse.si
wrote:
On Jul 10, 2014 6:41 PM, Rafael Schloming r...@alum.mit.edu wrote:
Hi Everyone,
I wanted to give people a quick heads up. I would like to land the
events
branch soon. If you don't use the events API then this probably won't
impact you, however if you do then you may experience some compilation
failures. This is because of the following changes:
The PN_{CONNECTION,SESSION,LINK}_LOCAL_STATE events have been
decomposed
into two distinct events:
PN_{CONNECTION,SESSION,LINK}_OPEN and
PN_{CONNECTION,SESSION,LINK}_CLOSE
Similarly, PN_{CONNECTION,SESSION,LINK}_REMOTE_STATE has been
decomposed
into:
PN_{CONNECTION,SESSION,LINK}_REMOTE_OPEN and
PN_{CONNECTION,SESSION,LINK}_REMOTE_CLOSE
To fix your code all you need to do is adjust your switch statements to
match on the new names, e.g. something like this:
...
case PN_CONNECTION_REMOTE_STATE:
...
Would become something like this:
...
case PN_CONNECTION_REMOTE_OPEN: // fall through
case PN_CONNECTION_REMOTE_CLOSE:
...
Please give me a shout if this will cause a problem for you, otherwise
I
will land the branch in a day or two.
When speed reading the new event api the other day, the change seemed
quite large, but such a mechanic change seems easy to adapt.
Bozzo
[jira] [Assigned] (PROTON-476) Support a user-context for SASL and SSL objects.
[ https://issues.apache.org/jira/browse/PROTON-476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ken Giusti reassigned PROTON-476: - Assignee: Ken Giusti Support a user-context for SASL and SSL objects. Key: PROTON-476 URL: https://issues.apache.org/jira/browse/PROTON-476 Project: Qpid Proton Issue Type: New Feature Components: proton-c Affects Versions: 0.5 Reporter: Ken Giusti Assignee: Ken Giusti Fix For: 0.8 For consistency and convenience, I'd like to add an API that would allow an application-defined context be associated with the pn_sasl_t, pn_ssl_domain_t, and pn_ssl_t objects. This api would follow the convention used by other proton classes (eg, pn_connection_get_context(), pn_connection_set_context()). ex: void *pn_sasl_get_context(pn_sasl_t); void pn_sasl_set_context(pn_sasl_t *, void *context); -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (PROTON-632) [python] Add user context handle for all objects provided by the binding
Ken Giusti created PROTON-632: - Summary: [python] Add user context handle for all objects provided by the binding Key: PROTON-632 URL: https://issues.apache.org/jira/browse/PROTON-632 Project: Qpid Proton Issue Type: Improvement Components: python-binding Affects Versions: 0.7 Reporter: Ken Giusti Assignee: Ken Giusti Fix For: 0.8 Purely syntactic sugar, but we should add a 'context' field to the API of all of the singleton objects (connection, link, session, delivery, etc) provided by the binding. This context field would be available for the user application - exactly like the get/set context methods in the C engine. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PROTON-558) Make friendly protocol field logging optional for low-memory devices
[ https://issues.apache.org/jira/browse/PROTON-558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14066421#comment-14066421 ] Andrew Stitcher commented on PROTON-558: I did a bit more work reducing the space use of the tables: (unfortunately the svn integration seems to have failed) PROTON-558: Reduce the memory usage for the field name tables some more. - Used a string pool and instead of keeping addresses of strings hold offsets into the string pool. - This moves all the tables into rodata and only leaves the string pool pointer as relro. [ https://svn.apache.org/r1611404 ] Make friendly protocol field logging optional for low-memory devices Key: PROTON-558 URL: https://issues.apache.org/jira/browse/PROTON-558 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.6, 0.7 Reporter: Markus Horstmann Assignee: Andrew Stitcher Fix For: 0.8 Embedded devices tend to be memory constrained (i.e. 128KB RAM). The FIELDS structure used for protocol logging consumes significant memory. Making it optional would help reduce the memory footprint. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (PROTON-561) Using the java broker, messenger apparently doesn't propagate error back from broker to messenger
[
https://issues.apache.org/jira/browse/PROTON-561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14066894#comment-14066894
]
Keith Wall commented on PROTON-561:
---
Should be fixed in Java Broker 0.30.
Using the java broker, messenger apparently doesn't propagate error back from
broker to messenger
-
Key: PROTON-561
URL: https://issues.apache.org/jira/browse/PROTON-561
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.6, 0.7
Reporter: Justin Ross
(The java broker logging for AMQP 1.0 is minimal; I'll mention that in
another jira.)
The test program below simply hangs. It didn't seem to want to time out,
either.
{noformat}
from proton import Message, Messenger
msgr = Messenger()
msgr.start()
try:
msg = Message()
msg.address = amqp://0.0.0.0:5672/test
msg.body = test
msgr.put(msg)
msgr.send()
finally:
msgr.stop()
{noformat}
By contrast, the same operation rendered in the qpid_messaging API produces
the expected error:
{noformat}
import sys
# You will need to build the swig python binding and point at it
sys.path.append(/home/jross/code/qpid/cpp/build/bindings/qpid/python)
from qpid_messaging import Connection
conn = Connection(0.0.0.0:5672, protocol=amqp1.0)
conn.open()
try:
session = conn.session()
sender = session.sender(test)
message = Message(test)
sender.send(message)
finally:
conn.close()
{noformat}
Error:
{noformat}
Traceback (most recent call last):
File /home/jross/test2.py, line 13, in module
sender = session.sender(test)
File
/home/jross/code/qpid/cpp/build/bindings/qpid/python/qpid_messaging.py,
line 560, in sender
s = self._sender(target)
File
/home/jross/code/qpid/cpp/build/bindings/qpid/python/qpid_messaging.py,
line 532, in _sender
def _sender(self, *args): return _qpid_messaging.Session__sender(self,
*args)
_qpid_messaging.NotFound: No such target : test
{noformat}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (PROTON-633) pn_data_clear() doesn't clear embedded error.
Andrew Stitcher created PROTON-633: -- Summary: pn_data_clear() doesn't clear embedded error. Key: PROTON-633 URL: https://issues.apache.org/jira/browse/PROTON-633 Project: Qpid Proton Issue Type: Bug Reporter: Andrew Stitcher Assignee: Rafael H. Schloming Priority: Minor Using pn_data_clear(data) to clear the contents of data doesn't reset the embedded error indicator. It's not clear to me if this is the correct behaviour or not. Is there a case for setting the error, resetting the data and then checking the error status? I'd rather expect to clear the data and then set the error status. -- This message was sent by Atlassian JIRA (v6.2#6252)
