[jira] [Updated] (QPID-6740) [C++ broker, Python client] Message not delivered after "empty" exception
[
https://issues.apache.org/jira/browse/QPID-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viktor Horvath updated QPID-6740:
-
Summary: [C++ broker, Python client] Message not delivered after "empty"
exception (was: Message not delivered after "empty" exception)
> [C++ broker, Python client] Message not delivered after "empty" exception
> -
>
> Key: QPID-6740
> URL: https://issues.apache.org/jira/browse/QPID-6740
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker, Python Client
>Affects Versions: 0.32
> Environment: CentOS 7.1
> qpid (C++) 0.32, qpid-python 0.32
>Reporter: Viktor Horvath
>
> If this is not a bug, the documentation might need an update, as I'm not
> aware of what I did wrong.
> Here is a test case, you will need two ipython consoles.
> {code:title=console 1}
> from qpid.messaging import Connection
> session = Connection.establish('amqp://127.0.0.1').session()
> sender = session.sender(
> 'mytestqueue; {create: always, node: {durable: True, type: queue}}')
> cleaner = session.receiver('mytestqueue')
> cleaner.fetch(timeout=0) # will raise a qpid.messaging.exceptions.Empty
> {code}
> (The receiver is named _cleaner_ because it is only supposed to "free" the
> queue from any old messages.)
> {code:title=console 2}
> from qpid.messaging import Connection
> session = Connection.establish('amqp://127.0.0.1').session()
> receiver = session.receiver('mytestqueue')
> receiver.fetch()
> {code}
> Back to the first console:
> {code:title=console 1}
> sender.send({'msg': 'test'})
> {code}
> *This message does not arrive at the second console. The receiver.fetch()
> still blocks.*
> I have the following observations about this situation:
> # One workaround is to call cleaner.close(), the blocking receiver will
> immediately return the message.
> # Another workaround is to specify a time-out in the receiver.fetch() call
> (test it with timeout=60). The message will be returned, though only at the
> end of the time-out!
> # Sending a second message will result in immediate delivery of the first
> message.
> # Once the situation is unblocked, you have to start anew in order to
> experience the blocking situation again. Don't forget to call
> session.acknowledge() before ending the console 2, or use a fresh queue.
> # The problem only manifests itself when receiver.fetch() starts before the
> message is sent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-6740) Message not delivered after "empty" exception
[
https://issues.apache.org/jira/browse/QPID-6740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viktor Horvath updated QPID-6740:
-
Description:
If this is not a bug, the documentation might need an update, as I'm not aware
of what I did wrong.
Here is a test case, you will need two ipython consoles.
{code:title=console 1}
from qpid.messaging import Connection
session = Connection.establish('amqp://127.0.0.1').session()
sender = session.sender(
'mytestqueue; {create: always, node: {durable: True, type: queue}}')
cleaner = session.receiver('mytestqueue')
cleaner.fetch(timeout=0) # will raise a qpid.messaging.exceptions.Empty
{code}
(The receiver is named _cleaner_ because it is only supposed to "free" the
queue from any old messages.)
{code:title=console 2}
from qpid.messaging import Connection
session = Connection.establish('amqp://127.0.0.1').session()
receiver = session.receiver('mytestqueue')
receiver.fetch()
{code}
Back to the first console:
{code:title=console 1}
sender.send({'msg': 'test'})
{code}
*This message does not arrive at the second console. The receiver.fetch() still
blocks.*
I have the following observations about this situation:
# One workaround is to call cleaner.close(), the blocking receiver will
immediately return the message.
# Another workaround is to specify a time-out in the receiver.fetch() call
(test it with timeout=60). The message will be returned, though only at the end
of the time-out!
# Sending a second message will result in immediate delivery of the first
message.
# Once the situation is unblocked, you have to start anew in order to
experience the blocking situation again. Don't forget to call
session.acknowledge() before ending the console 2, or use a fresh queue.
# The problem only manifests itself when receiver.fetch() starts before the
message is sent.
was:
If this is not a bug, the documentation might need an update, as I'm not aware
of what I did wrong :-)
Here is a test case, you will need two ipython consoles.
{code:title=console 1}
from qpid.messaging import Connection
session = Connection.establish('amqp://127.0.0.1').session()
sender = session.sender(
'mytestqueue; {create: always, node: {durable: True, type: queue}}')
cleaner = session.receiver('mytestqueue')
cleaner.fetch(timeout=0) # will raise a qpid.messaging.exceptions.Empty
{code}
(The receiver is named _cleaner_ because it is only supposed to "free" the
queue from any old messages.)
{code:title=console 2}
from qpid.messaging import Connection
session = Connection.establish('amqp://127.0.0.1').session()
receiver = session.receiver('mytestqueue')
receiver.fetch()
{code}
Back to the first console:
{code:title=console 1}
sender.send({'msg': 'test'})
{code}
*This message does not arrive at the second console. The receiver.fetch() still
blocks.*
I have the following observations about this situation:
# One workaround is to call cleaner.close(), the blocking receiver will
immediately return the message.
# Another workaround is to specify a time-out in the receiver.fetch() call
(test it with timeout=60). The message will be returned, though only at the end
of the time-out!
# Sending a second message will result in immediate delivery of the first
message.
# Once the situation is unblocked, you have to start anew in order to
experience the blocking situation again. Don't forget to call
session.acknowledge() before ending the console 2, or use a fresh queue.
# The problem only manifests itself when receiver.fetch() starts before the
message is sent.
> Message not delivered after "empty" exception
> -
>
> Key: QPID-6740
> URL: https://issues.apache.org/jira/browse/QPID-6740
> Project: Qpid
> Issue Type: Bug
> Components: C++ Broker, Python Client
>Affects Versions: 0.32
> Environment: CentOS 7.1
> qpid (C++) 0.32, qpid-python 0.32
>Reporter: Viktor Horvath
>
> If this is not a bug, the documentation might need an update, as I'm not
> aware of what I did wrong.
> Here is a test case, you will need two ipython consoles.
> {code:title=console 1}
> from qpid.messaging import Connection
> session = Connection.establish('amqp://127.0.0.1').session()
> sender = session.sender(
> 'mytestqueue; {create: always, node: {durable: True, type: queue}}')
> cleaner = session.receiver('mytestqueue')
> cleaner.fetch(timeout=0) # will raise a qpid.messaging.exceptions.Empty
> {code}
> (The receiver is named _cleaner_ because it is only supposed to "free" the
> queue from any old messages.)
> {code:title=console 2}
> from qpid.messaging import Connection
> session = Connection.establish('amqp://127.0.0.1').session()
> receiver = session.receiver('mytestqueue')
> receiver.fetch()
> {code}
> Back to the first console:
> {code:title=console 1}
> sender.send({'msg': 'test'})
> {code}
> *This m
[jira] [Created] (QPID-6740) Message not delivered after "empty" exception
Viktor Horvath created QPID-6740:
Summary: Message not delivered after "empty" exception
Key: QPID-6740
URL: https://issues.apache.org/jira/browse/QPID-6740
Project: Qpid
Issue Type: Bug
Components: C++ Broker, Python Client
Affects Versions: 0.32
Environment: CentOS 7.1
qpid (C++) 0.32, qpid-python 0.32
Reporter: Viktor Horvath
If this is not a bug, the documentation might need an update, as I'm not aware
of what I did wrong :-)
Here is a test case, you will need two ipython consoles.
{code:title=console 1}
from qpid.messaging import Connection
session = Connection.establish('amqp://127.0.0.1').session()
sender = session.sender(
'mytestqueue; {create: always, node: {durable: True, type: queue}}')
cleaner = session.receiver('mytestqueue')
cleaner.fetch(timeout=0) # will raise a qpid.messaging.exceptions.Empty
{code}
(The receiver is named _cleaner_ because it is only supposed to "free" the
queue from any old messages.)
{code:title=console 2}
from qpid.messaging import Connection
session = Connection.establish('amqp://127.0.0.1').session()
receiver = session.receiver('mytestqueue')
receiver.fetch()
{code}
Back to the first console:
{code:title=console 1}
sender.send({'msg': 'test'})
{code}
*This message does not arrive at the second console. The receiver.fetch() still
blocks.*
I have the following observations about this situation:
# One workaround is to call cleaner.close(), the blocking receiver will
immediately return the message.
# Another workaround is to specify a time-out in the receiver.fetch() call
(test it with timeout=60). The message will be returned, though only at the end
of the time-out!
# Sending a second message will result in immediate delivery of the first
message.
# Once the situation is unblocked, you have to start anew in order to
experience the blocking situation again. Don't forget to call
session.acknowledge() before ending the console 2, or use a fresh queue.
# The problem only manifests itself when receiver.fetch() starts before the
message is sent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
Review Request 38439: PROTON-992 : introduce pn_init() fn
--- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/38439/ --- Review request for qpid, Alan Conway, Kenneth Giusti, and Ted Ross. Repository: qpid-proton-git Description --- PROTON-992 : introduce a pn_init() fn, so we can initialize things like Cyrus SASL exactly-once. New file proton.h to hold declaration, because this doesn't seem to fit anywhere else. There is a flag in the sasl code to show whether this new interface has been used or not. If not -- allow code to function as before. Don't require current proton apps to change. Diffs - proton-c/include/proton/proton.h PRE-CREATION proton-c/src/sasl/cyrus_sasl.c 809bad5 proton-c/src/sasl/none_sasl.c 674326f proton-c/src/sasl/sasl-internal.h b3f4c7f proton-c/src/util.c e2c6727 Diff: https://reviews.apache.org/r/38439/diff/ Testing --- ctest -VV to confirm that not using the new interface does not break anything. And I hacked a copy of dispatch router to make it call the new pn_init() from main -- and confirm that the cyrus sasl server init and client init fns are called exactly once. Thanks, michael goulish
[jira] [Commented] (QPID-6730) Make the journal flush timeout configurable in the C++ broker
[ https://issues.apache.org/jira/browse/QPID-6730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14790839#comment-14790839 ] Jakub Scholz commented on QPID-6730: Oh, nice. I didn't know that. Thanks. > Make the journal flush timeout configurable in the C++ broker > - > > Key: QPID-6730 > URL: https://issues.apache.org/jira/browse/QPID-6730 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: qpid-cpp-0.34 >Reporter: Michael Cressman >Assignee: Andrew Stitcher >Priority: Minor > Fix For: qpid-cpp-next > > > Linear store does not flush the buffer often enough for synchronous durable > messages. Make the journal flush timeout configurable so users can tune > performance by changing this setting. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6730) Make the journal flush timeout configurable in the C++ broker
[ https://issues.apache.org/jira/browse/QPID-6730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14790657#comment-14790657 ] Andrew Stitcher commented on QPID-6730: --- [~scholzj] As with all the time values in the broker options you can use a suffix (eg."1ms") so you don't have to specify in seconds if you use a suffix. You can use "s", "ms", "us", "ns" as suffices. > Make the journal flush timeout configurable in the C++ broker > - > > Key: QPID-6730 > URL: https://issues.apache.org/jira/browse/QPID-6730 > Project: Qpid > Issue Type: Improvement > Components: C++ Broker >Affects Versions: qpid-cpp-0.34 >Reporter: Michael Cressman >Assignee: Andrew Stitcher >Priority: Minor > Fix For: qpid-cpp-next > > > Linear store does not flush the buffer often enough for synchronous durable > messages. Make the journal flush timeout configurable so users can tune > performance by changing this setting. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-110) Incorrect error handling when the sender.send(...) call / message transfer causes an error
[
https://issues.apache.org/jira/browse/QPIDJMS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14768829#comment-14768829
]
Robbie Gemmell commented on QPIDJMS-110:
I have put in an initial change for the first issue. The related issue is a bit
more general and will need some more thought. I'm heading out for a while
shortly but will look into that later
> Incorrect error handling when the sender.send(...) call / message transfer
> causes an error
> --
>
> Key: QPIDJMS-110
> URL: https://issues.apache.org/jira/browse/QPIDJMS-110
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Reporter: Jakub Scholz
>Assignee: Robbie Gemmell
>
> It seems to me that the error handling doesn't work properly when sending a
> message triggers an error (i.e. the sender.send(...) call, not creating
> sender).
> On the C++ broker, it is easy to configure the access control to allow
> message producers to send messages to a certain exchange (topic) only with
> some particular subjects / routing keys. When the subject / routing key is
> wrong, the C++ broker will raise "unathorized access" error and detach the
> link.
> I was running this scenario from the Qpid JMS client and it seems that it
> doesn't handle the error well:
> 1) Connect with the JMS client to the C++ broker
> 2) Open a sender to an exchange on the broker (this has to be allowed in the
> ACLs on the broker)
> 3) Try to send message with subject (i.e. JMSType) which is not allowed in
> broker ACLs
> 4) The broker detaches the link and the Proton library in the client seems to
> handle it, but the client doesn't seem to raise any exception to the outside.
> 2015-09-15 17:48:36 +0200 TRACE org.apache.qpid.jms.provider.amqp.FRAMES -
> RECV: Detach{handle=0, closed=true,
> error=Error{condition=amqp:unauthorized-access, description='user1@QPID1234
> cannot publish to broadcast with routing-key bad.routing.key
> (/builddir/build/BUILD/qpid-cpp-0.34/src/qpid/broker/amqp/Authorise.cpp:118)',
> info=null}}
> 2015-09-15 17:48:36 +0200 TRACE
> org.apache.qpid.jms.provider.amqp.AmqpProvider - New Proton Event: LINK_FLOW
> 2015-09-15 17:48:36 +0200 TRACE
> org.apache.qpid.jms.provider.amqp.AmqpProvider - New Proton Event:
> LINK_REMOTE_CLOSE
> 2015-09-15 17:48:36 +0200 INFO
> org.apache.qpid.jms.provider.amqp.AmqpAbstractResource - Resource
> JmsProducerInfo {producerId = ID:7W0192-58645-1442332115394-0:1:1:1,
> destination = broadcast} was remotely closed
> 2015-09-15 17:48:36 +0200 TRACE
> org.apache.qpid.jms.provider.amqp.AmqpProvider - New Proton Event:
> LINK_LOCAL_CLOSE
> 2015-09-15 17:48:36 +0200 INFO org.apache.qpid.jms.JmsSession - A JMS
> resource has been remotely closed: JmsProducerInfo {producerId =
> ID:7W0192-58645-1442332115394-0:1:1:1, destination = broadcast}
> 2015-09-15 17:48:36 +0200 TRACE org.apache.qpid.jms.provider.amqp.FRAMES -
> SENT: Detach{handle=0, closed=true, error=null}
> When sending messages asynchronously in a loop, the send(...) call will
> finish and few "sent" message later it will throw at least
> "javax.jms.JMSException: send not allowed after the sender is closed."
> exception. It doesn't contain the original error, but at least it is clear
> that something went wrong. So I think that is quite OK.
> But when sending messages synchronously, it seems to get stuck in the
> send(...) call and never return, although the underlying session is already
> gone. I would expect that the send(...) call returns and either throws some
> exception directly or through the Exception Listener.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPIDJMS-110) Incorrect error handling when the sender.send(...) call / message transfer causes an error
[
https://issues.apache.org/jira/browse/QPIDJMS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robbie Gemmell reassigned QPIDJMS-110:
--
Assignee: Robbie Gemmell
> Incorrect error handling when the sender.send(...) call / message transfer
> causes an error
> --
>
> Key: QPIDJMS-110
> URL: https://issues.apache.org/jira/browse/QPIDJMS-110
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Reporter: Jakub Scholz
>Assignee: Robbie Gemmell
>
> It seems to me that the error handling doesn't work properly when sending a
> message triggers an error (i.e. the sender.send(...) call, not creating
> sender).
> On the C++ broker, it is easy to configure the access control to allow
> message producers to send messages to a certain exchange (topic) only with
> some particular subjects / routing keys. When the subject / routing key is
> wrong, the C++ broker will raise "unathorized access" error and detach the
> link.
> I was running this scenario from the Qpid JMS client and it seems that it
> doesn't handle the error well:
> 1) Connect with the JMS client to the C++ broker
> 2) Open a sender to an exchange on the broker (this has to be allowed in the
> ACLs on the broker)
> 3) Try to send message with subject (i.e. JMSType) which is not allowed in
> broker ACLs
> 4) The broker detaches the link and the Proton library in the client seems to
> handle it, but the client doesn't seem to raise any exception to the outside.
> 2015-09-15 17:48:36 +0200 TRACE org.apache.qpid.jms.provider.amqp.FRAMES -
> RECV: Detach{handle=0, closed=true,
> error=Error{condition=amqp:unauthorized-access, description='user1@QPID1234
> cannot publish to broadcast with routing-key bad.routing.key
> (/builddir/build/BUILD/qpid-cpp-0.34/src/qpid/broker/amqp/Authorise.cpp:118)',
> info=null}}
> 2015-09-15 17:48:36 +0200 TRACE
> org.apache.qpid.jms.provider.amqp.AmqpProvider - New Proton Event: LINK_FLOW
> 2015-09-15 17:48:36 +0200 TRACE
> org.apache.qpid.jms.provider.amqp.AmqpProvider - New Proton Event:
> LINK_REMOTE_CLOSE
> 2015-09-15 17:48:36 +0200 INFO
> org.apache.qpid.jms.provider.amqp.AmqpAbstractResource - Resource
> JmsProducerInfo {producerId = ID:7W0192-58645-1442332115394-0:1:1:1,
> destination = broadcast} was remotely closed
> 2015-09-15 17:48:36 +0200 TRACE
> org.apache.qpid.jms.provider.amqp.AmqpProvider - New Proton Event:
> LINK_LOCAL_CLOSE
> 2015-09-15 17:48:36 +0200 INFO org.apache.qpid.jms.JmsSession - A JMS
> resource has been remotely closed: JmsProducerInfo {producerId =
> ID:7W0192-58645-1442332115394-0:1:1:1, destination = broadcast}
> 2015-09-15 17:48:36 +0200 TRACE org.apache.qpid.jms.provider.amqp.FRAMES -
> SENT: Detach{handle=0, closed=true, error=null}
> When sending messages asynchronously in a loop, the send(...) call will
> finish and few "sent" message later it will throw at least
> "javax.jms.JMSException: send not allowed after the sender is closed."
> exception. It doesn't contain the original error, but at least it is clear
> that something went wrong. So I think that is quite OK.
> But when sending messages synchronously, it seems to get stuck in the
> send(...) call and never return, although the underlying session is already
> gone. I would expect that the send(...) call returns and either throws some
> exception directly or through the Exception Listener.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-110) Incorrect error handling when the sender.send(...) call / message transfer causes an error
[
https://issues.apache.org/jira/browse/QPIDJMS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14767942#comment-14767942
]
ASF subversion and git services commented on QPIDJMS-110:
-
Commit 49aad78c81c33f9268f04c76449afa7fe439381c in qpid-jms's branch
refs/heads/master from Robert Gemmell
[ https://git-wip-us.apache.org/repos/asf?p=qpid-jms.git;h=49aad78 ]
QPIDJMS-110: ensure deliveries pending update get processed when the producer
link is remotely closed
> Incorrect error handling when the sender.send(...) call / message transfer
> causes an error
> --
>
> Key: QPIDJMS-110
> URL: https://issues.apache.org/jira/browse/QPIDJMS-110
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Reporter: Jakub Scholz
>
> It seems to me that the error handling doesn't work properly when sending a
> message triggers an error (i.e. the sender.send(...) call, not creating
> sender).
> On the C++ broker, it is easy to configure the access control to allow
> message producers to send messages to a certain exchange (topic) only with
> some particular subjects / routing keys. When the subject / routing key is
> wrong, the C++ broker will raise "unathorized access" error and detach the
> link.
> I was running this scenario from the Qpid JMS client and it seems that it
> doesn't handle the error well:
> 1) Connect with the JMS client to the C++ broker
> 2) Open a sender to an exchange on the broker (this has to be allowed in the
> ACLs on the broker)
> 3) Try to send message with subject (i.e. JMSType) which is not allowed in
> broker ACLs
> 4) The broker detaches the link and the Proton library in the client seems to
> handle it, but the client doesn't seem to raise any exception to the outside.
> 2015-09-15 17:48:36 +0200 TRACE org.apache.qpid.jms.provider.amqp.FRAMES -
> RECV: Detach{handle=0, closed=true,
> error=Error{condition=amqp:unauthorized-access, description='user1@QPID1234
> cannot publish to broadcast with routing-key bad.routing.key
> (/builddir/build/BUILD/qpid-cpp-0.34/src/qpid/broker/amqp/Authorise.cpp:118)',
> info=null}}
> 2015-09-15 17:48:36 +0200 TRACE
> org.apache.qpid.jms.provider.amqp.AmqpProvider - New Proton Event: LINK_FLOW
> 2015-09-15 17:48:36 +0200 TRACE
> org.apache.qpid.jms.provider.amqp.AmqpProvider - New Proton Event:
> LINK_REMOTE_CLOSE
> 2015-09-15 17:48:36 +0200 INFO
> org.apache.qpid.jms.provider.amqp.AmqpAbstractResource - Resource
> JmsProducerInfo {producerId = ID:7W0192-58645-1442332115394-0:1:1:1,
> destination = broadcast} was remotely closed
> 2015-09-15 17:48:36 +0200 TRACE
> org.apache.qpid.jms.provider.amqp.AmqpProvider - New Proton Event:
> LINK_LOCAL_CLOSE
> 2015-09-15 17:48:36 +0200 INFO org.apache.qpid.jms.JmsSession - A JMS
> resource has been remotely closed: JmsProducerInfo {producerId =
> ID:7W0192-58645-1442332115394-0:1:1:1, destination = broadcast}
> 2015-09-15 17:48:36 +0200 TRACE org.apache.qpid.jms.provider.amqp.FRAMES -
> SENT: Detach{handle=0, closed=true, error=null}
> When sending messages asynchronously in a loop, the send(...) call will
> finish and few "sent" message later it will throw at least
> "javax.jms.JMSException: send not allowed after the sender is closed."
> exception. It doesn't contain the original error, but at least it is clear
> that something went wrong. So I think that is quite OK.
> But when sending messages synchronously, it seems to get stuck in the
> send(...) call and never return, although the underlying session is already
> gone. I would expect that the send(...) call returns and either throws some
> exception directly or through the Exception Listener.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6732) Change performance test framework to use a rate limiter/hill climbing algorithm to determine a sustatinable throughput for a given testcase
[ https://issues.apache.org/jira/browse/QPID-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14747330#comment-14747330 ] ASF subversion and git services commented on QPID-6732: --- Commit 1703384 from [~k-wall] in branch 'java/trunk' [ https://svn.apache.org/r1703384 ] QPID-6732: [Java Perf Tests] Use variables in perftests-jndi.properties in order to allow remote broker host to be conveniently injected Remove redundant examples scripts/config etc > Change performance test framework to use a rate limiter/hill climbing > algorithm to determine a sustatinable throughput for a given testcase > > > Key: QPID-6732 > URL: https://issues.apache.org/jira/browse/QPID-6732 > Project: Qpid > Issue Type: New Feature > Components: Java Performance Tests >Reporter: Keith Wall >Assignee: Keith Wall > Fix For: qpid-java-6.0 > > Attachments: > 0001-QPID-6732-Java-Perf-Tests-Change-PerfTestFrame-to-us.patch, > 0001-QPID-6732-Java-Perf-Tests-Change-PerfTestFrame-to-us.patch, > 0001-QPID-6732-Java-PerfTests-correct-the-calculation-of-.patch, > 0001-QPID-6732-Java-PerfTests-new-default-perf-test.patch, QPID-6732.tar.bz2 > > > Change the performance test framework to utilise a rate limiter and a hill > climbing algorithm to allow it to discover the highest sustainable throughput > (where input rate ≈ output rate) for a given test scenario. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6732) Change performance test framework to use a rate limiter/hill climbing algorithm to determine a sustatinable throughput for a given testcase
[ https://issues.apache.org/jira/browse/QPID-6732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14747265#comment-14747265 ] ASF subversion and git services commented on QPID-6732: --- Commit 1703381 from [~k-wall] in branch 'java/trunk' [ https://svn.apache.org/r1703381 ] QPID-6732: [Java PerfTests] Invoke queue creation/deletion methods with reflection to maintain compatibility with Qpid Client <= 0.32 Required owing to the AMQShortString removal in the private API of AMQSession [QPID-6545] > Change performance test framework to use a rate limiter/hill climbing > algorithm to determine a sustatinable throughput for a given testcase > > > Key: QPID-6732 > URL: https://issues.apache.org/jira/browse/QPID-6732 > Project: Qpid > Issue Type: New Feature > Components: Java Performance Tests >Reporter: Keith Wall >Assignee: Keith Wall > Fix For: qpid-java-6.0 > > Attachments: > 0001-QPID-6732-Java-Perf-Tests-Change-PerfTestFrame-to-us.patch, > 0001-QPID-6732-Java-Perf-Tests-Change-PerfTestFrame-to-us.patch, > 0001-QPID-6732-Java-PerfTests-correct-the-calculation-of-.patch, > 0001-QPID-6732-Java-PerfTests-new-default-perf-test.patch, QPID-6732.tar.bz2 > > > Change the performance test framework to utilise a rate limiter and a hill > climbing algorithm to allow it to discover the highest sustainable throughput > (where input rate ≈ output rate) for a given test scenario. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-6545) malformed cyrillic strings that passed as TextMessage's property
[ https://issues.apache.org/jira/browse/QPID-6545?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14747266#comment-14747266 ] ASF subversion and git services commented on QPID-6545: --- Commit 1703381 from [~k-wall] in branch 'java/trunk' [ https://svn.apache.org/r1703381 ] QPID-6732: [Java PerfTests] Invoke queue creation/deletion methods with reflection to maintain compatibility with Qpid Client <= 0.32 Required owing to the AMQShortString removal in the private API of AMQSession [QPID-6545] > malformed cyrillic strings that passed as TextMessage's property > > > Key: QPID-6545 > URL: https://issues.apache.org/jira/browse/QPID-6545 > Project: Qpid > Issue Type: Bug > Components: Java Client >Affects Versions: 0.32 > Environment: Windows 8 x84 Russian, RabbitMQ 3.1.5 >Reporter: Nikita Konev >Assignee: Keith Wall > Fix For: qpid-java-6.0 > > Attachments: Runner.java, > TEST-org.apache.qpid.test.unit.message.UTF8Test-testUTF8Jp.txt, > UTF8_StringPropAddition.diff, screenRabbit.png > > > When I attempt pass string that contains cyrillic symbols, it is malformed. > I see malformed string in Rabbit's web interface and in java code which > receives messages from Rabbit. > Java src in utf8 Runner.java:38 and rabbit's screen attached. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-110) Incorrect error handling when the sender.send(...) call / message transfer causes an error
[
https://issues.apache.org/jira/browse/QPIDJMS-110?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14747193#comment-14747193
]
Jakub Scholz commented on QPIDJMS-110:
--
Similar scenario is when the queue where the transfer is targeted is full. In
that case, the broker directly closes the connection, resulting in the same
situation in the JMS client - the synchronous send gets stuck. But I guess this
might also happen purely as a race condition, when the detach / connection
close is triggered independently on the transfer, only with a wrong timing and
cause the send to be stuck.
> Incorrect error handling when the sender.send(...) call / message transfer
> causes an error
> --
>
> Key: QPIDJMS-110
> URL: https://issues.apache.org/jira/browse/QPIDJMS-110
> Project: Qpid JMS
> Issue Type: Bug
> Components: qpid-jms-client
>Reporter: Jakub Scholz
>
> It seems to me that the error handling doesn't work properly when sending a
> message triggers an error (i.e. the sender.send(...) call, not creating
> sender).
> On the C++ broker, it is easy to configure the access control to allow
> message producers to send messages to a certain exchange (topic) only with
> some particular subjects / routing keys. When the subject / routing key is
> wrong, the C++ broker will raise "unathorized access" error and detach the
> link.
> I was running this scenario from the Qpid JMS client and it seems that it
> doesn't handle the error well:
> 1) Connect with the JMS client to the C++ broker
> 2) Open a sender to an exchange on the broker (this has to be allowed in the
> ACLs on the broker)
> 3) Try to send message with subject (i.e. JMSType) which is not allowed in
> broker ACLs
> 4) The broker detaches the link and the Proton library in the client seems to
> handle it, but the client doesn't seem to raise any exception to the outside.
> 2015-09-15 17:48:36 +0200 TRACE org.apache.qpid.jms.provider.amqp.FRAMES -
> RECV: Detach{handle=0, closed=true,
> error=Error{condition=amqp:unauthorized-access, description='user1@QPID1234
> cannot publish to broadcast with routing-key bad.routing.key
> (/builddir/build/BUILD/qpid-cpp-0.34/src/qpid/broker/amqp/Authorise.cpp:118)',
> info=null}}
> 2015-09-15 17:48:36 +0200 TRACE
> org.apache.qpid.jms.provider.amqp.AmqpProvider - New Proton Event: LINK_FLOW
> 2015-09-15 17:48:36 +0200 TRACE
> org.apache.qpid.jms.provider.amqp.AmqpProvider - New Proton Event:
> LINK_REMOTE_CLOSE
> 2015-09-15 17:48:36 +0200 INFO
> org.apache.qpid.jms.provider.amqp.AmqpAbstractResource - Resource
> JmsProducerInfo {producerId = ID:7W0192-58645-1442332115394-0:1:1:1,
> destination = broadcast} was remotely closed
> 2015-09-15 17:48:36 +0200 TRACE
> org.apache.qpid.jms.provider.amqp.AmqpProvider - New Proton Event:
> LINK_LOCAL_CLOSE
> 2015-09-15 17:48:36 +0200 INFO org.apache.qpid.jms.JmsSession - A JMS
> resource has been remotely closed: JmsProducerInfo {producerId =
> ID:7W0192-58645-1442332115394-0:1:1:1, destination = broadcast}
> 2015-09-15 17:48:36 +0200 TRACE org.apache.qpid.jms.provider.amqp.FRAMES -
> SENT: Detach{handle=0, closed=true, error=null}
> When sending messages asynchronously in a loop, the send(...) call will
> finish and few "sent" message later it will throw at least
> "javax.jms.JMSException: send not allowed after the sender is closed."
> exception. It doesn't contain the original error, but at least it is clear
> that something went wrong. So I think that is quite OK.
> But when sending messages synchronously, it seems to get stuck in the
> send(...) call and never return, although the underlying session is already
> gone. I would expect that the send(...) call returns and either throws some
> exception directly or through the Exception Listener.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
