[jira] [Closed] (QPID-7768) Problem building on Fedora rawhide
[
https://issues.apache.org/jira/browse/QPID-7768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross closed QPID-7768.
-
Resolution: Duplicate
> Problem building on Fedora rawhide
> --
>
> Key: QPID-7768
> URL: https://issues.apache.org/jira/browse/QPID-7768
> Project: Qpid
> Issue Type: Bug
> Components: C++ Build
>Affects Versions: qpid-cpp-1.36.0
> Environment: [ 78%] Building CXX object
> src/CMakeFiles/qpidbroker.dir/qpid/broker/SessionAdapter.cpp.o
> cd /builddir/build/BUILD/qpid-cpp-1.36.0/src && /usr/bin/c++
> -DXQ_EFFECTIVE_BOOLEAN_VALUE_HPP -Dqpidbroker_EXPORTS
> -I/builddir/build/BUILD/qpid-cpp-1.36.0/src
> -I/builddir/build/BUILD/qpid-cpp-1.36.0/src/../include -I/usr/include/nss3
> -I/usr/include/nspr4 -std=c++11 -Wno-implicit-fallthrough
> -Wno-deprecated-declarations -O2 -g -pipe -Wall -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong
> --param=ssp-buffer-size=4 -grecord-gcc-switches
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -m64 -mtune=generic
> -fvisibility-inlines-hidden -Werror -pedantic -Wall -Wextra -Wno-shadow
> -Wpointer-arith -Wcast-qual -Wcast-align -Wno-long-long
> -Wvolatile-register-var -Winvalid-pch -Wno-system-headers
> -Woverloaded-virtual -Wno-error=deprecated-declarations -O2 -g -DNDEBUG -fPIC
> -pthread -o CMakeFiles/qpidbroker.dir/qpid/broker/SessionAdapter.cpp.o -c
> /builddir/build/BUILD/qpid-cpp-1.36.0/src/qpid/broker/SessionAdapter.cpp
> In file included from
> /builddir/build/BUILD/qpid-cpp-1.36.0/src/qpid/broker/SelectorToken.cpp:22:0:
> /builddir/build/BUILD/qpid-cpp-1.36.0/src/qpid/broker/SelectorToken.h: In
> member function 'const qpid::broker::Token&
> qpid::broker::Tokeniser::nextToken()':
> /builddir/build/BUILD/qpid-cpp-1.36.0/src/qpid/broker/SelectorToken.h:67:8:
> error: '.qpid::broker::Token::type' may be used uninitialized in
> this function [-Werror=maybe-uninitialized]
> struct Token {
> ^
> cc1plus: all warnings being treated as errors
> make[2]: *** [src/CMakeFiles/qpidbroker.dir/build.make:3282:
> src/CMakeFiles/qpidbroker.dir/qpid/broker/SelectorToken.cpp.o] Error 1
>Reporter: Irina Boverman
>Assignee: Justin Ross
>
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-832) Remove deprecated entities and attributes from the hawtio and stand-alone console
Ernest Allen created DISPATCH-832: - Summary: Remove deprecated entities and attributes from the hawtio and stand-alone console Key: DISPATCH-832 URL: https://issues.apache.org/jira/browse/DISPATCH-832 Project: Qpid Dispatch Issue Type: Task Components: Console Affects Versions: 0.8.0 Reporter: Ernest Allen Opening a separate Jira since the console changes are independent of the schema changes (that is, the current console works against the old schema with the entities and attributes marked as deprecated as well as the new schema with the deprecated entities removed). This jira is to remove the references to the deprecated entities and attributes from the css files and remove the code that was handling the deprecated entities and attributes if they appeared. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (DISPATCH-832) Remove deprecated entities and attributes from the hawtio and stand-alone console
[ https://issues.apache.org/jira/browse/DISPATCH-832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen reassigned DISPATCH-832: - Assignee: Ernest Allen > Remove deprecated entities and attributes from the hawtio and stand-alone > console > - > > Key: DISPATCH-832 > URL: https://issues.apache.org/jira/browse/DISPATCH-832 > Project: Qpid Dispatch > Issue Type: Task > Components: Console >Affects Versions: 0.8.0 >Reporter: Ernest Allen >Assignee: Ernest Allen > > Opening a separate Jira since the console changes are independent of the > schema changes (that is, the current console works against the old schema > with the entities and attributes marked as deprecated as well as the new > schema with the deprecated entities removed). > This jira is to remove the references to the deprecated entities and > attributes from the css files and remove the code that was handling the > deprecated entities and attributes if they appeared. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1512) Expose the "aborted" flag for transferred deliveries
[
https://issues.apache.org/jira/browse/PROTON-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173947#comment-16173947
]
Alan Conway commented on PROTON-1512:
-
Thinking some more, and I think the original design is correct.
- The AMQP 'aborted' flag on a transfer means throw away *all* data for the
delivery.
- Abort is only useful for multi-frame messages, where part of the message is
already sent.
- We should *never* generate frames with aborted=true and data.
aborted=true *requires* you to ignore the data, so sending both is
meaningless.
I would update proton to enforce this.
- If we receive aborted=true with data from some daft library, we will ignore
the data.
The spec requires us to ignore it so nobody can fault us on that.
What this means for dispatch:
- if we receive an aborted=true frame before we have enough message headers to
forward the message,
we simply ignore the whole delivery like it never happened.
- once we have started forwarding a message, if we get an aborted=true frame,
we forward
an empty aborted=true frame. We're not obliged to forward any data on that
frame since
the aborted=true flag compels the receiver to throw away all the data anyway.
It is quite possible to have proton expose the data (I already did it before I
thought this through) but I believe it is *impossible* do do that *and* have
older
clients correctly raise an error when a message is aborted. Eitehr they will
loop or
stall forever on a delivery wating for data that never comes, or they will
incorrectly
believe the message is completed.
There are 2 different ways that existing bidings and dispatch gather messages,
any way
I try to expose data on an aborted frame will break case A below.
If aborted frames are treated as partial, case A will hang/stall/never finish.
If they are not partial then case A will incorrectly complete the message.
The only way to get all existing clients to fail is to say aborted messages
are not partial and have pn_link_recv return an immediate error.
{code}
/* A: wait for a complete delivery, copy to application */
case PN_DELIVERY: {
if (pn_delivery_readable(d) && !pn_delivery_partial(d)) {
int ret = pn_link_recv(pn_delivery_link(d), buffer,
pn_delivery_pending(d));
if (ret >= 0) {
got_message(buffer, ret);
} else {
error(ret);
}
return COMPLETE_OR_ERROR;
}
break; /* Wait for more PN_DELIVERY events */
}
/* B: Append result of link_recv to app buffer till complete */
case PN_DELIVERY: {
int ret = pn_link_recv(pn_delivery_link(d), buffer+received_so_far,
pn_delivery_pending(d));
if (ret > 0) {
received_so_far += ret;
} else if (ret < 0) {
if (ret == PN_EOS) got_message(buffer, received_so_far);
if (ret < 0) error(ret);
return COMPLETE_OR_ERROR;
}
break; /* Wait for more PN_DELIVERY events */
}
{code}
> Expose the "aborted" flag for transferred deliveries
>
>
> Key: PROTON-1512
> URL: https://issues.apache.org/jira/browse/PROTON-1512
> Project: Qpid Proton
> Issue Type: New Feature
> Components: proton-c
>Reporter: Ted Ross
>Assignee: Alan Conway
> Labels: api
> Fix For: proton-c-0.18.0
>
>
> As we develop support for message streaming in Qpid Dispatch Router (i.e.
> frames for large multi-frame messages are forwarded to destinations as they
> arrive, before the complete message is received), there is a need to handle
> the case where a received message is never completed.
> The AMQP protocol has a provision for this in the "aborted" flag in the
> transfer performative. If the router is in the process of streaming a large
> message from sender to receiver and the sender drops before completing the
> delivery, the router can send a transfer to the downstream receivers with the
> "aborted" flag set. This would indicate that the message should not be
> processed and would not cause any framing errors on the link.
> Proton does not currently expose this capability in its API (There is a
> pn_link_abort in the C header file, but it is commented out and not
> implemented).
> In order to properly handle the failure cases for message streaming, this
> feature must be usable in Proton.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (DISPATCH-812) Remove the console stress test directories
[ https://issues.apache.org/jira/browse/DISPATCH-812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ernest Allen resolved DISPATCH-812. --- Resolution: Fixed Assignee: Ernest Allen Fix Version/s: 1.0.0 Removed the directories that contained test data. > Remove the console stress test directories > -- > > Key: DISPATCH-812 > URL: https://issues.apache.org/jira/browse/DISPATCH-812 > Project: Qpid Dispatch > Issue Type: Task > Components: Console >Affects Versions: 0.8.0 >Reporter: Ernest Allen >Assignee: Ernest Allen > Fix For: 1.0.0 > > > The directories under console/test/topologies should be removed and be git > ignored. > They are only used to stress test the console with very large router networks > and can easily be recreated when needed. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (DISPATCH-831) Change conntector.cost default value to 1 instead of '1'
Ernest Allen created DISPATCH-831: - Summary: Change conntector.cost default value to 1 instead of '1' Key: DISPATCH-831 URL: https://issues.apache.org/jira/browse/DISPATCH-831 Project: Qpid Dispatch Issue Type: Bug Components: Container Affects Versions: 0.8.0 Reporter: Ernest Allen Priority: Trivial The schema lists the connector.cost attribute as being an integer, however the default value is the string '1'. This is causing javascript errors in the console. I have a work-around for the console but it would be better to fix this at the source. Note: the listener.cost attribute is also an integer and it has an integer value as the default so I'm assuming that nothing is relying on the default value to be a string. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1512) Expose the "aborted" flag for transferred deliveries
[ https://issues.apache.org/jira/browse/PROTON-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173705#comment-16173705 ] Ted Ross commented on PROTON-1512: -- The above comment is unclear. I replied on the email thread with in-line remarks and Jira seems to have removed my remarks from their context. > Expose the "aborted" flag for transferred deliveries > > > Key: PROTON-1512 > URL: https://issues.apache.org/jira/browse/PROTON-1512 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Reporter: Ted Ross >Assignee: Alan Conway > Labels: api > Fix For: proton-c-0.18.0 > > > As we develop support for message streaming in Qpid Dispatch Router (i.e. > frames for large multi-frame messages are forwarded to destinations as they > arrive, before the complete message is received), there is a need to handle > the case where a received message is never completed. > The AMQP protocol has a provision for this in the "aborted" flag in the > transfer performative. If the router is in the process of streaming a large > message from sender to receiver and the sender drops before completing the > delivery, the router can send a transfer to the downstream receivers with the > "aborted" flag set. This would indicate that the message should not be > processed and would not cause any framing errors on the link. > Proton does not currently expose this capability in its API (There is a > pn_link_abort in the C header file, but it is commented out and not > implemented). > In order to properly handle the failure cases for message streaming, this > feature must be usable in Proton. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1512) Expose the "aborted" flag for transferred deliveries
[ https://issues.apache.org/jira/browse/PROTON-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173703#comment-16173703 ] Ted Ross commented on PROTON-1512: -- To be pedantic, I think that Dispatch Router should only forward the aborted delivery if it has already forwarded an earlier frame from the same delivery. If a new delivery arrives with the aborted flag set, the router should simply drop it (and issue replacement credit). I'm not sure I agree, but I'm also not sure the spec is clear on what should happen. I think it's ok for the receiver to receive A, B, D. If it cares it can observe that there is a gap in the delivery sequence. > Expose the "aborted" flag for transferred deliveries > > > Key: PROTON-1512 > URL: https://issues.apache.org/jira/browse/PROTON-1512 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Reporter: Ted Ross >Assignee: Alan Conway > Labels: api > Fix For: proton-c-0.18.0 > > > As we develop support for message streaming in Qpid Dispatch Router (i.e. > frames for large multi-frame messages are forwarded to destinations as they > arrive, before the complete message is received), there is a need to handle > the case where a received message is never completed. > The AMQP protocol has a provision for this in the "aborted" flag in the > transfer performative. If the router is in the process of streaming a large > message from sender to receiver and the sender drops before completing the > delivery, the router can send a transfer to the downstream receivers with the > "aborted" flag set. This would indicate that the message should not be > processed and would not cause any framing errors on the link. > Proton does not currently expose this capability in its API (There is a > pn_link_abort in the C header file, but it is commented out and not > implemented). > In order to properly handle the failure cases for message streaming, this > feature must be usable in Proton. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (PROTON-1587) failure on one SSL connection causes error:140E0197:SSL routines:SSL_shutdown:shutdown while in init
[ https://issues.apache.org/jira/browse/PROTON-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Justin Ross reassigned PROTON-1587: --- Assignee: Alan Conway (was: Andrew Stitcher) > failure on one SSL connection causes error:140E0197:SSL > routines:SSL_shutdown:shutdown while in init > > > Key: PROTON-1587 > URL: https://issues.apache.org/jira/browse/PROTON-1587 > Project: Qpid Proton > Issue Type: Bug > Components: proton-c >Reporter: Gordon Sim >Assignee: Alan Conway > Labels: tls > Fix For: proton-c-0.18.0 > > Attachments: proton-1587.tgz > > -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1512) Expose the "aborted" flag for transferred deliveries
[ https://issues.apache.org/jira/browse/PROTON-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173634#comment-16173634 ] Alan Conway commented on PROTON-1512: - OK, I'll redo the impl to preserve whatever data is in the aborted frame but finish with a PN_STATE error rather than PN_EOS. It does make sense that since a sender could compose aborted frames any way they like, proton might as well simply reflect that to the application to be handled as the application likes. In particular it means the router can forward aborted frames verbatim and let the ultimate receiver decide what to do about it if they do included data, which makes the router more transparent. > Expose the "aborted" flag for transferred deliveries > > > Key: PROTON-1512 > URL: https://issues.apache.org/jira/browse/PROTON-1512 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Reporter: Ted Ross >Assignee: Alan Conway > Labels: api > Fix For: proton-c-0.18.0 > > > As we develop support for message streaming in Qpid Dispatch Router (i.e. > frames for large multi-frame messages are forwarded to destinations as they > arrive, before the complete message is received), there is a need to handle > the case where a received message is never completed. > The AMQP protocol has a provision for this in the "aborted" flag in the > transfer performative. If the router is in the process of streaming a large > message from sender to receiver and the sender drops before completing the > delivery, the router can send a transfer to the downstream receivers with the > "aborted" flag set. This would indicate that the message should not be > processed and would not cause any framing errors on the link. > Proton does not currently expose this capability in its API (There is a > pn_link_abort in the C header file, but it is commented out and not > implemented). > In order to properly handle the failure cases for message streaming, this > feature must be usable in Proton. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1512) Expose the "aborted" flag for transferred deliveries
[ https://issues.apache.org/jira/browse/PROTON-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173576#comment-16173576 ] Chuck Rolke commented on PROTON-1512: - I'm trying to consume proton's behavior in qpid-dispatch. If a sender sends an aborted delivery to the router I believe that the router must forward that aborted delivery to it's message receivers. Then the receivers discard any data they have received so far. When proton discards the frame in which the abort is set and that is the only frame then proton has discarded the message arguments, header, router headers, and the router can't route a meaningful message. From the outside the receiver will not see the same stream that the sender sent. If sender sends A, B, C(aborted), D and receiver receives A, B, D with no indication that anything weird happened to message C then the system is unreliable. WRT a single-frame message with the aborted flag set: Why not? The spec allows for it and somebody will do it: I did it on my very first try! > Expose the "aborted" flag for transferred deliveries > > > Key: PROTON-1512 > URL: https://issues.apache.org/jira/browse/PROTON-1512 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Reporter: Ted Ross >Assignee: Alan Conway > Labels: api > Fix For: proton-c-0.18.0 > > > As we develop support for message streaming in Qpid Dispatch Router (i.e. > frames for large multi-frame messages are forwarded to destinations as they > arrive, before the complete message is received), there is a need to handle > the case where a received message is never completed. > The AMQP protocol has a provision for this in the "aborted" flag in the > transfer performative. If the router is in the process of streaming a large > message from sender to receiver and the sender drops before completing the > delivery, the router can send a transfer to the downstream receivers with the > "aborted" flag set. This would indicate that the message should not be > processed and would not cause any framing errors on the link. > Proton does not currently expose this capability in its API (There is a > pn_link_abort in the C header file, but it is commented out and not > implemented). > In order to properly handle the failure cases for message streaming, this > feature must be usable in Proton. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1512) Expose the "aborted" flag for transferred deliveries
[ https://issues.apache.org/jira/browse/PROTON-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173507#comment-16173507 ] Alan Conway commented on PROTON-1512: - Not sure I understand the problem. First: If a frame is aborted, by definition it's content (if any) is irrelevant and must be discarded, so it seems correct to return PN_STATE immediately; rather than return data that can only be thrown away. You can call pn_delivery_aborted() to tell the difference between an aborted frame and some other problem that causes a PN_STATE return. If you want to send an aborted frame, it doesn't need to have any data in it - it would be ignored in any case. Second: Why would you ever send a single-frame message with the aborted flag set? The only reason to abort a message is if >0 frames are already sent and there are >0 frames left to go but the remaining frames can never be sent for some reason. If a message is complete in a single frame then either send it or don't - there's no reason to use aborted. > Expose the "aborted" flag for transferred deliveries > > > Key: PROTON-1512 > URL: https://issues.apache.org/jira/browse/PROTON-1512 > Project: Qpid Proton > Issue Type: New Feature > Components: proton-c >Reporter: Ted Ross >Assignee: Alan Conway > Labels: api > Fix For: proton-c-0.18.0 > > > As we develop support for message streaming in Qpid Dispatch Router (i.e. > frames for large multi-frame messages are forwarded to destinations as they > arrive, before the complete message is received), there is a need to handle > the case where a received message is never completed. > The AMQP protocol has a provision for this in the "aborted" flag in the > transfer performative. If the router is in the process of streaming a large > message from sender to receiver and the sender drops before completing the > delivery, the router can send a transfer to the downstream receivers with the > "aborted" flag set. This would indicate that the message should not be > processed and would not cause any framing errors on the link. > Proton does not currently expose this capability in its API (There is a > pn_link_abort in the C header file, but it is commented out and not > implemented). > In order to properly handle the failure cases for message streaming, this > feature must be usable in Proton. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7773) REST API queries that identify a single object by its full path should return a object rather than a list.
[
https://issues.apache.org/jira/browse/QPID-7773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173385#comment-16173385
]
Lorenz Quack commented on QPID-7773:
I agree with the approach laid out in [Keith's first
comment|https://issues.apache.org/jira/browse/QPID-7773?focusedCommentId=16107142=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16107142]
with the following addition (which is currently implemented)
bq. if a URL uniquely does not identify a single object e.g /queue or
/virtualhost/myvhn, a list must result *unless the specified parent hierarchy
(in the second example "myvhn") itself cannot be found in which case 404 should
be returned*
Unfortunately, the third point
bq. if a URL uniquely identifies a single object is qualified by a filter e..g.
/queue/vhn/vh/myqueue?type=standard, if the filter matches, the object should
be returned otherwise a 404 should result
is not implemented in the specified way. If the filter matches I get a list and
if it does not I get a 200 with an empty list.
> REST API queries that identify a single object by its full path should return
> a object rather than a list.
> --
>
> Key: QPID-7773
> URL: https://issues.apache.org/jira/browse/QPID-7773
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Keith Wall
> Fix For: qpid-java-broker-7.0.0
>
>
> Currently if I GET for, say a queue, by the object's full path
> {{/queue/vhn/vh/myqueue}}, I get a JSON list contain the queue object, rather
> than an object directly. This makes the REST API's abstraction inconsistent:
> I PUT a queue as an object, but GET gives me a list.
> The REST API should be returning a list only in those situations where a
> multiple object response could arise e.g. {{/queue/vhn/vh}}, wildcards or
> filtering.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-325) reading from empty buffer of a BytesMessage should return 0, not -1
[
https://issues.apache.org/jira/browse/QPIDJMS-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173310#comment-16173310
]
Robbie Gemmell commented on QPIDJMS-325:
I think we may need to agree to disagree. I think either way is ok, but as I
said I'm not against changing it just for consistency. I think we've spent
longer discussing it than will ever apply to real world usage concerned with
the difference. At least we can all agree the javadoc sucks (if the length of
the array equals the number of bytes, should the stream not be read? :P)
> reading from empty buffer of a BytesMessage should return 0, not -1
> ---
>
> Key: QPIDJMS-325
> URL: https://issues.apache.org/jira/browse/QPIDJMS-325
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.25.0
>Reporter: Jiri Daněk
>Priority: Trivial
>
> Consider the following test. According to
> http://docs.oracle.com/javaee/7/api/javax/jms/BytesMessage.html#readBytes-byte:A-
> the #readBytes method should return 0 when it is first called, as the number
> of bytes in the buffer is 0 and it read 0 bytes. Only on subsequent calls it
> should return -1. What happens now is that the method returns -1 the first
> time.
> See the commented lines to try the same thing with ActiveMQ JMS Client
> library, and with StreamMessage instead of BytesMessage. The behavior there
> should be the same.
> ActiveMQ passes the test with BytesMessage and fails it with StreamMessage.
> Qpid JMS fails with BytesMessage and passes with StreamMessage.
> {code}
> import org.apache.activemq.ActiveMQConnectionFactory;
> import org.apache.qpid.jms.JmsConnectionFactory;
> import org.junit.Test;
> import javax.jms.*;
> import static com.google.common.truth.Truth.assertThat;
> public class EmptyBufferInputTest {
> @Test
> public void testEmptyBufferInput() throws JMSException {
> //ConnectionFactory connectionFactory = new
> ActiveMQConnectionFactory("tcp://127.0.0.1:61616");
> JmsConnectionFactory connectionFactory = new
> JmsConnectionFactory("amqp://127.0.0.1:5672");
> Connection connection = connectionFactory.createConnection();
> Session session = connection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
> final byte[] BYTE_LIST = {1, 2, 4};
> //StreamMessage message = session.createStreamMessage();
> BytesMessage message = session.createBytesMessage();
> message.clearBody();
> byte[] readList = new byte[BYTE_LIST.length - 1];
> byte[] emptyList = {};
> message.writeBytes(emptyList);
> message.reset();
> final int IS_EMPTY = 0;
> assertThat(message.readBytes(readList)).isEqualTo(IS_EMPTY);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-806) Go thru every deprecated entity and make sure a warning is put out when a deprecated entity is used.
[ https://issues.apache.org/jira/browse/DISPATCH-806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173304#comment-16173304 ] Ganesh Murthy commented on DISPATCH-806: We are removing all deprecated entities in the upcoming 1.0 version. [~tedross] , can this JIRA be closed? > Go thru every deprecated entity and make sure a warning is put out when a > deprecated entity is used. > > > Key: DISPATCH-806 > URL: https://issues.apache.org/jira/browse/DISPATCH-806 > Project: Qpid Dispatch > Issue Type: Bug > Components: Container >Affects Versions: 0.8.0 >Reporter: Ganesh Murthy >Assignee: Ganesh Murthy > Fix For: 1.0.0 > > > If any deprecated entity or attribute is used, make sure a warning log > message is put out by the router warning of such deprecated usage. -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPIDJMS-325) reading from empty buffer of a BytesMessage should return 0, not -1
[
https://issues.apache.org/jira/browse/QPIDJMS-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173296#comment-16173296
]
Rob Godfrey edited comment on QPIDJMS-325 at 9/20/17 2:54 PM:
--
[~gemmellr] I don't see anything in the *JavaDoc* that supports reasoning about
the behaviour based on how many bytes were originally in the stream. The
JavaDoc defines the semantics purely in terms of how many bytes are left in the
stream (0) versus the size of the array being read into (hopefully non-zero),
and whether a prior read had returned a number of bytes *less* than the number
of bytes in the passed array.
I agree that if one applies common sense then -1 would seem an entirely
reasonable value to return on the first read (no matter the size of the array
passed in). But if the JavaDoc provides the only definition of the expected
semantics, then I don't think the common sense interpretation can be derived
from the JavaDoc (although as I noted in my earlier comment, presuming that the
JavaDoc is of sufficient precision and accuracy to be able to define correct
semantics is not necessarily a sound course of action :-) ).
Edited to add: To be clear I imagine the number of people who really care about
this, and the number of applications which will break depending on whether the
implementation is changed / remains the same is likely to be 0 (within a small
rounding error)
was (Author: rgodfrey):
[~gemmellr] I don't see anything in the *JavaDoc* that supports reasoning about
the behaviour based on how many bytes were originally in the stream. The
JavaDoc defines the semantics purely in terms of how many bytes are left in the
stream (0) versus the size of the array being read into (hopefully non-zero),
and whether a prior read had returned a number of bytes *less* than the number
of bytes in the passed array.
I agree that if one applies common sense then -1 would seem an entirely
reasonable value to return on the first read (no matter the size of the array
passed in). But if the JavaDoc provides the only definition of the expected
semantics, then I don't think the common sense interpretation can be derived
from the JavaDoc (although as I noted in my earlier comment, presuming that the
JavaDoc is of sufficient precision and accuracy to be able to define correct
semantics is not necessarily a sound course of action :-) ).
> reading from empty buffer of a BytesMessage should return 0, not -1
> ---
>
> Key: QPIDJMS-325
> URL: https://issues.apache.org/jira/browse/QPIDJMS-325
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.25.0
>Reporter: Jiri Daněk
>Priority: Trivial
>
> Consider the following test. According to
> http://docs.oracle.com/javaee/7/api/javax/jms/BytesMessage.html#readBytes-byte:A-
> the #readBytes method should return 0 when it is first called, as the number
> of bytes in the buffer is 0 and it read 0 bytes. Only on subsequent calls it
> should return -1. What happens now is that the method returns -1 the first
> time.
> See the commented lines to try the same thing with ActiveMQ JMS Client
> library, and with StreamMessage instead of BytesMessage. The behavior there
> should be the same.
> ActiveMQ passes the test with BytesMessage and fails it with StreamMessage.
> Qpid JMS fails with BytesMessage and passes with StreamMessage.
> {code}
> import org.apache.activemq.ActiveMQConnectionFactory;
> import org.apache.qpid.jms.JmsConnectionFactory;
> import org.junit.Test;
> import javax.jms.*;
> import static com.google.common.truth.Truth.assertThat;
> public class EmptyBufferInputTest {
> @Test
> public void testEmptyBufferInput() throws JMSException {
> //ConnectionFactory connectionFactory = new
> ActiveMQConnectionFactory("tcp://127.0.0.1:61616");
> JmsConnectionFactory connectionFactory = new
> JmsConnectionFactory("amqp://127.0.0.1:5672");
> Connection connection = connectionFactory.createConnection();
> Session session = connection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
> final byte[] BYTE_LIST = {1, 2, 4};
> //StreamMessage message = session.createStreamMessage();
> BytesMessage message = session.createBytesMessage();
> message.clearBody();
> byte[] readList = new byte[BYTE_LIST.length - 1];
> byte[] emptyList = {};
> message.writeBytes(emptyList);
> message.reset();
> final int IS_EMPTY = 0;
> assertThat(message.readBytes(readList)).isEqualTo(IS_EMPTY);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail:
[jira] [Commented] (QPIDJMS-325) reading from empty buffer of a BytesMessage should return 0, not -1
[
https://issues.apache.org/jira/browse/QPIDJMS-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173296#comment-16173296
]
Rob Godfrey commented on QPIDJMS-325:
-
[~gemmellr] I don't see anything in the *JavaDoc* that supports reasoning about
the behaviour based on how many bytes were originally in the stream. The
JavaDoc defines the semantics purely in terms of how many bytes are left in the
stream (0) versus the size of the array being read into (hopefully non-zero),
and whether a prior read had returned a number of bytes *less* than the number
of bytes in the passed array.
I agree that if one applies common sense then -1 would seem an entirely
reasonable value to return on the first read (no matter the size of the array
passed in). But if the JavaDoc provides the only definition of the expected
semantics, then I don't think the common sense interpretation can be derived
from the JavaDoc (although as I noted in my earlier comment, presuming that the
JavaDoc is of sufficient precision and accuracy to be able to define correct
semantics is not necessarily a sound course of action :-) ).
> reading from empty buffer of a BytesMessage should return 0, not -1
> ---
>
> Key: QPIDJMS-325
> URL: https://issues.apache.org/jira/browse/QPIDJMS-325
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.25.0
>Reporter: Jiri Daněk
>Priority: Trivial
>
> Consider the following test. According to
> http://docs.oracle.com/javaee/7/api/javax/jms/BytesMessage.html#readBytes-byte:A-
> the #readBytes method should return 0 when it is first called, as the number
> of bytes in the buffer is 0 and it read 0 bytes. Only on subsequent calls it
> should return -1. What happens now is that the method returns -1 the first
> time.
> See the commented lines to try the same thing with ActiveMQ JMS Client
> library, and with StreamMessage instead of BytesMessage. The behavior there
> should be the same.
> ActiveMQ passes the test with BytesMessage and fails it with StreamMessage.
> Qpid JMS fails with BytesMessage and passes with StreamMessage.
> {code}
> import org.apache.activemq.ActiveMQConnectionFactory;
> import org.apache.qpid.jms.JmsConnectionFactory;
> import org.junit.Test;
> import javax.jms.*;
> import static com.google.common.truth.Truth.assertThat;
> public class EmptyBufferInputTest {
> @Test
> public void testEmptyBufferInput() throws JMSException {
> //ConnectionFactory connectionFactory = new
> ActiveMQConnectionFactory("tcp://127.0.0.1:61616");
> JmsConnectionFactory connectionFactory = new
> JmsConnectionFactory("amqp://127.0.0.1:5672");
> Connection connection = connectionFactory.createConnection();
> Session session = connection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
> final byte[] BYTE_LIST = {1, 2, 4};
> //StreamMessage message = session.createStreamMessage();
> BytesMessage message = session.createBytesMessage();
> message.clearBody();
> byte[] readList = new byte[BYTE_LIST.length - 1];
> byte[] emptyList = {};
> message.writeBytes(emptyList);
> message.reset();
> final int IS_EMPTY = 0;
> assertThat(message.readBytes(readList)).isEqualTo(IS_EMPTY);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-7772) Add statistics panel to view tabs within the Web Management Console
[
https://issues.apache.org/jira/browse/QPID-7772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173234#comment-16173234
]
Lorenz Quack edited comment on QPID-7772 at 9/20/17 2:49 PM:
-
I have a couple of comments with regards to the changes made in this JIRA:
* The columns of statistics grids are not resizable.
* The position of the "Edit & Delete" Bar is a bit surprising. It is tucked
under the statistics panel if present and under the attributes panel otherwise.
Is this by coincidence or what was the reasoning to put it there? I was okay
with it being under the attributes since all configured objects have attributes
but now it just seems arbitrary and inconsistent. That is ignoring the
additional oddity that is the Broker tab which seems to follow different design
yet again.
* Shouldn't all ConfiguredObjects that have statistics also have a statistics
panel? AMQP Ports and BrokerLoggers are two examples that fall into this
category.
* -Exchange stats seem to not work. ("inbound" is just showing 0s even though
messages are flowing)-
* There seem to be at least two UI bugs (Firefox 55.0.2 on Linux):
** Collapse a statisitics panel, switch tab, switch back, reopen the statistics
panel and the grid headers won't show until next update.
** UI bug: The right column in the Attributes panel of the following tabs
starts on the second row (these are the ones modified under this JIRA with the
exception of Connection which does not seem to be affected): VH, Queue, Port,
Exchange
* The minus.svg has an {{id="plus"}} which seems... counter-intuitive
was (Author: lorenz.quack):
I have a couple of comments with regards to the changes made in this JIRA:
* The columns of statistics grids are not resizable.
* The position of the "Edit & Delete" Bar is a bit surprising. It is tucked
under the statistics panel if present and under the attributes panel otherwise.
Is this by coincidence or what was the reasoning to put it there? I was okay
with it being under the attributes since all configured objects have attributes
but now it just seems arbitrary and inconsistent. That is ignoring the
additional oddity that is the Broker tab which seems to follow different design
yet again.
* Shouldn't all ConfiguredObjects that have statistics also have a statistics
panel? AMQP Ports and BrokerLoggers are two examples that fall into this
category.
* Exchange stats seem to not work. ("inbound" is just showing 0s even though
messages are flowing)
* There seem to be at least two UI bugs (Firefox 55.0.2 on Linux):
** Collapse a statisitics panel, switch tab, switch back, reopen the statistics
panel and the grid headers won't show until next update.
** UI bug: The right column in the Attributes panel of the following tabs
starts on the second row (these are the ones modified under this JIRA with the
exception of Connection which does not seem to be affected): VH, Queue, Port,
Exchange
* The minus.svg has an {{id="plus"}} which seems... counter-intuitive
> Add statistics panel to view tabs within the Web Management Console
> ---
>
> Key: QPID-7772
> URL: https://issues.apache.org/jira/browse/QPID-7772
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> Configured Objects within the Broker's object model already carry many useful
> statistics. Only a fraction of these are currently presented on the WMC and
> this means that most users are aware of their existence.
> Each view tab should have an expandable panel that provides the available
> statistics. The contents of the statistics panel should be entirely driven
> from the object's metadata. If the statistics panel is opened, the
> statistics should be updated automatically to the same refresh cycle of the
> request of the UI.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-325) reading from empty buffer of a BytesMessage should return 0, not -1
[
https://issues.apache.org/jira/browse/QPIDJMS-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173284#comment-16173284
]
Robbie Gemmell commented on QPIDJMS-325:
I think it can be interpreted that way, which is why I'm not against changing
it, but I also think it can be interpreted perfectly correctly the other way
that it is currently implemented.
There are no bytes in the stream as none were ever added to it, so -1 can be
returned. The text about less bytes in the stream than the array covers the
case of there being 1+ and the array being of size 2+. Unlike StreamMessage,
which calls out its behaviour very clearly that you must perform multiple
readBytes until -1 is returned and you must return 0 for an empty byte value,
BytesMessage does not do that, which I think allows either behaviour jsut fine.
An empty byte array inside a StreamMessage of elements is an entirely different
case than a BytesMessage with no content.
> reading from empty buffer of a BytesMessage should return 0, not -1
> ---
>
> Key: QPIDJMS-325
> URL: https://issues.apache.org/jira/browse/QPIDJMS-325
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.25.0
>Reporter: Jiri Daněk
>Priority: Trivial
>
> Consider the following test. According to
> http://docs.oracle.com/javaee/7/api/javax/jms/BytesMessage.html#readBytes-byte:A-
> the #readBytes method should return 0 when it is first called, as the number
> of bytes in the buffer is 0 and it read 0 bytes. Only on subsequent calls it
> should return -1. What happens now is that the method returns -1 the first
> time.
> See the commented lines to try the same thing with ActiveMQ JMS Client
> library, and with StreamMessage instead of BytesMessage. The behavior there
> should be the same.
> ActiveMQ passes the test with BytesMessage and fails it with StreamMessage.
> Qpid JMS fails with BytesMessage and passes with StreamMessage.
> {code}
> import org.apache.activemq.ActiveMQConnectionFactory;
> import org.apache.qpid.jms.JmsConnectionFactory;
> import org.junit.Test;
> import javax.jms.*;
> import static com.google.common.truth.Truth.assertThat;
> public class EmptyBufferInputTest {
> @Test
> public void testEmptyBufferInput() throws JMSException {
> //ConnectionFactory connectionFactory = new
> ActiveMQConnectionFactory("tcp://127.0.0.1:61616");
> JmsConnectionFactory connectionFactory = new
> JmsConnectionFactory("amqp://127.0.0.1:5672");
> Connection connection = connectionFactory.createConnection();
> Session session = connection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
> final byte[] BYTE_LIST = {1, 2, 4};
> //StreamMessage message = session.createStreamMessage();
> BytesMessage message = session.createBytesMessage();
> message.clearBody();
> byte[] readList = new byte[BYTE_LIST.length - 1];
> byte[] emptyList = {};
> message.writeBytes(emptyList);
> message.reset();
> final int IS_EMPTY = 0;
> assertThat(message.readBytes(readList)).isEqualTo(IS_EMPTY);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-325) reading from empty buffer of a BytesMessage should return 0, not -1
[
https://issues.apache.org/jira/browse/QPIDJMS-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173256#comment-16173256
]
Rob Godfrey commented on QPIDJMS-325:
-
Reading the javadoc, I think I agree with Jiri's original reasoning:
{quote}
If the number of bytes remaining in the stream is less than the length of array
value, the bytes should be read into the array. The return value of the total
number of bytes read will be less than the length of the array, indicating that
there are no more bytes left to be read from the stream.
{quote}
Followed by
{quote}
The *next* read of the stream returns -1.
{quote}
(emphasis mine).
To me that means that -1 is only returned after a prior read had already been
completed with that prior read returning a number *less* than the number of
bytes available to read into the array. (The implication of the latter is, I
think, that {code}msg.readBytes(new byte[0]);{code} should *ALWAYS* return 0,
unless a prior read has already returned -1).
As an aside on the validity of defining semantics from the javadoc... I note
that the Oracle
[javadoc|http://docs.oracle.com/javaee/7/api/javax/jms/BytesMessage.html#readBytes-byte:A-int-]
for the {code}int readBytes(byte[] value, int length){code} form is entirely
incorrect as it appears to have been copy and pasted from the single argument
method.
> reading from empty buffer of a BytesMessage should return 0, not -1
> ---
>
> Key: QPIDJMS-325
> URL: https://issues.apache.org/jira/browse/QPIDJMS-325
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.25.0
>Reporter: Jiri Daněk
>Priority: Trivial
>
> Consider the following test. According to
> http://docs.oracle.com/javaee/7/api/javax/jms/BytesMessage.html#readBytes-byte:A-
> the #readBytes method should return 0 when it is first called, as the number
> of bytes in the buffer is 0 and it read 0 bytes. Only on subsequent calls it
> should return -1. What happens now is that the method returns -1 the first
> time.
> See the commented lines to try the same thing with ActiveMQ JMS Client
> library, and with StreamMessage instead of BytesMessage. The behavior there
> should be the same.
> ActiveMQ passes the test with BytesMessage and fails it with StreamMessage.
> Qpid JMS fails with BytesMessage and passes with StreamMessage.
> {code}
> import org.apache.activemq.ActiveMQConnectionFactory;
> import org.apache.qpid.jms.JmsConnectionFactory;
> import org.junit.Test;
> import javax.jms.*;
> import static com.google.common.truth.Truth.assertThat;
> public class EmptyBufferInputTest {
> @Test
> public void testEmptyBufferInput() throws JMSException {
> //ConnectionFactory connectionFactory = new
> ActiveMQConnectionFactory("tcp://127.0.0.1:61616");
> JmsConnectionFactory connectionFactory = new
> JmsConnectionFactory("amqp://127.0.0.1:5672");
> Connection connection = connectionFactory.createConnection();
> Session session = connection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
> final byte[] BYTE_LIST = {1, 2, 4};
> //StreamMessage message = session.createStreamMessage();
> BytesMessage message = session.createBytesMessage();
> message.clearBody();
> byte[] readList = new byte[BYTE_LIST.length - 1];
> byte[] emptyList = {};
> message.writeBytes(emptyList);
> message.reset();
> final int IS_EMPTY = 0;
> assertThat(message.readBytes(readList)).isEqualTo(IS_EMPTY);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-325) reading from empty buffer of a BytesMessage should return 0, not -1
[
https://issues.apache.org/jira/browse/QPIDJMS-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173250#comment-16173250
]
Robbie Gemmell commented on QPIDJMS-325:
You've confused me a bit now. The original description says the two clients
behave differently for both types of message, since "ActiveMQ passes the test
with BytesMessage and fails it with StreamMessage. Qpid JMS fails with
BytesMessage and passes with StreamMessage."
To be clear, I think Qpid JMS is operating within the spec for both message
types as it stands, but was saying that I'm not necessarily against changing
its BytesMessage beheviour to be more consistent with its StreamMessage
implementation (though I also think theres no real need to). I think ActiveMQ
is also operating within the spec for BytesMessage, even if its behaviour is
not the same as Qpid JMS. It is not in spec for StreamMessage however, as it
explicitly states that it must return 0 for an empty element first before -1
(something BytesMessage does not say) and your test says that is not happening.
> reading from empty buffer of a BytesMessage should return 0, not -1
> ---
>
> Key: QPIDJMS-325
> URL: https://issues.apache.org/jira/browse/QPIDJMS-325
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.25.0
>Reporter: Jiri Daněk
>Priority: Trivial
>
> Consider the following test. According to
> http://docs.oracle.com/javaee/7/api/javax/jms/BytesMessage.html#readBytes-byte:A-
> the #readBytes method should return 0 when it is first called, as the number
> of bytes in the buffer is 0 and it read 0 bytes. Only on subsequent calls it
> should return -1. What happens now is that the method returns -1 the first
> time.
> See the commented lines to try the same thing with ActiveMQ JMS Client
> library, and with StreamMessage instead of BytesMessage. The behavior there
> should be the same.
> ActiveMQ passes the test with BytesMessage and fails it with StreamMessage.
> Qpid JMS fails with BytesMessage and passes with StreamMessage.
> {code}
> import org.apache.activemq.ActiveMQConnectionFactory;
> import org.apache.qpid.jms.JmsConnectionFactory;
> import org.junit.Test;
> import javax.jms.*;
> import static com.google.common.truth.Truth.assertThat;
> public class EmptyBufferInputTest {
> @Test
> public void testEmptyBufferInput() throws JMSException {
> //ConnectionFactory connectionFactory = new
> ActiveMQConnectionFactory("tcp://127.0.0.1:61616");
> JmsConnectionFactory connectionFactory = new
> JmsConnectionFactory("amqp://127.0.0.1:5672");
> Connection connection = connectionFactory.createConnection();
> Session session = connection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
> final byte[] BYTE_LIST = {1, 2, 4};
> //StreamMessage message = session.createStreamMessage();
> BytesMessage message = session.createBytesMessage();
> message.clearBody();
> byte[] readList = new byte[BYTE_LIST.length - 1];
> byte[] emptyList = {};
> message.writeBytes(emptyList);
> message.reset();
> final int IS_EMPTY = 0;
> assertThat(message.readBytes(readList)).isEqualTo(IS_EMPTY);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-325) reading from empty buffer of a BytesMessage should return 0, not -1
[
https://issues.apache.org/jira/browse/QPIDJMS-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173245#comment-16173245
]
Timothy Bish commented on QPIDJMS-325:
--
I'd agree that the StreamMessage in ActiveMQ 5.x has a bug. As for the code in
Qpid JMS I think that the BytesMessage meets the requirements of the
specification and don't really see a need to artificially try and make it
behave just like stream message as the two are quite different.
> reading from empty buffer of a BytesMessage should return 0, not -1
> ---
>
> Key: QPIDJMS-325
> URL: https://issues.apache.org/jira/browse/QPIDJMS-325
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.25.0
>Reporter: Jiri Daněk
>Priority: Trivial
>
> Consider the following test. According to
> http://docs.oracle.com/javaee/7/api/javax/jms/BytesMessage.html#readBytes-byte:A-
> the #readBytes method should return 0 when it is first called, as the number
> of bytes in the buffer is 0 and it read 0 bytes. Only on subsequent calls it
> should return -1. What happens now is that the method returns -1 the first
> time.
> See the commented lines to try the same thing with ActiveMQ JMS Client
> library, and with StreamMessage instead of BytesMessage. The behavior there
> should be the same.
> ActiveMQ passes the test with BytesMessage and fails it with StreamMessage.
> Qpid JMS fails with BytesMessage and passes with StreamMessage.
> {code}
> import org.apache.activemq.ActiveMQConnectionFactory;
> import org.apache.qpid.jms.JmsConnectionFactory;
> import org.junit.Test;
> import javax.jms.*;
> import static com.google.common.truth.Truth.assertThat;
> public class EmptyBufferInputTest {
> @Test
> public void testEmptyBufferInput() throws JMSException {
> //ConnectionFactory connectionFactory = new
> ActiveMQConnectionFactory("tcp://127.0.0.1:61616");
> JmsConnectionFactory connectionFactory = new
> JmsConnectionFactory("amqp://127.0.0.1:5672");
> Connection connection = connectionFactory.createConnection();
> Session session = connection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
> final byte[] BYTE_LIST = {1, 2, 4};
> //StreamMessage message = session.createStreamMessage();
> BytesMessage message = session.createBytesMessage();
> message.clearBody();
> byte[] readList = new byte[BYTE_LIST.length - 1];
> byte[] emptyList = {};
> message.writeBytes(emptyList);
> message.reset();
> final int IS_EMPTY = 0;
> assertThat(message.readBytes(readList)).isEqualTo(IS_EMPTY);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7772) Add statistics panel to view tabs within the Web Management Console
[
https://issues.apache.org/jira/browse/QPID-7772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173234#comment-16173234
]
Lorenz Quack commented on QPID-7772:
I have a couple of comments with regards to the changes made in this JIRA:
* The columns of statistics grids are not resizable.
* The position of the "Edit & Delete" Bar is a bit surprising. It is tucked
under the statistics panel if present and under the attributes panel otherwise.
Is this by coincidence or what was the reasoning to put it there? I was okay
with it being under the attributes since all configured objects have attributes
but now it just seems arbitrary and inconsistent. That is ignoring the
additional oddity that is the Broker tab which seems to follow different design
yet again.
* Shouldn't all ConfiguredObjects that have statistics also have a statistics
panel? AMQP Ports and BrokerLoggers are two examples that fall into this
category.
* Exchange stats seem to not work. ("inbound" is just showing 0s even though
messages are flowing)
* There seem to be at least two UI bugs (Firefox 55.0.2 on Linux):
** Collapse a statisitics panel, switch tab, switch back, reopen the statistics
panel and the grid headers won't show until next update.
** UI bug: The right column in the Attributes panel of the following tabs
starts on the second row (these are the ones modified under this JIRA with the
exception of Connection which does not seem to be affected): VH, Queue, Port,
Exchange
* The minus.svg has an {{id="plus"}} which seems... counter-intuitive
> Add statistics panel to view tabs within the Web Management Console
> ---
>
> Key: QPID-7772
> URL: https://issues.apache.org/jira/browse/QPID-7772
> Project: Qpid
> Issue Type: Improvement
> Components: Java Broker
>Reporter: Keith Wall
>Assignee: Keith Wall
>Priority: Minor
> Fix For: qpid-java-broker-7.0.0
>
>
> Configured Objects within the Broker's object model already carry many useful
> statistics. Only a fraction of these are currently presented on the WMC and
> this means that most users are aware of their existence.
> Each view tab should have an expandable panel that provides the available
> statistics. The contents of the statistics panel should be entirely driven
> from the object's metadata. If the statistics panel is opened, the
> statistics should be updated automatically to the same refresh cycle of the
> request of the UI.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPIDJMS-325) reading from empty buffer of a BytesMessage should return 0, not -1
[
https://issues.apache.org/jira/browse/QPIDJMS-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173231#comment-16173231
]
Jiri Daněk edited comment on QPIDJMS-325 at 9/20/17 2:19 PM:
-
Regarding consistency, the {{BytesMessage}} from
{{org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory}} behaves
the same way qpid-jms does (and so does their StreamMessage). I am not sure
which would be the more consistent choice of behavior for BytesMessage.
was (Author: jdanek):
Regarding consistency, the {{BytesMessage}} from
{{org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory}} behaves
the same way qpid-jms does (and so does their StreamMessage). I am not sure
which would be the more consistent choice.
> reading from empty buffer of a BytesMessage should return 0, not -1
> ---
>
> Key: QPIDJMS-325
> URL: https://issues.apache.org/jira/browse/QPIDJMS-325
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.25.0
>Reporter: Jiri Daněk
>Priority: Trivial
>
> Consider the following test. According to
> http://docs.oracle.com/javaee/7/api/javax/jms/BytesMessage.html#readBytes-byte:A-
> the #readBytes method should return 0 when it is first called, as the number
> of bytes in the buffer is 0 and it read 0 bytes. Only on subsequent calls it
> should return -1. What happens now is that the method returns -1 the first
> time.
> See the commented lines to try the same thing with ActiveMQ JMS Client
> library, and with StreamMessage instead of BytesMessage. The behavior there
> should be the same.
> ActiveMQ passes the test with BytesMessage and fails it with StreamMessage.
> Qpid JMS fails with BytesMessage and passes with StreamMessage.
> {code}
> import org.apache.activemq.ActiveMQConnectionFactory;
> import org.apache.qpid.jms.JmsConnectionFactory;
> import org.junit.Test;
> import javax.jms.*;
> import static com.google.common.truth.Truth.assertThat;
> public class EmptyBufferInputTest {
> @Test
> public void testEmptyBufferInput() throws JMSException {
> //ConnectionFactory connectionFactory = new
> ActiveMQConnectionFactory("tcp://127.0.0.1:61616");
> JmsConnectionFactory connectionFactory = new
> JmsConnectionFactory("amqp://127.0.0.1:5672");
> Connection connection = connectionFactory.createConnection();
> Session session = connection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
> final byte[] BYTE_LIST = {1, 2, 4};
> //StreamMessage message = session.createStreamMessage();
> BytesMessage message = session.createBytesMessage();
> message.clearBody();
> byte[] readList = new byte[BYTE_LIST.length - 1];
> byte[] emptyList = {};
> message.writeBytes(emptyList);
> message.reset();
> final int IS_EMPTY = 0;
> assertThat(message.readBytes(readList)).isEqualTo(IS_EMPTY);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-325) reading from empty buffer of a BytesMessage should return 0, not -1
[
https://issues.apache.org/jira/browse/QPIDJMS-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173231#comment-16173231
]
Jiri Daněk commented on QPIDJMS-325:
Regarding consistency, the {{BytesMessage}} from
{{org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory}} behaves
the same way qpid-jms does (and so does their StreamMessage). I am not sure
which would be the more consistent choice.
> reading from empty buffer of a BytesMessage should return 0, not -1
> ---
>
> Key: QPIDJMS-325
> URL: https://issues.apache.org/jira/browse/QPIDJMS-325
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.25.0
>Reporter: Jiri Daněk
>Priority: Trivial
>
> Consider the following test. According to
> http://docs.oracle.com/javaee/7/api/javax/jms/BytesMessage.html#readBytes-byte:A-
> the #readBytes method should return 0 when it is first called, as the number
> of bytes in the buffer is 0 and it read 0 bytes. Only on subsequent calls it
> should return -1. What happens now is that the method returns -1 the first
> time.
> See the commented lines to try the same thing with ActiveMQ JMS Client
> library, and with StreamMessage instead of BytesMessage. The behavior there
> should be the same.
> ActiveMQ passes the test with BytesMessage and fails it with StreamMessage.
> Qpid JMS fails with BytesMessage and passes with StreamMessage.
> {code}
> import org.apache.activemq.ActiveMQConnectionFactory;
> import org.apache.qpid.jms.JmsConnectionFactory;
> import org.junit.Test;
> import javax.jms.*;
> import static com.google.common.truth.Truth.assertThat;
> public class EmptyBufferInputTest {
> @Test
> public void testEmptyBufferInput() throws JMSException {
> //ConnectionFactory connectionFactory = new
> ActiveMQConnectionFactory("tcp://127.0.0.1:61616");
> JmsConnectionFactory connectionFactory = new
> JmsConnectionFactory("amqp://127.0.0.1:5672");
> Connection connection = connectionFactory.createConnection();
> Session session = connection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
> final byte[] BYTE_LIST = {1, 2, 4};
> //StreamMessage message = session.createStreamMessage();
> BytesMessage message = session.createBytesMessage();
> message.clearBody();
> byte[] readList = new byte[BYTE_LIST.length - 1];
> byte[] emptyList = {};
> message.writeBytes(emptyList);
> message.reset();
> final int IS_EMPTY = 0;
> assertThat(message.readBytes(readList)).isEqualTo(IS_EMPTY);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPIDJMS-325) reading from empty buffer of a BytesMessage should return 0, not -1
[
https://issues.apache.org/jira/browse/QPIDJMS-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Danek updated QPIDJMS-325:
---
Priority: Trivial (was: Minor)
> reading from empty buffer of a BytesMessage should return 0, not -1
> ---
>
> Key: QPIDJMS-325
> URL: https://issues.apache.org/jira/browse/QPIDJMS-325
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.25.0
>Reporter: Jiri Danek
>Priority: Trivial
>
> Consider the following test. According to
> http://docs.oracle.com/javaee/7/api/javax/jms/BytesMessage.html#readBytes-byte:A-
> the #readBytes method should return 0 when it is first called, as the number
> of bytes in the buffer is 0 and it read 0 bytes. Only on subsequent calls it
> should return -1. What happens now is that the method returns -1 the first
> time.
> See the commented lines to try the same thing with ActiveMQ JMS Client
> library, and with StreamMessage instead of BytesMessage. The behavior there
> should be the same.
> ActiveMQ passes the test with BytesMessage and fails it with StreamMessage.
> Qpid JMS fails with BytesMessage and passes with StreamMessage.
> {code}
> import org.apache.activemq.ActiveMQConnectionFactory;
> import org.apache.qpid.jms.JmsConnectionFactory;
> import org.junit.Test;
> import javax.jms.*;
> import static com.google.common.truth.Truth.assertThat;
> public class EmptyBufferInputTest {
> @Test
> public void testEmptyBufferInput() throws JMSException {
> //ConnectionFactory connectionFactory = new
> ActiveMQConnectionFactory("tcp://127.0.0.1:61616");
> JmsConnectionFactory connectionFactory = new
> JmsConnectionFactory("amqp://127.0.0.1:5672");
> Connection connection = connectionFactory.createConnection();
> Session session = connection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
> final byte[] BYTE_LIST = {1, 2, 4};
> //StreamMessage message = session.createStreamMessage();
> BytesMessage message = session.createBytesMessage();
> message.clearBody();
> byte[] readList = new byte[BYTE_LIST.length - 1];
> byte[] emptyList = {};
> message.writeBytes(emptyList);
> message.reset();
> final int IS_EMPTY = 0;
> assertThat(message.readBytes(readList)).isEqualTo(IS_EMPTY);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-325) reading from empty buffer of a BytesMessage should return 0, not -1
[
https://issues.apache.org/jira/browse/QPIDJMS-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173225#comment-16173225
]
Robbie Gemmell commented on QPIDJMS-325:
I don't entirely agree with your assessment, though I'm not necessarily against
changing things to be more consistent.
I think ActiveMQ's StreamMessage behaviour is incorrect, as the javadoc says it
is, however I don't think either clients behaviour is invalid for BytesMessage.
The definition there is much less specific and doesn't so strictly state what
should occur in that case whereas it does for StreamMessage, which in part
makes sense because the two are actually fairly different. In StreamMessage,
the precise behaviour around the start and end of a readBytes process is far
more important because there could be multiple such elements in the
StreamMessage back to back, and mixed with other types of element, and the end
of the message or wrong element type being encountered causes exceptions, so
you need to better demarcate which element is being read and that one elements
inspection is complete before the next begins etc. With BytesMessage its just a
single group of bytes, the end is the end, and no exception is thrown at the
end of the message so it makes less difference what is returned, which is
presumably why the javadoc is so much less specific.
> reading from empty buffer of a BytesMessage should return 0, not -1
> ---
>
> Key: QPIDJMS-325
> URL: https://issues.apache.org/jira/browse/QPIDJMS-325
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Affects Versions: 0.25.0
>Reporter: Jiri Danek
>Priority: Minor
>
> Consider the following test. According to
> http://docs.oracle.com/javaee/7/api/javax/jms/BytesMessage.html#readBytes-byte:A-
> the #readBytes method should return 0 when it is first called, as the number
> of bytes in the buffer is 0 and it read 0 bytes. Only on subsequent calls it
> should return -1. What happens now is that the method returns -1 the first
> time.
> See the commented lines to try the same thing with ActiveMQ JMS Client
> library, and with StreamMessage instead of BytesMessage. The behavior there
> should be the same.
> ActiveMQ passes the test with BytesMessage and fails it with StreamMessage.
> Qpid JMS fails with BytesMessage and passes with StreamMessage.
> {code}
> import org.apache.activemq.ActiveMQConnectionFactory;
> import org.apache.qpid.jms.JmsConnectionFactory;
> import org.junit.Test;
> import javax.jms.*;
> import static com.google.common.truth.Truth.assertThat;
> public class EmptyBufferInputTest {
> @Test
> public void testEmptyBufferInput() throws JMSException {
> //ConnectionFactory connectionFactory = new
> ActiveMQConnectionFactory("tcp://127.0.0.1:61616");
> JmsConnectionFactory connectionFactory = new
> JmsConnectionFactory("amqp://127.0.0.1:5672");
> Connection connection = connectionFactory.createConnection();
> Session session = connection.createSession(false,
> Session.AUTO_ACKNOWLEDGE);
> final byte[] BYTE_LIST = {1, 2, 4};
> //StreamMessage message = session.createStreamMessage();
> BytesMessage message = session.createBytesMessage();
> message.clearBody();
> byte[] readList = new byte[BYTE_LIST.length - 1];
> byte[] emptyList = {};
> message.writeBytes(emptyList);
> message.reset();
> final int IS_EMPTY = 0;
> assertThat(message.readBytes(readList)).isEqualTo(IS_EMPTY);
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-7713) Clang build fails with link error
[
https://issues.apache.org/jira/browse/QPID-7713?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Justin Ross reassigned QPID-7713:
-
Assignee: Justin Ross
> Clang build fails with link error
> -
>
> Key: QPID-7713
> URL: https://issues.apache.org/jira/browse/QPID-7713
> Project: Qpid
> Issue Type: Bug
> Components: C++ Build
> Environment: Fedora 25 x86-64, Clang 3.9.1
>Reporter: Justin Ross
>Assignee: Justin Ross
> Fix For: qpid-cpp-1.37.0
>
>
> {noformat}
> CXX=clang++ cmake .. && make -j8
> ---
> [100%] Linking CXX executable event_driven_list_agents
> [100%] Built target qmf2_event_driven_list_agents
> [100%] Linking CXX executable agent
> [100%] Built target qmf2_agent
> [100%] Linking CXX shared module cqmf2_ruby.so
> [100%] Built target cqmf2_ruby
> 1 warning generated.
> [100%] Linking CXX shared module _cqmf2.so
> [100%] Built target _cqmf2
> [100%] Linking CXX executable unit_test
> /usr/bin/ld: CMakeFiles/unit_test.dir/ExchangeTest.cpp.o: undefined reference
> to symbol 'pthread_rwlock_init@@GLIBC_2.2.5'
> /usr/lib64/libpthread.so.0: error adding symbols: DSO missing from command
> line
> clang-3.9: error: linker command failed with exit code 1 (use -v to see
> invocation)
> src/tests/CMakeFiles/unit_test.dir/build.make:1479: recipe for target
> 'src/tests/unit_test' failed
> make[2]: *** [src/tests/unit_test] Error 1
> CMakeFiles/Makefile2:2715: recipe for target
> 'src/tests/CMakeFiles/unit_test.dir/all' failed
> make[1]: *** [src/tests/CMakeFiles/unit_test.dir/all] Error 2
> Makefile:160: recipe for target 'all' failed
> make: *** [all] Error 2
> real 4m22.309s
> user 25m59.212s
> sys 1m3.917s
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-773) Implement a 2-phase start in the Dispatch Router
[ https://issues.apache.org/jira/browse/DISPATCH-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173141#comment-16173141 ] Ted Ross commented on DISPATCH-773: --- Some workarounds for this that can be used now: # Follow Gordon's suggestion (from the email thread) of having two listeners, one for management and one for endpoint connections. Only open the second listener when the configuration is complete. # Set the router's defaultDistribution to "unavailable". This will cause attachment to unconfigured addresses to fail, forcing the clients to retry. > Implement a 2-phase start in the Dispatch Router > > > Key: DISPATCH-773 > URL: https://issues.apache.org/jira/browse/DISPATCH-773 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Routing Engine >Reporter: Adel Boutros >Assignee: Ted Ross > > All the needed information could be found here: > http://qpid.2158936.n2.nabble.com/Dispatch-router-2-phase-start-td7663118.html -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (DISPATCH-773) Implement a 2-phase start in the Dispatch Router
[ https://issues.apache.org/jira/browse/DISPATCH-773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16173136#comment-16173136 ] Ted Ross commented on DISPATCH-773: --- I don't like the 2-phase start idea because I don't believe it solves the general problem. This proposal would only be effective in a deployment where the address, autoLink, and linkRoute configuration is static and fully established at startup (in the first startup phase). In the more general case, where address provisioning occurs in an ongoing fashion, the problem still exists. For example, a queue/waypoint added to the configuration _must_ complete before any consumers attach subscriptions to that address, otherwise the consumer will interfere with deliveries sent to the queue. I claim that the proper solution to the problem is to remove the race condition and make the router behave properly regardless of whether endpoints attach before or after addresses are configured. > Implement a 2-phase start in the Dispatch Router > > > Key: DISPATCH-773 > URL: https://issues.apache.org/jira/browse/DISPATCH-773 > Project: Qpid Dispatch > Issue Type: New Feature > Components: Routing Engine >Reporter: Adel Boutros >Assignee: Ted Ross > > All the needed information could be found here: > http://qpid.2158936.n2.nabble.com/Dispatch-router-2-phase-start-td7663118.html -- This message was sent by Atlassian JIRA (v6.4.14#64029) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-325) reading from empty buffer of a BytesMessage should return 0, not -1
Jiri Danek created QPIDJMS-325:
--
Summary: reading from empty buffer of a BytesMessage should return
0, not -1
Key: QPIDJMS-325
URL: https://issues.apache.org/jira/browse/QPIDJMS-325
Project: Qpid JMS
Issue Type: Bug
Components: qpid-jms-client
Affects Versions: 0.25.0
Reporter: Jiri Danek
Priority: Minor
Consider the following test. According to
http://docs.oracle.com/javaee/7/api/javax/jms/BytesMessage.html#readBytes-byte:A-
the #readBytes method should return 0 when it is first called, as the number
of bytes in the buffer is 0 and it read 0 bytes. Only on subsequent calls it
should return -1. What happens now is that the method returns -1 the first time.
See the commented lines to try the same thing with ActiveMQ JMS Client library,
and with StreamMessage instead of BytesMessage. The behavior there should be
the same.
ActiveMQ passes the test with BytesMessage and fails it with StreamMessage.
Qpid JMS fails with BytesMessage and passes with StreamMessage.
{code}
import org.apache.activemq.ActiveMQConnectionFactory;
import org.apache.qpid.jms.JmsConnectionFactory;
import org.junit.Test;
import javax.jms.*;
import static com.google.common.truth.Truth.assertThat;
public class EmptyBufferInputTest {
@Test
public void testEmptyBufferInput() throws JMSException {
//ConnectionFactory connectionFactory = new
ActiveMQConnectionFactory("tcp://127.0.0.1:61616");
JmsConnectionFactory connectionFactory = new
JmsConnectionFactory("amqp://127.0.0.1:5672");
Connection connection = connectionFactory.createConnection();
Session session = connection.createSession(false,
Session.AUTO_ACKNOWLEDGE);
final byte[] BYTE_LIST = {1, 2, 4};
//StreamMessage message = session.createStreamMessage();
BytesMessage message = session.createBytesMessage();
message.clearBody();
byte[] readList = new byte[BYTE_LIST.length - 1];
byte[] emptyList = {};
message.writeBytes(emptyList);
message.reset();
final int IS_EMPTY = 0;
assertThat(message.readBytes(readList)).isEqualTo(IS_EMPTY);
}
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
