[jira] [Commented] (PROTON-348) Tests and examples need some platform helper functions
[ https://issues.apache.org/jira/browse/PROTON-348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747856#comment-13747856 ] Cliff Jansen commented on PROTON-348: - see https://reviews.apache.org/r/12275 and comment about license. Perhaps time to bite the bullet and write our own limited getargs. Keeping open for now... > Tests and examples need some platform helper functions > -- > > Key: PROTON-348 > URL: https://issues.apache.org/jira/browse/PROTON-348 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.5 > Environment: All >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: 0.5 > > > New functionality in examples and tests require platform neutral basic > functionality such as getopt (again) and time. The existing code doesn't > build on Windows. Presumably additional such functionality will be needed in > the future. -- 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] [Resolved] (PROTON-212) Windows snprintf and vsnprintf differ on overflow from C99
[ https://issues.apache.org/jira/browse/PROTON-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-212. - Resolution: Fixed Fix Version/s: (was: 0.4) 0.5 fixed: r1512109 > Windows snprintf and vsnprintf differ on overflow from C99 > -- > > Key: PROTON-212 > URL: https://issues.apache.org/jira/browse/PROTON-212 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.4 > Environment: Windows >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: 0.5 > > > The Windows implementation of these functions differ from the C99 versions on > overflow, which is actually a critical feature of these functions. > _snprintf has the decency to be named differently to at least provide a clue. > vsnprintf is named identically for bonus points. -- 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] [Resolved] (PROTON-213) Reconcile C99 and C++ inconsistencies within proton
[ https://issues.apache.org/jira/browse/PROTON-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-213. - Resolution: Fixed fixed: r1441965 > Reconcile C99 and C++ inconsistencies within proton > --- > > Key: PROTON-213 > URL: https://issues.apache.org/jira/browse/PROTON-213 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Affects Versions: 0.4 > Environment: Visual Studio on Windows >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: 0.4 > > > These are essenially the differences required to get a version of proton that > already works with g++ to work in Visual Studio. > This mainly consists of header inconsistencies: stdint.h, stdbool.h, > inttypes.h > Also a few functions: atoll(), snprintf() > No PRIxx printf fromat specifiers > Similarly, no "%z" for size_t operands -- 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] [Resolved] (PROTON-159) port proton to C++
[ https://issues.apache.org/jira/browse/PROTON-159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-159. - Resolution: Fixed Fixed: r1441947 r1441872 r1441857 r1441856 r1441855 > port proton to C++ > -- > > Key: PROTON-159 > URL: https://issues.apache.org/jira/browse/PROTON-159 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Affects Versions: 0.3 >Reporter: Cliff Jansen >Assignee: Cliff Jansen > Fix For: 0.4 > > Attachments: proton-159-0.diff, proton-159-0-partial.diff > > > Make code compile in both C99 and C++, using the gnu toolchain. This is a > necessary first step > towards a Microsoft Visual Studio port (where the compiler supports C++ but > not C99). -- 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] [Resolved] (PROTON-124) Porting Issue -- Visual Studio requires WSAStartup() and WSACleanup() to initialize\cleanup the Windows socket dll
[ https://issues.apache.org/jira/browse/PROTON-124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-124. - Resolution: Fixed Fixed in QPID-4181 > Porting Issue -- Visual Studio requires WSAStartup() and WSACleanup() to > initialize\cleanup the Windows socket dll > -- > > Key: PROTON-124 > URL: https://issues.apache.org/jira/browse/PROTON-124 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton >Assignee: Cliff Jansen > Fix For: 0.4 > > Attachments: WinSockets.patch > > > Put the WSAStartup code in pn_driver() and the WSACleanup() code in > pn_driver_free(). > Used a _WINDOWS macro around the Windows code. -- 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] [Resolved] (PROTON-148) Porting Issue -- Visual Studio requires an explicit cast inside the resize macros
[
https://issues.apache.org/jira/browse/PROTON-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cliff Jansen resolved PROTON-148.
-
Resolution: Fixed
fixed in PROTON-159
> Porting Issue -- Visual Studio requires an explicit cast inside the resize
> macros
> -
>
> Key: PROTON-148
> URL: https://issues.apache.org/jira/browse/PROTON-148
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c
> Environment: WIndows using Visual Studio 2010
>Reporter: Mary hinton
>Assignee: Cliff Jansen
> Labels: build
> Fix For: 0.4
>
> Attachments: PN_ENSURE.patch
>
>
> The PN_ENSURE and PN_ENSUREZ macros do not compile using Visual Studio
> toolset.
> Suggest changing the macros to the following for both ports:
> #define PN_ENSURE(ARRAY, CAPACITY, COUNT, PNTYPE) \
> while ((CAPACITY) < (COUNT)) { \
> (CAPACITY) = (CAPACITY) ? 2 * (CAPACITY) : 16; \
> (ARRAY) = (PNTYPE) realloc((ARRAY), (CAPACITY) * sizeof (*(ARRAY))); \
> }
> #define PN_ENSUREZ(ARRAY, CAPACITY, COUNT, PNTYPE)\
> {\
> size_t _old_capacity = (CAPACITY); \
> PN_ENSURE((ARRAY), (CAPACITY), (COUNT), PNTYPE); \
> memset((ARRAY) + _old_capacity, 0, \
>sizeof(*(ARRAY))*((CAPACITY) - _old_capacity)); \
> }
--
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] [Resolved] (PROTON-123) Porting Issue -- Visual Studio compilers do not support %zu and %zi (C99) in printf statements
[ https://issues.apache.org/jira/browse/PROTON-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-123. - Resolution: Fixed fixed in PROTON-213 > Porting Issue -- Visual Studio compilers do not support %zu and %zi (C99) in > printf statements > -- > > Key: PROTON-123 > URL: https://issues.apache.org/jira/browse/PROTON-123 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton >Assignee: Cliff Jansen > Fix For: 0.4 > > > Replaced the %zu and %zi with %lu and %li. > %li for ssize_t and %lu for size_t -- 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] [Resolved] (PROTON-99) Porting Issue -- pn_dtag macro does not compile with Visual Studio compiler
[
https://issues.apache.org/jira/browse/PROTON-99?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cliff Jansen resolved PROTON-99.
Resolution: Fixed
fixed in PROTON-159
> Porting Issue -- pn_dtag macro does not compile with Visual Studio compiler
> ---
>
> Key: PROTON-99
> URL: https://issues.apache.org/jira/browse/PROTON-99
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c
> Environment: Windows using Visual Studio 2010
>Reporter: Mary hinton
>Assignee: Cliff Jansen
> Labels: build
> Fix For: 0.4
>
> Attachments: pn_dtag.patch
>
>
> I would like to replace the pn_dtag macro with a function that will compile
> using either GNU or Visual Studio compilers.
> engine.h
> Replace:
> #define pn_dtag(BYTES, SIZE) ((pn_delivery_tag_t) {(SIZE), (BYTES)}
> With:
> pn_delivery_tag_t pn_dtag(const char *bytes, size_t size);
> engine.c
> Add:
> pn_delivery_tag_t pn_dtag(const char *bytes, size_t size)
> {
> pn_delivery_tag_t delivt;
> delivt.bytes = bytes;
> delivt.size = size;
> return delivt;
> }
--
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] [Resolved] (PROTON-122) Porting Issue -- Visual Studio compilers have different header files
[ https://issues.apache.org/jira/browse/PROTON-122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-122. - Resolution: Fixed fixed in PROTON-159 > Porting Issue -- Visual Studio compilers have different header files > - > > Key: PROTON-122 > URL: https://issues.apache.org/jira/browse/PROTON-122 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 10 >Reporter: Mary hinton >Assignee: Cliff Jansen > Fix For: 0.4 > > > Visual Studio compilers have different header files. > I looked through the files that qpid cpp uses for including Visual Studio > header files. > It looks like most of the diffences in header files are set up in Boost. > Boost uses the macro BOOST_WINDOWS. > Maybe we could use PROTON_WINDOWS for including the windows header files. > If you don't want a new macro, we can use one of the Visual Studio specific > macro (_WINDOWS) > for the header files. > It's not really a CPLUSPLUS vs. C issue, since many of the header files are > specific to Windows. > (for example winsock2.h which is used by C++ and C in Visual Studio). > Also, some of the current header files are not used on Windows, but may be > used by CYGWIN or MinGW. > If this sounds okay, I'll set up a patch for including the necessary windows > header files. -- 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] [Resolved] (PROTON-68) Porting Issue -- dll imports and exports on Visual Studio
[ https://issues.apache.org/jira/browse/PROTON-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-68. Resolution: Fixed fixed r1446466 > Porting Issue -- dll imports and exports on Visual Studio > - > > Key: PROTON-68 > URL: https://issues.apache.org/jira/browse/PROTON-68 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton >Assignee: Cliff Jansen > Labels: build > Fix For: 0.4 > > > Visual Studio dlls use a macro to explicitly state which functions will be > exported. I don’t have a list of all the functions that will be exported, so > I just made the ones used by proton.c to be exportable. That left a lot that > would be internal to the dll only. Then when I was working with the python, I > realized that python was going to be importing a lot of functions from the > dll that should never be exported unless testing, so I defined another macro > for the python (ruby, etc) exported functions. Swig also had to be taken into > account. > This is what I’m using right now and it should work on the Linux/Unix > platform: > #ifdef SWIGWIN >#define QPID_PROTON_API > #else >#ifdef _WINDOWS > #ifdef qpid_proton_EXPORTS > #define QPID_PROTON_API __declspec(dllexport) > #ifdef qpid_proton_python_EXPORTS >#define QPID_PROTON_PY __declspec(dllexport) > #else >#define QPID_PROTON_PY > #endif > #else > #define QPID_PROTON_API __declspec(dllimport) > #ifdef qpid_proton_python_IMPORTS >#define QPID_PROTON_PY __declspec(dllimport) > #else >#define QPID_PROTON_PY > #endif > #endif >#else > #define QPID_PROTON_API >#endif > #endif > That means all the headers will need to be changed to include the macros. > e.g. > QPID_PROTON_API pn_data_t *pn_data(size_t capacity); > QPID_PROTON_API void pn_data_free(pn_data_t *data); > QPID_PROTON_PY int pn_data_errno(pn_data_t *data); -- 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] [Resolved] (PROTON-98) Porting Issue -- Visual Studio compiler requires explicit casts
[ https://issues.apache.org/jira/browse/PROTON-98?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-98. Resolution: Fixed fixed r1407338 > Porting Issue -- Visual Studio compiler requires explicit casts > --- > > Key: PROTON-98 > URL: https://issues.apache.org/jira/browse/PROTON-98 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton >Assignee: Cliff Jansen > Labels: build > Fix For: 0.4 > > Attachments: explicitCasts2.patch, ExplicitCasts.patch > > > I would like to get the code changed to add explicit casts where the Visual > Studio compiler requires it. > The GNU compiler isn’t so picky, but we need the explicit casts for Visual > Studio tools. > The problem is in many of the files. > C:\qpid\qpid\proton\proton-c\src\proton.c(278): struct client_context *ctx > = (client_context *) pn_connector_context(ctor);// explicit > cast > C:\qpid\qpid\proton\proton-c\src\buffer.c(41): pn_buffer_t *buf = > (pn_buffer_t *) malloc(sizeof(pn_buffer_t)); // > explicit cast > C:\qpid\qpid\proton\proton-c\src\buffer.c(45): buf->bytes = capacity ? > (char *) malloc(capacity) : NULL; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(706):return (pn_type_t) > PN_ARG_ERR; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(758):return (pn_type_t) > PN_ARG_ERR; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1210):atom->u.type = > (pn_type_t) va_arg(*ap, int); // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1311): char **sptr > = (char **) ptr; // explicit > cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1875): pn_data_t *data = > (pn_data_t *) malloc(sizeof(pn_data_t)); // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1878): data->nodes = > capacity ? (pn_node_t *) malloc(capacity * sizeof(pn_node_t)) : NULL; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(1931): data->nodes = > (pn_node_t *) realloc(data->nodes, data->capacity * sizeof(pn_node_t)); > // explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(2151):char > **sptr = (char**) ptr; > // explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(3114):return (pn_type_t) > -1; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\codec\codec.c(3764):return (pn_type_t) > -1; // > explicit cast > C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(32): > pn_dispatcher_t *disp = (pn_dispatcher_t *) calloc(sizeof(pn_dispatcher_t), > 1); // explicit cast > C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(47): disp->output > = (char *) malloc(disp->capacity); // explicit > cast > C:\qpid\qpid\proton\proton-c\src\dispatcher\dispatcher.c(248): > disp->output = (char *) realloc(disp->output, disp->capacity);// > explicit cast > C:\qpid\qpid\proton\proton-c\src\driver.c(193): pn_listener_t *l = > (pn_listener_t *) malloc(sizeof(pn_listener_t));// > explicit cast > C:\qpid\qpid\proton\proton-c\src\driver.c(410): pn_connector_t *c = > (pn_connector_t *) malloc(sizeof(pn_connector_t)); // > explicit cast > C:\qpid\qpid\proton\proton-c\src\driver.c(656): pn_driver_t *d = > (pn_driver_t *) malloc(sizeof(pn_driver_t)); // > explicit cast > C:\qpid\qpid\proton\proton-c\src\driver.c(748):d->fds = (pollfd *) > realloc(d->fds, d->capacity*sizeof(struct pollfd)); // explicit cast > C:\qpid\qpid\proton\proton-c\src\engine\engine.c(47): db->deliveries = > (pn_delivery_state_t *) malloc(sizeof(pn_delivery_state_t) * capacity);// > explicit cast > C:\qpid\qpid\proton\proton-c\src\engine\engine.c(438): pn_connection_t > *conn = (pn_connection_t *)malloc(sizeof(pn_connection_t)); > // explicit cast > C:\qpid\qpid\proton\proton-c\src\engine\engine.c(730): pn_session_t *ssn = > (pn_session_t *) malloc(sizeof(pn_session_t)); // > explicit cast >
[jira] [Resolved] (PROTON-67) Porting Issue -- Initialization with braces is not supported by Visual Studio.
[
https://issues.apache.org/jira/browse/PROTON-67?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Cliff Jansen resolved PROTON-67.
Resolution: Fixed
fixed in proton-159
> Porting Issue -- Initialization with braces is not supported by Visual Studio.
> --
>
> Key: PROTON-67
> URL: https://issues.apache.org/jira/browse/PROTON-67
> Project: Qpid Proton
> Issue Type: Improvement
> Components: proton-c
> Environment: Windows using Visual Studio 2010
>Reporter: Mary hinton
>Assignee: Cliff Jansen
> Labels: build
> Fix For: 0.4
>
>
> In the Windows port, I used ifdef(s) for the initializations to keep the
> current code for Linux, and added code to compile in Visual Studio. If there
> is no objection, maybe we could replace the current initialization code with
> the Visual Studio code and remove the #ifdef(s).
> Here's some examples:
> Eample1
> ssize_t pn_data_encode(pn_data_t *data, char *bytes, size_t size)
> {
> #ifndef _WINDOWS
>pn_atoms_t latoms = {.size=data->size + data->extras, .start=atoms};
> #else
> pn_atoms_t latoms;
>latoms.size = data->size + data->extras;
>latoms.start = atoms;
> #endif
>
>
> Example 2
>
> #ifndef _WINDOWS
> return (pn_bytes_t) {size, start};
> #else
> pn_bytes_t pnBytes;
> pnBytes.size = size;
> pnBytes.start= start;
> return pnBytes;
> #endif
>
> Example 3
>
> pn_do_transfer()
>
> #ifndef _WINDOWS
> delivery = pn_delivery(link, pn_dtag(tag.start, tag.size));
> #else
> pn_delivery_tag_t delivt;
> delivt.bytes = tag.start;
> delivt.size = tag.size;
> delivery = pn_delivery(link, delivt);
> #endif
--
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] [Resolved] (PROTON-57) Proton porting problems between current codebase and Visual Studio 2010 toolset
[ https://issues.apache.org/jira/browse/PROTON-57?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Cliff Jansen resolved PROTON-57. Resolution: Fixed fixed in PROTON-159 > Proton porting problems between current codebase and Visual Studio 2010 > toolset > --- > > Key: PROTON-57 > URL: https://issues.apache.org/jira/browse/PROTON-57 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c > Environment: Windows using Visual Studio 2010 >Reporter: Mary hinton >Assignee: Cliff Jansen > Labels: build > Fix For: 0.4 > > Attachments: codec.c.patch, messenger.c.patch > > > This thread will be used to discuss the porting problems encountered using > Visual Studio 2010 > Here’s the first one to discuss: > > 1. Visual Studio doesn’t support variable length arrays. > a. Currently using malloc()/realloc() in my port just to get it to > compile and be able to report memory allocation errors. This is not what I > want to submit to the proton group for memory allocation. > b. Cliff had a good method that included setting up macros and replace > the VLAs with alloca() in the Windows version, but it could still cause > problems when the stack overflowed. VLAs can also run out of stack space. > c. _malloca() should be a better way than _alloca() on Visual Studio. > Any messages under 1K would be allocated out of the stack. Over 1K will use > heap. If the average messages are under 1K, this may be the most efficient > way in Visual Studio. _malloca() also has new security enhancements. > 1. Using _malloca() in the Windows version and VLA in Linux would > require two macros. The major difference for the Linux version would be to > use the new macro for VLA and to include the new free macro even though there > is nothing to free using VLA. In Visual Studio, _freea(buf) will not free > anything if it is allocating off the stack. > Linux can continue to use VLAs. > #ifdef C99 > #define PN_VLA(TYPE, buf, size) TYPE buf[size] > #define PN_VLA_FREE > #else > #define PN_VLA(TYPE, buf, size) TYPE *buf = (TYPE*) > _malloca(size) >#define PN_VLA_FREE(buf) _freea(buf) > #endif > d. If the average size messages to allocate out of the stack needs to be > increased for performance reasons, we can set up a new memory model. The 1K > is not adjustable for _malloca(). > We can set up new macros along the lines of Microsoft’s suggestion below. > “I would suggest something similar to what ATL does. Use alloca for small > (where you define what that is) sizes and use heap allocation for larger > ones. You can wrap the logic inside of a class or macros. To work around > the fact that alloca isn't cleaned up at block scope, rewrite the block into > functions or use lambdas. (I think alloca works inside of lambdas.)” -- 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-411) [proton-c] windows cmake configures file libqpid-proton.pc with unix settings
Chuck Rolke created PROTON-411:
--
Summary: [proton-c] windows cmake configures file
libqpid-proton.pc with unix settings
Key: PROTON-411
URL: https://issues.apache.org/jira/browse/PROTON-411
Project: Qpid Proton
Issue Type: Bug
Components: proton-c
Affects Versions: 0.4
Environment: Windows
Reporter: Chuck Rolke
Windows needs something other than hard coded
Libs: -L${libdir -lqpid-proton
Cflags: -I${includedir}}
All the other computed values configured into this file are correct: PREFIX,
EXEC_PREFIX, LIBDIR, INCLUDEDIR.
--
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] [Resolved] (PROTON-305) Remove accept mode from Perl bindings
[ https://issues.apache.org/jira/browse/PROTON-305?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-305. Resolution: Fixed This appears to have been committed in r1479572. > Remove accept mode from Perl bindings > - > > Key: PROTON-305 > URL: https://issues.apache.org/jira/browse/PROTON-305 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Affects Versions: 0.5 >Reporter: Darryl L. Pierce >Assignee: Darryl L. Pierce > Fix For: 0.5 > > > This was removed from the underlying C implementation. -- 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] [Resolved] (PROTON-315) proton-j Messenger testIncomingQueueBiggerThanWindow failing
[ https://issues.apache.org/jira/browse/PROTON-315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-315. Resolution: Fixed Fix Version/s: 0.5 Closing because this no longer appears to be skipped or failing. > proton-j Messenger testIncomingQueueBiggerThanWindow failing > > > Key: PROTON-315 > URL: https://issues.apache.org/jira/browse/PROTON-315 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Reporter: Philip Harvey >Assignee: Rafael H. Schloming > Fix For: 0.5 > > > This test has been failing since the changes for PROTON-295 were committed. > https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-proton-j/338/#showFailuresLink -- 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] [Resolved] (PROTON-160) Allow open.hostname to be configured independently of network hostname
[ https://issues.apache.org/jira/browse/PROTON-160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-160. Resolution: Fixed This has sat for a while now, and there are various more specific JIRAs for other SSL issues, so I'm going to consider this fixed by the new route APIs until I hear otherwise. > Allow open.hostname to be configured independently of network hostname > -- > > Key: PROTON-160 > URL: https://issues.apache.org/jira/browse/PROTON-160 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c, proton-j >Affects Versions: 0.1, 0.2 >Reporter: David Ingham >Assignee: Rafael H. Schloming > Labels: api > Fix For: 0.5 > > > In a scaled-out, multi-tenant broker environment, the host on which the > container is running is often different from the host to which a client is > establishing the tcp connection. The 'hostname' field in the connection open > performative was added to support this scenario. Currently there's no way to > control this from the Messenger API. > Options include: > (1) (preferred) add a new 'networkhost' field to Message to allow the network > address to be specified. If provided, this information would be used when > establishing the network connection and the data in the 'address' field would > be used in the connection open hostname field. This is somewhat in line with > the way that connection redirect (amqp:connection:redirect) is specified. > (2) extend the syntax of address with query string to supply hostname, e.g., > username:password@tcpaddress:tcpport/entityname?hostname=foo where 'foo' > would become the hostname used in the connection open frame. This is the > approach used by the current Qpid AMQP 1.0 JMS client. -- 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] [Resolved] (PROTON-147) Don't send a Sender Disposition until the all the transfers for a delivery have been sent.
[ https://issues.apache.org/jira/browse/PROTON-147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-147. Resolution: Fixed Reviewing current traces, I don't believe we do this anymore. Please reopen/refile if you encounter this again. > Don't send a Sender Disposition until the all the transfers for a delivery > have been sent. > -- > > Key: PROTON-147 > URL: https://issues.apache.org/jira/browse/PROTON-147 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Reporter: Hiram Chirino > Attachments: PROTON-147.patch > > -- 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] [Resolved] (PROTON-126) Sender.send should return void
[ https://issues.apache.org/jira/browse/PROTON-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-126. Resolution: Not A Problem I'm closing this because it is so old. Please reopen if you believe this merits further discussion. > Sender.send should return void > -- > > Key: PROTON-126 > URL: https://issues.apache.org/jira/browse/PROTON-126 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Reporter: Hiram Chirino >Assignee: Rafael H. Schloming > > No flow control is in place. You can easily OOM a JVM since Sender.send > continues to accept more bytes even if the peer is not accepting anymore data. -- 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] [Resolved] (PROTON-121) Platform specific code is mixed in with platform independent code
[ https://issues.apache.org/jira/browse/PROTON-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-121. Resolution: Fixed this appears to be fixed now > Platform specific code is mixed in with platform independent code > - > > Key: PROTON-121 > URL: https://issues.apache.org/jira/browse/PROTON-121 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Andrew Stitcher >Assignee: Andrew Stitcher > Fix For: 0.5 > > > the function pn_error_from errno() is platform specific and so should not be > in error.c which is (everywhere else) purely platform independent. > It should be moved to a platform (POSIX) specific file (perhaps a file with > only this single function). > [The clue for this is the #define POSIX_C_SOURCE at the top of error.c] -- 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] [Resolved] (PROTON-80) Codec should respect the const-ness of the input buffer.
[ https://issues.apache.org/jira/browse/PROTON-80?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-80. --- Resolution: Fixed > Codec should respect the const-ness of the input buffer. > > > Key: PROTON-80 > URL: https://issues.apache.org/jira/browse/PROTON-80 > Project: Qpid Proton > Issue Type: Improvement > Components: proton-c >Reporter: Ken Giusti >Assignee: Ken Giusti >Priority: Minor > > The method should not modify the caller's data buffer. -- 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] [Commented] (PROTON-58) NullPointerException on receiver.recv(...)
[ https://issues.apache.org/jira/browse/PROTON-58?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747644#comment-13747644 ] ASF subversion and git services commented on PROTON-58: --- Commit 1516508 from r...@apache.org in branch 'proton/trunk' [ https://svn.apache.org/r1516508 ] PROTON-58: throw illegal state instead of NPE > NullPointerException on receiver.recv(...) > -- > > Key: PROTON-58 > URL: https://issues.apache.org/jira/browse/PROTON-58 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Reporter: Hiram Chirino >Assignee: Keith Wall > Labels: api > > Caused by: java.lang.NullPointerException > at > org.apache.qpid.proton.engine.impl.ReceiverImpl.recv(ReceiverImpl.java:73) -- 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] [Resolved] (PROTON-58) NullPointerException on receiver.recv(...)
[ https://issues.apache.org/jira/browse/PROTON-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-58. --- Resolution: Fixed Assignee: Rafael H. Schloming (was: Keith Wall) > NullPointerException on receiver.recv(...) > -- > > Key: PROTON-58 > URL: https://issues.apache.org/jira/browse/PROTON-58 > Project: Qpid Proton > Issue Type: Bug > Components: proton-j >Reporter: Hiram Chirino >Assignee: Rafael H. Schloming > Labels: api > > Caused by: java.lang.NullPointerException > at > org.apache.qpid.proton.engine.impl.ReceiverImpl.recv(ReceiverImpl.java:73) -- 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
[VOTE]: Release Proton 0.5 RC3 as 0.5 final
Hi Everyone, After a bunch more tests/fixes I think we're ready to go for a vote now. I've posted 0.5 RC3 in the usual places: Source is here: http://people.apache.org/~rhs/qpid-proton-0.5rc3/ Java binaries are here: https://repository.apache.org/content/repositories/orgapacheqpid-109/ I've attached the svn change log for everything since RC2. Please peruse/test and register your vote: [ ] Yes, release 0.5 RC3 as 0.5 final [ ] No, 0.5 RC3 has the following issues... --Rafael r1516495 | rhs | 2013-08-22 12:04:14 -0400 (Thu, 22 Aug 2013) | 1 line fixed java driver stall; fixed java messenger to clean up the driver after stopping; added useful illegal state exceptions to the java messenger impl r1516485 | rhs | 2013-08-22 11:25:32 -0400 (Thu, 22 Aug 2013) | 1 line made logging use consistent ids r1516484 | rhs | 2013-08-22 11:24:14 -0400 (Thu, 22 Aug 2013) | 1 line added -n option for running multiple iterations; useful in debugging intermittent failures r1516433 | rhs | 2013-08-22 08:28:19 -0400 (Thu, 22 Aug 2013) | 1 line PROTON-397: added example contributed by Marc Berkowitz r1516431 | rhs | 2013-08-22 08:25:26 -0400 (Thu, 22 Aug 2013) | 1 line added target to svn:ignore r1516430 | rhs | 2013-08-22 08:24:43 -0400 (Thu, 22 Aug 2013) | 1 line added target directories to svn:ignore r1516427 | rhs | 2013-08-22 08:14:20 -0400 (Thu, 22 Aug 2013) | 1 line Fixed hang in Messenger.stop(); added recv() to Messenger interface. r1516194 | chug | 2013-08-21 12:03:42 -0400 (Wed, 21 Aug 2013) | 4 lines PROTON-405: Windows install can't find jar files. This patch adds a cmake option to skip building/installing jars. r1516192 | chug | 2013-08-21 11:46:17 -0400 (Wed, 21 Aug 2013) | 1 line NO-JIRA: Repair windows build after nonportable rhs commit r1516161 r1516184 | rhs | 2013-08-21 11:16:19 -0400 (Wed, 21 Aug 2013) | 1 line don't set an error for PN_OVERFLOW, this fixes PROTON-336, also fixed error accessors to be consistent r1516161 | rhs | 2013-08-21 09:53:25 -0400 (Wed, 21 Aug 2013) | 11 lines Added simple smoke tests for the bindings. Encountered numerous issues along the way and fixed as appropriate, including: - added tracker return values for ruby put/get - fixed ruby accept/reject to omit the tracker arg - fixed a deprecation warning in the perl binding - added disposition calls for php (PROTON-365) - added incoming/outgoing window properties for php - fixed put of messages without an address (PROTON-368) - added C level inspection method for messages to allow consistent printing of messages across bindings r1515860 | rhs | 2013-08-20 12:31:43 -0400 (Tue, 20 Aug 2013) | 1 line PROTON-389: added all dispositions to switch statement r1515858 | rhs | 2013-08-20 12:18:19 -0400 (Tue, 20 Aug 2013) | 1 line removed reference to a nonexistent file r1515795 | mcpierce | 2013-08-20 08:20:53 -0400 (Tue, 20 Aug 2013) | 6 lines PROTON-406: Fix installing the Ruby bindings. Previously it checked for RUBY_VENDORLIB_DIR as provided by Cmake. But this variable is not provided by older versions of CMake. Additionally, older versions of Ruby did not provide a vendorlibdir. In those cases, the behavior is to now get the Ruby sitearch dir instead. r1515614 | chug | 2013-08-19 17:30:57 -0400 (Mon, 19 Aug 2013) | 2 lines PROTON-407: [proton-c] Windows install does not install .lib nor .pdb files This patch installs the .lib file(s) to the /bin directory. r1515559 | chug | 2013-08-19 15:01:10 -0400 (Mon, 19 Aug 2013) | 1 line PROTON-408: [proton-c] Windows build does not put "d" suffix on debug file names r1515455 | philharveyonline | 2013-08-19 10:58:11 -0400 (Mon, 19 Aug 2013) | 2 lines PROTON-343: Removed proton-logging module and its usages (all of which are fun
[jira] [Resolved] (PROTON-397) Need an example using the proton-j Messenger and Message API
[ https://issues.apache.org/jira/browse/PROTON-397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael H. Schloming resolved PROTON-397. Resolution: Fixed Fix Version/s: 0.5 Assignee: Rafael H. Schloming > Need an example using the proton-j Messenger and Message API > > > Key: PROTON-397 > URL: https://issues.apache.org/jira/browse/PROTON-397 > Project: Qpid Proton > Issue Type: Wish > Components: proton-j >Affects Versions: 0.4, 0.5 >Reporter: Marc Berkowitz >Assignee: Rafael H. Schloming > Labels: example, test > Fix For: 0.5 > > Attachments: proton-397.tar.gz > > Original Estimate: 48h > Remaining Estimate: 48h > > Need a java counterpart to proton/examples/messenger/py, > with a pair of simple java commaind-line programs that send and receive > messages. Fixed bug PROTON-257 does not show how to use interface Messenger. > I have a simple version, closely based on examples/messenger/py, which I can > contribute, -- 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] [Commented] (PROTON-397) Need an example using the proton-j Messenger and Message API
[ https://issues.apache.org/jira/browse/PROTON-397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13747472#comment-13747472 ] ASF subversion and git services commented on PROTON-397: Commit 1516433 from r...@apache.org in branch 'proton/trunk' [ https://svn.apache.org/r1516433 ] PROTON-397: added example contributed by Marc Berkowitz > Need an example using the proton-j Messenger and Message API > > > Key: PROTON-397 > URL: https://issues.apache.org/jira/browse/PROTON-397 > Project: Qpid Proton > Issue Type: Wish > Components: proton-j >Affects Versions: 0.4, 0.5 >Reporter: Marc Berkowitz > Labels: example, test > Attachments: proton-397.tar.gz > > Original Estimate: 48h > Remaining Estimate: 48h > > Need a java counterpart to proton/examples/messenger/py, > with a pair of simple java commaind-line programs that send and receive > messages. Fixed bug PROTON-257 does not show how to use interface Messenger. > I have a simple version, closely based on examples/messenger/py, which I can > contribute, -- 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
