[jira] [Commented] (QPID-8345) [Broker-J][AMQP 1.0] Consumed messages are left in acquired state on a queue when receiver’s desired snd-settle-mode is set to settled and transactions are not used for
[
https://issues.apache.org/jira/browse/QPID-8345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890266#comment-16890266
]
Rob Godfrey commented on QPID-8345:
---
[~robbie] yes - to be fair, when sending settled the sender has complete
freedom to use any outcome it likes, and is under no obligation to inform the
receiver of the message what that outcome would be (since the outcome is a
sender only concern). The "sensible" thing is for the broker to be sending
messages as "ACCEPTED", and if the sender wishes to inform the receiver this
could be enumerated on every message. Although the spec does not say this, I
would interpret the behaviour of the sender having default outcome X, and
sending settled to be the same as saying the terminal state was X on every
settled transfer... but since the receiver has no need to know the state the
spec makes no mention / provision for this use case.
> [Broker-J][AMQP 1.0] Consumed messages are left in acquired state on a queue
> when receiver’s desired snd-settle-mode is set to settled and transactions
> are not used for message receiving
> --
>
> Key: QPID-8345
> URL: https://issues.apache.org/jira/browse/QPID-8345
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0, qpid-java-broker-7.0.1,
> qpid-java-broker-7.1.0, qpid-java-broker-7.0.4, qpid-java-broker-7.0.5,
> qpid-java-broker-7.0.6, qpid-java-broker-7.0.7, qpid-java-broker-7.1.1,
> qpid-java-broker-7.1.2, qpid-java-broker-7.0.8, qpid-java-broker-7.1.3,
> qpid-java-broker-7.1.4
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.5
>
>
> When receiving link desired {{snd-settle-mode}} is set to {{settled}} and
> transactions are not used for message receiving, the broker sending link
> sends the messages pre-settled.
> However, the consumed messages are left in acquired state on the queue after
> sending them to consumer. Such messages stack in {{acquired}} state until
> broker is restarted. After the restart, the persistent message became
> available for consumption again.
> The broker currently does not apply {{default-outcome}} set on receiving link
> (indicating the outcome to be used for transfers that have not reached a
> terminal state at the
> receiver when the transfer is settled [see section 3.5.3 Source]).
> Based on value of {{default-outcome}} set on consumer link source, the broker
> should apply the following:
> * {{accepted}} or {{null}}; remove message from the queue
> * {{rejected}}, {{released}}, {{modified}}; release message
> * any other outcome; close link with an error {{not-implemented}}
> * not valid outcome (for example, {{received}}); close link with an error
> {{invalid-field}}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-8345) [Broker-J][AMQP 1.0] Consumed messages are left in acquired state on a queue when receiver’s desired snd-settle-mode is set to settled and sender sends pre-settled
[
https://issues.apache.org/jira/browse/QPID-8345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890215#comment-16890215
]
Rob Godfrey edited comment on QPID-8345 at 7/22/19 2:36 PM:
[~robbie] actually I think that [~orudyy] is correct here - that if the
*sending* side sets a default outcome of released and send a message settled
then it really is saying "I'm sending you this message, and I assume that you
are going to release it". Obviously this makes no sense; and for the broker it
probably makes no sense to set the default outcome on the sending link to
anything other than accepted on a link where it is sending settled. Note that
it is solely up to the broker to set what it believes to be a sensible default
outcome here (no matter what the receiving client wants the default outcome to
be).
was (Author: rgodfrey):
[~robbie] actually I think that [~orudyy] is correct here - that if the
*sending* side sets a default outcome of released and send a message settled
then it really is saying "I'm sending you this message, and I assume that you
are going to release it". Obviously this makes no sense; and for the broker it
probably makes no sense to set the default outcome on the sending link to
anything other than rejected. Note that it is solely up to the broker to set
what it believes to be a sensible default outcome here (no matter what the
receiving client wants the default outcome to be).
> [Broker-J][AMQP 1.0] Consumed messages are left in acquired state on a queue
> when receiver’s desired snd-settle-mode is set to settled and sender sends
> pre-settled messages without using transactions
> ---
>
> Key: QPID-8345
> URL: https://issues.apache.org/jira/browse/QPID-8345
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0, qpid-java-broker-7.0.1,
> qpid-java-broker-7.1.0, qpid-java-broker-7.0.4, qpid-java-broker-7.0.5,
> qpid-java-broker-7.0.6, qpid-java-broker-7.0.7, qpid-java-broker-7.1.1,
> qpid-java-broker-7.1.2, qpid-java-broker-7.0.8, qpid-java-broker-7.1.3,
> qpid-java-broker-7.1.4
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.5
>
>
> When receiving link desired {{snd-settle-mode}} is set to {{settled}} and
> transactions are not used for message receiving, the broker sending link
> sends the messages pre-settled.
> However, the consumed messages are left in acquired state on the queue after
> sending them to consumer. Such messages stack in {{acquired}} state until
> broker is restarted. After the restart, the persistent message became
> available for consumption again.
> The broker currently does not apply {{default-outcome}} set on receiving link
> (indicating the outcome to be used for transfers that have not reached a
> terminal state at the
> receiver when the transfer is settled [see section 3.5.3 Source]).
> Based on value of {{default-outcome}} set on consumer link source, the broker
> should apply the following:
> * {{accepted}} or {{null}}; remove message from the queue
> * {{rejected}}, {{released}}, {{modified}}; release message
> * any other outcome; close link with an error {{not-implemented}}
> * not valid outcome (for example, {{received}}); close link with an error
> {{invalid-field}}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8345) [Broker-J][AMQP 1.0] Consumed messages are left in acquired state on a queue when receiver’s desired snd-settle-mode is set to settled and sender sends pre-settled messa
[
https://issues.apache.org/jira/browse/QPID-8345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16890215#comment-16890215
]
Rob Godfrey commented on QPID-8345:
---
[~robbie] actually I think that [~orudyy] is correct here - that if the
*sending* side sets a default outcome of released and send a message settled
then it really is saying "I'm sending you this message, and I assume that you
are going to release it". Obviously this makes no sense; and for the broker it
probably makes no sense to set the default outcome on the sending link to
anything other than rejected. Note that it is solely up to the broker to set
what it believes to be a sensible default outcome here (no matter what the
receiving client wants the default outcome to be).
> [Broker-J][AMQP 1.0] Consumed messages are left in acquired state on a queue
> when receiver’s desired snd-settle-mode is set to settled and sender sends
> pre-settled messages without using transactions
> ---
>
> Key: QPID-8345
> URL: https://issues.apache.org/jira/browse/QPID-8345
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0, qpid-java-broker-7.0.1,
> qpid-java-broker-7.1.0, qpid-java-broker-7.0.4, qpid-java-broker-7.0.5,
> qpid-java-broker-7.0.6, qpid-java-broker-7.0.7, qpid-java-broker-7.1.1,
> qpid-java-broker-7.1.2, qpid-java-broker-7.0.8, qpid-java-broker-7.1.3,
> qpid-java-broker-7.1.4
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.5
>
>
> When receiving link desired {{snd-settle-mode}} is set to {{settled}} and
> transactions are not used for message receiving, the broker sending link
> sends the messages pre-settled.
> However, the consumed messages are left in acquired state on the queue after
> sending them to consumer. Such messages stack in {{acquired}} state until
> broker is restarted. After the restart, the persistent message became
> available for consumption again.
> The broker currently does not apply {{default-outcome}} set on receiving link
> (indicating the outcome to be used for transfers that have not reached a
> terminal state at the
> receiver when the transfer is settled [see section 3.5.3 Source]).
> Based on value of {{default-outcome}} set on consumer link source, the broker
> should apply the following:
> * {{accepted}} or {{null}}; remove message from the queue
> * {{rejected}}, {{released}}, {{modified}}; release message
> * any other outcome; close link with an error {{not-implemented}}
> * not valid outcome (for example, {{received}}); close link with an error
> {{invalid-field}}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-3616) Java Broker misinterprets message.flow infinite credit value (0xFFFFFFFF)
[
https://issues.apache.org/jira/browse/QPID-3616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16881407#comment-16881407
]
Rob Godfrey commented on QPID-3616:
---
I believe this was fixed in QPID-8225 (there was a recent change in QPID-8322
which got rid of one wrinkle),
> Java Broker misinterprets message.flow infinite credit value (0x)
> -
>
> Key: QPID-3616
> URL: https://issues.apache.org/jira/browse/QPID-3616
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: 0.13
>Reporter: Keith Wall
>Priority: Major
>
> The AMQP 0-10 defines 0x as meaning "an infinite amount of credit."
> as the value argument to the message.flow command.
> A bug in the Java Broker (WindowCreditManager) means that this value is
> interpreted literally. The WCM class should be changed to understand the
> special value.
> It also appears that notification logic in WindowCreditManager#restoreCredit
> presently relies on this defect. This must be refactored during this change.
> SubscriptionImpl and Subscription_0_10 appears to contain further workarounds
> in #creditStateChanged() callback methods. These should be reworked too.
> {code}
> if(_state.compareAndSet(State.SUSPENDED, State.ACTIVE))
> {
> _stateListener.stateChange(this, State.SUSPENDED, State.ACTIVE);
> }
> else
> {
> // this is a hack to get round the issue of increasing bytes credit
> _stateListener.stateChange(this, State.ACTIVE, State.ACTIVE);
> }
> {code}
> This defect is unlikely to affect users as 0x gives a bytes credit of
> 4GB or a message credit limit of more than 4 billion.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Resolved] (QPID-3616) Java Broker misinterprets message.flow infinite credit value (0xFFFFFFFF)
[
https://issues.apache.org/jira/browse/QPID-3616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Godfrey resolved QPID-3616.
---
Resolution: Fixed
> Java Broker misinterprets message.flow infinite credit value (0x)
> -
>
> Key: QPID-3616
> URL: https://issues.apache.org/jira/browse/QPID-3616
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: 0.13
>Reporter: Keith Wall
>Priority: Major
>
> The AMQP 0-10 defines 0x as meaning "an infinite amount of credit."
> as the value argument to the message.flow command.
> A bug in the Java Broker (WindowCreditManager) means that this value is
> interpreted literally. The WCM class should be changed to understand the
> special value.
> It also appears that notification logic in WindowCreditManager#restoreCredit
> presently relies on this defect. This must be refactored during this change.
> SubscriptionImpl and Subscription_0_10 appears to contain further workarounds
> in #creditStateChanged() callback methods. These should be reworked too.
> {code}
> if(_state.compareAndSet(State.SUSPENDED, State.ACTIVE))
> {
> _stateListener.stateChange(this, State.SUSPENDED, State.ACTIVE);
> }
> else
> {
> // this is a hack to get round the issue of increasing bytes credit
> _stateListener.stateChange(this, State.ACTIVE, State.ACTIVE);
> }
> {code}
> This defect is unlikely to affect users as 0x gives a bytes credit of
> 4GB or a message credit limit of more than 4 billion.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8318) [Broker-J] [AMQP 0-8/9/9-1] Queue.Purge does not return deleted count
[ https://issues.apache.org/jira/browse/QPID-8318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-8318: -- Status: Reviewable (was: In Progress) > [Broker-J] [AMQP 0-8/9/9-1] Queue.Purge does not return deleted count > - > > Key: QPID-8318 > URL: https://issues.apache.org/jira/browse/QPID-8318 > Project: Qpid > Issue Type: Improvement > Components: Broker-J > Reporter: Rob Godfrey > Assignee: Rob Godfrey >Priority: Major > > As reported in > https://stackoverflow.com/questions/56264607/rabbitmq-java-api-queuepurge-method-called-on-qpid-returns-purgeok-response-wi > Queue.Purge is not correctly returning the number of messages deleted. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8318) [Broker-J] [AMQP 0-8/9/9-1] Queue.Purge does not return deleted count
Rob Godfrey created QPID-8318: - Summary: [Broker-J] [AMQP 0-8/9/9-1] Queue.Purge does not return deleted count Key: QPID-8318 URL: https://issues.apache.org/jira/browse/QPID-8318 Project: Qpid Issue Type: Improvement Components: Broker-J Reporter: Rob Godfrey Assignee: Rob Godfrey As reported in https://stackoverflow.com/questions/56264607/rabbitmq-java-api-queuepurge-method-called-on-qpid-returns-purgeok-response-wi Queue.Purge is not correctly returning the number of messages deleted. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Moved] (QPIDJMS-452) Receiving a large message with a jms polling consumer with timeout of 1 sec can hang when the timeout is reached while message is in transfer.
[ https://issues.apache.org/jira/browse/QPIDJMS-452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey moved QPID-8295 to QPIDJMS-452: --- Affects Version/s: (was: Future) Component/s: (was: Java Common) Workflow: classic default workflow (was: QPid Workflow) Key: QPIDJMS-452 (was: QPID-8295) Project: Qpid JMS (was: Qpid) > Receiving a large message with a jms polling consumer with timeout of 1 sec > can hang when the timeout is reached while message is in transfer. > -- > > Key: QPIDJMS-452 > URL: https://issues.apache.org/jira/browse/QPIDJMS-452 > Project: Qpid JMS > Issue Type: Bug > Environment: Windows >Reporter: Bas >Priority: Major > Labels: test > Attachments: LargeJmsMessageConsumerTest.java > > > Receiving a large message with a polling consumer with timeout of 1 sec can > hang when the timeout is reached while message is in transfer. > Message is not delivered and further polling is discontinued > > Test case included but timing maybe difficult when running on a different > machine. Try chaning the sleep in the test case or increasing the message > size. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8286) [Broker-J] Add operation into priority queue to change message priority
[ https://issues.apache.org/jira/browse/QPID-8286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16793661#comment-16793661 ] Rob Godfrey commented on QPID-8286: --- [~orudyy] is the expectation here that this update to priority would modify the persistent storage of the message (including flowing to/restoring from disk? Also what value would the receiving client see as the message priority - the original or the updated value? > [Broker-J] Add operation into priority queue to change message priority > --- > > Key: QPID-8286 > URL: https://issues.apache.org/jira/browse/QPID-8286 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-8.0.0, qpid-java-broker-7.1.2 > > > The functionality to change message priority is required for some use case > scenarios involving priority queues. At the moment, in order to change the > priority, the messages need to be consumed (for example, using selector > 'JMSMessageID=ID:XYZ') and re-published with a different priority. I > management operation can be introduced on the priority queue which can simply > dequeue the message and re-enqueue it with a provided priority. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
Re: [NOTICE / DISCUSS] migrating Git repositories to gitbox.apache.org
On Mon, 10 Dec 2018 at 17:10, Robbie Gemmell wrote: > Hi Folks, > > Per the below mail sent by the ASF Infrastructure team (to dev@), our Git > repositories will be migrated from the original/old git-wip-us service on > to > the newer gitbox.apache.org service by February 7th. > > This is definitely happening, but we have some say over when/how it does: > 1. Document consensus on list and voluntarily request to move by Jan 9th. > 2. Wait for mandated move between Jan 9th and Feb 6th, coordinate with > infra >to proceed once it has been. > 3. Do nothing, ignore the mandate, and be forcibly moved on Feb 7th. > > I'm in favour of volunteering and doing it sooner than later, so to > that end here is my lazy consensus statement: > > Unless there is discussion here resulting in decision to delay, I will > raise the migration request JIRA with Infra on Thursday 13th Dec, > hopefully allowing completion of the process by the end of this week > if they have bandwidth to do so. > > Robbie > Not that it is required for a lazy consensus, but I am +1 on "sooner" :) -- Rob > > On Fri, 7 Dec 2018 at 16:52, Daniel Gruno wrote: > > > > [NOTICE] Mandatory relocation of Apache git repositories on > git-wip-us.apache.org > > > > > > [IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE > > DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS] > > > > Hello Apache projects, > > > > I am writing to you because you may have git repositories on the > > git-wip-us server, which is slated to be decommissioned in the coming > > months. All repositories will be moved to the new gitbox service which > > includes direct write access on github as well as the standard ASF > > commit access via gitbox.apache.org. > > > > ## Why this move? ## > > The move comes as a result of retiring the git-wip service, as the > > hardware it runs on is longing for retirement. In lieu of this, we > > have decided to consolidate the two services (git-wip and gitbox), to > > ease the management of our repository systems and future-proof the > > underlying hardware. The move is fully automated, and ideally, nothing > > will change in your workflow other than added features and access to > > GitHub. > > > > ## Timeframe for relocation ## > > Initially, we are asking that projects voluntarily request to move > > their repositories to gitbox, hence this email. The voluntary > > timeframe is between now and January 9th 2019, during which projects > > are free to either move over to gitbox or stay put on git-wip. After > > this phase, we will be requiring the remaining projects to move within > > one month, after which we will move the remaining projects over. > > > > To have your project moved in this initial phase, you will need: > > > > - Consensus in the project (documented via the mailing list) > > - File a JIRA ticket with INFRA to voluntarily move your project repos > >over to gitbox (as stated, this is highly automated and will take > >between a minute and an hour, depending on the size and number of > >your repositories) > > > > To sum up the preliminary timeline; > > > > - December 9th 2018 -> January 9th 2019: Voluntary (coordinated) > >relocation > > - January 9th -> February 6th: Mandated (coordinated) relocation > > - February 7th: All remaining repositories are mass migrated. > > > > This timeline may change to accommodate various scenarios. > > > > ## Using GitHub with ASF repositories ## > > When your project has moved, you are free to use either the ASF > > repository system (gitbox.apache.org) OR GitHub for your development > > and code pushes. To be able to use GitHub, please follow the primer > > at: https://reference.apache.org/committer/github > > > > > > We appreciate your understanding of this issue, and hope that your > > project can coordinate voluntarily moving your repositories in a > > timely manner. > > > > All settings, such as commit mail targets, issue linking, PR > > notification schemes etc will automatically be migrated to gitbox as > > well. > > > > With regards, Daniel on behalf of ASF Infra. > > > > PS:For inquiries, please reply to us...@infra.apache.org, not your > > project's dev list :-). > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org > For additional commands, e-mail: dev-h...@qpid.apache.org > >
[jira] [Updated] (QPID-8260) [Broker-J] Add support for provided preferences store into Derby and JDBC system configs
[
https://issues.apache.org/jira/browse/QPID-8260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Godfrey updated QPID-8260:
--
Summary: [Broker-J] Add support for provided preferences store into Derby
and JDBC system configs (was: [Broker-J] Ass support for provided preferences
store into Derby and JDBC system configs)
> [Broker-J] Add support for provided preferences store into Derby and JDBC
> system configs
>
>
> Key: QPID-8260
> URL: https://issues.apache.org/jira/browse/QPID-8260
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0, qpid-java-broker-7.0.7
>
>
> Both Derby and JDBC system configs declare their preference stores as
> provided ones, but, they do not implement the PreferenceStoreProvider
> interface. As result, the creation of provided store fails with an error as
> below:
> {noformat}
> ERROR [Broker-Config] (o.a.q.s.m.AbstractConfiguredObject) - Failed to open
> object with name 'Broker'. Object will be put into ERROR state.
> org.apache.qpid.server.configuration.IllegalConfigurationException: Cannot
> create provided preference store on non PreferenceStoreProvider
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8257) Sybase message store not supporting empty messages
[ https://issues.apache.org/jira/browse/QPID-8257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676633#comment-16676633 ] Rob Godfrey commented on QPID-8257: --- [~alex.rufous] but that is a choice at a higher level of the code... we never pass null into AbstractJDBCMessageStore::addContent (because that would NPE :-) ). I think the safest thing is to confine the change to the Sybase JDBC implementation. Separately we could make the decision about whether to simply omit a content record when there is no content, though that may have other implications. > Sybase message store not supporting empty messages > -- > > Key: QPID-8257 > URL: https://issues.apache.org/jira/browse/QPID-8257 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.3 >Reporter: Olivier VERMEULEN >Priority: Major > > Unlike other databases Sybase default nullability for a column is "NOT NULL". > And since we don't specify anything when creating the QPID_MESSAGE_CONTENT > table, the "content" column defaults to "NOT NULL". > So when we send an empty message, this constraint is broken and we receive a > SybSQLException... -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-8257) Sybase message store not supporting empty messages
[ https://issues.apache.org/jira/browse/QPID-8257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676614#comment-16676614 ] Rob Godfrey edited comment on QPID-8257 at 11/6/18 11:13 AM: - [~overmeulen] The thing is that the column shouldn't need to be nullable, as Alex pointed out, an insert into the content table is only called if there is content (albeit that content may be of zero length). So it's sort of wrong to have all that code in the store for nullable columns when the only reason is because Sybase can't store a 0 length content in an image. As such, although it's a bit hacky, I think "image null" is a more appropriate solution. If I were wanting to make the solution less hacky, I'd probably add a "blob type needs to be nullable" boolean have that false for everything except Sybase and true for Sybase ... though at that point it is essentially an isSybase flag. was (Author: rgodfrey): [~overmeulen] The thing is that the column shouldn't need to be nullable, as Alex pointed out, an insert into the content table is only called if there is content (albeit that content may be of zero length). So it's sort of wrong to have all that code in the store for nullable columns when the only reason is because Sybase can't store a 0 length content in an image. As such, although it's a bit hacky, I think "image null" is a more appropriate solution. > Sybase message store not supporting empty messages > -- > > Key: QPID-8257 > URL: https://issues.apache.org/jira/browse/QPID-8257 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.3 >Reporter: Olivier VERMEULEN >Priority: Major > > Unlike other databases Sybase default nullability for a column is "NOT NULL". > And since we don't specify anything when creating the QPID_MESSAGE_CONTENT > table, the "content" column defaults to "NOT NULL". > So when we send an empty message, this constraint is broken and we receive a > SybSQLException... -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8257) Sybase message store not supporting empty messages
[ https://issues.apache.org/jira/browse/QPID-8257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676614#comment-16676614 ] Rob Godfrey commented on QPID-8257: --- [~overmeulen] The thing is that the column shouldn't need to be nullable, as Alex pointed out, an insert into the content table is only called if there is content (albeit that content may be of zero length). So it's sort of wrong to have all that code in the store for nullable columns when the only reason is because Sybase can't store a 0 length content in an image. As such, although it's a bit hacky, I think "image null" is a more appropriate solution. > Sybase message store not supporting empty messages > -- > > Key: QPID-8257 > URL: https://issues.apache.org/jira/browse/QPID-8257 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.3 >Reporter: Olivier VERMEULEN >Priority: Major > > Unlike other databases Sybase default nullability for a column is "NOT NULL". > And since we don't specify anything when creating the QPID_MESSAGE_CONTENT > table, the "content" column defaults to "NOT NULL". > So when we send an empty message, this constraint is broken and we receive a > SybSQLException... -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8257) Sybase message store not supporting empty messages
[ https://issues.apache.org/jira/browse/QPID-8257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676599#comment-16676599 ] Rob Godfrey commented on QPID-8257: --- [~alex.rufous] IIRC (and this was *years* ago) there were (API?) issues trying to use the Blob type on Sybase that made me use image instead. If the hacky change of just making the type "image null" for Sybase works, I'd be tempted to go with that :) > Sybase message store not supporting empty messages > -- > > Key: QPID-8257 > URL: https://issues.apache.org/jira/browse/QPID-8257 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.3 >Reporter: Olivier VERMEULEN >Priority: Major > > Unlike other databases Sybase default nullability for a column is "NOT NULL". > And since we don't specify anything when creating the QPID_MESSAGE_CONTENT > table, the "content" column defaults to "NOT NULL". > So when we send an empty message, this constraint is broken and we receive a > SybSQLException... -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8257) Sybase message store not supporting empty messages
[ https://issues.apache.org/jira/browse/QPID-8257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676596#comment-16676596 ] Rob Godfrey commented on QPID-8257: --- Looking at this a bit more, would the simplest change of replacing "image" with "image null" for the blobType argument in the constructor for Sybase details inJDBCDetails.java work? > Sybase message store not supporting empty messages > -- > > Key: QPID-8257 > URL: https://issues.apache.org/jira/browse/QPID-8257 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.3 >Reporter: Olivier VERMEULEN >Priority: Major > > Unlike other databases Sybase default nullability for a column is "NOT NULL". > And since we don't specify anything when creating the QPID_MESSAGE_CONTENT > table, the "content" column defaults to "NOT NULL". > So when we send an empty message, this constraint is broken and we receive a > SybSQLException... -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8257) Sybase message store not supporting empty messages
[ https://issues.apache.org/jira/browse/QPID-8257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16676588#comment-16676588 ] Rob Godfrey commented on QPID-8257: --- Alex, Olivier - I guess the probable cause might be that Sybase is interpreting an "image" type with no content as equivalent to a null (i.e. there is no concept of an "empty" image). > Sybase message store not supporting empty messages > -- > > Key: QPID-8257 > URL: https://issues.apache.org/jira/browse/QPID-8257 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.3 >Reporter: Olivier VERMEULEN >Priority: Major > > Unlike other databases Sybase default nullability for a column is "NOT NULL". > And since we don't specify anything when creating the QPID_MESSAGE_CONTENT > table, the "content" column defaults to "NOT NULL". > So when we send an empty message, this constraint is broken and we receive a > SybSQLException... -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8242) [Broker-J] JDBC store should remove message content/metadata asynchronously
[ https://issues.apache.org/jira/browse/QPID-8242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey reassigned QPID-8242: - Assignee: Alex Rudyy (was: Rob Godfrey) > [Broker-J] JDBC store should remove message content/metadata asynchronously > --- > > Key: QPID-8242 > URL: https://issues.apache.org/jira/browse/QPID-8242 > Project: Qpid > Issue Type: Improvement > Components: Broker-J > Reporter: Rob Godfrey >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > Attachments: QPID-8242.patch > > > Currently in the JDBC store the message content is deleted synchronously > after the last reference is removed. There is no need to make this operation > synchronous and the message deletes could be batched. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8242) [Broker-J] JDBC store should remove message content/metadata asynchronously
[ https://issues.apache.org/jira/browse/QPID-8242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-8242: -- Status: Reviewable (was: In Progress) > [Broker-J] JDBC store should remove message content/metadata asynchronously > --- > > Key: QPID-8242 > URL: https://issues.apache.org/jira/browse/QPID-8242 > Project: Qpid > Issue Type: Improvement > Components: Broker-J > Reporter: Rob Godfrey > Assignee: Rob Godfrey >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > Attachments: QPID-8242.patch > > > Currently in the JDBC store the message content is deleted synchronously > after the last reference is removed. There is no need to make this operation > synchronous and the message deletes could be batched. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8242) [Broker-J] JDBC store should remove message content/metadata asynchronously
[ https://issues.apache.org/jira/browse/QPID-8242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey reassigned QPID-8242: - Assignee: Rob Godfrey > [Broker-J] JDBC store should remove message content/metadata asynchronously > --- > > Key: QPID-8242 > URL: https://issues.apache.org/jira/browse/QPID-8242 > Project: Qpid > Issue Type: Improvement > Components: Broker-J > Reporter: Rob Godfrey > Assignee: Rob Godfrey >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > Attachments: QPID-8242.patch > > > Currently in the JDBC store the message content is deleted synchronously > after the last reference is removed. There is no need to make this operation > synchronous and the message deletes could be batched. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8245) [Broker-J] [AMQP 0-8..0-91] Decode FieldTable fields on demand
[ https://issues.apache.org/jira/browse/QPID-8245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16633855#comment-16633855 ] Rob Godfrey commented on QPID-8245: --- [~alex.rufous] Ah - I forgot about that flow to disk feature :-) > [Broker-J] [AMQP 0-8..0-91] Decode FieldTable fields on demand > -- > > Key: QPID-8245 > URL: https://issues.apache.org/jira/browse/QPID-8245 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.0 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > Attachments: > 0001-QPID-8245-Broker-J-Stop-rellocating-message-headers-.patch, > 0002-QPID-8245-Add-factory-methods-to-create-field-table-.patch, > 0003-QPID-8245-Remove-FiledTable-setters-methods-modifyin.patch, > 0004-QPID-8245-Decode-field-table-properties-when-require.patch, > 0005-QPID-8245-Remove-methods-getXXX-in-order-to-simplify.patch, > 0005-QPID-8245-Split-field-table-into-2-implementations.patch, > 0006-QPID-8245-some-code-clean-up.patch, > 0007-QPID-8245-Change-decoding-to-decode-only-value-for-t.patch > > > At the moment all field table properties are decoded when decode > functionality is invoked. For use cases when only some of the field table > properties are queried, the decoding functionality can be changed to stop > decoding on getting the requested property. Potentially, such approach can > improve the performance of routing transient messages when destinations are > bound to the routing exchange using selector filters. As filter expression > contains only some properties, the decoding of message headers can be stopped > on getting all fields specified in selector expression. > The idea is illustrated by Rob Godfrey on > [QPID-8238|https://issues.apache.org/jira/browse/QPID-8238?focusedCommentId=16601936=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16601936] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPID-8245) [Broker-J] [AMQP 0-8..0-91] Decode FieldTable fields on demand
[
https://issues.apache.org/jira/browse/QPID-8245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16633750#comment-16633750
]
Rob Godfrey edited comment on QPID-8245 at 10/1/18 9:18 AM:
[~alex.rufous] Yes - that was my intent, I just also imagined changing the name
to imply that the map was no longer a reference of all the properties, but just
a cache of some of them
One comment on your patch, in FieldTable.java:
{code:java}
QpidByteBuffer dup = _encodedForm.duplicate();
while(dup.hasRemaining())
{
final byte[] bytes = AMQShortString.readAMQShortStringAsBytes(dup);
if(Arrays.equals(keyBytes, bytes))
{
return AMQTypedValue.readFromBuffer(dup);
}
else
{
AMQType type = AMQTypeMap.getType(dup.get());
type.skip(dup);
}
}
{code}
Shouldn't his be
{code:java}
try(QpidByteBuffer dup = _encodedForm.duplicate())
{
while(dup.hasRemaining())
{
final byte[] bytes = AMQShortString.readAMQShortStringAsBytes(dup);
if(Arrays.equals(keyBytes, bytes))
{
return AMQTypedValue.readFromBuffer(dup);
}
else
{
AMQType type = AMQTypeMap.getType(dup.get());
type.skip(dup);
}
}
}
{code}
To stop the duplicate leaking?
was (Author: rgodfrey):
[~alex.rufous] Yes - that was my intent, I just also imagined changing the name
to imply that the map was no longer a reference of all the properties, but just
a cache of some of them
> [Broker-J] [AMQP 0-8..0-91] Decode FieldTable fields on demand
> --
>
> Key: QPID-8245
> URL: https://issues.apache.org/jira/browse/QPID-8245
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
> Attachments:
> 0001-QPID-8245-Broker-J-Stop-rellocating-message-headers-.patch,
> 0002-QPID-8245-Add-factory-methods-to-create-field-table-.patch,
> 0003-QPID-8245-Remove-FiledTable-setters-methods-modifyin.patch,
> 0004-QPID-8245-Decode-field-table-properties-when-require.patch,
> 0005-QPID-8245-Remove-methods-getXXX-in-order-to-simplify.patch,
> 0005-QPID-8245-Split-field-table-into-2-implementations.patch,
> 0006-QPID-8245-some-code-clean-up.patch,
> 0007-QPID-8245-Change-decoding-to-decode-only-value-for-t.patch
>
>
> At the moment all field table properties are decoded when decode
> functionality is invoked. For use cases when only some of the field table
> properties are queried, the decoding functionality can be changed to stop
> decoding on getting the requested property. Potentially, such approach can
> improve the performance of routing transient messages when destinations are
> bound to the routing exchange using selector filters. As filter expression
> contains only some properties, the decoding of message headers can be stopped
> on getting all fields specified in selector expression.
> The idea is illustrated by Rob Godfrey on
> [QPID-8238|https://issues.apache.org/jira/browse/QPID-8238?focusedCommentId=16601936=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16601936]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8245) [Broker-J] [AMQP 0-8..0-91] Decode FieldTable fields on demand
[ https://issues.apache.org/jira/browse/QPID-8245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16633750#comment-16633750 ] Rob Godfrey commented on QPID-8245: --- [~alex.rufous] Yes - that was my intent, I just also imagined changing the name to imply that the map was no longer a reference of all the properties, but just a cache of some of them > [Broker-J] [AMQP 0-8..0-91] Decode FieldTable fields on demand > -- > > Key: QPID-8245 > URL: https://issues.apache.org/jira/browse/QPID-8245 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.0 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > Attachments: > 0001-QPID-8245-Broker-J-Stop-rellocating-message-headers-.patch, > 0002-QPID-8245-Add-factory-methods-to-create-field-table-.patch, > 0003-QPID-8245-Remove-FiledTable-setters-methods-modifyin.patch, > 0004-QPID-8245-Decode-field-table-properties-when-require.patch, > 0005-QPID-8245-Remove-methods-getXXX-in-order-to-simplify.patch, > 0005-QPID-8245-Split-field-table-into-2-implementations.patch, > 0006-QPID-8245-some-code-clean-up.patch, > 0007-QPID-8245-Change-decoding-to-decode-only-value-for-t.patch > > > At the moment all field table properties are decoded when decode > functionality is invoked. For use cases when only some of the field table > properties are queried, the decoding functionality can be changed to stop > decoding on getting the requested property. Potentially, such approach can > improve the performance of routing transient messages when destinations are > bound to the routing exchange using selector filters. As filter expression > contains only some properties, the decoding of message headers can be stopped > on getting all fields specified in selector expression. > The idea is illustrated by Rob Godfrey on > [QPID-8238|https://issues.apache.org/jira/browse/QPID-8238?focusedCommentId=16601936=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16601936] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8245) [Broker-J] [AMQP 0-8..0-91] Decode FiledTable fields on demand
[
https://issues.apache.org/jira/browse/QPID-8245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627756#comment-16627756
]
Rob Godfrey commented on QPID-8245:
---
[~alex.rufous] My assumption is that it will be quicker to "skip" than to
decode a value, and that the only time on the critical path where
get() will ever be called will be on the filtering code, and that
in all other cases (such as converting a message to a different protocol, or
displaying the headers in the console) we can ignore the overhead of completely
re-decoding... so the code would look something like this:
{code}
private static final Object NOT_PRESENT = new Object();
public Object get(String key)
{
Object value = _cached.get(key);
if(value == null)
{
value = findValueForKey(key);
_cached.putIfAbsent(key, value);
}
return value == NOT_PRESENT ? null : value;
}
private Object findValueForKey(key)
{
AMQShortString keyAsShortString = AMQShortString.valueOf(key);
QpidByteBuffer dup = _encodedForm.duplicate();
while(dup.hasRemaining())
{
if(nextKeyEquals(dup, keyAsShortString)
{
AMQTypedValue value = AMQTypedValue.readFromBuffer(slice);
return value.getValue();
}
else
{
skipValue(dup);
}
}
return NOT_PRESENT;
}
{code}
> [Broker-J] [AMQP 0-8..0-91] Decode FiledTable fields on demand
> --
>
> Key: QPID-8245
> URL: https://issues.apache.org/jira/browse/QPID-8245
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
> Attachments:
> 0001-QPID-8245-Broker-J-Stop-rellocating-message-headers-.patch,
> 0002-QPID-8245-Add-factory-methods-to-create-field-table-.patch,
> 0003-QPID-8245-Remove-FiledTable-setters-methods-modifyin.patch,
> 0004-QPID-8245-Decode-field-table-properties-when-require.patch,
> 0005-QPID-8245-Remove-methods-getXXX-in-order-to-simplify.patch,
> 0005-QPID-8245-Split-field-table-into-2-implementations.patch
>
>
> At the moment all field table properties are decoded when decode
> functionality is invoked. For use cases when only some of the field table
> properties are queried, the decoding functionality can be changed to stop
> decoding on getting the requested property. Potentially, such approach can
> improve the performance of routing transient messages when destinations are
> bound to the routing exchange using selector filters. As filter expression
> contains only some properties, the decoding of message headers can be stopped
> on getting all fields specified in selector expression.
> The idea is illustrated by Rob Godfrey on
> [QPID-8238|https://issues.apache.org/jira/browse/QPID-8238?focusedCommentId=16601936=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16601936]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8245) [Broker-J] [AMQP 0-8..0-91] Decode FiledTable fields on demand
[
https://issues.apache.org/jira/browse/QPID-8245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627470#comment-16627470
]
Rob Godfrey commented on QPID-8245:
---
[~alex.rufous] So the majority of the patches aren't that different I think. I
got rid of all the getXXX methods and just kept
{code:java}
public Object get()
{
...
}
{code}
The other thing is I don't think there is any need for two different
implementations in the broker - we only need the version that stores the byte
buffer. When creating a new FieldTable we pass in a map and it is converted to
the binary encoding. In decoding my approach (which I hadn't finished) was
slightly different. I would hold a _properties map, only containing the values
for keys that have been specifically requested. I wouldn't bother keeping a
record of the position I've decoded "up to"... In the case where a message has
150 properties, and a filter on the property that happens to be the 135th...
there's really no point remembering all those other decoded values.
Anyway, I had a quick scan of your patches and they look reasonable
> [Broker-J] [AMQP 0-8..0-91] Decode FiledTable fields on demand
> --
>
> Key: QPID-8245
> URL: https://issues.apache.org/jira/browse/QPID-8245
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.1.0
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
> Attachments:
> 0001-QPID-8245-Broker-J-Stop-rellocating-message-headers-.patch,
> 0002-QPID-8245-Add-factory-methods-to-create-field-table-.patch,
> 0003-QPID-8245-Remove-FiledTable-setters-methods-modifyin.patch,
> 0004-QPID-8245-Decode-field-table-properties-when-require.patch,
> 0005-QPID-8245-Split-field-table-into-2-implementations.patch
>
>
> At the moment all field table properties are decoded when decode
> functionality is invoked. For use cases when only some of the field table
> properties are queried, the decoding functionality can be changed to stop
> decoding on getting the requested property. Potentially, such approach can
> improve the performance of routing transient messages when destinations are
> bound to the routing exchange using selector filters. As filter expression
> contains only some properties, the decoding of message headers can be stopped
> on getting all fields specified in selector expression.
> The idea is illustrated by Rob Godfrey on
> [QPID-8238|https://issues.apache.org/jira/browse/QPID-8238?focusedCommentId=16601936=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16601936]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8242) [Broker-J] JDBC store should remove message content/metadata asynchronously
[ https://issues.apache.org/jira/browse/QPID-8242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-8242: -- Attachment: (was: QPID-8242.patch) > [Broker-J] JDBC store should remove message content/metadata asynchronously > --- > > Key: QPID-8242 > URL: https://issues.apache.org/jira/browse/QPID-8242 > Project: Qpid > Issue Type: Improvement > Components: Broker-J > Reporter: Rob Godfrey >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > Attachments: QPID-8242.patch > > > Currently in the JDBC store the message content is deleted synchronously > after the last reference is removed. There is no need to make this operation > synchronous and the message deletes could be batched. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8242) [Broker-J] JDBC store should remove message content/metadata asynchronously
[ https://issues.apache.org/jira/browse/QPID-8242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-8242: -- Attachment: QPID-8242.patch > [Broker-J] JDBC store should remove message content/metadata asynchronously > --- > > Key: QPID-8242 > URL: https://issues.apache.org/jira/browse/QPID-8242 > Project: Qpid > Issue Type: Improvement > Components: Broker-J > Reporter: Rob Godfrey >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > Attachments: QPID-8242.patch > > > Currently in the JDBC store the message content is deleted synchronously > after the last reference is removed. There is no need to make this operation > synchronous and the message deletes could be batched. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8245) [Broker-J] [AMQP 0-8..0-91] Decode FiledTable fields on demand
[ https://issues.apache.org/jira/browse/QPID-8245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16627149#comment-16627149 ] Rob Godfrey commented on QPID-8245: --- So I started playing around with this before I went on vacation. I don't have that laptop with me at the moment, but I'll try picking it up again in a couple of days when I get home (the other aspect from a performance perspective is that if you decode only on a filter query, you can populate the key with the string from the filter, meaning the filter will do identity comparisons and won't need to actually compare strings for the most part) > [Broker-J] [AMQP 0-8..0-91] Decode FiledTable fields on demand > -- > > Key: QPID-8245 > URL: https://issues.apache.org/jira/browse/QPID-8245 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-7.1.0 >Reporter: Alex Rudyy >Priority: Major > > At the moment all field table properties are decoded when decode > functionality is invoked. For use cases when only some of the field table > properties are queried, the decoding functionality can be changed to stop > decoding on getting the requested property. Potentially, such approach can > improve the performance of routing transient messages when destinations are > bound to the routing exchange using selector filters. As filter expression > contains only some properties, the decoding of message headers can be stopped > on getting all fields specified in selector expression. > The idea is illustrated by Rob Godfrey on > [QPID-8238|https://issues.apache.org/jira/browse/QPID-8238?focusedCommentId=16601936=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-16601936] -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8242) [Broker-J] JDBC store should remove message content/metadata asynchronously
[ https://issues.apache.org/jira/browse/QPID-8242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-8242: -- Attachment: QPID-8242.patch > [Broker-J] JDBC store should remove message content/metadata asynchronously > --- > > Key: QPID-8242 > URL: https://issues.apache.org/jira/browse/QPID-8242 > Project: Qpid > Issue Type: Improvement > Components: Broker-J > Reporter: Rob Godfrey >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > Attachments: QPID-8242.patch > > > Currently in the JDBC store the message content is deleted synchronously > after the last reference is removed. There is no need to make this operation > synchronous and the message deletes could be batched. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8242) [Broker-J] JDBC store should remove message content/metadata asynchronously
[ https://issues.apache.org/jira/browse/QPID-8242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-8242: -- Attachment: (was: QPID-8242.patch) > [Broker-J] JDBC store should remove message content/metadata asynchronously > --- > > Key: QPID-8242 > URL: https://issues.apache.org/jira/browse/QPID-8242 > Project: Qpid > Issue Type: Improvement > Components: Broker-J > Reporter: Rob Godfrey >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > Currently in the JDBC store the message content is deleted synchronously > after the last reference is removed. There is no need to make this operation > synchronous and the message deletes could be batched. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8242) [Broker-J] JDBC store should remove message content/metadata asynchronously
[ https://issues.apache.org/jira/browse/QPID-8242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-8242: -- Attachment: QPID-8242.patch > [Broker-J] JDBC store should remove message content/metadata asynchronously > --- > > Key: QPID-8242 > URL: https://issues.apache.org/jira/browse/QPID-8242 > Project: Qpid > Issue Type: Improvement > Components: Broker-J > Reporter: Rob Godfrey >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > Attachments: QPID-8242.patch > > > Currently in the JDBC store the message content is deleted synchronously > after the last reference is removed. There is no need to make this operation > synchronous and the message deletes could be batched. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8242) [Broker-J] JDBC store should remove message content/metadata asynchronously
[ https://issues.apache.org/jira/browse/QPID-8242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-8242: -- Summary: [Broker-J] JDBC store should remove message content/metadata asynchronously (was: [Broker-J] JDBC store should remove message content/metadata asynchronousle) > [Broker-J] JDBC store should remove message content/metadata asynchronously > --- > > Key: QPID-8242 > URL: https://issues.apache.org/jira/browse/QPID-8242 > Project: Qpid > Issue Type: Improvement > Components: Broker-J > Reporter: Rob Godfrey >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > Currently in the JDBC store the message content is deleted synchronously > after the last reference is removed. There is no need to make this operation > synchronous and the message deletes could be batched. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8242) [Broker-J] JDBC store should remove message content/metadata asynchronousle
Rob Godfrey created QPID-8242: - Summary: [Broker-J] JDBC store should remove message content/metadata asynchronousle Key: QPID-8242 URL: https://issues.apache.org/jira/browse/QPID-8242 Project: Qpid Issue Type: Improvement Components: Broker-J Reporter: Rob Godfrey Fix For: qpid-java-broker-7.1.0 Currently in the JDBC store the message content is deleted synchronously after the last reference is removed. There is no need to make this operation synchronous and the message deletes could be batched. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8241) [Broker-J] Remove use of javax.xml.bind.DatatypeConverter
[ https://issues.apache.org/jira/browse/QPID-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey reassigned QPID-8241: - Assignee: Rob Godfrey > [Broker-J] Remove use of javax.xml.bind.DatatypeConverter > - > > Key: QPID-8241 > URL: https://issues.apache.org/jira/browse/QPID-8241 > Project: Qpid > Issue Type: Improvement > Components: Broker-J > Reporter: Rob Godfrey > Assignee: Rob Godfrey >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > As per [this > comment|https://issues.apache.org/jira/browse/QPID-7885?focusedCommentId=16613383=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16613383] > on QPID-7885, javax.xml.bind.DatatypeConverter is no longer contained in the > default classpath in Java 9. As such we should reimplement all places in the > broker code using this. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8241) [Broker-J] Remove use of javax.xml.bind.DatatypeConverter
[ https://issues.apache.org/jira/browse/QPID-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-8241: -- Status: Reviewable (was: In Progress) > [Broker-J] Remove use of javax.xml.bind.DatatypeConverter > - > > Key: QPID-8241 > URL: https://issues.apache.org/jira/browse/QPID-8241 > Project: Qpid > Issue Type: Improvement > Components: Broker-J > Reporter: Rob Godfrey > Assignee: Rob Godfrey >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > As per [this > comment|https://issues.apache.org/jira/browse/QPID-7885?focusedCommentId=16613383=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16613383] > on QPID-7885, javax.xml.bind.DatatypeConverter is no longer contained in the > default classpath in Java 9. As such we should reimplement all places in the > broker code using this. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8241) [Broker-J] Remove use of javax.xml.bind.DatatypeConverter
[
https://issues.apache.org/jira/browse/QPID-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16619166#comment-16619166
]
Rob Godfrey commented on QPID-8241:
---
Note there are a couple of tests that verify a Date/Time of the form
{{1970-01-02Z}}. As far as I can tell this is neither a valid date nor a valid
datetime ({{1970-01-02}} would be a valid date, {{1970-01-02T00:00:00Z}} would
be a valid datetime).
As the form seems invalid I suggest changing the tests as part of this change.
> [Broker-J] Remove use of javax.xml.bind.DatatypeConverter
> -
>
> Key: QPID-8241
> URL: https://issues.apache.org/jira/browse/QPID-8241
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
> Reporter: Rob Godfrey
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
>
> As per [this
> comment|https://issues.apache.org/jira/browse/QPID-7885?focusedCommentId=16613383=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16613383]
> on QPID-7885, javax.xml.bind.DatatypeConverter is no longer contained in the
> default classpath in Java 9. As such we should reimplement all places in the
> broker code using this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8241) [Broker-J] Remove use of javax.xml.bind.DatatypeConverter
[ https://issues.apache.org/jira/browse/QPID-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-8241: -- Issue Type: Improvement (was: Bug) > [Broker-J] Remove use of javax.xml.bind.DatatypeConverter > - > > Key: QPID-8241 > URL: https://issues.apache.org/jira/browse/QPID-8241 > Project: Qpid > Issue Type: Improvement > Components: Broker-J > Reporter: Rob Godfrey >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > As per [this > comment|https://issues.apache.org/jira/browse/QPID-7885?focusedCommentId=16613383=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16613383] > on QPID-7885, javax.xml.bind.DatatypeConverter is no longer contained in the > default classpath in Java 9. As such we should reimplement all places in the > broker code using this. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8241) [Broker-J] Remove use of javax.xml.bind.DatatypeConverter
[ https://issues.apache.org/jira/browse/QPID-8241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-8241: -- Description: As per [this comment|https://issues.apache.org/jira/browse/QPID-7885?focusedCommentId=16613383=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16613383] on QPID-7885, javax.xml.bind.DatatypeConverter is no longer contained in the default classpath in Java 9. As such we should reimplement all places in the broker code using this. (was: As per this comment on QPID-7885, javax.xml.bind.DatatypeConverter is no longer contained in the default classpath in Java 9. As such we should reimplement all places in the broker code using this.) > [Broker-J] Remove use of javax.xml.bind.DatatypeConverter > - > > Key: QPID-8241 > URL: https://issues.apache.org/jira/browse/QPID-8241 > Project: Qpid > Issue Type: Bug > Components: Broker-J > Reporter: Rob Godfrey >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > As per [this > comment|https://issues.apache.org/jira/browse/QPID-7885?focusedCommentId=16613383=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16613383] > on QPID-7885, javax.xml.bind.DatatypeConverter is no longer contained in the > default classpath in Java 9. As such we should reimplement all places in the > broker code using this. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8241) [Broker-J] Remove use of javax.xml.bind.DatatypeConverter
Rob Godfrey created QPID-8241: - Summary: [Broker-J] Remove use of javax.xml.bind.DatatypeConverter Key: QPID-8241 URL: https://issues.apache.org/jira/browse/QPID-8241 Project: Qpid Issue Type: Bug Components: Broker-J Reporter: Rob Godfrey Fix For: qpid-java-broker-7.1.0 As per this comment on QPID-7885, javax.xml.bind.DatatypeConverter is no longer contained in the default classpath in Java 9. As such we should reimplement all places in the broker code using this. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7885) [Java Broker] Support Java 9
[ https://issues.apache.org/jira/browse/QPID-7885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16614763#comment-16614763 ] Rob Godfrey commented on QPID-7885: --- For this particular issue I wonder if it might not be better to simply remove the use of DatatypeConverter from Broker-J. It was originally only used as a convenient way to get Base64 encoding without requiring an external library I believe. For Java 8 onwards we can use the Base64 class for this. Support of hex printing for binaries is trivial. The only other place it is used seems to be in the parsing / printing of Dates - and I would hope we could do this without resorting to a class that is really intended for xml data binding. > [Java Broker] Support Java 9 > > > Key: QPID-7885 > URL: https://issues.apache.org/jira/browse/QPID-7885 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Lorenz Quack >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > With the Java 9 on the horizon it is time to get Qpid's Java components ready. > * make sure component compile with JDK9 > * make sure components run with JRE9 > * take advantage of the new Java Module System -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8238) [Broker-J] Improve performance of asynchronous publishing of transient messages into topic exchange having queues bound using non-overlapping selectors
[ https://issues.apache.org/jira/browse/QPID-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16601990#comment-16601990 ] Rob Godfrey commented on QPID-8238: --- [~alex.rufous] that's interesting. I'll maybe play with my patch a bit more anyway, it's really just a superset of your change I think. Mainly once I started looking at it, I just hated the fact that the FieldTable is mutable in the broker, and the class has a lot of methods that don't really need to exist > [Broker-J] Improve performance of asynchronous publishing of transient > messages into topic exchange having queues bound using non-overlapping > selectors > > > Key: QPID-8238 > URL: https://issues.apache.org/jira/browse/QPID-8238 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.6 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > Attachments: > 0001-QPID-8238-Use-java.lang.String-for-keys-and-values-i.patch > > > The performance of asynchronous publishing of transient messages into topic > exchange which routes messages into queues bound using non-overlapping > selectors is 2-3 times slower than performance of 0.32 broker. The > performance degradation is observed with AMQP 0.9, though, I suspect that the > AMQP 0-10 protocol could be affected as well. > I was running tests with 10 concurrent producers publishing messages on > separate connections using the same routing key into 10 different queues > (subscribers queues) bound to the exchange using non-overlapping selectors. > My testing showed that performance of 7.0 broker for this particular use case > was 2-3 times worse than performance of 0.32 broker. > The following factors contributed to degradation of performance: > • Copying data from direct memory into heap memory whilst decoding > message headers. Due to this factor, the decoding of message headers is > around twice slower. It seems it contributes around 70% to total performance > degradation > • The message routing algorithm is slower due to need to support a new > feature to route messages into bound exchanges (in addition to queues) using > replacement routing key. > • AMQ short strings caching contributes 5-10% to total performance > degradation. The caching was added to manage heap space more efficiently. > The numbers provided here could be inaccurate due instrumentation overhead > whilst profiling the issue. > Potentially, caching can be turned off but that will not improve performance > much. > On other hand, adding of additional caching of strings to amqp-short-strings > would improve the performance a bit. Whilst evaluating selectors, the fields > used in selector expressions are represented as java strings but they get > converted every time into amqp-short-strings when looking up for message > header values. If 10 queues are bound to the exchange using the same binding > key, the selector expression is evaluated 10 times for the incoming message. > Thus, all selector field names are get converted into amqp-short-strings 10 > times as well. It seems adding caching here can improve the performance. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8238) [Broker-J] Improve performance of asynchronous publishing of transient messages into topic exchange having queues bound using non-overlapping selectors
[
https://issues.apache.org/jira/browse/QPID-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16601936#comment-16601936
]
Rob Godfrey commented on QPID-8238:
---
[~alex.rufous] Did you test the performance after your patch? I started
looking at the same sort of change, but then also expanded it because for the
broker the FieldTable really doesn't need to be mutable... and then I was
looking at maybe only decoding fields that were actually queried (the advantage
there being you could potentially skip decoding fields that were never looked
at, and you could also actually avoid creating a String instance, e.g.
something like this massively simplified pseudo code:
{code:java}
Object get(String key)
{
Object value = _map.get(key);
if(value == null && !_map.containsKey(key))
{
byte[] bytesKey = getUTF8Value(key);
value = getValueForKey(bytesKey);
_map.put(key, value);
}
return value;
}
{code}
> [Broker-J] Improve performance of asynchronous publishing of transient
> messages into topic exchange having queues bound using non-overlapping
> selectors
>
>
> Key: QPID-8238
> URL: https://issues.apache.org/jira/browse/QPID-8238
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
> Attachments:
> 0001-QPID-8238-Use-java.lang.String-for-keys-and-values-i.patch
>
>
> The performance of asynchronous publishing of transient messages into topic
> exchange which routes messages into queues bound using non-overlapping
> selectors is 2-3 times slower than performance of 0.32 broker. The
> performance degradation is observed with AMQP 0.9, though, I suspect that the
> AMQP 0-10 protocol could be affected as well.
> I was running tests with 10 concurrent producers publishing messages on
> separate connections using the same routing key into 10 different queues
> (subscribers queues) bound to the exchange using non-overlapping selectors.
> My testing showed that performance of 7.0 broker for this particular use case
> was 2-3 times worse than performance of 0.32 broker.
> The following factors contributed to degradation of performance:
> • Copying data from direct memory into heap memory whilst decoding
> message headers. Due to this factor, the decoding of message headers is
> around twice slower. It seems it contributes around 70% to total performance
> degradation
> • The message routing algorithm is slower due to need to support a new
> feature to route messages into bound exchanges (in addition to queues) using
> replacement routing key.
> • AMQ short strings caching contributes 5-10% to total performance
> degradation. The caching was added to manage heap space more efficiently.
> The numbers provided here could be inaccurate due instrumentation overhead
> whilst profiling the issue.
> Potentially, caching can be turned off but that will not improve performance
> much.
> On other hand, adding of additional caching of strings to amqp-short-strings
> would improve the performance a bit. Whilst evaluating selectors, the fields
> used in selector expressions are represented as java strings but they get
> converted every time into amqp-short-strings when looking up for message
> header values. If 10 queues are bound to the exchange using the same binding
> key, the selector expression is evaluated 10 times for the incoming message.
> Thus, all selector field names are get converted into amqp-short-strings 10
> times as well. It seems adding caching here can improve the performance.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8238) [Broker-J] Improve performance of asynchronous publishing of transient messages into topic exchange having queues bound using non-overlapping selectors
[ https://issues.apache.org/jira/browse/QPID-8238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16598564#comment-16598564 ] Rob Godfrey commented on QPID-8238: --- In terms of the AMQShortString -> String conversions - would it not make more sense to perhaps look at using java.lang.String values as the keys / values in the FieldTable. It would be interesting perhaps to compare 0-10 performance which uses String and not some other type. > [Broker-J] Improve performance of asynchronous publishing of transient > messages into topic exchange having queues bound using non-overlapping > selectors > > > Key: QPID-8238 > URL: https://issues.apache.org/jira/browse/QPID-8238 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.6 >Reporter: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > The performance of asynchronous publishing of transient messages into topic > exchange which routes messages into queues bound using non-overlapping > selectors is 2-3 times slower than performance of 0.32 broker. The > performance degradation is observed with AMQP 0.9, though, I suspect that the > AMQP 0-10 protocol could be affected as well. > I was running tests with 10 concurrent producers publishing messages on > separate connections using the same routing key into 10 different queues > (subscribers queues) bound to the exchange using non-overlapping selectors. > My testing showed that performance of 7.0 broker for this particular use case > was 2-3 times worse than performance of 0.32 broker. > The following factors contributed to degradation of performance: > • Copying data from direct memory into heap memory whilst decoding > message headers. Due to this factor, the decoding of message headers is > around twice slower. It seems it contributes around 70% to total performance > degradation > • The message routing algorithm is slower due to need to support a new > feature to route messages into bound exchanges (in addition to queues) using > replacement routing key. > • AMQ short strings caching contributes 5-10% to total performance > degradation. The caching was added to manage heap space more efficiently. > The numbers provided here could be inaccurate due instrumentation overhead > whilst profiling the issue. > Potentially, caching can be turned off but that will not improve performance > much. > On other hand, adding of additional caching of strings to amqp-short-strings > would improve the performance a bit. Whilst evaluating selectors, the fields > used in selector expressions are represented as java strings but they get > converted every time into amqp-short-strings when looking up for message > header values. If 10 queues are bound to the exchange using the same binding > key, the selector expression is evaluated 10 times for the incoming message. > Thus, all selector field names are get converted into amqp-short-strings 10 > times as well. It seems adding caching here can improve the performance. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1917) [proton-c] the c++ proton consumer with retry should continue to retry if virtual host not active
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16593394#comment-16593394
]
Rob Godfrey commented on PROTON-1917:
-
So - I cleaned and rebuilt the broker at the end of last week, just in case I
had given you a bad build somehow (before I noticed you had actually described
a different error). Can you re-download from the other JIRA and try again...
there should literally be no way that the (rebuilt) broker could generate the
amqp:not-found "Virtual host 'localhost' is not active" error.
> [proton-c] the c++ proton consumer with retry should continue to retry if
> virtual host not active
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string , const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container ) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message )
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // Can be used for throttling
> // std::this_thread::sleep_for(std::chrono::milliseconds(100));
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().close();
>}
>void on_transport_error(proton::transport& error) override {
> std::cout << "receive_with_retry: on_transport_error: " <<
> error.error().what() << std::endl;
> error.connection().close();
>}
>void on_error(const proton::error_condition& error) override {
> std::cout << "receive_with_retry: on_error: " << error.what() <<
> std::endl;
>}
> };
> void receiveWithRetry(const std::string& url, const std::string& queueName){
>try {
> std::cout << "main: start" << std::endl;
> receive_with_retry receiveWithRetry(url, queueName);
> proton::container(receive
[jira] [Commented] (PROTON-1917) [proton-c] the c++ proton consumer with retry should continue to retry if virtual host not active
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16590741#comment-16590741
]
Rob Godfrey commented on PROTON-1917:
-
Hmmm... that's a different error - it's reporting you are requesting a hostname
that isn't known, rather than a host which resolves to a virtual host which is
still recovering after restart. Do you have a virtual host that should resolve
to 'lahad01'?
-- Rob
> [proton-c] the c++ proton consumer with retry should continue to retry if
> virtual host not active
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string , const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container ) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message )
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // Can be used for throttling
> // std::this_thread::sleep_for(std::chrono::milliseconds(100));
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().close();
>}
>void on_transport_error(proton::transport& error) override {
> std::cout << "receive_with_retry: on_transport_error: " <<
> error.error().what() << std::endl;
> error.connection().close();
>}
>void on_error(const proton::error_condition& error) override {
> std::cout << "receive_with_retry: on_error: " << error.what() <<
> std::endl;
>}
> };
> void receiveWithRetry(const std::string& url, const std::string& queueName){
>try {
> std::cout << "main: start" << std::endl;
> receive_with_retry receiveWithRetry(url, queueName);
> proton::container(receiveWithRetry).run();
> std::cout << "main: end" << std::endl;
>}
>catch (const std::exception& cause) {
> std::cout <&l
[jira] [Updated] (QPID-8233) [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet active should use connection-forced error
[ https://issues.apache.org/jira/browse/QPID-8233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-8233: -- Attachment: apache-qpid-broker-j-7.0.3-bin.zip > [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet > active should use connection-forced error > --- > > Key: QPID-8233 > URL: https://issues.apache.org/jira/browse/QPID-8233 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2, > qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4, > qpid-java-broker-7.0.5, qpid-java-broker-7.0.6 >Reporter: Rob Godfrey >Priority: Major > Fix For: qpid-java-broker-7.0.7 > > Attachments: QPID-8233.diff, apache-qpid-broker-j-7.0.3-bin.zip > > > Currently if a connection is made to a broker where a virtual host is in the > process of activating, the client received a "not-found" error with a > description "virtual host is not active". A client receiving this would not > expect that simply retrying is likely to lead to success. > Instead of sending "not-found" the broker should send "connection-forced" > which, while still inaccurate, at least indicates that the client should retry -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8233) [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet active should use connection-forced error
[ https://issues.apache.org/jira/browse/QPID-8233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-8233: -- Attachment: (was: apache-qpid-broker-j-7.0.3-bin.zip) > [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet > active should use connection-forced error > --- > > Key: QPID-8233 > URL: https://issues.apache.org/jira/browse/QPID-8233 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.3, qpid-java-broker-7.0.2, > qpid-java-broker-7.0.0, qpid-java-broker-7.0.1, qpid-java-broker-7.0.4, > qpid-java-broker-7.0.5, qpid-java-broker-7.0.6 >Reporter: Rob Godfrey >Priority: Major > Fix For: qpid-java-broker-7.0.7 > > Attachments: QPID-8233.diff > > > Currently if a connection is made to a broker where a virtual host is in the > process of activating, the client received a "not-found" error with a > description "virtual host is not active". A client receiving this would not > expect that simply retrying is likely to lead to success. > Instead of sending "not-found" the broker should send "connection-forced" > which, while still inaccurate, at least indicates that the client should retry -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8234) [Broker-J] Return amqp error "amqp:connection:forced" on opening connections to non-existing or not-active virtual hosts
[
https://issues.apache.org/jira/browse/QPID-8234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16590059#comment-16590059
]
Rob Godfrey commented on QPID-8234:
---
I think this duplicates QPID-8233 :)
> [Broker-J] Return amqp error "amqp:connection:forced" on opening connections
> to non-existing or not-active virtual hosts
>
>
> Key: QPID-8234
> URL: https://issues.apache.org/jira/browse/QPID-8234
> Project: Qpid
> Issue Type: Bug
>Affects Versions: qpid-java-broker-7.0.6
>Reporter: Alex Rudyy
>Priority: Major
>
> On attempt to open connection to non-existing or not available virtual host,
> it would be better to use {{amqp:connection:forced}} error conditions rather
> than {{amqp:not-found}}
> As per spec {{amqp:connection:forced}} is defined as {quote} An operator
> intervened to close the connection for some reason. The client could retry at
> some later date.{quote}. It allows retrying whilst {{amqp:not-found}} can be
> interpreted on the client to stop reconnecting.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8235) [Broker-J] Broker should delay opening/closing connections to virtual hosts which are still activating
Rob Godfrey created QPID-8235: - Summary: [Broker-J] Broker should delay opening/closing connections to virtual hosts which are still activating Key: QPID-8235 URL: https://issues.apache.org/jira/browse/QPID-8235 Project: Qpid Issue Type: Bug Reporter: Rob Godfrey Currently when a client attempts to connect to a virtual host which is still activating then the connection is immediately closed. Instead the broker should distinguish between hosts which are in the process of activating, and those that are in a more long term non-active state. Where the virtualhost is still activating, the broker should not immediately respond, but instead defer any further action until the activation has completed. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8233) [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet active should use connection-forced error
[ https://issues.apache.org/jira/browse/QPID-8233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16590049#comment-16590049 ] Rob Godfrey commented on QPID-8233: --- Attached are a patch and a full build of Broker-J 7.0.3 with this patch applied to see if this approach solves the problem detailed in PROTON-1917 > [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet > active should use connection-forced error > --- > > Key: QPID-8233 > URL: https://issues.apache.org/jira/browse/QPID-8233 > Project: Qpid > Issue Type: Bug > Components: Broker-J > Reporter: Rob Godfrey >Priority: Major > Attachments: QPID-8233.diff, apache-qpid-broker-j-7.0.3-bin.zip > > > Currently if a connection is made to a broker where a virtual host is in the > process of activating, the client received a "not-found" error with a > description "virtual host is not active". A client receiving this would not > expect that simply retrying is likely to lead to success. > Instead of sending "not-found" the broker should send "connection-forced" > which, while still inaccurate, at least indicates that the client should retry -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8233) [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet active should use connection-forced error
[ https://issues.apache.org/jira/browse/QPID-8233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-8233: -- Attachment: apache-qpid-broker-j-7.0.3-bin.zip > [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet > active should use connection-forced error > --- > > Key: QPID-8233 > URL: https://issues.apache.org/jira/browse/QPID-8233 > Project: Qpid > Issue Type: Bug > Components: Broker-J > Reporter: Rob Godfrey >Priority: Major > Attachments: QPID-8233.diff, apache-qpid-broker-j-7.0.3-bin.zip > > > Currently if a connection is made to a broker where a virtual host is in the > process of activating, the client received a "not-found" error with a > description "virtual host is not active". A client receiving this would not > expect that simply retrying is likely to lead to success. > Instead of sending "not-found" the broker should send "connection-forced" > which, while still inaccurate, at least indicates that the client should retry -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8233) [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet active should use connection-forced error
[ https://issues.apache.org/jira/browse/QPID-8233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-8233: -- Attachment: QPID-8233.diff > [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet > active should use connection-forced error > --- > > Key: QPID-8233 > URL: https://issues.apache.org/jira/browse/QPID-8233 > Project: Qpid > Issue Type: Bug > Components: Broker-J > Reporter: Rob Godfrey >Priority: Major > Attachments: QPID-8233.diff > > > Currently if a connection is made to a broker where a virtual host is in the > process of activating, the client received a "not-found" error with a > description "virtual host is not active". A client receiving this would not > expect that simply retrying is likely to lead to success. > Instead of sending "not-found" the broker should send "connection-forced" > which, while still inaccurate, at least indicates that the client should retry -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1917) [proton-c] the c++ proton consumer with retry should continue to retry if virtual host not active
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16590045#comment-16590045
]
Rob Godfrey commented on PROTON-1917:
-
I have created QPID-8233 for the Broker-J change, and I will post on that a
proposed fix which [~jeremy.aouad] may wish to try
> [proton-c] the c++ proton consumer with retry should continue to retry if
> virtual host not active
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string , const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container ) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message )
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // Can be used for throttling
> // std::this_thread::sleep_for(std::chrono::milliseconds(100));
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().close();
>}
>void on_transport_error(proton::transport& error) override {
> std::cout << "receive_with_retry: on_transport_error: " <<
> error.error().what() << std::endl;
> error.connection().close();
>}
>void on_error(const proton::error_condition& error) override {
> std::cout << "receive_with_retry: on_error: " << error.what() <<
> std::endl;
>}
> };
> void receiveWithRetry(const std::string& url, const std::string& queueName){
>try {
> std::cout << "main: start" << std::endl;
> receive_with_retry receiveWithRetry(url, queueName);
> proton::container(receiveWithRetry).run();
> std::cout << "main: end" << std::endl;
>}
>catch (const std::exception& cause) {
> std::cout << "main: caught exception: " << cause.what() << std::endl;
>}
> }
> int main() {
>try {
> receiveWithRetry("amqp://localhost:5673", "test_queue");
> return 0;
>}
>catch (const std::exception& e) {
> std::cerr << e.what() << std::endl;
>}
>return 1;
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8233) [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet active should use connection-forced error
Rob Godfrey created QPID-8233: - Summary: [Broker-J][AMQP 1.0] Failure on connecting to a virtual host which is not yet active should use connection-forced error Key: QPID-8233 URL: https://issues.apache.org/jira/browse/QPID-8233 Project: Qpid Issue Type: Bug Components: Broker-J Reporter: Rob Godfrey Currently if a connection is made to a broker where a virtual host is in the process of activating, the client received a "not-found" error with a description "virtual host is not active". A client receiving this would not expect that simply retrying is likely to lead to success. Instead of sending "not-found" the broker should send "connection-forced" which, while still inaccurate, at least indicates that the client should retry -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1917) [proton-c] the c++ proton consumer with retry should continue to retry if virtual host not active
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16590026#comment-16590026
]
Rob Godfrey commented on PROTON-1917:
-
[~jeremy.aouad] Which version of Broker-J are you using? I think the most
pragmatic change would be to have Broker-J return "connection-forced" rather
than "not-found", this would be a one line change in Broker-J and maybe
[~alex.rufous] can bundle that change into a patch release if you are using a
relatively recent version.
Ultimately I would like to change the behaviour of Broker-J so that it waits
until it has attempted to activate the virtual host before it responds to the
open request, but that is a bigger change
> [proton-c] the c++ proton consumer with retry should continue to retry if
> virtual host not active
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string , const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container ) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message )
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // Can be used for throttling
> // std::this_thread::sleep_for(std::chrono::milliseconds(100));
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().close();
>}
>void on_transport_error(proton::transport& error) override {
> std::cout << "receive_with_retry: on_transport_error: " <<
> error.error().what() << std::endl;
> error.connection().close();
>}
>void on_error(const proton::error_condition& error) override {
> std::cout << "receive_with_retry: on_error: " << error.what() <<
> std::endl;
>}
> };
> void receiveWithRetry(const std::string& url, const std::string& queueName){
>try {
> std::cout << "main: start" << s
[jira] [Commented] (PROTON-1917) [proton-c] the c++ proton consumer with retry should continue to retry if virtual host not active
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16589996#comment-16589996
]
Rob Godfrey commented on PROTON-1917:
-
[~gemmellr] Do you know how the JMS client will behave in this situation?
> [proton-c] the c++ proton consumer with retry should continue to retry if
> virtual host not active
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string , const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container ) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message )
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // Can be used for throttling
> // std::this_thread::sleep_for(std::chrono::milliseconds(100));
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().close();
>}
>void on_transport_error(proton::transport& error) override {
> std::cout << "receive_with_retry: on_transport_error: " <<
> error.error().what() << std::endl;
> error.connection().close();
>}
>void on_error(const proton::error_condition& error) override {
> std::cout << "receive_with_retry: on_error: " << error.what() <<
> std::endl;
>}
> };
> void receiveWithRetry(const std::string& url, const std::string& queueName){
>try {
> std::cout << "main: start" << std::endl;
> receive_with_retry receiveWithRetry(url, queueName);
> proton::container(receiveWithRetry).run();
> std::cout << "main: end" << std::endl;
>}
>catch (const std::exception& cause) {
> std::cout << "main: caught exception: " << cause.what() << std::endl;
>}
> }
> int main() {
>try {
> receiveWithRetry("amqp://localhost:5673", "test_queue");
> return 0;
>}
>catch (const std::exception& e) {
> std::cerr << e.what() << std::endl;
>}
>return 1;
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-1917) [proton-c] the c++ proton consumer with retry should continue to retry if virtual host not active
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16589977#comment-16589977
]
Rob Godfrey edited comment on PROTON-1917 at 8/23/18 9:48 AM:
--
I'm still not totally convinced that this is really Proton's fault, other than
via a knowledge of the description string which is specific to Broker-J it
can't know that it should retry on this error.
I think Broker-J would be better using a different error condition. Rather
than amqp:not-found, it would perhaps be better for it to use
amqp:connection:forced which is defined as "An operator intervened to close the
connection for some reason. The client could retry at some later date." which
explicitly allows for retrying, even though it's not quite what is happening.
I don't know if proton would continue retrying in this case.
was (Author: rgodfrey):
I'm still not totally convinced that this is really Proton's fault, other than
via a knowledge of the description string which is specific to Broker-J it
can't know that it should retry on this error.
I think Broker-J would be better using a different error condition. Rather
than amqp:not-found, it would perhaps be better for it to use
amqp:connection:forced which is defined as "An operator intervened to close the
connection for some reason. The client could retry at some later date." which
explicit allows for retrying, even though it's not quite what is happening. I
don't know if proton would continue retrying in this case.
> [proton-c] the c++ proton consumer with retry should continue to retry if
> virtual host not active
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string , const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container ) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message )
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // Can be used for throttling
> // std::this_thread::sleep_for(std::chrono::milliseconds(100));
> //
[jira] [Commented] (PROTON-1917) [proton-c] the c++ proton consumer with retry should continue to retry if virtual host not active
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16589977#comment-16589977
]
Rob Godfrey commented on PROTON-1917:
-
I'm still not totally convinced that this is really Proton's fault, other than
via a knowledge of the description string which is specific to Broker-J it
can't know that it should retry on this error.
I think Broker-J would be better using a different error condition. Rather
than amqp:not-found, it would perhaps be better for it to use
amqp:connection:forced which is defined as "An operator intervened to close the
connection for some reason. The client could retry at some later date." which
explicit allows for retrying, even though it's not quite what is happening. I
don't know if proton would continue retrying in this case.
> [proton-c] the c++ proton consumer with retry should continue to retry if
> virtual host not active
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string , const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container ) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message )
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // Can be used for throttling
> // std::this_thread::sleep_for(std::chrono::milliseconds(100));
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().close();
>}
>void on_transport_error(proton::transport& error) override {
> std::cout << "receive_with_retry: on_transport_error: " <<
> error.error().what() << std::endl;
> error.connection().close();
>}
>void on_error(const proton::error_condition& error) override {
> std::cout << "receive_with_retry: on_error: " << error.what() <<
> std::endl;
>}
> };
> void receiveWithRetry(const std::string& url, const std::st
[jira] [Updated] (PROTON-1917) [proton-c] the c++ proton consumer with retry should continue to retry if virtual host not active
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Godfrey updated PROTON-1917:
Summary: [proton-c] the c++ proton consumer with retry should continue to
retry if virtual host not active (was: [proton-c] When qpid broker is killed
and started, the c++ proton consumer (with retry) is randomly exiting with an
error)
> [proton-c] the c++ proton consumer with retry should continue to retry if
> virtual host not active
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string , const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container ) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message )
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().close();
>}
>void on_transport_error(proton::transport& error) override {
> std::cout << "receive_with_retry: on_transport_error: " <<
> error.error().what() << std::endl;
> error.connection().close();
>}
>void on_error(const proton::error_condition& error) override {
> std::cout << "receive_with_retry: on_error: " << error.what() <<
> std::endl;
>}
> };
> void receiveWithRetry(const std::string& url, const std::string& queueName){
>try {
> std::cout << "main: start" << std::endl;
> receive_with_retry receiveWithRetry(url, queueName);
> proton::container(receiveWithRetry).run();
> std::cout << "main: end" << std::endl;
>}
>catch (const std::exception& cause) {
> std::cout << "main: caught exception: " << cause.what() << std::endl;
>}
> }
> int main() {
>try {
> receiveWithRetry("amqp://localhost:5673", "test_queue");
> return 0;
>}
>catch (const std::exception& e) {
> std::cerr << e.what() << std::endl;
>}
>return 1;
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (PROTON-1917) [proton-c] When qpid broker is killed and started, the c++ proton consumer (with retry) is randomly exiting with an error
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16589937#comment-16589937
]
Rob Godfrey edited comment on PROTON-1917 at 8/23/18 9:09 AM:
--
>From the error message I'm assuming you are using Qpid Broker-J as your
>broker. When Qpid Broker-J starts up, the individual virtualhosts within the
>broker do not all start up immediately, so there is a brief period of time
>where the TCP/IP port for the broker is accepting connections but the
>individual virtual hosts may not yet be available. This behaviour makes more
>sense when you consider the case of HA vritualhosts where the virtual host on
>this particular broker may not be the "active" node cluster and so will not
>become immediately active. As such the "error" is nothing to worry about and
>it should simply continue to retry.
was (Author: rgodfrey):
This is not really a proton issue. From the error message I'm assuming you are
using Qpid Broker-J as your broker. When Qpid Broker-J starts up, the
individual virtualhosts within the broker do not all start up immediately, so
there is a brief period of time where the TCP/IP port for the broker is
accepting connections but the individual virtual hosts may not yet be
available. This behaviour makes more sense when you consider the case of HA
vritualhosts where the virtual host on this particular broker may not be the
"active" node cluster and so will not become immediately active. As such the
"error" is nothing to worry about and you should simply continue to retry.
> [proton-c] When qpid broker is killed and started, the c++ proton consumer
> (with retry) is randomly exiting with an error
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string , const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container ) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message )
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
[jira] [Resolved] (PROTON-1917) [proton-c] When qpid broker is killed and started, the c++ proton consumer (with retry) is randomly exiting with an error
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Godfrey resolved PROTON-1917.
-
Resolution: Not A Problem
> [proton-c] When qpid broker is killed and started, the c++ proton consumer
> (with retry) is randomly exiting with an error
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string , const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container ) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message )
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().close();
>}
>void on_transport_error(proton::transport& error) override {
> std::cout << "receive_with_retry: on_transport_error: " <<
> error.error().what() << std::endl;
> error.connection().close();
>}
>void on_error(const proton::error_condition& error) override {
> std::cout << "receive_with_retry: on_error: " << error.what() <<
> std::endl;
>}
> };
> void receiveWithRetry(const std::string& url, const std::string& queueName){
>try {
> std::cout << "main: start" << std::endl;
> receive_with_retry receiveWithRetry(url, queueName);
> proton::container(receiveWithRetry).run();
> std::cout << "main: end" << std::endl;
>}
>catch (const std::exception& cause) {
> std::cout << "main: caught exception: " << cause.what() << std::endl;
>}
> }
> int main() {
>try {
> receiveWithRetry("amqp://localhost:5673", "test_queue");
> return 0;
>}
>catch (const std::exception& e) {
> std::cerr << e.what() << std::endl;
>}
>return 1;
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Reopened] (PROTON-1917) [proton-c] When qpid broker is killed and started, the c++ proton consumer (with retry) is randomly exiting with an error
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Godfrey reopened PROTON-1917:
-
> [proton-c] When qpid broker is killed and started, the c++ proton consumer
> (with retry) is randomly exiting with an error
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string , const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container ) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message )
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().close();
>}
>void on_transport_error(proton::transport& error) override {
> std::cout << "receive_with_retry: on_transport_error: " <<
> error.error().what() << std::endl;
> error.connection().close();
>}
>void on_error(const proton::error_condition& error) override {
> std::cout << "receive_with_retry: on_error: " << error.what() <<
> std::endl;
>}
> };
> void receiveWithRetry(const std::string& url, const std::string& queueName){
>try {
> std::cout << "main: start" << std::endl;
> receive_with_retry receiveWithRetry(url, queueName);
> proton::container(receiveWithRetry).run();
> std::cout << "main: end" << std::endl;
>}
>catch (const std::exception& cause) {
> std::cout << "main: caught exception: " << cause.what() << std::endl;
>}
> }
> int main() {
>try {
> receiveWithRetry("amqp://localhost:5673", "test_queue");
> return 0;
>}
>catch (const std::exception& e) {
> std::cerr << e.what() << std::endl;
>}
>return 1;
> }
> {code}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (PROTON-1917) [proton-c] When qpid broker is killed and started, the c++ proton consumer (with retry) is randomly exiting with an error
[
https://issues.apache.org/jira/browse/PROTON-1917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16589937#comment-16589937
]
Rob Godfrey commented on PROTON-1917:
-
This is not really a proton issue. From the error message I'm assuming you are
using Qpid Broker-J as your broker. When Qpid Broker-J starts up, the
individual virtualhosts within the broker do not all start up immediately, so
there is a brief period of time where the TCP/IP port for the broker is
accepting connections but the individual virtual hosts may not yet be
available. This behaviour makes more sense when you consider the case of HA
vritualhosts where the virtual host on this particular broker may not be the
"active" node cluster and so will not become immediately active. As such the
"error" is nothing to worry about and you should simply continue to retry.
> [proton-c] When qpid broker is killed and started, the c++ proton consumer
> (with retry) is randomly exiting with an error
> -
>
> Key: PROTON-1917
> URL: https://issues.apache.org/jira/browse/PROTON-1917
> Project: Qpid Proton
> Issue Type: Bug
> Components: cpp-binding
>Affects Versions: proton-c-0.22.0
>Reporter: Jeremy
>Priority: Major
>
> I have a running broker, and a configured queue containing messages.
> I also have a consumer, where I configured the max number of attempts to 0
> (infinite retry).
> I kill the broker (ctrl-c) and start it on the same port.
> Upon reconnection, I get the following error message randomly:
> {code:java}
> receive_with_retry on_connection_open
> receive_with_retry: on_error: amqp:not-found: Virtual host 'localhost' is not
> active
> main: end{code}
> In the case where the consumer is able to connect, the consumer continues to
> consume the messages normally.
> However, in the broker web interface, I see upon each re-connection, an extra
> connection (same ip and port) to the queue. As if, the old connection is not
> killed. I wasn't expecting this behavior. This might be a separate issue.
> I was able to reproduce with the following code, on windows 7 (msvc 12 2013)
> {code:java}
> class receive_with_retry : public proton::messaging_handler {
> private:
>std::string url;
>std::string queueName;
> public:
>receive_with_retry(const std::string , const std::string& q) : url(u),
> queueName(q) {}
>void on_container_start(proton::container ) override {
> std::cout << "receive_with_retry on_container_start" << std::endl;
> c.connect(
> url,
> proton::connection_options()
> .idle_timeout(proton::duration(2000))
> .reconnect(proton::reconnect_options()
> .max_attempts(0)
> .delay(proton::duration(3000))
> .delay_multiplier(1)
> .max_delay(proton::duration(3001;
>}
>void on_connection_open(proton::connection& c) override {
> std::cout << "receive_with_retry on_connection_open " << std::endl;
> c.open_receiver(queueName,
> proton::receiver_options().auto_accept(false));
>}
>void on_session_open(proton::session& session) override {
> std::cout << "receive_with_retry on_session_open " << std::endl;
>}
>void on_receiver_open(proton::receiver& receiver) override {
> std::cout << "receive_with_retry on_receiver_open " << std::endl;
> receiver.open();
>}
>void on_message(proton::delivery& delivery, proton::message )
> override {
> std::cout << "receive_with_retry on_message " << message.body() <<
> std::endl;
> // commented out in order not to exit immediately, but continue on
> consuming the messages.
> // delivery.receiver().close();
> // delivery.receiver().connection().close();
>}
>void on_transport_error(proton::transport& error) override {
> std::cout << "receive_with_retry: on_transport_error: " <<
> error.error().what() << std::endl;
> error.connection().close();
>}
>void on_error(const proton::error_condition& error) override {
> std::cout << "receive_with_retry: on_error: " << error.what() <<
> std::endl;
>}
> };
> void receiveWithRetry(const std::string& url, const std::string& queueN
[jira] [Commented] (QPID-8227) [Broker-J] Replace qpidbrokerversion.properties with jar metadata
[ https://issues.apache.org/jira/browse/QPID-8227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16573425#comment-16573425 ] Rob Godfrey commented on QPID-8227: --- Under what situations would the fallback-version.txt be used? Just wondering if it is really necessary? > [Broker-J] Replace qpidbrokerversion.properties with jar metadata > - > > Key: QPID-8227 > URL: https://issues.apache.org/jira/browse/QPID-8227 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Alex Rudyy >Assignee: Alex Rudyy >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > Historically, the released qpid broker version was stored in file > qpidbrokerversion.properties. jar metadata can be used to get implementation > version information -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8225) [Broker-J][AMQP 0-10] stops delivering queue/consumer messages after 4 GB data transfer
[ https://issues.apache.org/jira/browse/QPID-8225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-8225: -- Attachment: qpid-broker-plugins-amqp-0-10-protocol-7.0.6.jar > [Broker-J][AMQP 0-10] stops delivering queue/consumer messages after 4 GB > data transfer > --- > > Key: QPID-8225 > URL: https://issues.apache.org/jira/browse/QPID-8225 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.6 >Reporter: Michael Dyslin >Priority: Critical > Attachments: protocol.log, > qpid-broker-plugins-amqp-0-10-protocol-7.0.6.jar > > > Created this Jira so I could send a logfile attachment to be analyzed. > Attachments are removed from the user discussion email lists. > > Log file is for the java broker with a NameAndLevel filter of > org.apache.qpid.server.protocol.v0_10.ServerConnection at the DEBUG level. > Activity was: > # Start the java broker > # Start the consumer > # Start the producer > # 2 messages sent every 10 seconds > # Stopped producer after 10 messages sent > # stopped the consumer much later > This log does not contain the problem where message flow stopped, probably > due to CREDIT flow mode exceeding 4 GB credit. > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8225) [Broker-J][AMQP 0-10] stops delivering queue/consumer messages after 4 GB data transfer
[ https://issues.apache.org/jira/browse/QPID-8225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-8225: -- Issue Type: Bug (was: Task) > [Broker-J][AMQP 0-10] stops delivering queue/consumer messages after 4 GB > data transfer > --- > > Key: QPID-8225 > URL: https://issues.apache.org/jira/browse/QPID-8225 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.6 >Reporter: Michael Dyslin >Priority: Minor > Attachments: protocol.log > > > Created this Jira so I could send a logfile attachment to be analyzed. > Attachments are removed from the user discussion email lists. > > Log file is for the java broker with a NameAndLevel filter of > org.apache.qpid.server.protocol.v0_10.ServerConnection at the DEBUG level. > Activity was: > # Start the java broker > # Start the consumer > # Start the producer > # 2 messages sent every 10 seconds > # Stopped producer after 10 messages sent > # stopped the consumer much later > This log does not contain the problem where message flow stopped, probably > due to CREDIT flow mode exceeding 4 GB credit. > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8225) [Broker-J][AMQP 0-10] stops delivering queue/consumer messages after 4 GB data transfer
[ https://issues.apache.org/jira/browse/QPID-8225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-8225: -- Priority: Critical (was: Minor) > [Broker-J][AMQP 0-10] stops delivering queue/consumer messages after 4 GB > data transfer > --- > > Key: QPID-8225 > URL: https://issues.apache.org/jira/browse/QPID-8225 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.6 >Reporter: Michael Dyslin >Priority: Critical > Attachments: protocol.log > > > Created this Jira so I could send a logfile attachment to be analyzed. > Attachments are removed from the user discussion email lists. > > Log file is for the java broker with a NameAndLevel filter of > org.apache.qpid.server.protocol.v0_10.ServerConnection at the DEBUG level. > Activity was: > # Start the java broker > # Start the consumer > # Start the producer > # 2 messages sent every 10 seconds > # Stopped producer after 10 messages sent > # stopped the consumer much later > This log does not contain the problem where message flow stopped, probably > due to CREDIT flow mode exceeding 4 GB credit. > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8225) [Broker-J][AMQP 0-10] stops delivering queue/consumer messages after 4 GB data transfer
[ https://issues.apache.org/jira/browse/QPID-8225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-8225: -- Summary: [Broker-J][AMQP 0-10] stops delivering queue/consumer messages after 4 GB data transfer (was: Java Broker (7.0.6) stops delivering queue/consumer messages after 4 GB data transfer) > [Broker-J][AMQP 0-10] stops delivering queue/consumer messages after 4 GB > data transfer > --- > > Key: QPID-8225 > URL: https://issues.apache.org/jira/browse/QPID-8225 > Project: Qpid > Issue Type: Task > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.6 >Reporter: Michael Dyslin >Priority: Minor > Attachments: protocol.log > > > Created this Jira so I could send a logfile attachment to be analyzed. > Attachments are removed from the user discussion email lists. > > Log file is for the java broker with a NameAndLevel filter of > org.apache.qpid.server.protocol.v0_10.ServerConnection at the DEBUG level. > Activity was: > # Start the java broker > # Start the consumer > # Start the producer > # 2 messages sent every 10 seconds > # Stopped producer after 10 messages sent > # stopped the consumer much later > This log does not contain the problem where message flow stopped, probably > due to CREDIT flow mode exceeding 4 GB credit. > > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-402) Massive performance degradation in 0.34.0
[ https://issues.apache.org/jira/browse/QPIDJMS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16543700#comment-16543700 ] Rob Godfrey commented on QPIDJMS-402: - [~gemmellr] so I've now tried two more Mac laptops. On my 2017 15" MacBook Pro I saw 0.34 being faster than 0.33 (though nowhere near as dramatically as the improvement I saw on Fedora). On my 2013 13" MacBook Pro I see numbers much closer to those from my 2018 12" MacBook (non-Pro) which I shared earlier. Unlike the first laptop, the 2013 13" has active cooling and so is not thermally throttled in "normal" operation, yet I get 11500msg/s on 0.33 and 8800msg/s on 0.34 ... so I think the best we can say is that results on OS X are hardware dependant (all the laptops are running OS X 10.13). > Massive performance degradation in 0.34.0 > - > > Key: QPIDJMS-402 > URL: https://issues.apache.org/jira/browse/QPIDJMS-402 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.34.0 > Environment: Windows 7x64 + Oracle JDK 8u161x64 > Windows 7x64 + Open JDK 8u171x64 > CloudFoundry (Ubuntu Trusty) + Open JDK 8u172x64 >Reporter: Johan Stenberg >Priority: Critical > Attachments: QpidJms402_PerfTest.java, > image-2018-07-13-16-39-19-707.png, qpidjms402.zip > > > This is a followup issue for > [http://qpid.2158936.n2.nabble.com/qpid-jms-Severe-performance-issue-after-upgrading-from-0-33-0-to-0-34-0-td7678052.html] > I am attaching a simple test case that shows the issue. When I use qpid jms > 0.33 I get 2000msg/s send + receive on my local machine. When I switch to > 0.34 the message rate drops to 20msg/s. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-402) Massive performance degradation in 0.34.0
[ https://issues.apache.org/jira/browse/QPIDJMS-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16543213#comment-16543213 ] Rob Godfrey commented on QPIDJMS-402: - Testing on my machines, the machine/operating system certainly seems to influence which version is faster. And on Win 10 I do see *really* poor performance. On my Mac laptop, 0.33.0 was consistently faster: 0.33.0: Sent: 13362 msg/s Received: 13140 msg/s Sent: 13680 msg/s Received: 13513 msg/s Sent: 12571 msg/s Received: 12692 msg/s Sent: 11124 msg/s Received: 11283 msg/s 0.34.0: Sent: 9360 msg/s Received: 9360 msg/s Sent: 9246 msg/s Received: 9246 msg/s Sent: 9975 msg/s Received: 9974 msg/s Sent: 9859 msg/s Received: 9858 msg/s However, on my Dell XPS 15, running Fedora I get 0.33.0: Sent: 52921 msg/s Received: 49663 msg/s Sent: 51995 msg/s Received: 50321 msg/s Sent: 51277 msg/s Received: 48177 msg/s Sent: 51958 msg/s Received: 48534 msg/s 0.34.0: Sent: 72084 msg/s Received: 72077 msg/s Sent: 72134 msg/s Received: 72123 msg/s Sent: 72049 msg/s Received: 72063 msg/s Sent: 70504 msg/s Received: 70497 msg/s Switching over to running Windows 10 on that same Dell XPS 15: 0.33: Sent: 43435 msg/s Received: 43434 msg/s Sent: 41245 msg/s Received: 41246 msg/s Sent: 42785 msg/s Received: 42786 msg/s Sent: 42807 msg/s Received: 42807 msg/s 0.34: Sent: 68 msg/s Received: 68 msg/s Sent: 78 msg/s Received: 71 msg/s Sent: 77 msg/s Received: 68 msg/s Sent: 68 msg/s Received: 73 msg/s > Massive performance degradation in 0.34.0 > - > > Key: QPIDJMS-402 > URL: https://issues.apache.org/jira/browse/QPIDJMS-402 > Project: Qpid JMS > Issue Type: Bug > Components: qpid-jms-client >Affects Versions: 0.34.0 > Environment: Windows 7x64 + Oracle JDK 8u161x64 > Windows 7x64 + Open JDK 8u171x64 > CloudFoundry (Ubuntu Trusty) + Open JDK 8u172x64 >Reporter: Johan Stenberg >Priority: Critical > Attachments: QpidJms402_PerfTest.java, qpidjms402.zip > > > This is a followup issue for > [http://qpid.2158936.n2.nabble.com/qpid-jms-Severe-performance-issue-after-upgrading-from-0-33-0-to-0-34-0-td7678052.html] > I am attaching a simple test case that shows the issue. When I use qpid jms > 0.33 I get 2000msg/s send + receive on my local machine. When I switch to > 0.34 the message rate drops to 20msg/s. > > -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7153) Allow expired messages to be sent to DLQ
[
https://issues.apache.org/jira/browse/QPID-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16533852#comment-16533852
]
Rob Godfrey commented on QPID-7153:
---
{noformat}- q -> !((q instanceof AbstractQueue) && ((AbstractQueue)
q).wouldExpire(node.getMessage(;
+ q -> !((q instanceof Queue) && wouldExpireNow((Queue)q, node.getMessage(;
{noformat}
This seems wrong to me - you are passing a Queue object which does not define
the method to AbstractQueue which is a particular implementation. I think the
prior version is more correct.
> Allow expired messages to be sent to DLQ
>
>
> Key: QPID-7153
> URL: https://issues.apache.org/jira/browse/QPID-7153
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
>Reporter: Keith Wall
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
> Attachments: 0002-QPID-7153-Adress-review-comments.patch,
> QPID-7153v2.diff
>
>
> Currently the Java Broker simply discards messages that expire (TTL). The
> behaviour should be configurable and allow for expired messages to be
> directed to the alternate exchange to allow for dead-lettering.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7153) Allow expired messages to be sent to DLQ
[ https://issues.apache.org/jira/browse/QPID-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16483766#comment-16483766 ] Rob Godfrey commented on QPID-7153: --- Good point on the MAX_VALUE calculation. I did consider a third expiry behaviour "NEVER" which one could use for DLQs (rather than doing the hacky max value thing) but ultimately decided against it. I'll update the patch to address the issue. On the method naming I was thinking of "expire" as in the action of expiring a message rather than the state of the message, but expiresNow is probably less ambiguous. > Allow expired messages to be sent to DLQ > > > Key: QPID-7153 > URL: https://issues.apache.org/jira/browse/QPID-7153 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Priority: Major > Attachments: QPID-7153v2.diff > > > Currently the Java Broker simply discards messages that expire (TTL). The > behaviour should be configurable and allow for expired messages to be > directed to the alternate exchange to allow for dead-lettering. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8193) [Broker-J] Updating maximum / minimum TTL on a queue does not affect messages already in the queue (until restart)
Rob Godfrey created QPID-8193: - Summary: [Broker-J] Updating maximum / minimum TTL on a queue does not affect messages already in the queue (until restart) Key: QPID-8193 URL: https://issues.apache.org/jira/browse/QPID-8193 Project: Qpid Issue Type: Improvement Components: Broker-J Reporter: Rob Godfrey Updating the maximum / minimum TTL on a queue does not change the calculated expiration on queue entries (updateExpiration is only called from doEnqueue). Expiration should be recalculated after minimum/maximum ttl is modified. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7153) Allow expired messages to be sent to DLQ
[ https://issues.apache.org/jira/browse/QPID-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16478856#comment-16478856 ] Rob Godfrey commented on QPID-7153: --- Updated after getting round to actually testing :) Fix the case where the message expires only because a max ttl has been set on the original queue (the message itself has no expiry) and no min/max expiry has been set on the dlq queue. > Allow expired messages to be sent to DLQ > > > Key: QPID-7153 > URL: https://issues.apache.org/jira/browse/QPID-7153 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Priority: Major > Attachments: QPID-7153v2.diff > > > Currently the Java Broker simply discards messages that expire (TTL). The > behaviour should be configurable and allow for expired messages to be > directed to the alternate exchange to allow for dead-lettering. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7153) Allow expired messages to be sent to DLQ
[ https://issues.apache.org/jira/browse/QPID-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-7153: -- Attachment: QPID-7153v2.diff > Allow expired messages to be sent to DLQ > > > Key: QPID-7153 > URL: https://issues.apache.org/jira/browse/QPID-7153 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Priority: Major > Attachments: QPID-7153v2.diff > > > Currently the Java Broker simply discards messages that expire (TTL). The > behaviour should be configurable and allow for expired messages to be > directed to the alternate exchange to allow for dead-lettering. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7153) Allow expired messages to be sent to DLQ
[ https://issues.apache.org/jira/browse/QPID-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-7153: -- Attachment: (was: QPID-7153.diff) > Allow expired messages to be sent to DLQ > > > Key: QPID-7153 > URL: https://issues.apache.org/jira/browse/QPID-7153 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Priority: Major > Attachments: QPID-7153v2.diff > > > Currently the Java Broker simply discards messages that expire (TTL). The > behaviour should be configurable and allow for expired messages to be > directed to the alternate exchange to allow for dead-lettering. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7153) Allow expired messages to be sent to DLQ
[ https://issues.apache.org/jira/browse/QPID-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16477245#comment-16477245 ] Rob Godfrey commented on QPID-7153: --- Attached an untested patch which might provide a way forward for this - following the conversation on the users list - it aims to prevent routing loops by only routing expired messages to queues where they will not immediately be re-expired. > Allow expired messages to be sent to DLQ > > > Key: QPID-7153 > URL: https://issues.apache.org/jira/browse/QPID-7153 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Priority: Major > Attachments: QPID-7153.diff > > > Currently the Java Broker simply discards messages that expire (TLL). The > behaviour should be configurable and allow for expired messages to be > directed to the alternate exchange to allow for dead-lettering. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-7153) Allow expired messages to be sent to DLQ
[ https://issues.apache.org/jira/browse/QPID-7153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Godfrey updated QPID-7153: -- Attachment: QPID-7153.diff > Allow expired messages to be sent to DLQ > > > Key: QPID-7153 > URL: https://issues.apache.org/jira/browse/QPID-7153 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Priority: Major > Attachments: QPID-7153.diff > > > Currently the Java Broker simply discards messages that expire (TLL). The > behaviour should be configurable and allow for expired messages to be > directed to the alternate exchange to allow for dead-lettering. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8178) [Broker-J] [Websocket] Support authentication from bearer token carried by authentication header
[ https://issues.apache.org/jira/browse/QPID-8178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460690#comment-16460690 ] Rob Godfrey commented on QPID-8178: --- For this case, what would you expect the agreed SASL mechanism to be? Logically it is really EXTERNAL - the authentication context is carried external to the SASL exchange. An OAUTH2 provider which offers EXTERNAL should therefore be looking for this token in the websocket transport rather than inspecting any client supplied cert. > [Broker-J] [Websocket] Support authentication from bearer token carried by > authentication header > > > Key: QPID-8178 > URL: https://issues.apache.org/jira/browse/QPID-8178 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Priority: Minor > Fix For: Future > > > Broker-J's AMQP websocket support should be enhanced to accept a bearer token > from the websocket transport. If present and the port is configured to use > an authentication provider that supports the XOAUTH-2 mechanism, the token > should be passed to the authentication provider so it can complete the > authentication process. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPIDJMS-373) Support for OAuth flow and setting of "Authorization" Header for WS upgrade request
[
https://issues.apache.org/jira/browse/QPIDJMS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426828#comment-16426828
]
Rob Godfrey edited comment on QPIDJMS-373 at 4/5/18 12:27 PM:
--
[~gemmellr] Registering a callback would be a nice general purpose enhancement
I think; it seems to me that this might be the only case where a user wants
automatically invoke some action prior to initiating the connection. For
example the issue being discussed here for adding the oauth bearer token into a
"header" prior to establishing the connection over WebSocket could similarly
apply to the case of making an XOAUTH2 TCP connection, where you want to inject
the token into the password of the connection to be returned.
was (Author: rgodfrey):
[~gemmellr] Registering a callback would be a nice general purpose enhancement
I think; it seems to me that this might be the only case where a user wants
automatically invoke some action prior to initiating the connection
> Support for OAuth flow and setting of "Authorization" Header for WS upgrade
> request
> ---
>
> Key: QPIDJMS-373
> URL: https://issues.apache.org/jira/browse/QPIDJMS-373
> Project: Qpid JMS
> Issue Type: New Feature
> Components: qpid-jms-client
>Reporter: Michael Bolz
>Priority: Major
>
> Add support for OAuth flow ("client_credentials" and "password") and setting
> of "Authorization" Header during WebSocket connection handshake.
> Used "Authorization" Header or OAuth settings should/could be set via the
> "transport" parameters (TransportOptions).
>
> As PoC I created a [Fork|https://github.com/mibo/qpid-jms/tree/ws_add_header]
> and have done one commit for the [add of the Authorization
> Header|https://github.com/mibo/qpid-jms/commit/711052f0891556db0da6e7d68908b2f9dafadede]
> and one commit for the [OAuth
> flow|https://github.com/mibo/qpid-jms/commit/de70f0d3e4441358a239b3e776455201c133895d].
>
> Hope this feature is not only interesting for me.
> If yes, I will add the currently missing tests to my contribution and do a
> pull request.
>
> Regards, Michael
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-373) Support for OAuth flow and setting of "Authorization" Header for WS upgrade request
[
https://issues.apache.org/jira/browse/QPIDJMS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16426828#comment-16426828
]
Rob Godfrey commented on QPIDJMS-373:
-
[~gemmellr] Registering a callback would be a nice general purpose enhancement
I think; it seems to me that this might be the only case where a user wants
automatically invoke some action prior to initiating the connection
> Support for OAuth flow and setting of "Authorization" Header for WS upgrade
> request
> ---
>
> Key: QPIDJMS-373
> URL: https://issues.apache.org/jira/browse/QPIDJMS-373
> Project: Qpid JMS
> Issue Type: New Feature
> Components: qpid-jms-client
>Reporter: Michael Bolz
>Priority: Major
>
> Add support for OAuth flow ("client_credentials" and "password") and setting
> of "Authorization" Header during WebSocket connection handshake.
> Used "Authorization" Header or OAuth settings should/could be set via the
> "transport" parameters (TransportOptions).
>
> As PoC I created a [Fork|https://github.com/mibo/qpid-jms/tree/ws_add_header]
> and have done one commit for the [add of the Authorization
> Header|https://github.com/mibo/qpid-jms/commit/711052f0891556db0da6e7d68908b2f9dafadede]
> and one commit for the [OAuth
> flow|https://github.com/mibo/qpid-jms/commit/de70f0d3e4441358a239b3e776455201c133895d].
>
> Hope this feature is not only interesting for me.
> If yes, I will add the currently missing tests to my contribution and do a
> pull request.
>
> Regards, Michael
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-373) Support for OAuth flow and setting of "Authorization" Header for WS upgrade request
[
https://issues.apache.org/jira/browse/QPIDJMS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425990#comment-16425990
]
Rob Godfrey commented on QPIDJMS-373:
-
Is there an advantage to doing this as a new transport rather than writing a
ConnectionFactory or something, whereby the connection factory does the work to
obtain the OAUTH credentials before then calling the underlying factory and
setting the auth header on the ws transport`/
> Support for OAuth flow and setting of "Authorization" Header for WS upgrade
> request
> ---
>
> Key: QPIDJMS-373
> URL: https://issues.apache.org/jira/browse/QPIDJMS-373
> Project: Qpid JMS
> Issue Type: New Feature
> Components: qpid-jms-client
>Reporter: Michael Bolz
>Priority: Major
>
> Add support for OAuth flow ("client_credentials" and "password") and setting
> of "Authorization" Header during WebSocket connection handshake.
> Used "Authorization" Header or OAuth settings should/could be set via the
> "transport" parameters (TransportOptions).
>
> As PoC I created a [Fork|https://github.com/mibo/qpid-jms/tree/ws_add_header]
> and have done one commit for the [add of the Authorization
> Header|https://github.com/mibo/qpid-jms/commit/711052f0891556db0da6e7d68908b2f9dafadede]
> and one commit for the [OAuth
> flow|https://github.com/mibo/qpid-jms/commit/de70f0d3e4441358a239b3e776455201c133895d].
>
> Hope this feature is not only interesting for me.
> If yes, I will add the currently missing tests to my contribution and do a
> pull request.
>
> Regards, Michael
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Comment Edited] (QPIDJMS-373) Support for OAuth flow and setting of "Authorization" Header for WS upgrade request
[
https://issues.apache.org/jira/browse/QPIDJMS-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16425990#comment-16425990
]
Rob Godfrey edited comment on QPIDJMS-373 at 4/4/18 6:36 PM:
-
Is there an advantage to doing this as a new transport rather than writing a
ConnectionFactory or something, whereby the connection factory does the work to
obtain the OAUTH credentials before then calling the underlying factory and
setting the auth header on the ws transport
was (Author: rgodfrey):
Is there an advantage to doing this as a new transport rather than writing a
ConnectionFactory or something, whereby the connection factory does the work to
obtain the OAUTH credentials before then calling the underlying factory and
setting the auth header on the ws transport`/
> Support for OAuth flow and setting of "Authorization" Header for WS upgrade
> request
> ---
>
> Key: QPIDJMS-373
> URL: https://issues.apache.org/jira/browse/QPIDJMS-373
> Project: Qpid JMS
> Issue Type: New Feature
> Components: qpid-jms-client
>Reporter: Michael Bolz
>Priority: Major
>
> Add support for OAuth flow ("client_credentials" and "password") and setting
> of "Authorization" Header during WebSocket connection handshake.
> Used "Authorization" Header or OAuth settings should/could be set via the
> "transport" parameters (TransportOptions).
>
> As PoC I created a [Fork|https://github.com/mibo/qpid-jms/tree/ws_add_header]
> and have done one commit for the [add of the Authorization
> Header|https://github.com/mibo/qpid-jms/commit/711052f0891556db0da6e7d68908b2f9dafadede]
> and one commit for the [OAuth
> flow|https://github.com/mibo/qpid-jms/commit/de70f0d3e4441358a239b3e776455201c133895d].
>
> Hope this feature is not only interesting for me.
> If yes, I will add the currently missing tests to my contribution and do a
> pull request.
>
> Regards, Michael
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8152) [Broker-J][BDB] Virtual host start-up fails with IOException: User limit of inotify instances reached or too many open files
[
https://issues.apache.org/jira/browse/QPID-8152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16424222#comment-16424222
]
Rob Godfrey commented on QPID-8152:
---
I agree with [~k-wall] it would seem better to document than to turn off the
feature. If we were trying to be really kind we could try to identify the
exception when it is thrown and offer guidance in the log/exception message.
> [Broker-J][BDB] Virtual host start-up fails with IOException: User limit of
> inotify instances reached or too many open files
>
>
> Key: QPID-8152
> URL: https://issues.apache.org/jira/browse/QPID-8152
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Affects Versions: qpid-java-broker-7.0.0, qpid-java-broker-7.0.3
>Reporter: Alex Rudyy
>Priority: Minor
>
> Newer versions of BDB JE register {{java.nio.file.WatchService}} to detect
> unexpected deletion of the data files owned by JE.
> In some poorly configured environments the user inotify limit can be breached
> on virtual host/virtual host node start-up. This situation ends-up in
> exception like the one below:
> {noformat}
> Caused by: java.io.IOException: User limit of inotify instances reached or
> too many open files
> at
> sun.nio.fs.LinuxWatchService.(LinuxWatchService.java:64)
> at
> sun.nio.fs.LinuxFileSystem.newWatchService(LinuxFileSystem.java:47)
> at
> com.sleepycat.je.log.FileDeletionDetector.(FileDeletionDetector.java:85)
> ... 29 common frames omitted
> {noformat}
> Though the root of the problem is a poorly configured environment, it would
> be safer to disable file deletion detection watcher by default.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8150) [Broker-J] Prevent test failures due to slow initialisation of hostname resolution in HostnameAliasImpl
[
https://issues.apache.org/jira/browse/QPID-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Godfrey updated QPID-8150:
--
Fix Version/s: qpid-java-broker-7.1.0
> [Broker-J] Prevent test failures due to slow initialisation of hostname
> resolution in HostnameAliasImpl
> ---
>
> Key: QPID-8150
> URL: https://issues.apache.org/jira/browse/QPID-8150
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Reporter: Rob Godfrey
>Assignee: Rob Godfrey
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
>
> On some operating systems / configurations (notably my laptop running OS X :)
> ) the resolution of potential hostnames which resolve to the local machine
> which takes place in {{HostnameAliasImpl}} can take a long time due to
> fruitless lookups. This can cause various system tests to fail.
> To prevent these failures
> # Do not include the hostname virtual host alias where it is not needed in
> the system tests
> # Reorder the list of {{InetAddress}} objects that are iterated over in the
> resolution phase so that addresses more likely to resolve (like the loopback
> interface) are processed first
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8150) [Broker-J] Prevent test failures due to slow initialisation of hostname resolution in HostnameAliasImpl
[
https://issues.apache.org/jira/browse/QPID-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Godfrey reassigned QPID-8150:
-
Assignee: Rob Godfrey
> [Broker-J] Prevent test failures due to slow initialisation of hostname
> resolution in HostnameAliasImpl
> ---
>
> Key: QPID-8150
> URL: https://issues.apache.org/jira/browse/QPID-8150
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Reporter: Rob Godfrey
>Assignee: Rob Godfrey
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
>
> On some operating systems / configurations (notably my laptop running OS X :)
> ) the resolution of potential hostnames which resolve to the local machine
> which takes place in {{HostnameAliasImpl}} can take a long time due to
> fruitless lookups. This can cause various system tests to fail.
> To prevent these failures
> # Do not include the hostname virtual host alias where it is not needed in
> the system tests
> # Reorder the list of {{InetAddress}} objects that are iterated over in the
> resolution phase so that addresses more likely to resolve (like the loopback
> interface) are processed first
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8150) [Broker-J] Prevent test failures due to slow initialisation of hostname resolution in HostnameAliasImpl
[
https://issues.apache.org/jira/browse/QPID-8150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Godfrey updated QPID-8150:
--
Status: Reviewable (was: In Progress)
> [Broker-J] Prevent test failures due to slow initialisation of hostname
> resolution in HostnameAliasImpl
> ---
>
> Key: QPID-8150
> URL: https://issues.apache.org/jira/browse/QPID-8150
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Reporter: Rob Godfrey
>Assignee: Rob Godfrey
>Priority: Major
> Fix For: qpid-java-broker-7.1.0
>
>
> On some operating systems / configurations (notably my laptop running OS X :)
> ) the resolution of potential hostnames which resolve to the local machine
> which takes place in {{HostnameAliasImpl}} can take a long time due to
> fruitless lookups. This can cause various system tests to fail.
> To prevent these failures
> # Do not include the hostname virtual host alias where it is not needed in
> the system tests
> # Reorder the list of {{InetAddress}} objects that are iterated over in the
> resolution phase so that addresses more likely to resolve (like the loopback
> interface) are processed first
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8150) [Broker-J] Prevent test failures due to slow initialisation of hostname resolution in HostnameAliasImpl
Rob Godfrey created QPID-8150:
-
Summary: [Broker-J] Prevent test failures due to slow
initialisation of hostname resolution in HostnameAliasImpl
Key: QPID-8150
URL: https://issues.apache.org/jira/browse/QPID-8150
Project: Qpid
Issue Type: Improvement
Components: Broker-J
Reporter: Rob Godfrey
On some operating systems / configurations (notably my laptop running OS X :) )
the resolution of potential hostnames which resolve to the local machine which
takes place in {{HostnameAliasImpl}} can take a long time due to fruitless
lookups. This can cause various system tests to fail.
To prevent these failures
# Do not include the hostname virtual host alias where it is not needed in the
system tests
# Reorder the list of {{InetAddress}} objects that are iterated over in the
resolution phase so that addresses more likely to resolve (like the loopback
interface) are processed first
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8143) [Broker-J] Properly validate @ManagedAttributeValueTypes, and allow for factory methods
[
https://issues.apache.org/jira/browse/QPID-8143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Godfrey updated QPID-8143:
--
Status: Reviewable (was: In Progress)
> [Broker-J] Properly validate @ManagedAttributeValueTypes, and allow for
> factory methods
> ---
>
> Key: QPID-8143
> URL: https://issues.apache.org/jira/browse/QPID-8143
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Reporter: Rob Godfrey
>Assignee: Rob Godfrey
>Priority: Major
>
> Currently types annotated with the {{@ManagedAttributeValueType}} annotation
> are not correctly validated (the validator is not being run).
> Such types should be interfaces with only accessor methods unless they are
> marked as "abstract" which means they cannot be instantiated from input. For
> abstract types, allow the use of classes as well as interfaces. For
> non-abstract types allow the use of a factory method rather than forcing the
> use of proxy classes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8143) [Broker-J] Properly validate @ManagedAttributeValueTypes, and allow for factory methods
[
https://issues.apache.org/jira/browse/QPID-8143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Godfrey reassigned QPID-8143:
-
Assignee: Keith Wall (was: Rob Godfrey)
> [Broker-J] Properly validate @ManagedAttributeValueTypes, and allow for
> factory methods
> ---
>
> Key: QPID-8143
> URL: https://issues.apache.org/jira/browse/QPID-8143
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Reporter: Rob Godfrey
>Assignee: Keith Wall
>Priority: Major
>
> Currently types annotated with the {{@ManagedAttributeValueType}} annotation
> are not correctly validated (the validator is not being run).
> Such types should be interfaces with only accessor methods unless they are
> marked as "abstract" which means they cannot be instantiated from input. For
> abstract types, allow the use of classes as well as interfaces. For
> non-abstract types allow the use of a factory method rather than forcing the
> use of proxy classes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Assigned] (QPID-8143) [Broker-J] Properly validate @ManagedAttributeValueTypes, and allow for factory methods
[
https://issues.apache.org/jira/browse/QPID-8143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Godfrey reassigned QPID-8143:
-
Assignee: Rob Godfrey
> [Broker-J] Properly validate @ManagedAttributeValueTypes, and allow for
> factory methods
> ---
>
> Key: QPID-8143
> URL: https://issues.apache.org/jira/browse/QPID-8143
> Project: Qpid
> Issue Type: Improvement
> Components: Broker-J
> Reporter: Rob Godfrey
>Assignee: Rob Godfrey
>Priority: Major
>
> Currently types annotated with the {{@ManagedAttributeValueType}} annotation
> are not correctly validated (the validator is not being run).
> Such types should be interfaces with only accessor methods unless they are
> marked as "abstract" which means they cannot be instantiated from input. For
> abstract types, allow the use of classes as well as interfaces. For
> non-abstract types allow the use of a factory method rather than forcing the
> use of proxy classes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPID-8143) [Broker-J] Properly validate @ManagedAttributeValueTypes, and allow for factory methods
Rob Godfrey created QPID-8143:
-
Summary: [Broker-J] Properly validate @ManagedAttributeValueTypes,
and allow for factory methods
Key: QPID-8143
URL: https://issues.apache.org/jira/browse/QPID-8143
Project: Qpid
Issue Type: Improvement
Components: Broker-J
Reporter: Rob Godfrey
Currently types annotated with the {{@ManagedAttributeValueType}} annotation
are not correctly validated (the validator is not being run).
Such types should be interfaces with only accessor methods unless they are
marked as "abstract" which means they cannot be instantiated from input. For
abstract types, allow the use of classes as well as interfaces. For
non-abstract types allow the use of a factory method rather than forcing the
use of proxy classes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPIDJMS-371) String representation of JMSMessageID values generated with message ID policy of type 'UUID' cannot be used in selector expressions
[
https://issues.apache.org/jira/browse/QPIDJMS-371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16411731#comment-16411731
]
Rob Godfrey commented on QPIDJMS-371:
-
[~alex.rufous] the JMS client is working as designed and as per the draft
mapping specification. As I wrote on QPID-8139 the solution to the problem
here is for Broker-J to use a differently implementation of the JMSSelector
parser such that it recognizes the ID:AMQP_*: prefixes and treats the
appropriately.
> String representation of JMSMessageID values generated with message ID policy
> of type 'UUID' cannot be used in selector expressions
> ---
>
> Key: QPIDJMS-371
> URL: https://issues.apache.org/jira/browse/QPIDJMS-371
> Project: Qpid JMS
> Issue Type: Bug
>Reporter: Alex Rudyy
>Priority: Major
>
> Message ID policy of type {{UUID}} generates {{JMSMessageID}} values of AMQP
> type {{UUID}}. Such {{JMSMessageID}} values represented as {{String}}
> values (returned from method {{Message#getJMSMessageID()}}) in format
> {{ID:AMQP_UUID:}}. When such string value is used
> to build a JMS selector expression for example, {{String.format("JMSMessageID
> ='%s'", message#getJMSMessageID() )}}, the expression is sent to the broker
> in unmodified form. The Broker might not be aware about prefix
> ''ID:AMQP_UUID:' and can fail to find the message corresponding the
> expression.
> I did not test other Message ID policies and I guess that similar issue might
> happen for them as well.
> I am not sure whether custom prefixes are added by design with an intention
> to document them as part of JMSMapping specification. If not, it would be
> desirable to strip custom prefixes either from selector expression or
> {{String}} representation of JMSMessageID values.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8139) [Broker-J] Selector containing JMSMessageID expressions might not find the message when expression JMSMessageID value starts with 'ID:' prefix but the real message id do
[ https://issues.apache.org/jira/browse/QPID-8139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16411729#comment-16411729 ] Rob Godfrey commented on QPID-8139: --- [~alex.rufous]: the draft JMS AMQP mapping specifies how JMSMessageID should be sent over AMQP - I think what we need to do in the broker is use a slightly modified implementation of the JMS selector code when the consumer is using the AMQP 1.0 protocol so that it recognizes the rules defined in the mapping > [Broker-J] Selector containing JMSMessageID expressions might not find the > message when expression JMSMessageID value starts with 'ID:' prefix but the > real message id does not include the prefix > -- > > Key: QPID-8139 > URL: https://issues.apache.org/jira/browse/QPID-8139 > Project: Qpid > Issue Type: Bug > Components: Broker-J >Affects Versions: qpid-java-broker-7.0.2 >Reporter: Alex Rudyy >Priority: Major > > JMS specification requires JMSMessageID value to start with prefix "ID:". The > JMS client might add the prefix "ID:" to the values not starting from "ID:" > in order to be JMS compliment. If the altered JMSMessageID value is used to > build a selector expression like "JMSMEssageID='ID:'", the target > message might not be found as Broker-J uses real message ids in message > lookup. > Potentially, filtering functionality for JMSMEssageID expression can be > enhanced to detect the cases when the "ID:" prefix is specified in the > selector but not included into the real message id value and find the correct > message. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-7567) [Java Broker] Select appropriate certificate for TLS based on SNIServerName
[ https://issues.apache.org/jira/browse/QPID-7567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16411174#comment-16411174 ] Rob Godfrey commented on QPID-7567: --- Yeah - I basically decided that if you have multiple valid certificates for a server name then any one of them should do; and if you only want to send the one associated with a particular alias, you should not have added the other certificates into your store. The alias is there only for the case where a valid certificate can't be found (for whatever reason). > [Java Broker] Select appropriate certificate for TLS based on SNIServerName > --- > > Key: QPID-7567 > URL: https://issues.apache.org/jira/browse/QPID-7567 > Project: Qpid > Issue Type: Improvement > Components: Broker-J >Reporter: Keith Wall >Assignee: Keith Wall >Priority: Major > Fix For: qpid-java-broker-7.1.0 > > > Enable SNI support for the Java Broker. > We will need a X509ExtendedKeyManager implementation that gets the > SNIServerName from the SSL handshakes and then selects the most appropriate > certificate alias for the indicated hostname. > I found the following example helpful: > https://github.com/grahamedgecombe/netty-sni-example/blob/master/src/main/java/SniKeyManager.java > https://docs.oracle.com/javase/8/docs/technotes/guides/security/enhancements-8.html > This change requires Java 8, but it is probably possible to retain support > for Java 7 using reflection. > It looks to me like the clients (Qpid JMS Client and Legacy) require no > changes. They both pass the hostname through to the SSLEngine, so the > SNIServerName should already be passed through. Client side support in Java > was added at Java 7. -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Created] (QPIDJMS-367) Add support for XOAUTH2 Sasl Autentication
Rob Godfrey created QPIDJMS-367: --- Summary: Add support for XOAUTH2 Sasl Autentication Key: QPIDJMS-367 URL: https://issues.apache.org/jira/browse/QPIDJMS-367 Project: Qpid JMS Issue Type: Improvement Components: qpid-jms-client Reporter: Rob Godfrey [https://developers.google.com/gmail/imap/xoauth2-protocol] defines a SASL mechanism which allows for authentication using an OAUTH2 Acess Token. This mechanism is supported by Qpid Broker-J and it would be useful if the Qpid JMS client could connect using this mechanism. The mechanics of the mechanism pass a username and token, the latter essentially being equivalent to a password for these purposes. The Token MUST be provided as a Base64 encoded string (the contents of which are a token in JSON format, though this detail is opaque to the client). -- This message was sent by Atlassian JIRA (v7.6.3#76005) - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8122) [Broker-J] Create JDBC backed virtualhost node fails on MariaDB when database charset is utf8mb4
[
https://issues.apache.org/jira/browse/QPID-8122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16395092#comment-16395092
]
Rob Godfrey commented on QPID-8122:
---
This table seems like it was designed with the notion of children having
multiple parents in mind. Given we removed that capability there seems no
reason to have parent_type as part of the primary key. In fact maybe it is
simply better to remove this table altogether and move the parent_id field to
whichever table stores the objects themselves.
> [Broker-J] Create JDBC backed virtualhost node fails on MariaDB when database
> charset is utf8mb4
>
>
> Key: QPID-8122
> URL: https://issues.apache.org/jira/browse/QPID-8122
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
> Environment: 10.0.34-MariaDB-0ubuntu0.16.04.1 Ubuntu 16.04
>Reporter: Keith Wall
>Priority: Major
>
> With MariaDB 10.0.34 on Ubuntu 16.04 defaults its database character set type
> to {{utf8mb4}}.
> {noformat}
> MariaDB [qpid]> show variables like 'character_set_database';
> +++
> | Variable_name | Value |
> +++
> | character_set_database | utf8mb4 |
> +++
> 1 row in set (0.00 sec)
> {noformat}
> If I try and create a JDBC backed VHN, it fails with the following exception:
> {noformat}
> 2018-03-09 13:22:58,067 ERROR [Broker-Config]
> (o.a.q.s.u.ServerScopedRuntimeException) - Unable to open configuration tables
> java.sql.SQLSyntaxErrorException: (conn=173) Specified key was too long; max
> key length is 767 bytes
> at
> org.mariadb.jdbc.internal.util.exceptions.ExceptionMapper.get(ExceptionMapper.java:177)
> at
> org.mariadb.jdbc.internal.util.exceptions.ExceptionMapper.getException(ExceptionMapper.java:110)
> at
> org.mariadb.jdbc.MariaDbStatement.executeExceptionEpilogue(MariaDbStatement.java:228)
> at
> org.mariadb.jdbc.MariaDbStatement.executeInternal(MariaDbStatement.java:334)
> at org.mariadb.jdbc.MariaDbStatement.execute(MariaDbStatement.java:386)
> at com.jolbox.bonecp.StatementHandle.execute(StatementHandle.java:300)
> at
> org.apache.qpid.server.store.jdbc.AbstractJDBCConfigurationStore.createConfiguredObjectHierarchyTable(AbstractJDBCConfigurationStore.java:497)
> at
> org.apache.qpid.server.store.jdbc.AbstractJDBCConfigurationStore.createOrOpenConfigurationStoreDatabase(AbstractJDBCConfigurationStore.java:448)
> {noformat}
> The primary key length of the QPID_CONFIGURED_OBJECT_HIERARCHY is too long in
> this character set mode.
> It seems other MariaDB packages on other distributions default to {{latin1}}
> which does not face this problem. Switching to {{latin1}} like so is a
> workaround:
> {noformat}
> ALTER DATABASE qpid CHARACTER SET latin1{noformat}
> However, this would mean that a characters appearing in configuration items
> outwith latin1 would be lost.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8122) [Broker-J] Create JDBC backed virtualhost node fails on MariaDB when database charset is utf8mb4
[
https://issues.apache.org/jira/browse/QPID-8122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16393041#comment-16393041
]
Rob Godfrey commented on QPID-8122:
---
Does MariaDB/MySQL have a binary type? Another alternative would be to make
the type of the column binary and to do the encoding/decoding to/from utf8
ourselves
> [Broker-J] Create JDBC backed virtualhost node fails on MariaDB when database
> charset is utf8mb4
>
>
> Key: QPID-8122
> URL: https://issues.apache.org/jira/browse/QPID-8122
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
> Environment: 10.0.34-MariaDB-0ubuntu0.16.04.1 Ubuntu 16.04
>Reporter: Keith Wall
>Priority: Major
>
> With MariaDB 10.0.34 on Ubuntu 16.04 defaults its database character set type
> to {{utf8mb4}}.
> {noformat}
> MariaDB [qpid]> show variables like 'character_set_database';
> +++
> | Variable_name | Value |
> +++
> | character_set_database | utf8mb4 |
> +++
> 1 row in set (0.00 sec)
> {noformat}
> If I try and create a JDBC backed VHN, it fails with the following exception:
> {noformat}
> 2018-03-09 13:22:58,067 ERROR [Broker-Config]
> (o.a.q.s.u.ServerScopedRuntimeException) - Unable to open configuration tables
> java.sql.SQLSyntaxErrorException: (conn=173) Specified key was too long; max
> key length is 767 bytes
> at
> org.mariadb.jdbc.internal.util.exceptions.ExceptionMapper.get(ExceptionMapper.java:177)
> at
> org.mariadb.jdbc.internal.util.exceptions.ExceptionMapper.getException(ExceptionMapper.java:110)
> at
> org.mariadb.jdbc.MariaDbStatement.executeExceptionEpilogue(MariaDbStatement.java:228)
> at
> org.mariadb.jdbc.MariaDbStatement.executeInternal(MariaDbStatement.java:334)
> at org.mariadb.jdbc.MariaDbStatement.execute(MariaDbStatement.java:386)
> at com.jolbox.bonecp.StatementHandle.execute(StatementHandle.java:300)
> at
> org.apache.qpid.server.store.jdbc.AbstractJDBCConfigurationStore.createConfiguredObjectHierarchyTable(AbstractJDBCConfigurationStore.java:497)
> at
> org.apache.qpid.server.store.jdbc.AbstractJDBCConfigurationStore.createOrOpenConfigurationStoreDatabase(AbstractJDBCConfigurationStore.java:448)
> {noformat}
> The primary key length of the QPID_CONFIGURED_OBJECT_HIERARCHY is too long in
> this character set mode.
> It seems other MariaDB packages on other distributions default to {{latin1}}
> which does not face this problem. Switching to {{latin1}} like so is a
> workaround:
> {noformat}
> ALTER DATABASE qpid CHARACTER SET latin1{noformat}
> However, this would mean that a characters appearing in configuration items
> outwith latin1 would be lost.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Commented] (QPID-8114) [Broker-J] Attempting to use an unknown filter type incorrectly causes connection closure with a decode error
[
https://issues.apache.org/jira/browse/QPID-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16381738#comment-16381738
]
Rob Godfrey commented on QPID-8114:
---
Attached a patch which I think would address this particular instance of the
problem; however it is a more general thing that we are handling unknown
described types as a decoding error, rather than higher up in the stack. The
patch provides the outlines of a generalized mechanism for this, but we would
need to go through all the "specialized" described types and fix them, along
with all the places in the codec where this sort of thing may occur
> [Broker-J] Attempting to use an unknown filter type incorrectly causes
> connection closure with a decode error
> -
>
> Key: QPID-8114
> URL: https://issues.apache.org/jira/browse/QPID-8114
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
>Reporter: Rob Godfrey
>Priority: Major
> Attachments:
> QPID-8114___[Broker-J]_Attempting_to_use_an_unknown_filter_type_incorrectly_causes_connect.patch
>
>
> As discovered in QPID-8113 if a client attempts to attach to a source using
> an unknown filter type (i.e. an unrecognised descriptor) the broker responds
> with a decode error similar to
> {{[0x555941994670]:0 <- @close(24) [error=@error(29)
> [condition=:"amqp:decode-error", description="Expected key type is 'Filter'
> but got 'DescribedType'"]]}}
> Instead the broker should simply fail to attach (i.e. attach with
> source=null) and then immediately detach with a {{not-implemented}} error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
[jira] [Updated] (QPID-8114) [Broker-J] Attempting to use an unknown filter type incorrectly causes connection closure with a decode error
[
https://issues.apache.org/jira/browse/QPID-8114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Godfrey updated QPID-8114:
--
Attachment:
QPID-8114___[Broker-J]_Attempting_to_use_an_unknown_filter_type_incorrectly_causes_connect.patch
> [Broker-J] Attempting to use an unknown filter type incorrectly causes
> connection closure with a decode error
> -
>
> Key: QPID-8114
> URL: https://issues.apache.org/jira/browse/QPID-8114
> Project: Qpid
> Issue Type: Bug
> Components: Broker-J
> Reporter: Rob Godfrey
>Priority: Major
> Attachments:
> QPID-8114___[Broker-J]_Attempting_to_use_an_unknown_filter_type_incorrectly_causes_connect.patch
>
>
> As discovered in QPID-8113 if a client attempts to attach to a source using
> an unknown filter type (i.e. an unrecognised descriptor) the broker responds
> with a decode error similar to
> {{[0x555941994670]:0 <- @close(24) [error=@error(29)
> [condition=:"amqp:decode-error", description="Expected key type is 'Filter'
> but got 'DescribedType'"]]}}
> Instead the broker should simply fail to attach (i.e. attach with
> source=null) and then immediately detach with a {{not-implemented}} error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
