[jira] [Updated] (PROTON-512) Possibility to set idle timeout for messenger
[ https://issues.apache.org/jira/browse/PROTON-512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Soltys updated PROTON-512: Attachment: messenger.h.patch messenger.c.patch Propagate idle timeout settings to the messenger interface. Possibility to set idle timeout for messenger - Key: PROTON-512 URL: https://issues.apache.org/jira/browse/PROTON-512 Project: Qpid Proton Issue Type: Bug Components: proton-c Affects Versions: 0.6 Reporter: Tomas Soltys Labels: features, patch Fix For: 0.7 Attachments: messenger.c.patch, messenger.h.patch I would like to specify an idle timeout for a messenger which would be then used for all created connections. I see that there is an interface for pn_transport_t which is allowing it but it is not accessible from outside. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-515) Port to OpenVMS
[ https://issues.apache.org/jira/browse/PROTON-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Soltys updated PROTON-515: Attachment: (was: platform_fmt.h.patch) Port to OpenVMS --- Key: PROTON-515 URL: https://issues.apache.org/jira/browse/PROTON-515 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.6 Environment: OpenVMS Reporter: Tomas Soltys Labels: OpenVMS, patch Fix For: 0.7 There is a need for proton-c port to OpenVMS platform. To make proton-c functional on OpenVMS few changes in the source code are required. Here is list of files I have identified which require some attention: proton-c/src/platform_fmt.h proton-c/src/posix/driver.c proton-c/src/object/object.c proton-c/src/codec/codec.c -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-515) Port to OpenVMS
[ https://issues.apache.org/jira/browse/PROTON-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Soltys updated PROTON-515: Attachment: (was: object.c.patch) Port to OpenVMS --- Key: PROTON-515 URL: https://issues.apache.org/jira/browse/PROTON-515 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.6 Environment: OpenVMS Reporter: Tomas Soltys Labels: OpenVMS, patch Fix For: 0.7 There is a need for proton-c port to OpenVMS platform. To make proton-c functional on OpenVMS few changes in the source code are required. Here is list of files I have identified which require some attention: proton-c/src/platform_fmt.h proton-c/src/posix/driver.c proton-c/src/object/object.c proton-c/src/codec/codec.c -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-515) Port to OpenVMS
[ https://issues.apache.org/jira/browse/PROTON-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Soltys updated PROTON-515: Attachment: (was: driver.c.patch) Port to OpenVMS --- Key: PROTON-515 URL: https://issues.apache.org/jira/browse/PROTON-515 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.6 Environment: OpenVMS Reporter: Tomas Soltys Labels: OpenVMS, patch Fix For: 0.7 There is a need for proton-c port to OpenVMS platform. To make proton-c functional on OpenVMS few changes in the source code are required. Here is list of files I have identified which require some attention: proton-c/src/platform_fmt.h proton-c/src/posix/driver.c proton-c/src/object/object.c proton-c/src/codec/codec.c -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (PROTON-515) Port to OpenVMS
[ https://issues.apache.org/jira/browse/PROTON-515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tomas Soltys updated PROTON-515: Attachment: (was: codec.c.patch) Port to OpenVMS --- Key: PROTON-515 URL: https://issues.apache.org/jira/browse/PROTON-515 Project: Qpid Proton Issue Type: Improvement Components: proton-c Affects Versions: 0.6 Environment: OpenVMS Reporter: Tomas Soltys Labels: OpenVMS, patch Fix For: 0.7 There is a need for proton-c port to OpenVMS platform. To make proton-c functional on OpenVMS few changes in the source code are required. Here is list of files I have identified which require some attention: proton-c/src/platform_fmt.h proton-c/src/posix/driver.c proton-c/src/object/object.c proton-c/src/codec/codec.c -- This message was sent by Atlassian JIRA (v6.2#6252)
Minimizing the Proton Engine/Messenger RAM Footprint for embedded devices
Hello Proton Experts, I am new to this mailing list and use of the Proton system, so please do not get offended if I say something naïve. My team is attempting to use the Proton-C Engine/Messenger package on a small footprint embedded device. We are attempting to send sensor information and receive data to/from the MS Azure Service Bus infrastructure. We are attempting to use the QPid Proton 0.6 release. The system is using C code on an ARM-xxx processor. Our configuration has very limited RAM and have been attempting to reduce the run-time requirement to fit in 50Kb or so. Our data needs are not very big and normally would fit in 1024 bytes of payload. We have trimmed the Proton input/output buffers down from 16KB to smaller values. Have attempted to disable logging and anything else we could to get the footprint smaller. At the moment we have the RAM consumption near 43Kbytes. However, once we start attempting to make socket connections, we see additional RAM allocations that push over the 50KB limit. My first question is- has this been done on other systems where the RAM is very limited? If yes, is that example available for us to review? Is it feasible to limit some of the functions/options in the library to at least get basic functionality of AMQP 1.0 to Azure/Service Bus running? Our expectation is that we need to have at least one transmit link and one receive link to pre-defined topics on the Service Bus side. Ultimately we need to have AMQPS (via TLS). But in the short term we are just attempting to get basic communication running. Thanks for any sage advice you may have. It will certainly be appreciated! Dave Johnson -- View this message in context: http://qpid.2158936.n2.nabble.com/Minimizing-the-Proton-Engine-Messenger-RAM-Footprint-for-embedded-devices-tp7607409.html Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
Messenger: pn_delivery leaking pn_disposition memory?
In one of our automated client stress tests, we've noticed that we seem to be leaking memory. We were previously seeing this on qpid-proton 0.6 and I've retested on 0.7 RC3 and it is still occurring ==16195== 45,326,848 bytes in 25,294 blocks are possibly lost in loss record 1,865 of 1,867 ==16195==at 0x4C274A0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==16195==by 0x86CC7AC: pn_data (codec.c:363) ==16195==by 0x86D7372: pn_disposition_init (engine.c:1066) ==16195==by 0x86D756B: pn_delivery (engine.c:1102) ==16195==by 0x86DB93E: pn_do_transfer (transport.c:738) ==16195==by 0x86D3A21: pn_dispatch_frame (dispatcher.c:146) ==16195==by 0x86D3B28: pn_dispatcher_input (dispatcher.c:169) ==16195==by 0x86DCB4C: pn_input_read_amqp (transport.c:1117) ==16195==by 0x86DF4FD: pn_io_layer_input_passthru (transport.c:1964) ==16195==by 0x86DF4FD: pn_io_layer_input_passthru (transport.c:1964) ==16195==by 0x86DC74E: transport_consume (transport.c:1037) ==16195==by 0x86DF89B: pn_transport_process (transport.c:2052) ==16195== ==16195== 45,326,848 bytes in 25,294 blocks are possibly lost in loss record 1,866 of 1,867 ==16195==at 0x4C274A0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==16195==by 0x86CC7AC: pn_data (codec.c:363) ==16195==by 0x86D4E58: pn_condition_init (engine.c:203) ==16195==by 0x86D738A: pn_disposition_init (engine.c:1067) ==16195==by 0x86D756B: pn_delivery (engine.c:1102) ==16195==by 0x86DB93E: pn_do_transfer (transport.c:738) ==16195==by 0x86D3A21: pn_dispatch_frame (dispatcher.c:146) ==16195==by 0x86D3B28: pn_dispatcher_input (dispatcher.c:169) ==16195==by 0x86DCB4C: pn_input_read_amqp (transport.c:1117) ==16195==by 0x86DF4FD: pn_io_layer_input_passthru (transport.c:1964) ==16195==by 0x86DF4FD: pn_io_layer_input_passthru (transport.c:1964) ==16195==by 0x86DC74E: transport_consume (transport.c:1037) ==16195== ==16195== 45,328,640 bytes in 25,295 blocks are possibly lost in loss record 1,867 of 1,867 ==16195==at 0x4C274A0: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==16195==by 0x86CC7AC: pn_data (codec.c:363) ==16195==by 0x86D7360: pn_disposition_init (engine.c:1065) ==16195==by 0x86D756B: pn_delivery (engine.c:1102) ==16195==by 0x86DB93E: pn_do_transfer (transport.c:738) ==16195==by 0x86D3A21: pn_dispatch_frame (dispatcher.c:146) ==16195==by 0x86D3B28: pn_dispatcher_input (dispatcher.c:169) ==16195==by 0x86DCB4C: pn_input_read_amqp (transport.c:1117) ==16195==by 0x86DF4FD: pn_io_layer_input_passthru (transport.c:1964) ==16195==by 0x86DF4FD: pn_io_layer_input_passthru (transport.c:1964) ==16195==by 0x86DC74E: transport_consume (transport.c:1037) ==16195==by 0x86DF89B: pn_transport_process (transport.c:2052) Looking at the code I can see this should get freed in pn_disposition_finalize once pn_decref(delivery) is called, but I haven't yet had a chance to determine why this isn't occurring. Has anyone else seen this before and is there anything obvious we could be doing wrong? -- View this message in context: http://qpid.2158936.n2.nabble.com/Messenger-pn-delivery-leaking-pn-disposition-memory-tp7607416.html Sent from the Apache Qpid Proton mailing list archive at Nabble.com.
Re: Minimizing the Proton Engine/Messenger RAM Footprint for embedded devices
Hello and welcome to the list. See inline for further comments... On Fri, Apr 25, 2014 at 11:55 AM, dcjohns41 david.johns...@honeywell.comwrote: Hello Proton Experts, I am new to this mailing list and use of the Proton system, so please do not get offended if I say something naïve. No worries. Please don't be shy. ;-) My team is attempting to use the Proton-C Engine/Messenger package on a small footprint embedded device. We are attempting to send sensor information and receive data to/from the MS Azure Service Bus infrastructure. We are attempting to use the QPid Proton 0.6 release. The system is using C code on an ARM-xxx processor. Our configuration has very limited RAM and have been attempting to reduce the run-time requirement to fit in 50Kb or so. Our data needs are not very big and normally would fit in 1024 bytes of payload. We have trimmed the Proton input/output buffers down from 16KB to smaller values. Have attempted to disable logging and anything else we could to get the footprint smaller. At the moment we have the RAM consumption near 43Kbytes. However, once we start attempting to make socket connections, we see additional RAM allocations that push over the 50KB limit. My first question is- has this been done on other systems where the RAM is very limited? If yes, is that example available for us to review? I know it's been used on some embedded platforms, but I'm afraid I don't have any details. I'm guessing either the footprint requirements were not as small as yours or whatever tuning was required didn't make it back to the codebase. Is it feasible to limit some of the functions/options in the library to at least get basic functionality of AMQP 1.0 to Azure/Service Bus running? Our expectation is that we need to have at least one transmit link and one receive link to pre-defined topics on the Service Bus side. There's probably a bunch of different things we could try, but to be honest we haven't really taken a serious look at memory utilization. I'd start by instrumenting malloc/free so we can identify where the memory usage is coming from. I'd actually like to get that kind of instrumentation into the Proton codebase so if you are inclined to do this I'd love to see the patch. If not I hope to get around to it soon, but its always difficult to predict how much time I will have. Ultimately we need to have AMQPS (via TLS). But in the short term we are just attempting to get basic communication running. The builtin TLS support relies on openssl, so there may be limits to what we can do in terms of memory utilization there. Of course you always have the option of not using the builtin TLS layer and supplying your own, but again I'd say first thing would probably be to instrument and see how close we are to your goal. --Rafae
