[jira] [Commented] (PROTON-2231) Assertion fail on macOS with libuv in c-threaderciser test
[
https://issues.apache.org/jira/browse/PROTON-2231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17252077#comment-17252077
]
ASF subversion and git services commented on PROTON-2231:
-
Commit e4c179855fef161e656ba5ab422c1c24a2df9ded in qpid-proton's branch
refs/heads/master from Roddie Kieley
[ https://gitbox.apache.org/repos/asf?p=qpid-proton.git;h=e4c1798 ]
NO-JIRA: github actions CI for macOS disabled threaderciser test due to
PROTON-2231.
> Assertion fail on macOS with libuv in c-threaderciser test
> --
>
> Key: PROTON-2231
> URL: https://issues.apache.org/jira/browse/PROTON-2231
> Project: Qpid Proton
> Issue Type: Bug
> Components: proton-c
>Affects Versions: proton-c-0.32.0
>Reporter: Jiri Daněk
>Assignee: Roddie Kieley
>Priority: Major
> Labels: freebsd, macOS
>
> As described on PROTON-2225, the test fails with assertion error. It is
> currently disabled on macOS for this reason (in .travis.yml).
> {noformat}
> 6: Test command: /usr/local/opt/python/libexec/bin/python
> "/Users/travis/build/jiridanek/qpid-proton/scripts/env.py" "--"
> "/Users/travis/build/jiridanek/qpid-proton/build/c/tests/c-threaderciser"
> 6: Test timeout computed to be: 1500
> 6: threaderciser start: threads=8, time=1, actions=[listen, close-listen,
> connect, close-connect, wake, timeout, cancel-timeout]
> 6: Assertion failed: (p->active > 0), function remove_active_lh, file
> /Users/travis/build/jiridanek/qpid-proton/c/src/proactor/libuv.c, line 392.
> 6/31 Test #6: c-threaderciser ..***Failed0.18 sec
> {noformat}
> If the test is meant to stay disabled for a longer time, it will have to be
> disabled in CMakeLists.txt, so that users compiling the project do not run it
> accidentally.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8489) Connection thread looping
[
https://issues.apache.org/jira/browse/QPID-8489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17252073#comment-17252073
]
ASF subversion and git services commented on QPID-8489:
---
Commit 514e87c304b07e33697568d5c0d0ac8c0c794039 in qpid-broker-j's branch
refs/heads/7.1.x from aw924
[ https://gitbox.apache.org/repos/asf?p=qpid-broker-j.git;h=514e87c ]
QPID-8489 - Connection thread looping
This closes #73
(cherry picked from commit 5c27ca077282d0080f874dd9bf8fd24403e764cb)
> Connection thread looping
> -
>
> Key: QPID-8489
> URL: https://issues.apache.org/jira/browse/QPID-8489
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-8.0.2
>Reporter: Daniil Kirilyuk
>Priority: Minor
> Attachments:
> 0001-QPID-8489-Break-an-infinite-connection-processing-lo.patch, QPID-8489 -
> java.ssl.debug.log, QPID-8489.log, simple_recv.cpp, thread-dump.st
>
>
> Error happens quite rarely and is not easy to reproduce. Although the problem
> was partly fixed by fixing QPID-8477, it still can be reproduced. The main
> symptom is significant increase of CPU usage even when no messages are sent
> to broker anymore. CPU usage can rise from 30% to 90% and higher, making
> broker unusable. After such CPU rise the only way to fix broker will be
> restarting it.
> Analysis has shown, that error occurs with CPP proton client in cases when
> 1) SSL connection is used
> 2) connection errors on client side are ignored
> 3) connection is dropped due to the client process termination / network
> disconnection
> *Steps to reproduce*
> # Java broker should be installed
> # Broker should be configured to allow one connection
> # Prepare certificates
> # Install Qpid::Proton 0.28.0
> wget
> [http://archive.apache.org/dist/qpid/proton/0.28.0/qpid-proton-0.28.0.tar.gz]
> gunzip qpid-proton-0.28.0.tar.gz
> mkdir -p qpid-proton-0.28.0/build && pushd qpid-proton-0.28.0/build && cmake
> .. && make all && popd
> # Replace and edit example *qpid-proton-0.28.0/cpp/examples/simple_recv.cpp*
> with the one attached
> # Build again
> cd qpid-proton-0.28.0/build
> make
> # Break the broker
> ./cpp/examples/simple_recv & ./cpp/examples/simple_recv
> Connection error
> {color:#ffab00}^C <= Hit Ctrl+C to kill process{color}
> # {color:#172b4d}If CPU usage didn't increased, find the PID of the first
> simple_recv process using ps-ef | grep simple_recv and kill it using kill -9
> PID.{color}
> *Analysis*
> CPU usage rises when connection is dropped on the client side or when network
> is broken between client and broker. The main point is that client isn't well
> behaved and connection shouldn't be closed correctly.
> On broker side connection becomes "orphaned": it is still maintained by
> broker, but no real reading / writing is performed. Following method calls
> are performed in an endless loop for each "orphaned" connection:
> SelectorThread.performSelect()
> SelectorThread.ConnectionProcessor.processConnection()
> NetworkConnectionScheduler.processConnection()
> NonBlockingConnection.doWork()
> As there nothing physically read or written, both methods
> NonBlockingConnection.doRead() and NonBlockingConnection.doWrite() execute
> very fast (several milliseconds) without any blocking processes and after
> that connection is immediately rescheduled for processing in
> NetworkConnectionScheduler. After that loop repeats.
> As the connection lifecycle is normal, there is logged nothing unusual or
> suspicious (nothing is seen in log at all).
> In thread dump (see attachment) there is seen, that utilized are mostly
> thread with names virtualhost-default-iopool-XX. Typical stacktrace looks
> like following:
> {noformat}
> "virtualhost-default-iopool-39" #92 prio=5 os_prio=0 tid=0x7f47ec335800
> nid=0x37196 waiting on condition
> [0x7f476a4e3000]"virtualhost-default-iopool-39" #92 prio=5 os_prio=0
> tid=0x7f47ec335800 nid=0x37196 waiting on condition [0x7f476a4e3000]
> java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native
> Method) - parking to wait for <0xf39105d0> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:532)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.qpid.server.bytebuff
[jira] [Commented] (QPID-8489) Connection thread looping
[
https://issues.apache.org/jira/browse/QPID-8489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17252067#comment-17252067
]
ASF subversion and git services commented on QPID-8489:
---
Commit e0f51a73800dd43fe392caa50bf340b9c2a580aa in qpid-broker-j's branch
refs/heads/8.0.x from aw924
[ https://gitbox.apache.org/repos/asf?p=qpid-broker-j.git;h=e0f51a7 ]
QPID-8489 - Connection thread looping
This closes #73
(cherry picked from commit 5c27ca077282d0080f874dd9bf8fd24403e764cb)
> Connection thread looping
> -
>
> Key: QPID-8489
> URL: https://issues.apache.org/jira/browse/QPID-8489
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-8.0.2
>Reporter: Daniil Kirilyuk
>Priority: Minor
> Attachments:
> 0001-QPID-8489-Break-an-infinite-connection-processing-lo.patch, QPID-8489 -
> java.ssl.debug.log, QPID-8489.log, simple_recv.cpp, thread-dump.st
>
>
> Error happens quite rarely and is not easy to reproduce. Although the problem
> was partly fixed by fixing QPID-8477, it still can be reproduced. The main
> symptom is significant increase of CPU usage even when no messages are sent
> to broker anymore. CPU usage can rise from 30% to 90% and higher, making
> broker unusable. After such CPU rise the only way to fix broker will be
> restarting it.
> Analysis has shown, that error occurs with CPP proton client in cases when
> 1) SSL connection is used
> 2) connection errors on client side are ignored
> 3) connection is dropped due to the client process termination / network
> disconnection
> *Steps to reproduce*
> # Java broker should be installed
> # Broker should be configured to allow one connection
> # Prepare certificates
> # Install Qpid::Proton 0.28.0
> wget
> [http://archive.apache.org/dist/qpid/proton/0.28.0/qpid-proton-0.28.0.tar.gz]
> gunzip qpid-proton-0.28.0.tar.gz
> mkdir -p qpid-proton-0.28.0/build && pushd qpid-proton-0.28.0/build && cmake
> .. && make all && popd
> # Replace and edit example *qpid-proton-0.28.0/cpp/examples/simple_recv.cpp*
> with the one attached
> # Build again
> cd qpid-proton-0.28.0/build
> make
> # Break the broker
> ./cpp/examples/simple_recv & ./cpp/examples/simple_recv
> Connection error
> {color:#ffab00}^C <= Hit Ctrl+C to kill process{color}
> # {color:#172b4d}If CPU usage didn't increased, find the PID of the first
> simple_recv process using ps-ef | grep simple_recv and kill it using kill -9
> PID.{color}
> *Analysis*
> CPU usage rises when connection is dropped on the client side or when network
> is broken between client and broker. The main point is that client isn't well
> behaved and connection shouldn't be closed correctly.
> On broker side connection becomes "orphaned": it is still maintained by
> broker, but no real reading / writing is performed. Following method calls
> are performed in an endless loop for each "orphaned" connection:
> SelectorThread.performSelect()
> SelectorThread.ConnectionProcessor.processConnection()
> NetworkConnectionScheduler.processConnection()
> NonBlockingConnection.doWork()
> As there nothing physically read or written, both methods
> NonBlockingConnection.doRead() and NonBlockingConnection.doWrite() execute
> very fast (several milliseconds) without any blocking processes and after
> that connection is immediately rescheduled for processing in
> NetworkConnectionScheduler. After that loop repeats.
> As the connection lifecycle is normal, there is logged nothing unusual or
> suspicious (nothing is seen in log at all).
> In thread dump (see attachment) there is seen, that utilized are mostly
> thread with names virtualhost-default-iopool-XX. Typical stacktrace looks
> like following:
> {noformat}
> "virtualhost-default-iopool-39" #92 prio=5 os_prio=0 tid=0x7f47ec335800
> nid=0x37196 waiting on condition
> [0x7f476a4e3000]"virtualhost-default-iopool-39" #92 prio=5 os_prio=0
> tid=0x7f47ec335800 nid=0x37196 waiting on condition [0x7f476a4e3000]
> java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native
> Method) - parking to wait for <0xf39105d0> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:532)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.qpid.server.bytebuff
[jira] [Commented] (QPID-8489) Connection thread looping
[
https://issues.apache.org/jira/browse/QPID-8489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17252055#comment-17252055
]
ASF subversion and git services commented on QPID-8489:
---
Commit 5c27ca077282d0080f874dd9bf8fd24403e764cb in qpid-broker-j's branch
refs/heads/master from aw924
[ https://gitbox.apache.org/repos/asf?p=qpid-broker-j.git;h=5c27ca0 ]
QPID-8489 - Connection thread looping
This closes #73
> Connection thread looping
> -
>
> Key: QPID-8489
> URL: https://issues.apache.org/jira/browse/QPID-8489
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-8.0.2
>Reporter: Daniil Kirilyuk
>Priority: Minor
> Attachments:
> 0001-QPID-8489-Break-an-infinite-connection-processing-lo.patch, QPID-8489 -
> java.ssl.debug.log, QPID-8489.log, simple_recv.cpp, thread-dump.st
>
>
> Error happens quite rarely and is not easy to reproduce. Although the problem
> was partly fixed by fixing QPID-8477, it still can be reproduced. The main
> symptom is significant increase of CPU usage even when no messages are sent
> to broker anymore. CPU usage can rise from 30% to 90% and higher, making
> broker unusable. After such CPU rise the only way to fix broker will be
> restarting it.
> Analysis has shown, that error occurs with CPP proton client in cases when
> 1) SSL connection is used
> 2) connection errors on client side are ignored
> 3) connection is dropped due to the client process termination / network
> disconnection
> *Steps to reproduce*
> # Java broker should be installed
> # Broker should be configured to allow one connection
> # Prepare certificates
> # Install Qpid::Proton 0.28.0
> wget
> [http://archive.apache.org/dist/qpid/proton/0.28.0/qpid-proton-0.28.0.tar.gz]
> gunzip qpid-proton-0.28.0.tar.gz
> mkdir -p qpid-proton-0.28.0/build && pushd qpid-proton-0.28.0/build && cmake
> .. && make all && popd
> # Replace and edit example *qpid-proton-0.28.0/cpp/examples/simple_recv.cpp*
> with the one attached
> # Build again
> cd qpid-proton-0.28.0/build
> make
> # Break the broker
> ./cpp/examples/simple_recv & ./cpp/examples/simple_recv
> Connection error
> {color:#ffab00}^C <= Hit Ctrl+C to kill process{color}
> # {color:#172b4d}If CPU usage didn't increased, find the PID of the first
> simple_recv process using ps-ef | grep simple_recv and kill it using kill -9
> PID.{color}
> *Analysis*
> CPU usage rises when connection is dropped on the client side or when network
> is broken between client and broker. The main point is that client isn't well
> behaved and connection shouldn't be closed correctly.
> On broker side connection becomes "orphaned": it is still maintained by
> broker, but no real reading / writing is performed. Following method calls
> are performed in an endless loop for each "orphaned" connection:
> SelectorThread.performSelect()
> SelectorThread.ConnectionProcessor.processConnection()
> NetworkConnectionScheduler.processConnection()
> NonBlockingConnection.doWork()
> As there nothing physically read or written, both methods
> NonBlockingConnection.doRead() and NonBlockingConnection.doWrite() execute
> very fast (several milliseconds) without any blocking processes and after
> that connection is immediately rescheduled for processing in
> NetworkConnectionScheduler. After that loop repeats.
> As the connection lifecycle is normal, there is logged nothing unusual or
> suspicious (nothing is seen in log at all).
> In thread dump (see attachment) there is seen, that utilized are mostly
> thread with names virtualhost-default-iopool-XX. Typical stacktrace looks
> like following:
> {noformat}
> "virtualhost-default-iopool-39" #92 prio=5 os_prio=0 tid=0x7f47ec335800
> nid=0x37196 waiting on condition
> [0x7f476a4e3000]"virtualhost-default-iopool-39" #92 prio=5 os_prio=0
> tid=0x7f47ec335800 nid=0x37196 waiting on condition [0x7f476a4e3000]
> java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native
> Method) - parking to wait for <0xf39105d0> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:532)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at
> org.apache.qpid.server.bytebuffer.QpidByteBufferFactory.lambda$null$0(QpidByteBufferFactory.java:464
[jira] [Commented] (QPID-8489) Connection thread looping
[
https://issues.apache.org/jira/browse/QPID-8489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17252056#comment-17252056
]
ASF GitHub Bot commented on QPID-8489:
--
asfgit closed pull request #73:
URL: https://github.com/apache/qpid-broker-j/pull/73
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Connection thread looping
> -
>
> Key: QPID-8489
> URL: https://issues.apache.org/jira/browse/QPID-8489
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-8.0.2
>Reporter: Daniil Kirilyuk
>Priority: Minor
> Attachments:
> 0001-QPID-8489-Break-an-infinite-connection-processing-lo.patch, QPID-8489 -
> java.ssl.debug.log, QPID-8489.log, simple_recv.cpp, thread-dump.st
>
>
> Error happens quite rarely and is not easy to reproduce. Although the problem
> was partly fixed by fixing QPID-8477, it still can be reproduced. The main
> symptom is significant increase of CPU usage even when no messages are sent
> to broker anymore. CPU usage can rise from 30% to 90% and higher, making
> broker unusable. After such CPU rise the only way to fix broker will be
> restarting it.
> Analysis has shown, that error occurs with CPP proton client in cases when
> 1) SSL connection is used
> 2) connection errors on client side are ignored
> 3) connection is dropped due to the client process termination / network
> disconnection
> *Steps to reproduce*
> # Java broker should be installed
> # Broker should be configured to allow one connection
> # Prepare certificates
> # Install Qpid::Proton 0.28.0
> wget
> [http://archive.apache.org/dist/qpid/proton/0.28.0/qpid-proton-0.28.0.tar.gz]
> gunzip qpid-proton-0.28.0.tar.gz
> mkdir -p qpid-proton-0.28.0/build && pushd qpid-proton-0.28.0/build && cmake
> .. && make all && popd
> # Replace and edit example *qpid-proton-0.28.0/cpp/examples/simple_recv.cpp*
> with the one attached
> # Build again
> cd qpid-proton-0.28.0/build
> make
> # Break the broker
> ./cpp/examples/simple_recv & ./cpp/examples/simple_recv
> Connection error
> {color:#ffab00}^C <= Hit Ctrl+C to kill process{color}
> # {color:#172b4d}If CPU usage didn't increased, find the PID of the first
> simple_recv process using ps-ef | grep simple_recv and kill it using kill -9
> PID.{color}
> *Analysis*
> CPU usage rises when connection is dropped on the client side or when network
> is broken between client and broker. The main point is that client isn't well
> behaved and connection shouldn't be closed correctly.
> On broker side connection becomes "orphaned": it is still maintained by
> broker, but no real reading / writing is performed. Following method calls
> are performed in an endless loop for each "orphaned" connection:
> SelectorThread.performSelect()
> SelectorThread.ConnectionProcessor.processConnection()
> NetworkConnectionScheduler.processConnection()
> NonBlockingConnection.doWork()
> As there nothing physically read or written, both methods
> NonBlockingConnection.doRead() and NonBlockingConnection.doWrite() execute
> very fast (several milliseconds) without any blocking processes and after
> that connection is immediately rescheduled for processing in
> NetworkConnectionScheduler. After that loop repeats.
> As the connection lifecycle is normal, there is logged nothing unusual or
> suspicious (nothing is seen in log at all).
> In thread dump (see attachment) there is seen, that utilized are mostly
> thread with names virtualhost-default-iopool-XX. Typical stacktrace looks
> like following:
> {noformat}
> "virtualhost-default-iopool-39" #92 prio=5 os_prio=0 tid=0x7f47ec335800
> nid=0x37196 waiting on condition
> [0x7f476a4e3000]"virtualhost-default-iopool-39" #92 prio=5 os_prio=0
> tid=0x7f47ec335800 nid=0x37196 waiting on condition [0x7f476a4e3000]
> java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native
> Method) - parking to wait for <0xf39105d0> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject) at
> java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at
> org.apache.qpid.server.transport.SelectorThread.run(SelectorThread.java:532)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Wor
[GitHub] [qpid-broker-j] asfgit closed pull request #73: QPID-8489 - Connection thread looping
asfgit closed pull request #73: URL: https://github.com/apache/qpid-broker-j/pull/73 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2205) [c] Use a descriptive, legal error condition for abruptly closed connections
[ https://issues.apache.org/jira/browse/PROTON-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Daněk updated PROTON-2205: --- Affects Version/s: proton-c-0.33.0 > [c] Use a descriptive, legal error condition for abruptly closed connections > > > Key: PROTON-2205 > URL: https://issues.apache.org/jira/browse/PROTON-2205 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: proton-c-0.33.0 >Reporter: Justin Ross >Priority: Major > > Currently we use framing-error, but the spec doesn't permit that, and it > doesn't explain what happened very well. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (PROTON-2254) Relative paths in CMake share
[
https://issues.apache.org/jira/browse/PROTON-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Daněk updated PROTON-2254:
---
Description:
This sequency installs well:
{noformat}
cmake
make
make DESTDIR=/some/where install
{noformat}
However, further use of the installation fails, because of strict dependencies
on the *installed* paths in files like `ProtonConfig.cmake`:
{noformat}
set_target_properties(Proton::core
PROPERTIES
IMPORTED_LOCATION "/usr/local/lib/libqpid-proton-core.so"
IMPORTED_LOCATION_DEBUG "/usr/local/lib/libqpid-proton-core.so"
INTERFACE_INCLUDE_DIRECTORIES "${Proton_Core_INCLUDE_DIRS}")
{noformat}
**What would work:** First switch to the `DESTDIR`, then continue building
something like Qpid Dispatch Router.
**Solution:** Use relative directories, like in:
{noformat}
# Compute the installation prefix relative to this file.
get_filename_component(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)
get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
if(_IMPORT_PREFIX STREQUAL "/")
set(_IMPORT_PREFIX "")
endif()
{noformat}
**Work-around:** An unhappy quickfix is
{noformat}
find /some/where -name *.cmake -exec \
sed -i "s+/usr/+/some/where/usr/+g" {} \;
{noformat}
was:
This sequency installs well:
{{cmake}}
{{ make}}
{{ make DESTDIR=/some/where install}}
However, further use of the installation fails, because of strict dependencies
on the *installed* paths in files like `ProtonConfig.cmake`:
{{ set_target_properties(Proton::core}}
{{ PROPERTIES}}
{{ IMPORTED_LOCATION "/usr/local/lib/libqpid-proton-core.so"}}
{{ IMPORTED_LOCATION_DEBUG "/usr/local/lib/libqpid-proton-core.so"}}
{{ INTERFACE_INCLUDE_DIRECTORIES "${Proton_Core_INCLUDE_DIRS}")}}
**What would work:** First switch to the `DESTDIR`, then continue building
something like Qpid Dispatch Router.
**Solution:** Use relative directories, like in:
{{# Compute the installation prefix relative to this file.}}
{{ get_filename_component(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)}}
{{ get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)}}
{{ get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)}}
{{ get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)}}
{{ if(_IMPORT_PREFIX STREQUAL "/")}}
{{ set(_IMPORT_PREFIX "")}}
{{ endif()}}
**Work-around:** An unhappy quickfix is
{{ find /some/where -name *.cmake -exec \}}
{{ sed -i "s+/usr/+/some/where/usr/+g" {} \;}}
> Relative paths in CMake share
> -
>
> Key: PROTON-2254
> URL: https://issues.apache.org/jira/browse/PROTON-2254
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c
>Affects Versions: proton-c-0.31.0
> Environment: Debian Linux; build Proton then Dispatch into each their
> own `DESTDIR`. This is done by our "layered build" system,
> https://gitlab.com/arpa2/mkhere/-/blob/master/qpid_proton.sh and
> https://gitlab.com/arpa2/mkhere/-/blob/master/qpid_dispatch.sh
>Reporter: Rick van Rein
>Priority: Minor
> Labels: cmake, install, proton
> Original Estimate: 0.25h
> Remaining Estimate: 0.25h
>
> This sequency installs well:
> {noformat}
> cmake
> make
> make DESTDIR=/some/where install
> {noformat}
> However, further use of the installation fails, because of strict
> dependencies on the *installed* paths in files like `ProtonConfig.cmake`:
> {noformat}
> set_target_properties(Proton::core
> PROPERTIES
> IMPORTED_LOCATION "/usr/local/lib/libqpid-proton-core.so"
> IMPORTED_LOCATION_DEBUG "/usr/local/lib/libqpid-proton-core.so"
> INTERFACE_INCLUDE_DIRECTORIES "${Proton_Core_INCLUDE_DIRS}")
> {noformat}
> **What would work:** First switch to the `DESTDIR`, then continue building
> something like Qpid Dispatch Router.
> **Solution:** Use relative directories, like in:
> {noformat}
> # Compute the installation prefix relative to this file.
> get_filename_component(_IMPORT_PREFIX "${CMAKE_CURRENT_LIST_FILE}" PATH)
> get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
> get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
> get_filename_component(_IMPORT_PREFIX "${_IMPORT_PREFIX}" PATH)
> if(_IMPORT_PREFIX STREQUAL "/")
> set(_IMPORT_PREFIX "")
> endif()
> {noformat}
> **Work-around:** An unhappy quickfix is
> {noformat}
> find /some/where -name *.cmake -exec \
> sed -i "s+/usr/+/some/where/usr/+g" {} \;
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (PROTON-2310) Add support for logging raw connection payload transfers
Charles E. Rolke created PROTON-2310: Summary: Add support for logging raw connection payload transfers Key: PROTON-2310 URL: https://issues.apache.org/jira/browse/PROTON-2310 Project: Qpid Proton Issue Type: Improvement Reporter: Charles E. Rolke -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-8390) FindProton.cmake uses incorrect search paths for non-installed Proton
[ https://issues.apache.org/jira/browse/QPID-8390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Daněk resolved QPID-8390. -- Resolution: Fixed > FindProton.cmake uses incorrect search paths for non-installed Proton > - > > Key: QPID-8390 > URL: https://issues.apache.org/jira/browse/QPID-8390 > Project: Qpid > Issue Type: Bug > Environment: Ubuntu, gcc9 >Reporter: Chris Richardson >Assignee: Jiri Daněk >Priority: Major > Fix For: qpid-cpp-1.40.0 > > > This CMake script looks for proton library components under a "proton-c" > subdirectory instead of just "c" as it now is. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8390) FindProton.cmake uses incorrect search paths for non-installed Proton
[ https://issues.apache.org/jira/browse/QPID-8390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jiri Daněk reassigned QPID-8390: Assignee: Jiri Daněk > FindProton.cmake uses incorrect search paths for non-installed Proton > - > > Key: QPID-8390 > URL: https://issues.apache.org/jira/browse/QPID-8390 > Project: Qpid > Issue Type: Bug > Environment: Ubuntu, gcc9 >Reporter: Chris Richardson >Assignee: Jiri Daněk >Priority: Major > Fix For: qpid-cpp-1.40.0 > > > This CMake script looks for proton library components under a "proton-c" > subdirectory instead of just "c" as it now is. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8390) FindProton.cmake uses incorrect search paths for non-installed Proton
[ https://issues.apache.org/jira/browse/QPID-8390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251952#comment-17251952 ] ASF GitHub Bot commented on QPID-8390: -- jiridanek merged pull request #22: URL: https://github.com/apache/qpid-cpp/pull/22 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > FindProton.cmake uses incorrect search paths for non-installed Proton > - > > Key: QPID-8390 > URL: https://issues.apache.org/jira/browse/QPID-8390 > Project: Qpid > Issue Type: Bug > Environment: Ubuntu, gcc9 >Reporter: Chris Richardson >Priority: Major > Fix For: qpid-cpp-1.40.0 > > > This CMake script looks for proton library components under a "proton-c" > subdirectory instead of just "c" as it now is. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8390) FindProton.cmake uses incorrect search paths for non-installed Proton
[ https://issues.apache.org/jira/browse/QPID-8390?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251951#comment-17251951 ] ASF subversion and git services commented on QPID-8390: --- Commit 8e054e04e76ab24183ce7551f5e34a4ccfe8186e in qpid-cpp's branch refs/heads/master from Chris Richardson [ https://gitbox.apache.org/repos/asf?p=qpid-cpp.git;h=8e054e0 ] QPID-8390> Corrected FindProton.cmake relative path search (#22) > FindProton.cmake uses incorrect search paths for non-installed Proton > - > > Key: QPID-8390 > URL: https://issues.apache.org/jira/browse/QPID-8390 > Project: Qpid > Issue Type: Bug > Environment: Ubuntu, gcc9 >Reporter: Chris Richardson >Priority: Major > Fix For: qpid-cpp-1.40.0 > > > This CMake script looks for proton library components under a "proton-c" > subdirectory instead of just "c" as it now is. -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[GitHub] [qpid-cpp] jiridanek merged pull request #22: QPID-8390 Corrected FindProton.cmake relative path search
jiridanek merged pull request #22: URL: https://github.com/apache/qpid-cpp/pull/22 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8413) Python3 support in build scripts
[
https://issues.apache.org/jira/browse/QPID-8413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251909#comment-17251909
]
ASF GitHub Bot commented on QPID-8413:
--
jiridanek opened a new pull request #24:
URL: https://github.com/apache/qpid-cpp/pull/24
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Python3 support in build scripts
>
>
> Key: QPID-8413
> URL: https://issues.apache.org/jira/browse/QPID-8413
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Affects Versions: qpid-cpp-1.40.0
> Environment: Docker build environment for Qpid,
> [https://github.com/arpa2/docker-demo/tree/11429b52b9419c7f49367abe648b3bc67613bdba/build-qpid]
> Imports gcc/g++ and Python3 from Debian stable in binary layers. Builds
> proton but not qpid-cpp-broker.
> You are welcome to "docker build ." in this directory and see it fail. It
> uses qpid-cpp-broker as a git checkout from master so you can even work in
> there :)
>Reporter: Rick van Rein
>Priority: Major
> Labels: Python3, build-failure, cmake
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Python 2.7 is soon loosing support and as a result we gradually abandoned it
> in the 2nd half of 2019. We have certainly not been early adopters!
> Now, building Qpid from source, I find that it still relies on this old
> version. It does not even notice though, which is not very handy in a time
> that people are migrating:
>
> {\{-- Found PythonInterp: /usr/bin/python (found suitable version "3.7.3",
> minimum required is "2.7") }}
> \{{-- Found PythonInterp: /usr/bin/python (found version "3.7.3") }}
> \{{ File "", line 1}}
> {{ from distutils.sysconfig import get_python_lib; print
> get_python_lib(False, prefix='/usr/local').replace('
> ', '/')}}
> \{{ ^}}
> {{SyntaxError: invalid syntax}}
> {{CMake Error at managementgen/CMakeLists.txt:34 (install):}}
> \{{ install DIRECTORY given no DESTINATION!}}
>
> Python3 bails out with an error, about the lack of parenthesis, but CMake
> concludes its own things. Looking silly. It does continue to one more
> similar error:
>
> {{-- Regenerating Qpid Management Framework sources}}
> \{{ File "/usr/local/src/qpid-cpp-broker.git/managementgen/qmf-gen", line
> 64}}
> \{{ print "no input files"}}
> \{{ ^}}
> {{SyntaxError: Missing parentheses in call to 'print'. Did you mean
> print("no input files")?}}
> {{CMake Error at src/CMakeLists.txt:141 (include):}}
> \{{ include could not find load
> file:}}{{/usr/local/src/qpid-cpp-broker.git/build/src/managementgen.cmake}}
> {{CMake Error at /usr/share/cmake-3.13/Modules/FindBoost.cmake:2100
> (message):}}
> \{{ Unable to find the requested Boost libraries.}}{{Unable to find the
> Boost header files. Please set BOOST_ROOT to the root}}
> \{{ directory containing Boost or BOOST_INCLUDEDIR to the directory
> containing}}
> \{{ Boost's headers.}}
> {{Call Stack (most recent call first):}}
> \{{ src/CMakeLists.txt:194 (find_package)}}
> {{CMake Error at /usr/share/cmake-3.13/Modules/FindBoost.cmake:2100
> (message):}}
> \{{ Unable to find the requested Boost libraries.}}{{Unable to find the
> Boost header files. Please set BOOST_ROOT to the root}}
> \{{ directory containing Boost or BOOST_INCLUDEDIR to the directory
> containing}}
> \{{ Boost's headers.}}
> {{Call Stack (most recent call first):}}
> \{{ src/CMakeLists.txt:208 (find_package)}}
> {{CMake Error at src/CMakeLists.txt:210 (message):}}
> \{{ Required Boost C++ libraries not found. Please install or try setting}}
> \{{ BOOST_ROOT}}
> {{-- Configuring incomplete, errors occurred!}}
>
> Again, the parenthesis of print. And again, CMake concludes its own things,
> presumably from the exit value.
>
> I don't believe I am being a Python3 pusher at this time, not anymore; last
> year it has been anounced that Python2.7 would be gone at the start of 2020.
> (I checked again and found it is now set at [April
> 2020|http://pyfound.blogspot.com/2019/12/python-2-sunset.html[],] but still
> very soon.)
> Please update Qpid accordingly, so people relying on Python3 for
> security/updates have a way to continue using/building Qpid? By now,
> everyone should at least be able to run Python3, or else that is a fair
> upgrade expectation, as it will soon be the only real Python left.
>
> Thanks!
> -Rick
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-
[GitHub] [qpid-cpp] jiridanek opened a new pull request #24: QPID-8413: Python 3 support in managementgen
jiridanek opened a new pull request #24: URL: https://github.com/apache/qpid-cpp/pull/24 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8413) Python3 support in build scripts
[
https://issues.apache.org/jira/browse/QPID-8413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251904#comment-17251904
]
Jiri Daněk commented on QPID-8413:
--
I'm able to make the outputs from Python 2 and 3 identical, with the exception
of the md5 sums. The problem is that browsing attributes in a XML document
happens in a different order in Python 2 and Python 3, therefore they get
hashed in different order, and the hashes come out different. I am assuming
this is not a problem.
> Python3 support in build scripts
>
>
> Key: QPID-8413
> URL: https://issues.apache.org/jira/browse/QPID-8413
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Affects Versions: qpid-cpp-1.40.0
> Environment: Docker build environment for Qpid,
> [https://github.com/arpa2/docker-demo/tree/11429b52b9419c7f49367abe648b3bc67613bdba/build-qpid]
> Imports gcc/g++ and Python3 from Debian stable in binary layers. Builds
> proton but not qpid-cpp-broker.
> You are welcome to "docker build ." in this directory and see it fail. It
> uses qpid-cpp-broker as a git checkout from master so you can even work in
> there :)
>Reporter: Rick van Rein
>Priority: Major
> Labels: Python3, build-failure, cmake
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Python 2.7 is soon loosing support and as a result we gradually abandoned it
> in the 2nd half of 2019. We have certainly not been early adopters!
> Now, building Qpid from source, I find that it still relies on this old
> version. It does not even notice though, which is not very handy in a time
> that people are migrating:
>
> {\{-- Found PythonInterp: /usr/bin/python (found suitable version "3.7.3",
> minimum required is "2.7") }}
> \{{-- Found PythonInterp: /usr/bin/python (found version "3.7.3") }}
> \{{ File "", line 1}}
> {{ from distutils.sysconfig import get_python_lib; print
> get_python_lib(False, prefix='/usr/local').replace('
> ', '/')}}
> \{{ ^}}
> {{SyntaxError: invalid syntax}}
> {{CMake Error at managementgen/CMakeLists.txt:34 (install):}}
> \{{ install DIRECTORY given no DESTINATION!}}
>
> Python3 bails out with an error, about the lack of parenthesis, but CMake
> concludes its own things. Looking silly. It does continue to one more
> similar error:
>
> {{-- Regenerating Qpid Management Framework sources}}
> \{{ File "/usr/local/src/qpid-cpp-broker.git/managementgen/qmf-gen", line
> 64}}
> \{{ print "no input files"}}
> \{{ ^}}
> {{SyntaxError: Missing parentheses in call to 'print'. Did you mean
> print("no input files")?}}
> {{CMake Error at src/CMakeLists.txt:141 (include):}}
> \{{ include could not find load
> file:}}{{/usr/local/src/qpid-cpp-broker.git/build/src/managementgen.cmake}}
> {{CMake Error at /usr/share/cmake-3.13/Modules/FindBoost.cmake:2100
> (message):}}
> \{{ Unable to find the requested Boost libraries.}}{{Unable to find the
> Boost header files. Please set BOOST_ROOT to the root}}
> \{{ directory containing Boost or BOOST_INCLUDEDIR to the directory
> containing}}
> \{{ Boost's headers.}}
> {{Call Stack (most recent call first):}}
> \{{ src/CMakeLists.txt:194 (find_package)}}
> {{CMake Error at /usr/share/cmake-3.13/Modules/FindBoost.cmake:2100
> (message):}}
> \{{ Unable to find the requested Boost libraries.}}{{Unable to find the
> Boost header files. Please set BOOST_ROOT to the root}}
> \{{ directory containing Boost or BOOST_INCLUDEDIR to the directory
> containing}}
> \{{ Boost's headers.}}
> {{Call Stack (most recent call first):}}
> \{{ src/CMakeLists.txt:208 (find_package)}}
> {{CMake Error at src/CMakeLists.txt:210 (message):}}
> \{{ Required Boost C++ libraries not found. Please install or try setting}}
> \{{ BOOST_ROOT}}
> {{-- Configuring incomplete, errors occurred!}}
>
> Again, the parenthesis of print. And again, CMake concludes its own things,
> presumably from the exit value.
>
> I don't believe I am being a Python3 pusher at this time, not anymore; last
> year it has been anounced that Python2.7 would be gone at the start of 2020.
> (I checked again and found it is now set at [April
> 2020|http://pyfound.blogspot.com/2019/12/python-2-sunset.html[],] but still
> very soon.)
> Please update Qpid accordingly, so people relying on Python3 for
> security/updates have a way to continue using/building Qpid? By now,
> everyone should at least be able to run Python3, or else that is a fair
> upgrade expectation, as it will soon be the only real Python left.
>
> Thanks!
> -Rick
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-1898) support event channel option in http1 adaptor
Gordon Sim created DISPATCH-1898: Summary: support event channel option in http1 adaptor Key: DISPATCH-1898 URL: https://issues.apache.org/jira/browse/DISPATCH-1898 Project: Qpid Dispatch Issue Type: New Feature Components: Protocol Adaptors Reporter: Gordon Sim -- This message was sent by Atlassian Jira (v8.3.4#803005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8413) Python3 support in build scripts
[
https://issues.apache.org/jira/browse/QPID-8413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17251843#comment-17251843
]
Jiri Daněk commented on QPID-8413:
--
Python 3 support in {{managementgen}} can be tested the following way,
{noformat}
% python3 'managementgen/qmf-gen' '-c' 'out3/managementgen.cmake' '-b' '-l'
'-q' '-o' 'out3/src/qmf' 'src/qpid/broker/management-schema.xml'
'src/qpid/acl/management-schema.xml' 'src/qpid/ha/management-schema.xml'
'src/qpid/legacystore/management-schema.xml'
'src/qpid/linearstore/management-schema.xml'
% python2 'managementgen/qmf-gen' '-c' 'out2/managementgen.cmake' '-b' '-l'
'-q' '-o' 'out2/src/qmf' 'src/qpid/broker/management-schema.xml'
'src/qpid/acl/management-schema.xml' 'src/qpid/ha/management-schema.xml'
'src/qpid/legacystore/management-schema.xml'
'src/qpid/linearstore/management-schema.xml'
% meld out2 out3
{noformat}
The issues I saw so far: print(), import io, // operator, exception E as e
syntax
> Python3 support in build scripts
>
>
> Key: QPID-8413
> URL: https://issues.apache.org/jira/browse/QPID-8413
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker
>Affects Versions: qpid-cpp-1.40.0
> Environment: Docker build environment for Qpid,
> [https://github.com/arpa2/docker-demo/tree/11429b52b9419c7f49367abe648b3bc67613bdba/build-qpid]
> Imports gcc/g++ and Python3 from Debian stable in binary layers. Builds
> proton but not qpid-cpp-broker.
> You are welcome to "docker build ." in this directory and see it fail. It
> uses qpid-cpp-broker as a git checkout from master so you can even work in
> there :)
>Reporter: Rick van Rein
>Priority: Major
> Labels: Python3, build-failure, cmake
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> Python 2.7 is soon loosing support and as a result we gradually abandoned it
> in the 2nd half of 2019. We have certainly not been early adopters!
> Now, building Qpid from source, I find that it still relies on this old
> version. It does not even notice though, which is not very handy in a time
> that people are migrating:
>
> {\{-- Found PythonInterp: /usr/bin/python (found suitable version "3.7.3",
> minimum required is "2.7") }}
> \{{-- Found PythonInterp: /usr/bin/python (found version "3.7.3") }}
> \{{ File "", line 1}}
> {{ from distutils.sysconfig import get_python_lib; print
> get_python_lib(False, prefix='/usr/local').replace('
> ', '/')}}
> \{{ ^}}
> {{SyntaxError: invalid syntax}}
> {{CMake Error at managementgen/CMakeLists.txt:34 (install):}}
> \{{ install DIRECTORY given no DESTINATION!}}
>
> Python3 bails out with an error, about the lack of parenthesis, but CMake
> concludes its own things. Looking silly. It does continue to one more
> similar error:
>
> {{-- Regenerating Qpid Management Framework sources}}
> \{{ File "/usr/local/src/qpid-cpp-broker.git/managementgen/qmf-gen", line
> 64}}
> \{{ print "no input files"}}
> \{{ ^}}
> {{SyntaxError: Missing parentheses in call to 'print'. Did you mean
> print("no input files")?}}
> {{CMake Error at src/CMakeLists.txt:141 (include):}}
> \{{ include could not find load
> file:}}{{/usr/local/src/qpid-cpp-broker.git/build/src/managementgen.cmake}}
> {{CMake Error at /usr/share/cmake-3.13/Modules/FindBoost.cmake:2100
> (message):}}
> \{{ Unable to find the requested Boost libraries.}}{{Unable to find the
> Boost header files. Please set BOOST_ROOT to the root}}
> \{{ directory containing Boost or BOOST_INCLUDEDIR to the directory
> containing}}
> \{{ Boost's headers.}}
> {{Call Stack (most recent call first):}}
> \{{ src/CMakeLists.txt:194 (find_package)}}
> {{CMake Error at /usr/share/cmake-3.13/Modules/FindBoost.cmake:2100
> (message):}}
> \{{ Unable to find the requested Boost libraries.}}{{Unable to find the
> Boost header files. Please set BOOST_ROOT to the root}}
> \{{ directory containing Boost or BOOST_INCLUDEDIR to the directory
> containing}}
> \{{ Boost's headers.}}
> {{Call Stack (most recent call first):}}
> \{{ src/CMakeLists.txt:208 (find_package)}}
> {{CMake Error at src/CMakeLists.txt:210 (message):}}
> \{{ Required Boost C++ libraries not found. Please install or try setting}}
> \{{ BOOST_ROOT}}
> {{-- Configuring incomplete, errors occurred!}}
>
> Again, the parenthesis of print. And again, CMake concludes its own things,
> presumably from the exit value.
>
> I don't believe I am being a Python3 pusher at this time, not anymore; last
> year it has been anounced that Python2.7 would be gone at the start of 2020.
> (I checked again and found it is now set at [April
> 2020|http://pyfound.blogspot.com/2019/12/python-2-sunset.html[],] but still
> very soon.)
> Please update Qpid accordingly, so people relying on Python3 for
> security/up
[jira] [Created] (DISPATCH-1897) Console http libwebsocket realloc error Out Of Memory
Charles E. Rolke created DISPATCH-1897:
--
Summary: Console http libwebsocket realloc error Out Of Memory
Key: DISPATCH-1897
URL: https://issues.apache.org/jira/browse/DISPATCH-1897
Project: Qpid Dispatch
Issue Type: Bug
Components: Router Node
Affects Versions: 1.14.0
Environment: Build dockerfiles/Dockerfile-fedora on a Fedora 32 64-bit
host and run system_tests_tcp_adaptor there.
Building the docker image on a Fedora 31 64-bit host works properly.
Reporter: Charles E. Rolke
An ordinary http listener fails with a wild 64-but realloc:
{code:java}
2020-12-17 19:27:11.483999 + HTTP (trace) Event loop: poll
(/main/qpid-dispatch/src/http-libwebsockets.c:61)
2020-12-17 19:27:11.484005 + HTTP (trace) _realloc: size 6944: context
(/main/qpid-dispatch/src/http-libwebsockets.c:61)
2020-12-17 19:27:11.484015 + HTTP (trace) _realloc: size 72:
lws_smd_register (/main/qpid-dispatch/src/http-libwebsockets.c:61)
2020-12-17 19:27:11.484021 + HTTP (trace) lws_smd_register: registered
(/main/qpid-dispatch/src/http-libwebsockets.c:61)
2020-12-17 19:27:11.484032 + HTTP (trace) _realloc: size
18446744073709551552: fds table
(/main/qpid-dispatch/src/http-libwebsockets.c:61)
2020-12-17 19:27:11.484038 + HTTP (error) OOM allocating 1073741816 fds
(/main/qpid-dispatch/src/http-libwebsockets.c:61)
{code}
This issue was originally reported in DISPATCH-1895 at
[https://travis-ci.com/github/apache/qpid-dispatch/jobs/461797267]
There the problem was stated as a test hang in system_tests_tcp_adaptor. Test
orchestration failed when it was creating the first router
* _wait=true_
* Router subprocess is started
* Test frameworks waits for all ports to accept a TCP connection
Due to the error the http listener port went dead. The test timed out waiting
for the http port to come up.
The diagnostic logs quoted here were not available from the travis-ci system
but were found after some other system setup produced the same error.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[ANNOUNCE] Apache Qpid JMS 0.56.0 released
The Apache Qpid (http://qpid.apache.org) community is pleased to announce the immediate availability of Apache Qpid JMS 0.56.0. This is the latest release of our newer JMS client supporting the Advanced Message Queuing Protocol 1.0 (AMQP 1.0, ISO/IEC 19464, http://www.amqp.org), based around the Apache Qpid Proton protocol engine and implementing the AMQP JMS Mapping as it evolves at OASIS. The release is available now from our website: http://qpid.apache.org/download.html Binaries are also available via Maven Central: http://qpid.apache.org/maven.html Release notes can be found at: http://qpid.apache.org/releases/qpid-jms-0.56.0/release-notes.html Thanks to all involved, Robbie - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
