jenkins interop test failing due to PROTON-215 commits?
Hi, I notice that proton-jni on Jenkins is failing [1] , probably due to the recent PROTON-215 commits. The failing test is: proton_tests.interop.InteropTest.test_messagehttps://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-jni/org.apache.qpid$tests/35/testReport/junit/proton_tests.interop/InteropTest/test_message/ Is someone already looking into this? Thanks, Phil [1] https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-jni/lastBuild/
[jira] [Updated] (PROTON-214) Test proton_tests.messenger.MessengerTest.testSendBogus failed
[ https://issues.apache.org/jira/browse/PROTON-214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated PROTON-214: --- Attachment: JNIMessenger.patch Attached a small patch for the JNIMessenger to throw a relevant exception when checking the return code from calls to native methods Test proton_tests.messenger.MessengerTest.testSendBogus failed Key: PROTON-214 URL: https://issues.apache.org/jira/browse/PROTON-214 Project: Qpid Proton Issue Type: Bug Affects Versions: 0.3, 0.4 Environment: Run mvn test from a clean checkout - this uses proton-j by default. Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor Attachments: JNIMessenger.patch The system test proton_tests.messenger.MessengerTest.testSendBogus is failing against both the proton-jni profile and, on certain computers, when run against proton-j too. The proton-jni problem seems to be caused by the fact the the JNI Messenger implementation ignores proton-c's error return codes. I think I've seen this test pass occasionally against proton-j so I suspect there's something unreliable about the test. Here is the output. proton_tests.messenger.MessengerTest.testSendBogus ..Feb 4, 2013 2:07:19 PM org.apache.qpid.proton.messenger.impl.MessengerImpl processActive SEVERE: Error processing connection java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcher.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233) at sun.nio.ch.IOUtil.read(IOUtil.java:206) at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:236) at org.apache.qpid.proton.driver.impl.ConnectorImpl.read(ConnectorImpl.java:95) at org.apache.qpid.proton.driver.impl.ConnectorImpl.process(ConnectorImpl.java:80) at org.apache.qpid.proton.messenger.impl.MessengerImpl.processActive(MessengerImpl.java:426) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:525) at org.apache.qpid.proton.messenger.impl.MessengerImpl.waitUntil(MessengerImpl.java:506) at org.apache.qpid.proton.messenger.impl.MessengerImpl.send(MessengerImpl.java:205) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:186) at org.python.core.PyReflectedFunction.__call__(PyReflectedFunction.java:204) at org.python.core.PyObject.__call__(PyObject.java:387) at org.python.core.PyObject.__call__(PyObject.java:391) at org.python.core.PyMethod.__call__(PyMethod.java:109) at proton$py.send$201(__pyclasspath__/proton.py:997) at proton$py.call_function(__pyclasspath__/proton.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at proton_tests.messenger$py.teardown$4(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton_tests/messenger.py:52) at proton_tests.messenger$py.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton_tests/messenger.py) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:134) at org.python.core.PyFunction.__call__(PyFunction.java:317) at org.python.core.PyMethod.__call__(PyMethod.java:109) at org.python.pycode._pyx1.run$36(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:344) at org.python.pycode._pyx1.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test) at org.python.core.PyTableCode.call(PyTableCode.java:165) at org.python.core.PyBaseCode.call(PyBaseCode.java:166) at org.python.core.PyFunction.__call__(PyFunction.java:338) at org.python.core.PyMethod.__call__(PyMethod.java:139) at org.python.pycode._pyx1._run$55(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test:484) at org.python.pycode._pyx1.call_function(/fast/.jenkins/jobs/Trunk-Proton-J/workspace/proton/tests/target/classes/proton-test) at
Using post-review command to post changes to https://reviews.apache.org
This is my first attempt to submit a proton patch for a review. I do not have commit rights. Below is the outline of what I did, resulting in an error. Is this a legitimate error or something else is incorrect/not-configured? This is what I did: Created .reviewboardrc: $ cat .reviewboardrc REVIEWBOARD_URL = https://reviews.apache.org; Configured git: $ git config reviewboard.url https://reviews.apache.org Got source, made changes, created a patch: $ git clone git://git.apache.org/qpid-proton.git proton ... made changes $ git diff proton.patch Attempted to post a patch: $ post-review --diff-filename=proton.patch Above resulted in this: -- == HTTP Authentication Required Enter authorization information for Web API at reviews.apache.org Username: iboverma Password: There was an error creating this review request. The repository path git://git.apache.org/qpid-proton.git is not in the list of known repositories on the server. Ask the administrator to add this repository to the Review Board server. For information on adding repositories, please read http://www.reviewboard.org/docs/manual/dev/admin/configuration/repositories/ Regards, Irina.
[jira] [Updated] (PROTON-250) Add -fvisibility option when building shared libraries
[ https://issues.apache.org/jira/browse/PROTON-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Irina Boverman updated PROTON-250: -- Attachment: (was: patch.txt) Add -fvisibility option when building shared libraries --- Key: PROTON-250 URL: https://issues.apache.org/jira/browse/PROTON-250 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.3 Environment: GNU Compiler Reporter: Irina Boverman Priority: Minor Attachments: proton.patch Add an option to hide symbols in shared libraries except when they are declared public. Extends efforts already in place for Windows builds. Excludes an effort to determine what symbols should be considered public interfaces. The gcc 4 -fvisibility option is said to: ...very substantially improve linking and load times of shared object libraries, produce more optimized code, provide near-perfect API export and prevent symbol clashes. It is strongly recommended that you use this in any shared objects you distribute. See here: http://gcc.gnu.org/wiki/Visibility Attached patch (patch.txt) will build libqpid-proton.so shared library using this flag. It reduces number of symbols from 700+ to 500+. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (PROTON-250) Add -fvisibility option when building shared libraries
[ https://issues.apache.org/jira/browse/PROTON-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Irina Boverman updated PROTON-250: -- Attachment: proton.patch Add -fvisibility option when building shared libraries --- Key: PROTON-250 URL: https://issues.apache.org/jira/browse/PROTON-250 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.3 Environment: GNU Compiler Reporter: Irina Boverman Priority: Minor Attachments: proton.patch Add an option to hide symbols in shared libraries except when they are declared public. Extends efforts already in place for Windows builds. Excludes an effort to determine what symbols should be considered public interfaces. The gcc 4 -fvisibility option is said to: ...very substantially improve linking and load times of shared object libraries, produce more optimized code, provide near-perfect API export and prevent symbol clashes. It is strongly recommended that you use this in any shared objects you distribute. See here: http://gcc.gnu.org/wiki/Visibility Attached patch (patch.txt) will build libqpid-proton.so shared library using this flag. It reduces number of symbols from 700+ to 500+. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Problem building Proton-c's java bindings on Windows - Cannot open include file: 'stdbool.h
I’m trying to build Proton-C’s Java Bindings on Windows using Microsoft Visual Studio 2010 in order to verify the changes for PROTON-249. I’m following the instructions in the README successfully but I am failing to build target proton-jni (proton target is building okay). It is failing whilst trying to compile the Swig generated C code with the following error. 5-- Build started: Project: proton-swig, Configuration: Debug Win32 -- 5Build started 27/02/2013 16:30:14. 5InitializeBuildStatus: 5 Touching proton-swig.dir\Debug\proton-swig.unsuccessfulbuild. 5CustomBuild: 5 All outputs are up-to-date. 5ClCompile: 5 javaJAVA_wrap.c 5X:\src\proton\proton-c\include\proton/engine.h(27): fatal error C1083: Cannot open include file: 'stdbool.h': No such file or directory 5 5Build FAILED. I suspect that the binding/java/CMakeLists.txt needs to pass compiler flags when on Windows (via swig) in a similar way to that done in proton-c’s CMakeLists.txt. Can anyone give me a pointer into exactly what needs to be done? Kind regards, Keith.
[jira] [Created] (PROTON-252) Reduce visibiliy of constructors for classes that should be created by factories eg MessageImpl
Philip Harvey created PROTON-252: Summary: Reduce visibiliy of constructors for classes that should be created by factories eg MessageImpl Key: PROTON-252 URL: https://issues.apache.org/jira/browse/PROTON-252 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.4 Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor These constructors are currently public but deprecated, and should be made package-private where possible to enforce the use of the factories instead. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (PROTON-250) Add -fvisibility option when building shared libraries
[ https://issues.apache.org/jira/browse/PROTON-250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Darryl L. Pierce reassigned PROTON-250: --- Assignee: Darryl L. Pierce Add -fvisibility option when building shared libraries --- Key: PROTON-250 URL: https://issues.apache.org/jira/browse/PROTON-250 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.3 Environment: GNU Compiler Reporter: Irina Boverman Assignee: Darryl L. Pierce Priority: Minor Attachments: proton.patch Add an option to hide symbols in shared libraries except when they are declared public. Extends efforts already in place for Windows builds. Excludes an effort to determine what symbols should be considered public interfaces. The gcc 4 -fvisibility option is said to: ...very substantially improve linking and load times of shared object libraries, produce more optimized code, provide near-perfect API export and prevent symbol clashes. It is strongly recommended that you use this in any shared objects you distribute. See here: http://gcc.gnu.org/wiki/Visibility Attached patch (patch.txt) will build libqpid-proton.so shared library using this flag. It reduces number of symbols from 700+ to 500+. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (PROTON-253) Remove compile-time dependency on bouncycastle cryptography library
Philip Harvey created PROTON-253: Summary: Remove compile-time dependency on bouncycastle cryptography library Key: PROTON-253 URL: https://issues.apache.org/jira/browse/PROTON-253 Project: Qpid Proton Issue Type: Improvement Components: proton-j Affects Versions: 0.4 Reporter: Philip Harvey Assignee: Philip Harvey Priority: Minor It is inconvenient that the proton-j requires bouncycastle to be on the compile-time classpath, as the Proton user may wish to use an alternative provider, or to use Java's vanilla SSL certificate support. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: messenger - dead letters possible?
On Tue, 2013-02-26 at 15:17 -0500, Michael Goulish wrote:
Would it be possible, without breaking the messenger
paradigm very much, to provide some way of knowing
which messages had not been delivered after a specified
time?
i.e.
pn_message_set_ttl ( message, seconds );
and then maybe
int n_dead_letters = pn_messenger_expired ( messenger );
for ( i = 0 ; i n_dead_letters; ++ i )
{
pn_messenger_get_dead_letter ( messenger );
/* app does something with dead letter */
}
Good question: more generally how does/should proton expose the AMQP
settlement status of messages? That will be important when we start to
think about HA and fail-over of proton clients, so we can replay the
right messages.
Re: jenkins interop test failing due to PROTON-215 commits?
On Wed, 2013-02-27 at 11:19 +, Phil Harvey wrote: Hi, I notice that proton-jni on Jenkins is failing [1] , probably due to the recent PROTON-215 commits. The failing test is: proton_tests.interop.InteropTest.test_messagehttps://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-jni/org.apache.qpid$tests/35/testReport/junit/proton_tests.interop/InteropTest/test_message/ Is someone already looking into this? Thanks, Phil [1] https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-jni/lastBuild/ That would be my commit, apologies. Will investigate ASAP. BTW what mailing list to the Jenkins notices go to?
Re: jenkins interop test failing due to PROTON-215 commits?
notificati...@qpid.apache.org -- Rob On 27 February 2013 21:51, Alan Conway acon...@redhat.com wrote: On Wed, 2013-02-27 at 11:19 +, Phil Harvey wrote: Hi, I notice that proton-jni on Jenkins is failing [1] , probably due to the recent PROTON-215 commits. The failing test is: proton_tests.interop.InteropTest.test_messagehttps://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-jni/org.apache.qpid$tests/35/testReport/junit/proton_tests.interop/InteropTest/test_message/ Is someone already looking into this? Thanks, Phil [1] https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-jni/lastBuild/ That would be my commit, apologies. Will investigate ASAP. BTW what mailing list to the Jenkins notices go to?
Need help Re: jenkins interop test failing due to PROTON-215 commits?
On Wed, 2013-02-27 at 11:19 +, Phil Harvey wrote: Hi, I notice that proton-jni on Jenkins is failing [1] , probably due to the recent PROTON-215 commits. The failing test is: proton_tests.interop.InteropTest.test_messagehttps://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-jni/org.apache.qpid$tests/35/testReport/junit/proton_tests.interop/InteropTest/test_message/ Is someone already looking into this? Regarding: https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-jni/org.apache.qpid$tests/37/ I need some help with the JNI code to figure this out. I can't reproduce the problem on my fedora box. Can we get information about the jenkins build system, e.g. version of Java and Python involved? Here's a summary of what I think happens, this is running the interop.py tests in Jython: m = proton.Message() d = Proton.Data() m.decode(an amqp message read from a file.) d.decode(body) BANG We blow up with: TypeError: wrap(): 1st arg can't be coerced to byte[] This is in python class proton.Data def decode(self, encoded): return self._data.decode(ByteBuffer.wrap(encoded)) So it appears that a python Message.body is somehow set to something that cannot be coerced to byte[]. So I look at JNIMessage.getBody() and I see it returns a Section. A Section is an empty interface. Huh?? Can someone explain the relationship between a JNI python message body and this Section interface, and how it is supposed to be converted? Cheers, Alan.
Re: Need help Re: jenkins interop test failing due to PROTON-215 commits?
On 27 February 2013 23:28, Alan Conway acon...@redhat.com wrote: On Wed, 2013-02-27 at 11:19 +, Phil Harvey wrote: Hi, I notice that proton-jni on Jenkins is failing [1] , probably due to the recent PROTON-215 commits. The failing test is: proton_tests.interop.InteropTest.test_messagehttps://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-jni/org.apache.qpid$tests/35/testReport/junit/proton_tests.interop/InteropTest/test_message/ Is someone already looking into this? Regarding: https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-jni/org.apache.qpid$tests/37/ I need some help with the JNI code to figure this out. I can't reproduce the problem on my fedora box. Can we get information about the jenkins build system, e.g. version of Java and Python involved? Here's a summary of what I think happens, this is running the interop.py tests in Jython: m = proton.Message() d = Proton.Data() m.decode(an amqp message read from a file.) d.decode(body) BANG We blow up with: TypeError: wrap(): 1st arg can't be coerced to byte[] This is in python class proton.Data def decode(self, encoded): return self._data.decode(ByteBuffer.wrap(encoded)) So it appears that a python Message.body is somehow set to something that cannot be coerced to byte[]. So I look at JNIMessage.getBody() and I see it returns a Section. A Section is an empty interface. Huh?? Can someone explain the relationship between a JNI python message body and this Section interface, and how it is supposed to be converted? Cheers, Alan. So, the Java API more closely matches the AMQP spec than the C API here... An AMQP Message consists of a number of sections. The body may be a Data section, an AmqpValue section or an AmqpSequence section. So in the Java API getBody() returns a Section object that may be one of these three types. -- Rob
Re: Need help Re: jenkins interop test failing due to PROTON-215 commits?
On 27 February 2013 22:28, Alan Conway acon...@redhat.com wrote:
On Wed, 2013-02-27 at 11:19 +, Phil Harvey wrote:
Hi,
I notice that proton-jni on Jenkins is failing [1] , probably due to the
recent PROTON-215 commits.
The failing test is:
proton_tests.interop.InteropTest.test_messagehttps://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-jni/org.apache.qpid$tests/35/testReport/junit/proton_tests.interop/InteropTest/test_message/
Is someone already looking into this?
Regarding:
https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-jni/org.apache.qpid$tests/37/
I need some help with the JNI code to figure this out.
I can't reproduce the problem on my fedora box.
I'm reproducing using command:
mvn test -Pproton-jni
-Dproton.pythontest.pattern=proton_tests.interop.InteropTest.test_message
Can we get information
about the jenkins build system, e.g. version of Java and Python
involved?
You can see all the output of the build (cmake, make etc) by following
the Console Output link in the Jenkins job view. This includes the
versions numbers you have asked for.
https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-jni/37/console
-- Found SWIG: /usr/bin/swig2.0 (found version 2.0.4)
-- Found PythonLibs: /usr/lib/libpython2.7.so
-- Found Ruby: /usr/bin/ruby (found version 1.8.7)
-- Found Perl: /usr/bin/perl
-- Could NOT find PerlLibs (missing: PERL_LIBRARY) (found version 5.14.2)
-- Found JNI: /usr/lib/jvm/java-6-openjdk-amd64/jre/lib/amd64/libjawt.so
-- Found PythonInterp: /usr/bin/python (found version 2.7.3)
(I'm also seeing the test fail on Redhat Tikanga with Oracle JDK
1.6.0_39, and on Mac OS X with JDK 1.6.0_37 both with Python 2.7)
Here's a summary of what I think happens, this is running the
interop.py tests in Jython:
m = proton.Message()
d = Proton.Data()
m.decode(an amqp message read from a file.)
d.decode(body)
BANG
We blow up with: TypeError: wrap(): 1st arg can't be coerced to byte[]
This is in python class proton.Data
def decode(self, encoded):
return self._data.decode(ByteBuffer.wrap(encoded))
So it appears that a python Message.body is somehow set to something
that cannot be coerced to byte[]. So I look at JNIMessage.getBody() and
I see it returns a Section. A Section is an empty interface. Huh??
JNIMessage.decodeBody() method that determines the concrete type of
the object returned by getBody(). Adding a couple of
System.out.println(); to this method I see:
proton_tests.interop.InteropTest.test_message ...
in decodeBody()
dataType : BINARY notAmqpValue : false
body is AmqpValue{\xa1\x05hello}
fail
so _body is of type org.apache.qpid.proton.amqp.messaging.AmqpValue
Hope this helps
Can someone explain the relationship between a JNI python message body
and this Section interface, and how it is supposed to be converted?
Cheers,
Alan.
Re: Problem building Proton-c's java bindings on Windows - Cannot open include file: 'stdbool.h
Visual Studio is not friendly to modern day C (a perennial complaint that falls on deaf ears). You must use its C++ compiler on the proton-c code base. In the case of swig via Visual Studio, you have to coax it to use C++ too. See the lines if (BUILD_WITH_CXX) SET_SOURCE_FILES_PROPERTIES(python.i PROPERTIES CPLUSPLUS ON) endif (BUILD_WITH_CXX) in proton-c/bindings/python/CMakeLists.txt. Hopefully a similarly constructed directive will get swig compile working. Cliff On Wed, Feb 27, 2013 at 8:42 AM, Keith W keith.w...@gmail.com wrote: I’m trying to build Proton-C’s Java Bindings on Windows using Microsoft Visual Studio 2010 in order to verify the changes for PROTON-249. I’m following the instructions in the README successfully but I am failing to build target proton-jni (proton target is building okay). It is failing whilst trying to compile the Swig generated C code with the following error. 5-- Build started: Project: proton-swig, Configuration: Debug Win32 -- 5Build started 27/02/2013 16:30:14. 5InitializeBuildStatus: 5 Touching proton-swig.dir\Debug\proton-swig.unsuccessfulbuild. 5CustomBuild: 5 All outputs are up-to-date. 5ClCompile: 5 javaJAVA_wrap.c 5X:\src\proton\proton-c\include\proton/engine.h(27): fatal error C1083: Cannot open include file: 'stdbool.h': No such file or directory 5 5Build FAILED. I suspect that the binding/java/CMakeLists.txt needs to pass compiler flags when on Windows (via swig) in a similar way to that done in proton-c’s CMakeLists.txt. Can anyone give me a pointer into exactly what needs to be done? Kind regards, Keith.
