[jira] [Created] (PROTON-808) Binaries have their library locations stripped
Justin Ross created PROTON-808: -- Summary: Binaries have their library locations stripped Key: PROTON-808 URL: https://issues.apache.org/jira/browse/PROTON-808 Project: Qpid Proton Issue Type: Bug Components: proton-c Reporter: Justin Ross 1. Build proton 2. Install to /usr/local 3. Run proton - Blows up, can't find its library https://paste.apache.org/gd56 http://stackoverflow.com/questions/3352041/creating-binary-with-cmake-removes-runtime-path The default behavior of cmake is in my opinion wrong, and we should use the fix mentioned in that stackoverflow discussion. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Ruby memory management (was: Ruby and the Engine APIs)
On Wed, Jan 28, 2015 at 9:06 AM, Darryl L. Pierce dpie...@redhat.com wrote: On Wed, Jan 28, 2015 at 06:04:57AM -0500, Rafael Schloming wrote: On the face of it this sounds like it could be quite brittle and probably more complicated than just forgetting about swig for the one pn_rubyref_t struct and wrapping it manually. Did you attempt the latter option at all? Yes, there is a POC of this on my branch as well. Did it work? Can you send me a pointer to it? --Rafael
Re: Ruby memory management (was: Ruby and the Engine APIs)
On Wed, Jan 28, 2015 at 06:04:57AM -0500, Rafael Schloming wrote: On the face of it this sounds like it could be quite brittle and probably more complicated than just forgetting about swig for the one pn_rubyref_t struct and wrapping it manually. Did you attempt the latter option at all? Yes, there is a POC of this on my branch as well. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgphTZBbOghP3.pgp Description: PGP signature
Re: Ruby memory management (was: Ruby and the Engine APIs)
On Tue, Jan 27, 2015 at 5:35 PM, Darryl L. Pierce dpie...@redhat.com wrote: On Fri, Jan 23, 2015 at 03:46:34PM -0500, Darryl L. Pierce wrote: +1 Though, I was hoping we could avoid having to manually do things... So I have a working POC that assigns a Ruby object to a C struct in such a way as to keep the Ruby object from being reaped. The solution (for now) stores the object in a hidden global array for such objects for as long as they're held by the C structure and, when C is deleted or the reference changed, the object is removed from the array and available for reaping. I submitted a question to the Swig users mailing list, but that seems to be pretty low traffic and effectively unmanned ATM. Only 15 posts there in the last month and none of them have followups. On the face of it this sounds like it could be quite brittle and probably more complicated than just forgetting about swig for the one pn_rubyref_t struct and wrapping it manually. Did you attempt the latter option at all? It's really important to get this part right. If this isn't done well, then the whole binding will be unstable. Whatever has been done here with the current ruby bindings seems to seg fault about once every 10 test runs or so. We really can't afford to repeat that. --Rafael
Re: Ruby memory management (was: Ruby and the Engine APIs)
On Wed, Jan 28, 2015 at 09:19:29AM -0500, Rafael Schloming wrote: On Wed, Jan 28, 2015 at 9:06 AM, Darryl L. Pierce dpie...@redhat.com wrote: On Wed, Jan 28, 2015 at 06:04:57AM -0500, Rafael Schloming wrote: On the face of it this sounds like it could be quite brittle and probably more complicated than just forgetting about swig for the one pn_rubyref_t struct and wrapping it manually. Did you attempt the latter option at all? Yes, there is a POC of this on my branch as well. Did it work? Can you send me a pointer to it? Yes, it works. It uses Data_Wrap_Struct to encapsulate the pn_rubyref_t type, rb_gc_mark to mark any Ruby object held by that type against reaping, and does appropriate alloc and free operations on instances of the struct. https://github.com/mcpierce/Proton/tree/c-to-ruby-reference-gc-check -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgpRloAgXb9mC.pgp Description: PGP signature
[jira] [Closed] (PROTON-807) Proton does not decode AMQP small long encoding correctly and does not use it.
[ https://issues.apache.org/jira/browse/PROTON-807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan Conway closed PROTON-807. -- Resolution: Fixed Proton does not decode AMQP small long encoding correctly and does not use it. -- Key: PROTON-807 URL: https://issues.apache.org/jira/browse/PROTON-807 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Alan Conway Assignee: Alan Conway Fix For: 0.9 Proton incorrectly decodes an AMQP small long encoded value of -1 as 255. Proton itself never uses the small long encoding but qpid dispatch does, which is where this cropped up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: request/response stuff has broken the java build
On Tue, 2015-01-27 at 09:46 -0500, Rafael Schloming wrote: Do you have tracing turned on when they time out? With the protocol trace enabled the tests slow down enough that some of them don't finish before the various timeouts kick in. Much more insidious. It turns out that if you use 0.0.0.0 as a connect address AND you have a VPN running AND you are using jython then things hang (at least on fedora 20 in my house in January.) Looking up the ip(7) man page it seems like 0.0.0.0 is only supposed to be used as a bind address, not a connect address, so I switched the tests in question to use 127.0.0.1 and everything works (it also works if I turn off my VPN or use proper python) I didn't switch everything in python to use 127.0.0.1 for connect (NOTE 0.0.0.0 is still correct for listening) in case there was some hidden disaster there. Probably at least the examples and maybe the default port for class Url should be changed, any dissent? --Rafael On Tue, Jan 27, 2015 at 9:29 AM, Alan Conway acon...@redhat.com wrote: On Tue, 2015-01-27 at 09:00 -0500, Rafael Schloming wrote: Hi Alan, The recently added stuff in utils.py seems to have broken the java build. It uses the 'with' keyword which is apparently not supported in jython. --Rafael Fixing ASAP. I have persistent trouble with the java test failing with timeouts I need to figure that out and stop skipping them :(
[jira] [Commented] (PROTON-807) Proton does not decode AMQP small long encoding correctly and does not use it.
[ https://issues.apache.org/jira/browse/PROTON-807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14296165#comment-14296165 ] ASF subversion and git services commented on PROTON-807: Commit a515e195c4ea28b4bb513ed6e7a905b4fa34e2ad in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=a515e19 ] PROTON-807: Use the small int and small long encodings when possible. Due to an oversight, proton was using small encodings for unsigned int and long types but not for signed types. This patch corrects that. Proton does not decode AMQP small long encoding correctly and does not use it. -- Key: PROTON-807 URL: https://issues.apache.org/jira/browse/PROTON-807 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Alan Conway Assignee: Alan Conway Fix For: 0.9 Proton incorrectly decodes an AMQP small long encoded value of -1 as 255. Proton itself never uses the small long encoding but qpid dispatch does, which is where this cropped up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (PROTON-809) Changes to build on AIX with IBM XL C
Steve Huston created PROTON-809: --- Summary: Changes to build on AIX with IBM XL C Key: PROTON-809 URL: https://issues.apache.org/jira/browse/PROTON-809 Project: Qpid Proton Issue Type: Bug Components: proton-c Environment: IBM AIX 7, XL C/C++ 13.1 Reporter: Steve Huston Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-808) Binaries have their library locations stripped
[
https://issues.apache.org/jira/browse/PROTON-808?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14295231#comment-14295231
]
Justin Ross commented on PROTON-808:
And this, which is really a worse problem:
{noformat}
[jross@localhost flurry]$ python
Python 2.7.8 (default, Nov 10 2014, 08:19:18)
[GCC 4.9.2 20141101 (Red Hat 4.9.2-1)] on linux2
Type help, copyright, credits or license for more information.
from proton.handlers import *
Traceback (most recent call last):
File stdin, line 1, in module
File /usr/local/lib64/proton/bindings/python/proton/__init__.py, line 33,
in module
from cproton import *
File /usr/local/lib64/proton/bindings/python/cproton.py, line 28, in
module
_cproton = swig_import_helper()
File /usr/local/lib64/proton/bindings/python/cproton.py, line 24, in
swig_import_helper
_mod = imp.load_module('_cproton', fp, pathname, description)
ImportError: libqpid-proton.so.2: cannot open shared object file: No such file
or directory
[jross@localhost flurry]$ echo $PYTHONPATH
/usr/local/lib64/proton/bindings/python
{noformat}
Binaries have their library locations stripped
--
Key: PROTON-808
URL: https://issues.apache.org/jira/browse/PROTON-808
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Reporter: Justin Ross
1. Build proton
2. Install to /usr/local
3. Run proton
- Blows up, can't find its library
https://paste.apache.org/gd56
http://stackoverflow.com/questions/3352041/creating-binary-with-cmake-removes-runtime-path
The default behavior of cmake is in my opinion wrong, and we should use the
fix mentioned in that stackoverflow discussion.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (PROTON-806) closing a blocking sender hangs if connection has been lost
[ https://issues.apache.org/jira/browse/PROTON-806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14295304#comment-14295304 ] Jeff Ortel commented on PROTON-806: --- This has proven to be difficult to reproduce. I'd intended to supply a reproducer but have yet been able to do so. closing a blocking sender hangs if connection has been lost --- Key: PROTON-806 URL: https://issues.apache.org/jira/browse/PROTON-806 Project: Qpid Proton Issue Type: Bug Components: python-binding Affects Versions: 0.9 Reporter: Gordon Sim Assignee: Gordon Sim Fix For: 0.9 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Are the apache CI builds broken?
The apache CI builds say I broke the proton build
https://builds.apache.org/job/Qpid-proton-c/492/consoleText
So of course I want to fix it. However the build output shows it never
even gets to running the tests. It looks like there is a configuration
problem at the build server. Anyone know how to fix this?
Started by an SCM change
Building remotely on ubuntu-1 (docker Ubuntu ubuntu) in workspace
/home/jenkins/jenkins-slave/workspace/Qpid-proton-c
Cloning the remote Git repository
Cloning repository http://git-wip-us.apache.org/repos/asf/qpid-proton.git
git init /home/jenkins/jenkins-slave/workspace/Qpid-proton-c # timeout=10
Fetching upstream changes from
http://git-wip-us.apache.org/repos/asf/qpid-proton.git
git --version # timeout=10
git fetch --tags --progress
http://git-wip-us.apache.org/repos/asf/qpid-proton.git
+refs/heads/*:refs/remotes/origin/*
git config remote.origin.url
http://git-wip-us.apache.org/repos/asf/qpid-proton.git # timeout=10
git config remote.origin.fetch +refs/heads/*:refs/remotes/origin/* #
timeout=10
git config remote.origin.url
http://git-wip-us.apache.org/repos/asf/qpid-proton.git # timeout=10
Fetching upstream changes from
http://git-wip-us.apache.org/repos/asf/qpid-proton.git
git fetch --tags --progress
http://git-wip-us.apache.org/repos/asf/qpid-proton.git
+refs/heads/*:refs/remotes/origin/*
git rev-parse refs/remotes/origin/master^{commit} # timeout=10
git rev-parse refs/remotes/origin/origin/master^{commit} # timeout=10
Checking out Revision a515e195c4ea28b4bb513ed6e7a905b4fa34e2ad
(refs/remotes/origin/master)
git config core.sparsecheckout # timeout=10
git checkout -f a515e195c4ea28b4bb513ed6e7a905b4fa34e2ad
git rev-list c14244020a46ba0b20edf3e5c8599896751553d0 # timeout=10
[Qpid-proton-c] $ /bin/bash -e /tmp/hudson3255484645293485254.sh
No LSB modules are available.
Arch: x86_64 Uname: Linux pietas.apache.org 3.13.0-36-lowlatency #63-Ubuntu SMP
PREEMPT Wed Sep 3 21:56:12 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux lsb_release:
Distributor ID: Ubuntu Description: Ubuntu 14.04 LTS Release: 14.04 Codename:
trusty User: jenkins
Java home:
=
Listing installed packages
cmake 2.8.12.2-0ubuntu3
python 2.7.5-5ubuntu3
ruby 1:1.9.3.4
=
/usr/bin/python
Build step 'Execute shell' marked build as failure
Recording test results
Sending e-mails to: notificati...@qpid.apache.org
Finished: FAILURE
Re: Ruby memory management (was: Ruby and the Engine APIs)
On Wed, Jan 28, 2015 at 12:06:44PM -0500, Rafael Schloming wrote: Why did you reject it then? Are you referring to this? Though, I was hoping we could avoid having to manually do things... What I meant was that I would like to keep the work within the confines of the Swig code. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgp41pGyVkchT.pgp Description: PGP signature
[jira] [Commented] (PROTON-802) Unicode strings passed in through python binding cause exceptions
[
https://issues.apache.org/jira/browse/PROTON-802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14295593#comment-14295593
]
ASF subversion and git services commented on PROTON-802:
Commit 3ceaea363ee230f4b5cb8f920d45a6d58f040c3b in qpid-proton's branch
refs/heads/master from Rafael Schloming
[ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=3ceaea3 ]
PROTON-802: patch from kkliedal to do proper unicode to utf8 conversion between
the C API and python wrappers
Unicode strings passed in through python binding cause exceptions
-
Key: PROTON-802
URL: https://issues.apache.org/jira/browse/PROTON-802
Project: Qpid Proton
Issue Type: Bug
Components: python-binding
Affects Versions: 0.9
Environment: Ubuntu 14.04.1 64-bit
Reporter: Ken Leidal
Priority: Minor
Labels: encoding, string
The following traceback was thrown when passing in a python unicode string
for a host name. Ensuring the string is a python binary string (UTF-8) is a
work around.
{code:title=Traceback|borderStyle=solid}
Traceback (most recent call last):
File ./arc, line 246, in module
curses.wrapper(main)
File /usr/lib/python2.7/curses/wrapper.py, line 43, in wrapper
return func(stdscr, *args, **kwds)
File ./arc, line 244, in main
drv.run()
File /home/kkleidal/datawire/server/common.py, line 270, in run
self.process_events()
File /home/kkleidal/datawire/server/common.py, line 315, in process_events
ev.dispatch(h)
File /usr/lib/python2.7/dist-packages/proton/__init__.py, line 3365, in
dispatch
return dispatch(handler, self.type.method, self)
File /usr/lib/python2.7/dist-packages/proton/__init__.py, line 3311, in
dispatch
return m(*args)
File /home/kkleidal/datawire/server/common.py, line 723, in
on_link_remote_close
self.connect(network)
File /home/kkleidal/datawire/server/common.py, line 709, in connect
self.conn.hostname = network.host
File /usr/lib/python2.7/dist-packages/proton/wrapper.py, line 54, in
__setattr__
object.__setattr__(self, name, value)
File /usr/lib/python2.7/dist-packages/proton/__init__.py, line 2319, in
_set_hostname
return pn_connection_set_hostname(self._impl, name)
TypeError: in method 'pn_connection_set_hostname', argument 2 of type 'char
const *'
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: Ruby memory management (was: Ruby and the Engine APIs)
On Wed, Jan 28, 2015 at 12:06:44PM -0500, Rafael Schloming wrote: Why did you reject it then? Reject it? I don't recall rejecting any option. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgp_t6ZoIcDDx.pgp Description: PGP signature
Re: Ruby memory management (was: Ruby and the Engine APIs)
On Wed, Jan 28, 2015 at 1:05 PM, Darryl L. Pierce dpie...@redhat.com wrote: On Wed, Jan 28, 2015 at 12:06:44PM -0500, Rafael Schloming wrote: Why did you reject it then? Reject it? I don't recall rejecting any option. I meant why did you post about the global array thing and not this. Is there some reason you think one is preferred to the other? --Rafael
Re: Ruby memory management (was: Ruby and the Engine APIs)
Why did you reject it then? --Rafael On Wed, Jan 28, 2015 at 9:54 AM, Darryl L. Pierce dpie...@redhat.com wrote: On Wed, Jan 28, 2015 at 09:19:29AM -0500, Rafael Schloming wrote: On Wed, Jan 28, 2015 at 9:06 AM, Darryl L. Pierce dpie...@redhat.com wrote: On Wed, Jan 28, 2015 at 06:04:57AM -0500, Rafael Schloming wrote: On the face of it this sounds like it could be quite brittle and probably more complicated than just forgetting about swig for the one pn_rubyref_t struct and wrapping it manually. Did you attempt the latter option at all? Yes, there is a POC of this on my branch as well. Did it work? Can you send me a pointer to it? Yes, it works. It uses Data_Wrap_Struct to encapsulate the pn_rubyref_t type, rb_gc_mark to mark any Ruby object held by that type against reaping, and does appropriate alloc and free operations on instances of the struct. https://github.com/mcpierce/Proton/tree/c-to-ruby-reference-gc-check -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
[jira] [Commented] (PROTON-807) Proton does not decode AMQP small long encoding correctly and does not use it.
[ https://issues.apache.org/jira/browse/PROTON-807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14295412#comment-14295412 ] ASF subversion and git services commented on PROTON-807: Commit 249685a8cb675ab6fc16b14828fac2da949c9510 in qpid-proton's branch refs/heads/master from [~aconway] [ https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;h=249685a ] PROTON-807: Fix incorrect decoding of small long values. codec/decoder.c: Was treating signed small long values as unsigned. proton-j/src/main/resources/ccodec.py: Added missing byte operations, fix ulong decoeing. tests/python/proton_tests/codec.py: Test all integer types, positive, negative and min/max. Proton does not decode AMQP small long encoding correctly and does not use it. -- Key: PROTON-807 URL: https://issues.apache.org/jira/browse/PROTON-807 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Alan Conway Assignee: Alan Conway Fix For: 0.9 Proton incorrectly decodes an AMQP small long encoded value of -1 as 255. Proton itself never uses the small long encoding but qpid dispatch does, which is where this cropped up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (PROTON-807) Proton does not decode AMQP small long encoding correctly and does not use it.
[ https://issues.apache.org/jira/browse/PROTON-807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14295418#comment-14295418 ] Alan Conway commented on PROTON-807: Fixed the decoding problem. Did not modify proton to use small encodings, this needs more thought. Needs to work correctly with arrays, so encoder must know whether in array context and use array encoding if specified. Will raise separate issue. Has been verified to work with dispatch, proton needs additional tests for optional types (e.g. small long) that it does not generate. Will raise separate issue. Proton does not decode AMQP small long encoding correctly and does not use it. -- Key: PROTON-807 URL: https://issues.apache.org/jira/browse/PROTON-807 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.8 Reporter: Alan Conway Assignee: Alan Conway Fix For: 0.9 Proton incorrectly decodes an AMQP small long encoded value of -1 as 255. Proton itself never uses the small long encoding but qpid dispatch does, which is where this cropped up. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (PROTON-802) Unicode strings passed in through python binding cause exceptions
[
https://issues.apache.org/jira/browse/PROTON-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael H. Schloming resolved PROTON-802.
Resolution: Fixed
Unicode strings passed in through python binding cause exceptions
-
Key: PROTON-802
URL: https://issues.apache.org/jira/browse/PROTON-802
Project: Qpid Proton
Issue Type: Bug
Components: python-binding
Affects Versions: 0.9
Environment: Ubuntu 14.04.1 64-bit
Reporter: Ken Leidal
Priority: Minor
Labels: encoding, string
The following traceback was thrown when passing in a python unicode string
for a host name. Ensuring the string is a python binary string (UTF-8) is a
work around.
{code:title=Traceback|borderStyle=solid}
Traceback (most recent call last):
File ./arc, line 246, in module
curses.wrapper(main)
File /usr/lib/python2.7/curses/wrapper.py, line 43, in wrapper
return func(stdscr, *args, **kwds)
File ./arc, line 244, in main
drv.run()
File /home/kkleidal/datawire/server/common.py, line 270, in run
self.process_events()
File /home/kkleidal/datawire/server/common.py, line 315, in process_events
ev.dispatch(h)
File /usr/lib/python2.7/dist-packages/proton/__init__.py, line 3365, in
dispatch
return dispatch(handler, self.type.method, self)
File /usr/lib/python2.7/dist-packages/proton/__init__.py, line 3311, in
dispatch
return m(*args)
File /home/kkleidal/datawire/server/common.py, line 723, in
on_link_remote_close
self.connect(network)
File /home/kkleidal/datawire/server/common.py, line 709, in connect
self.conn.hostname = network.host
File /usr/lib/python2.7/dist-packages/proton/wrapper.py, line 54, in
__setattr__
object.__setattr__(self, name, value)
File /usr/lib/python2.7/dist-packages/proton/__init__.py, line 2319, in
_set_hostname
return pn_connection_set_hostname(self._impl, name)
TypeError: in method 'pn_connection_set_hostname', argument 2 of type 'char
const *'
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (PROTON-802) Unicode strings passed in through python binding cause exceptions
[
https://issues.apache.org/jira/browse/PROTON-802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael H. Schloming reassigned PROTON-802:
--
Assignee: Rafael H. Schloming
Unicode strings passed in through python binding cause exceptions
-
Key: PROTON-802
URL: https://issues.apache.org/jira/browse/PROTON-802
Project: Qpid Proton
Issue Type: Bug
Components: python-binding
Affects Versions: 0.9
Environment: Ubuntu 14.04.1 64-bit
Reporter: Ken Leidal
Assignee: Rafael H. Schloming
Priority: Minor
Labels: encoding, string
The following traceback was thrown when passing in a python unicode string
for a host name. Ensuring the string is a python binary string (UTF-8) is a
work around.
{code:title=Traceback|borderStyle=solid}
Traceback (most recent call last):
File ./arc, line 246, in module
curses.wrapper(main)
File /usr/lib/python2.7/curses/wrapper.py, line 43, in wrapper
return func(stdscr, *args, **kwds)
File ./arc, line 244, in main
drv.run()
File /home/kkleidal/datawire/server/common.py, line 270, in run
self.process_events()
File /home/kkleidal/datawire/server/common.py, line 315, in process_events
ev.dispatch(h)
File /usr/lib/python2.7/dist-packages/proton/__init__.py, line 3365, in
dispatch
return dispatch(handler, self.type.method, self)
File /usr/lib/python2.7/dist-packages/proton/__init__.py, line 3311, in
dispatch
return m(*args)
File /home/kkleidal/datawire/server/common.py, line 723, in
on_link_remote_close
self.connect(network)
File /home/kkleidal/datawire/server/common.py, line 709, in connect
self.conn.hostname = network.host
File /usr/lib/python2.7/dist-packages/proton/wrapper.py, line 54, in
__setattr__
object.__setattr__(self, name, value)
File /usr/lib/python2.7/dist-packages/proton/__init__.py, line 2319, in
_set_hostname
return pn_connection_set_hostname(self._impl, name)
TypeError: in method 'pn_connection_set_hostname', argument 2 of type 'char
const *'
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [java] Message codec improvements
Rafi, I just checked in some skeleton code to explore a particular approach. It avoids the intermediate objects we have in proton now (Ex FlowType.java) Instead the Flow class is directly used by the encoding/decoding layer. The Flow class uses java types as opposed to AMQP specific types, which will address one of your main concerns. The code is checked into the rajith-codec branch. The classes to look at Flow.java in the o/a/q/p/transport2 package TransportTypesEncoder and TransportTypesDecoder in o/a/q/p/codec2 package. I've also put some question marks in the code .. pls answer them. But more importantly pls provide feedback on the direction taken. I'm keen to settle down on the direction/approach first and then will start implementing the rest. Regards, Rajith On Tue, Jan 27, 2015 at 8:13 AM, Rafael Schloming r...@alum.mit.edu wrote: My inclination here would be to keep things simple. One of the more annoying aspects of working on the Java code is dealing with the fact that all the AMQP performatives use an entirely different type system. I would start out with developing a plain and simple POJO representation for all the performatives defined by the protocol. By POJO, I mean for example a Flow class where getCredit() actually returns a standard java type (probably a long) rather than an org.apache.qpid.proton.amqp.UnsignedInteger which I then need to convert into a long in order to do anything useful with. You could use some code generation here, but I wouldn't sacrifice the naturalness of the API just to allow it to be code generated, and I wouldn't think of this as an internal API just for the engine to use. We should have something here that anyone could use to easily decode/encode raw AMQP performatives in a natural way. Once you have those classes, it should be straightforward to write a DataHandler that will use the fast codec to produce them. --Rafael On Fri, Jan 23, 2015 at 12:09 PM, Rajith Muditha Attapattu rajit...@gmail.com wrote: Given the existing encorder was not put behind any sort of interface (the impl is directly used), it's proving to be a PIA to track down all the different types and changing them to use the new codec. Look at the public static void register(Decoder decoder, EncoderImpl encoder) method of any of the XXXType classes to get a sense of what I'm describing. We should take this opportunity to review the current approach and see if we could come up with a better alternative. If anybody has any suggestions, I would be happy to discuss them with you on the list. Regards, Rajith On Thu, Jan 15, 2015 at 3:15 PM, Rafael Schloming r...@alum.mit.edu wrote: I don't believe there is an existing one. --Rafael On Thu, Jan 15, 2015 at 3:10 PM, Rajith Muditha Attapattu rajit...@gmail.com wrote: Rafi, Do you have a JIRA for this work? Regards, Rajith On Wed, Jan 14, 2015 at 6:35 PM, Rajith Muditha Attapattu rajit...@gmail.com wrote: Rafi, I had a closer look at the code, put it on trunk and ran your benchmark. I see quite an improvement with respect to writing lists, maps and strings. Simply put the writeList and writeMap methods in the old encorder is about ~10 times slower than the new encorder. If I run with a sufficiently large set of strings, the old encorder is about ~2 times slower than the new encorder. I'm now focusing on hooking it up with the engine. Once that is done we can look at tweaking it further. But as it is, the new codec is a real improvement over the existing one. Great job Rafi! Rajith On Tue, Jan 6, 2015 at 10:28 AM, Rajith Muditha Attapattu rajit...@gmail.com wrote: Thanks Rafi, for the link. I agree that any work should use this as a basis. I plan to take a closer look at this in the next week or so. Rajith On Wed, Dec 17, 2014 at 1:24 PM, Rafael Schloming r...@alum.mit.edu wrote: A while back I implemented a relatively complete standalone codec here: https://github.com/rhs/qpid-proton-old/tree/codec/proton-j/src/main/java/org/apache/qpid/proton/codec2 It's quite a bit faster than the existing codec. I believe any new codec work should probably be based on this. It's relatively standalone, so should be easy to import into the tree, and then it's just a matter of modifying the rest of the engine to use it. Note that my qpid-proton-old repo is a clone of the pre-migration repo. --Rafael On Mon, Dec 15, 2014 at 2:17 PM, Rajith Muditha Attapattu rajit...@gmail.com wrote: I'm starting to look at improving this areas as I was told a few folks have noted some concerns. I would appreciate some
Re: [java] Message codec improvements
On Wed, Jan 28, 2015 at 2:01 PM, Rajith Muditha Attapattu rajit...@gmail.com wrote: Rafi, I just checked in some skeleton code to explore a particular approach. It avoids the intermediate objects we have in proton now (Ex FlowType.java) Instead the Flow class is directly used by the encoding/decoding layer. The Flow class uses java types as opposed to AMQP specific types, which will address one of your main concerns. The code is checked into the rajith-codec branch. The classes to look at Flow.java in the o/a/q/p/transport2 package TransportTypesEncoder and TransportTypesDecoder in o/a/q/p/codec2 package. I've also put some question marks in the code .. pls answer them. But more importantly pls provide feedback on the direction taken. I'm keen to settle down on the direction/approach first and then will start implementing the rest. It looks like a good start from what I saw from the commit message that flew through my inbox. One general question, are you intending to develop the rest of the performatives by hand, or is this just a skeleton to figure out what your generated output should look like, or is that TBD? If you put it up on reviewboard or make a PR or something I can make some more detailed line by line comments and answer the questions you embedded in the code. --Rafael
