Re: Possibility of a Broker-J 8.0.6 release?

[Oleksandr Rudyy]

Hi Tom,
I will try to build version 8.0.6 this week.
You can track the release JIRA QPID-8561.

Kind Regards,
Alex

On Tue, 17 Aug 2021 at 18:55, Tom Jordahl  wrote:
>
> Hi Qpid folks,
>
> Would it be possible to release Broker-J 8.0.6 ?
>
> I need the resolution of https://issues.apache.org/jira/browse/QPID-8552 - 
> Management interface should reject OPTIONS - which was flagged by our 
> security scanners, in a release.
>
> Thanks.
> --
> Tom

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Feature 'publish is enabled in site .asf.yaml

[Oleksandr Rudyy]

Hi folks,
As part of site changes for the Qpid Broker-J 8.0.5 release I added
the section 'publish' into  .asf.yaml in order to switch to new site
publishing functionality.

If required we can revert back to gitwcsub for publishing by removing
the publish feature in .asf.yaml file.

Kind Regards,
Alex

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: High Qpid Dequeue latency

[Oleksandr Rudyy]

Hi Ram,

I think that achieving a low latency (<100ms) all time could be a tricky
thing in a java broker. The full GC "stop the world" pauses can suspend
message delivery for seconds if not more. Though, the JVM GC can be tuned
to minimize a number of "stop the world" pauses and their duration which
might give you a relatively good average latency.

As for the described messaging use case, I agree that an increase of a
number of queues can cause a latency increase due to a design of the
application.  As far as I understood (please correct me if I am wrong),  20
MessageListeners are shared among N queue consumers.  If there are more
than 20 queues with messages, it could be that the prefetched messages
could be sitting waiting on the respective consumers blocked by the
MessageListeners processing 20 messages at a time. If a number of queues is
increased further, the more messages could be waiting for their turn to be
processed by the 20 MessageListeners.

The Qpid Broker-J itself can contribute to the latency increase with an
increase of queues and their consumers as it would need to handle more
connections and consumers. You are right, the Qpid Broker-J implements a
round-robin message delivery and a "fair" message distribution among
connected consumers. If you are interested in the implementation details,
you can find broker documentation at [1] describing how the consumer works.

As for improving commit time, I would like to suggest looking into newer
versions (8.0.x) of the Broker-J. There were some changes  made in
transaction code which can improve transaction performance for persistent
messages. Apart from that, I cannot think on top of my head about anything
else which might improve latency for the described architecture.

Kind Regards,
Alex

[1]
https://github.com/apache/qpid-broker-j/blob/master/doc/developer-guide/src/main/markdown/consumer-queue-interactions.md


On Mon, 11 Jan 2021 at 17:55, rammantripragada 
wrote:

> Hello Qpid Experts,
>
> We are looking for using qpid (broker-j v7.0.7 & very old client 0.16
> version ) for low dequeue latency messaging. There are app servers which
> send messages to broker and then these messages are dequeued back to the
> same set of app servers. We have created some N number of queues and for
> each queue there are consumers on each app server (will be say around 100
> app servers) which dequeue message using MessageListener (onMessage())
> interface . We created 20 listener ( jms session ) per app server and *each
> listener listens to all the queues*. We did perf run to figure out the
> dequeue latency  and we found that as the number of queues to which
> messages
> were getting enqueued concurrently were increasing, the dequeue latency was
> increasing.
>
> 
>
> The increase in dequeue latency with increase in queues seems to be due to
> the consumer dequeue pattern that we have where each listener (consumer)
> listens to all the queues. It appears that Qpid sends current available
> messages on the queues to the listeners in a round robin manner. The
> current
> way in which we register all listeners to all queues causes qpid to send
> all
> the available messages across the queues to a single consumer (listener) at
> a time in a round robin manner between all the listeners.
> E.g if we have say L1, L2& L3 as listeners and Q1, Q2, Q3 as queues. Each
> of
> the listener subscribes to all the 3 queues. Now when messages arrive on
> queue Q1, Q2, Q3,  qpid sends messages from Q1, Q2, Q3 to L1 first and next
> set of messages (max 1 from each queue as we have a prefetch limit of 1) to
> L2 and later L3 in a round robin manner.
>
> <
> http://qpid.2158936.n2.nabble.com/file/t396552/Screenshot_2020-12-09_at_3.png>
>
>
> We also found that each time jmssession.commit() was called on the listener
> to get the next message it was taking around 13ms as P95 value.  So if the
> listener L1 receives 3 messages m1, m2, m3 from Q1, Q2, Q3 then the dequeue
> latency of the second msg will be 13ms more than the first and the third
> message will be around 26ms more.  With increase in queues, more messages
> will be received by one consumer and the dequeue latency will increase.
>
> I need advice from the qpid experts for the following:
>
> 1. Is the above explanation on the behavior for increase in dequeue latency
> as the number of queues to which messages are enqueued increases is
> correct?
> 2. Is this 13ms commit time normal and can this be tuned further. Is there
> any way using MessageListener so that we can get all the messages in one
> shot rather than calling commit on the session to get the next message on
> the listener. So that we can reduce the overhead of commit time for each
> message dequeued next on the listener.
> 3. Also could you please let me know what is the best pattern we can follow
> to achieve low dequeue latency (<100ms) with higher number of queues. If we
> have one listener per 

[ANNOUNCE] Apache Qpid Broker-J 8.0.1 released

[Oleksandr Rudyy]

The Apache Qpid (http://qpid.apache.org) community is pleased to
announce the immediate availability of Apache Qpid Broker-J 8.0.1.

This is the latest release of pure java implementation of messaging broker
supporting the Advanced Message Queuing Protocol 1.0 (AMQP 1.0, ISO/IEC
19464,
http://www.amqp.org) and legacy AMQP protocols 0-10, 0-91, 0-9 and 0-8.

Please visit Qpid project site for more details:
http://qpid.apache.org/components/broker-j/index.html

The release is available now from our website:
http://qpid.apache.org/download.html

The release brings a number of improvements and bug fixes. The release
notes can be found at:
http://qpid.apache.org/releases/qpid-broker-j-8.0.1/release-notes.html

Thanks to all involved,
Qpid Team

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: [NOTICE] Jenkins CI server change, manual job migrations required

[Oleksandr Rudyy]

Hi Roobie,

Thanks for the update.
I will try to migrate Qpid Broker-J jobs over next week-end.

Kind Regards,
Alex

On Fri, 24 Jul 2020 at 13:30, Robbie Gemmell 
wrote:

> The Jenkins setup at https://builds.apache.org is being replaced,
> including a server migration to a new Cloudbees hosted Jenkins primary
> at https://ci-builds.apache.org (both names will go there after the
> old setup is turned off).
>
> We must manually migrate any jobs we want to keep to the new system.
>
> The old system is being switched off on August 15th, but with worker
> nodes already gradually being migrated to the new setup now as
> appropriate to balance demand from new migrated jobs.
>
> I asked for a Qpid folder and for all committers to have access to the
> jobs, where they will live under:
> https://ci-builds.apache.org/job/Qpid/
>
> Our old jobs are at: https://builds.apache.org/view/M-R/view/Qpid/
>
> I plan to migrate all the Qpid JMS and Proton-J jobs myself and I've
> done a couple as a test. I don't plan on migrating most other jobs so
> if you want to keep them then please migrate them.
>
> Full initial details are at [1], with more in other threads on
> builds@a.o [2], such as the plugin installation request thread [3] for
> any required plugins not yet installed (not sure we have any
> requirements here though).
>
> Robbie
>
> [1]
> https://lists.apache.org/thread.html/re974eed417a1bc294694701d5c91b4bf92689fcf32a4c91f169be87d%40%3Cbuilds.apache.org%3E
> [2] https://lists.apache.org/list.html?bui...@apache.org
> [3]
> https://lists.apache.org/thread.html/r37c73263595b93c61c3d9b44e88a57f63edd28afa9aba3047259f4a4%40%3Cbuilds.apache.org%3E
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

Re: o.a.q.s.m.p.ManagementException) - Unexpected Exception - Qpid 7.1.3

[Oleksandr Rudyy]

Hi Balanna,

This warning is reported when someone is trying to save a dashboard under
the same name as existing one.
For example, you can clone the dashboard and try to save cloned one using
the same name as original dashboard.
It should not happen whilst browsing.

Kind Regards,
Alex

On Mon, 15 Jul 2019 at 17:23, Nadikude, Balanna <
balanna.nadik...@franklintempleton.com> wrote:

> Hi,
>
> In management console when I click on Dashboard and then on browse then
> below WARN logged? Can I know why this happening on ONLY one server?
>
>
>
> 2019-07-15 09:23:18,626 WARN  [qtp2103783970-291]
> (o.a.q.s.m.p.ManagementException) - Unexpected Exception
>
>
>
> 2019-07-15 09:24:09,734 WARN  [qtp2103783970-167]
> (o.a.q.s.m.p.ManagementException) - Unexpected Exception
>
>
>
> 2019-07-15 09:24:21,724 WARN  [qtp2103783970-287]
> (o.a.q.s.m.p.ManagementException) - IllegalArgumentException processing
> request
> /api/v7.1/virtualhost/RCO_1_FIX_VHN/FIX_VHNG/userpreferences/X-Dashboard
> from user '/10.20.9.117:61272/readonly-all/support': Preference 'FIX
> Dash' of type 'X-Dashboard' already exists
>
>
>
> Thanks,
> Balanna Nadikude
>
> Notice:  All email and instant messages (including attachments) sent to or
> from Franklin Templeton Investments (FTI) personnel may be retained,
> monitored and/or reviewed by FTI and its agents, or authorized law
> enforcement personnel, without further notice or consent.
>
> Under new Data Protection regulations in Europe your personal information
> may be subject to our EU specific Privacy & Cookies Notice which you can
> read here, regardless of where the information originates. Depending on
> your location, other privacy laws and regulations may also apply to you.
> Please reference http://www.franklintempletonglobal.com/privacy
>
> .
>

Re: URGENT: missing links (was: [ANNOUNCE] Apache Qpid Broker-J versions 7.1.1 and 7.0.7 released)

[Oleksandr Rudyy]

Sebb,

I made a temporary change to the downloaded page where links to 7.0.7
release bundles are included.
I will make sure to provide the links to direct download pages in the next
release announcements.

Kind Regards,
Alex



On Fri, 1 Mar 2019 at 20:29, sebb  wrote:

> On Fri, 1 Mar 2019 at 20:23, Oleksandr Rudyy  wrote:
> >
> > Hi sebb,
> >
> > The Qpid download page only contains links to the highest versions of
> products developed as part of Qpid project. The highest released version
> for Qpid Broker-J is 7.1.1. Thus, the link to 7.1.1 is placed directly on
> the page.
> > At the top of the page there is a link "current releases" [1] to other
> versions where a link to Qpid Broker-J 7.0.7 download page can be found.
> >
> > No worries, it is an intentional decision to have only one link. It
> should not be a problem to find a link  to 7.0.7 via current releases.
>
> Announce messages must include a link to the download page where the
> release(s) can be found.
> Readers should not have to search on the website for the download page.
>
> > Kind Regards,
> > Alex
> >
> > [1] http://qpid.apache.org/releases/index.html#current-releases
> >
> >
> > On Fri, 1 Mar 2019 at 18:00, sebb  wrote:
> >>
> >> Accidentally accepted this for publication.
> >> I meant to delay or reject it as the download page does not appear to
> >> list version 7.0.7.
> >>
> >> Please correct the download page immediately.
> >>
> >> S.
> >> -- Forwarded message -
> >> From: Alex Rudyy 
> >> Date: Fri, 1 Mar 2019 at 17:56
> >> Subject: [ANNOUNCE] Apache Qpid Broker-J versions 7.1.1 and 7.0.7
> released
> >> To: , , <
> annou...@apache.org>
> >>
> >>
> >> The Apache Qpid (http://qpid.apache.org) community is pleased to
> >> announce the immediate availability of Apache Qpid Broker-J versions
> >> 7.1.1 and 7.0.7.
> >>
> >> These are the latest bugfix releases of pure java implementation of
> >> Qpid messaging broker
> >> supporting the Advanced Message Queuing Protocol 1.0 (AMQP 1.0, ISO/IEC
> 19464,
> >> http://www.amqp.org) and legacy AMQP protocols 0-10, 0-91, 0-9 and 0-8.
> >>
> >> These releases address vulnerability CVE-2019-0200 and incorporates a
> number
> >> of defect fixes and enhancements.
> >>
> >> Please visit Qpid project site for more details:
> >> http://qpid.apache.org/components/broker-j/index.html
> >>
> >> The releases are available now from our website:
> >> http://qpid.apache.org/download.html
> >>
> >> Release notes can be found at:
> >>
> http://qpid.apache.org/releases/qpid-broker-j-7.0.7/release-notes.html
> >>
> http://qpid.apache.org/releases/qpid-broker-j-7.1.1/release-notes.html
> >>
> >> Thanks to all involved,
> >> Alex
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> >> For additional commands, e-mail: dev-h...@qpid.apache.org
>

Re: URGENT: missing links (was: [ANNOUNCE] Apache Qpid Broker-J versions 7.1.1 and 7.0.7 released)

[Oleksandr Rudyy]

Hi sebb,

The Qpid download page only contains links to the highest versions of
products developed as part of Qpid project. The highest released version
for Qpid Broker-J is 7.1.1. Thus, the link to 7.1.1 is placed directly on
the page.
At the top of the page there is a link "current releases" [1] to other
versions where a link to Qpid Broker-J 7.0.7 download page can be found.

No worries, it is an intentional decision to have only one link. It should
not be a problem to find a link  to 7.0.7 via current releases.

Kind Regards,
Alex

[1] http://qpid.apache.org/releases/index.html#current-releases


On Fri, 1 Mar 2019 at 18:00, sebb  wrote:

> Accidentally accepted this for publication.
> I meant to delay or reject it as the download page does not appear to
> list version 7.0.7.
>
> Please correct the download page immediately.
>
> S.
> -- Forwarded message -
> From: Alex Rudyy 
> Date: Fri, 1 Mar 2019 at 17:56
> Subject: [ANNOUNCE] Apache Qpid Broker-J versions 7.1.1 and 7.0.7 released
> To: , , 
>
>
> The Apache Qpid (http://qpid.apache.org) community is pleased to
> announce the immediate availability of Apache Qpid Broker-J versions
> 7.1.1 and 7.0.7.
>
> These are the latest bugfix releases of pure java implementation of
> Qpid messaging broker
> supporting the Advanced Message Queuing Protocol 1.0 (AMQP 1.0, ISO/IEC
> 19464,
> http://www.amqp.org) and legacy AMQP protocols 0-10, 0-91, 0-9 and 0-8.
>
> These releases address vulnerability CVE-2019-0200 and incorporates a
> number
> of defect fixes and enhancements.
>
> Please visit Qpid project site for more details:
> http://qpid.apache.org/components/broker-j/index.html
>
> The releases are available now from our website:
> http://qpid.apache.org/download.html
>
> Release notes can be found at:
> http://qpid.apache.org/releases/qpid-broker-j-7.0.7/release-notes.html
> http://qpid.apache.org/releases/qpid-broker-j-7.1.1/release-notes.html
>
> Thanks to all involved,
> Alex
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>

Re: Jakarta EE TCKs and compatibility logo

[Oleksandr Rudyy]

Hi Mark,

I believe that Qpid Team members requested an access to TCK earlier in
order to test compatibility of Qpid JMS clients with JMS specs.
We  added maven module [1] to run TCK tests against Qpid Broker-J. Though,
TCK is not part of Qprid Broker-J project and it has to be provided
externally.
The TCK bundles need to be downloaded separately and the path to the TCK
folder needs to be specified to the maven build as JVM property.
Both TCK tests for JMS 1.1 and JMS 2.0 can be run. However, currently, only
older Oracle proprietary TCKs are supported due to hard-coded paths to the
dependency jars.

In order to run TCK tests with new Jakarta EE bundle, the maven profile
settings needs to be amended. I will change that later.

So, in general, I would like to continue running TCK tests with Qpid JMS
clients and  Qpid Broker-J using Jakarta EE bundle.
If Jakarta EE compatible logo is required to add to Qpid Project, I
suppose, we can add it.

Mark,
Do you know whether there are any plans to release TCK bundles into maven
repository?
I suppose that JMS 1.1 TCK is not supported by Jakarta EE and if I still
want to run JMS 1.1 TCK I need to use Oracle provided bundle.

Kind Regards,
Alex

[1]
https://cwiki.apache.org/confluence/display/qpid/How+To+Build+Qpid+Broker-J#HowToBuildQpidBroker-J-JMSTCK


On Sun, 17 Feb 2019 at 19:01, Mark Thomas  wrote:

> Ping.
>
> Just a gentle reminder as I haven't seen any emails to jcp-open@ as yet.
>
> Mark
>
> PS If you don't want to build from source, there are nightly TCK builds
> available here:
> https://download.eclipse.org/ee4j/jakartaee-tck/8.0.1/nightly/
>
>
> On 21/01/2019 10:46, Mark Thomas wrote:
> > Apologies for the noise.
> >
> > The correct link for [3] is:
> >
> > https://jakarta.ee/legal/trademark_guidelines/
> >
> > I've also corrected a handful of the project BCCs.
> >
> > Mark
> >
> >
> > On 18/01/2019 22:53, Mark Thomas wrote:
> >> Hi all,
> >>
> >> I am writing to your dev@ lists (on BCC) as your project has, in the
> >> past, requested access to the Java EE TCKs while they were controlled by
> >> Sun and then Oracle.
> >>
> >> As I am sure you are aware, Java EE has moved to Eclipse and is now
> >> Jakarta EE. The good news is that the TCKs have been open sourced.
> >>
> >> https://github.com/eclipse-ee4j/jakartaee-tck
> >>
> >> (I haven't tried to build the latest TCK from source yet but it is on my
> >> TODO list.)
> >>
> >> Shipping compatible implementations of the Jakarta EE specs (and being
> >> able to make public statements to that effect) will be subject only to
> >> the spec [1] and TCK [2] licenses. There will no longer be a TCK
> >> agreement or NDA to sign. However...
> >>
> >> The question has arisen whether or not any ASF projects will want to use
> >> the Jakarta EE compatible logo [3]. If a project wants to be able to do
> >> this, there are some organisational hoops to jump through. Before the
> >> ASF starts down that path the board has asked me to see if there are any
> >> projects that want to use the Jakarta EE compatible logo. After all,
> >> there is no point jumping through the hoops if no-one wants to use the
> logo.
> >>
> >> With the above in mind can you please discuss this amongst your project
> >> community and reply back to jcp-o...@apache.org whether or not your
> >> project is interested in being able to use the Jakarta EE compatible
> >> logo. I ask that you complete this no later than the next board meeting
> >> (20th February 2019).
> >>
> >> If you have any questions about any of the above, please also use
> >> jcp-o...@apache.org to ask them.
> >>
> >> Thanks,
> >>
> >> Mark
> >>
> >>
> >> [1] https://www.eclipse.org/legal/efsl.php
> >> [2] https://www.eclipse.org/legal/tck.php
> >> [3] https://www.eclipse.org/legal/tck.php
> >>
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>
>

Re: InputStream in SSLUtil.java line 449

[Oleksandr Rudyy]

Hi Jesse,

Thanks for letting us know about the defect.

I fixed the defect as part of QPID-8213.

Kind Regards,
Alex

[1] https://issues.apache.org/jira/browse/QPID-8213

On 27 June 2018 at 02:27, Jesse  wrote:
> Hello,
>
> I noticed that there may be an unclosed resource around line 449 of
> org.apache.qpid.server.transport.network.security.ssl.SSLUtil.java
>
> Let me know what you think or if you need more details.
>
> Thanks,
>
> Jesse
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: [AMQP1.0] Intended use-case of transaction-error transaction-timeout

[Oleksandr Rudyy]

Hi Keith,

I think that closing the connection is the simplest reasonable thing
to do in order to fail early on transaction timeout.
Though, I believe that the handling of transaction timeouts can be
improved further by closing the link(s), where the timed out
transactional work have been performed.
That would allow other transactional and non-transactional links on
the same connection to continue to operate without the impact.
I also do not think that closing of coordinator link would be
necessary in this case, as other link transactions can be run on the
same coordinator link.

Kind Regards,
Alex


On 6 February 2018 at 14:34, Keith W  wrote:
> An AMQP1.0 question has arisen during the implementation of
> QPID-8091[Broker-J] [AMQP 1.0] Store transaction timeout.   I would
> like some guidance as to the best way to use AMQP 1.0 in this
> situation.
>
> Background:
>
> Broker-J has a defence against long running store transactions.  The
> reason this defence exists relates to the way Berkeley BDB JE works:
> once a transaction is started, the BDB JE cleaner is unable to
> progress past that point in the transaction log until that transaction
> completes.   If a transaction remains open for a long period of time
> whilst other work continues, the transaction log will grow until
> eventually disk space is exhausted and the system fails.   Broker-J's
> defence against this it is to identify messaging connections that have
> long running transactions and terminate them, allowing the transaction
> to rollback and the cleaner to do its work.   When this happens, on
> the wire, for AMQP 0-8..0-91 the connection is closed and for AMQP
> 0-10 the session is detached.
>
> Question:
> My question relates to the best way to do an analogous action for AMQP 1.0.
>
> It would be possible to simply close the connection (as AMQP 0-8..0-91
> does) , but this seems distasteful.   More attractive - superficially
> at least - would be to somehow signal to the transaction controller
> that the time-out has occurred, and let other unrelated work continue.
>
> I noticed that transaction-error includes a transaction-timeout [1]
> option.  I am intrigued to know  the intended use-case(s).
>
> It would be possible to signal the timeout by having the transactional
> resource detach the coordinator link with a transaction-timeout.  This
> would require that transaction coordinators be capable of handling
> reasonably a spontaneous coordinator link detach.
>
> Assuming this is reasonable approach, what should be done with
> existing transfers that are associated with timed-out transactions?
> Things seem less than straight-forward:
>
> 1) For transactional posting - the transactional resource would need
> to reject the transfers (if the link supported the outcome) or close
> the link from where they came otherwise.
>
> 2) For transaction retirement - the specification allows[2], in the
> event of a controller-initiated rollback that the deliveries (which
> are still 'live' and still acquired by the controller) to be enlisted
> by the coordinator into a new transaction (or none).  It seems to me
> reasonable that this should also apply in the timeout situation i..e
> transaction resource initiated rollback.
>
> 3) For transaction acquisition - as there is no provision in the
> specification for existing transfers to be assigned a different
> transaction-id, I suppose the onus would be on the transaction
> coordinator to reject the transfers.
>
> Having explored the idea, I find myself returning  to a position of
> simply closing the connection.   The complications for both the
> transaction resource and transactional controller outweigh any
> benefits. However, I would appreciating hearing other thoughts and the
> background for transaction-timeout.
>
> Kind regards,
> Keith.
>
> [1] 
> http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transactions-v1.0-os.html#choice-transaction-error-transaction-rollback
> [2] 
> http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-transactions-v1.0-os.html#doc-idp120240
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: [DISCUSS] Proposal to mark "Won't Fix" all open "JMS AMQP 0-x" JIRAs

[Oleksandr Rudyy]

Keith,

Your suggestion looks reasonable to me.

+1 from me.

Kind Regards,
Alex


On 22 January 2018 at 22:27, Keith W  wrote:
> The JIRA component "JMS AMQP 0-x" corresponds to the old 0-8..0-10
> Qpid JMS Client.  As development work on this component is ceased, I
> proposing to mark all open JIRAs tagged for it as Won't Fix with a
> short explanatory comment.
>
> "Won't Fix.  Development work on this Qpid JMS AMQP 0-x client has
> ceased.  For a JMS client under active development, see the Qpid JMS
> AMQP 1.0 client - https://qpid.apache.org/components/jms/index.html;
>
> For a list of JIRAs:
>
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20QPID%20AND%20component%20in%20(%22JMS%20AMQP%200-x%22)%20AND%20status%20not%20in%20(Resolved%2C%20Closed%2C%20%22In%20Progress%22)%20ORDER%20BY%20component%20ASC
>
> Some JIRAs are tagged with both "JMS AMQP 0-x" and other component(s)
> - clients and/or brokers.   They all seem to be old/inactive so I am
> not intending to treat these differently.
>
> Comments welcome.
>
> Keith.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[ANNOUNCE] Apache Qpid Broker-J 7.0.0 released

[Oleksandr Rudyy]

The Apache Qpid (http://qpid.apache.org) community is pleased to announce
the immediate availability of Apache Qpid Broker-J 7.0.0.

Qpid Broker-J 7.0 brings the following major changes:

* Improved AMQP 1.0 support
* Support for AMQP JMS Mapping Version 1.0 WD09
* Support for JMS 2.0 shared subscriptions
* Improved message conversion for applications using different AMQP
protocols
* Improved direct memory management

The release is available now from our website:
http://qpid.apache.org/download.html

Binaries are also available via Maven Central:
http://qpid.apache.org/maven.html

Release notes can be found at:
 https://qpid.apache.org/releases/qpid-broker-j-7.0.0/release-notes.html

Thanks to all involved,
Alex

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[ANNOUNCE] Apache Qpid for Java 6.0.8 released

[Oleksandr Rudyy]

The Apache Qpid (https://qpid.apache.org) community is pleased to announce
the immediate availability of Apache Qpid for Java 6.0.8.

This release addresses defects and enhancements in Qpid Broker for Java
(a.k.a. qpid-broker-j).

The release is available now from our website:
https://qpid.apache.org/download.html

Binaries are also available via Maven Central:
https://qpid.apache.org/maven.html

Release notes can be found at:
https://qpid.apache.org/releases/qpid-java-6.0.8/release-notes.html

Qpid Java 6.1.4 release page can be found here:
https://qpid.apache.org/releases/qpid-java-6.0.8/index.html


Thanks to all involved,
Alex

[ANNOUNCE] Apache Qpid for Java 6.1.4 released

[Oleksandr Rudyy]

The Apache Qpid (https://qpid.apache.org) community is pleased to announce
the immediate availability of Apache Qpid for Java 6.1.4.

This release addresses defects and enhancements in Qpid Broker for Java
(a.k.a. qpid-broker-j).

The release is available now from our website:
https://qpid.apache.org/download.html

Binaries are also available via Maven Central:
https://qpid.apache.org/maven.html

Release notes can be found at:
https://qpid.apache.org/releases/qpid-java-6.1.4/release-notes.html

Qpid Java 6.1.4 release page can be found here:
https://qpid.apache.org/releases/qpid-java-6.1.4/index.html


Thanks to all involved,
Alex

Re: QPID 0.32 going out of memory

[Oleksandr Rudyy]

Akhil,

Appenders of type "org.apache.log4j.FileAppender" do not compress log files.
Thus, it means, that "ArchivingFileAppender" (of type
QpidCompositeRollingAppender ) is causing the issue. Potentially,  removal
or replacement of this appender with any suitable FileAppender (for
example, DailyRollingFileAppender or RollingFileAppender or any other log4j
file appender) might fix the issue.

> You mean to say that we should change Log4j and use
> slf4j instead.
> Yes presently we are using Log4j as appender and we have set the
> logging_level="info". Does changing it to only error will help?

sl4j is a logging framework used in newer versions of qpid brokers (6.0 and
above). You cannot use it with 0.32 version of Qpid Broker. In 6.x brokers
logging configuration is stored in broker own configuration.

"FileAppender" is a separate appender.  "FileAppender" and "Archiving
FileAppender" logs into different files separately from each other.
"FileAppender" does not compress its log files, whilst "Archiving
FileAppender" does it.
Changing log level on "FileAppender" to "error" will not help with the
issue.

Removal or replacement of "ArchivingFileAppender" (
QpidCompositeRollingAppender ) should fix the issue.

Kind Regards,
Alex


On 19 June 2017 at 14:13, Akhil Samnotra <samnotraak...@gmail.com> wrote:

> Also , we are using
> appender class="org.apache.log4j.QpidCompositeRollingAppender"
> name="ArchivingFileAppender">
> 
> 
>  value="${QPID_WORK}/log/${logprefix}qpidlog${logsuffix}.log"/>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
>
> 
> 
> 
> 
>
> We are presently using this configuration in Log4j.xml.
>
> Can you please help?
>
> Thanks
> Akhil Samnotra
>
>
> On Mon, Jun 19, 2017 at 6:40 PM, Akhil Samnotra <samnotraak...@gmail.com>
> wrote:
>
> > Hi ,
> > Thanks for the help . You mean to say that we should change Log4j and use
> > slf4j instead.
> > Yes presently we are using Log4j as appender and we have set the
> > logging_level="info". Does changing it to only error will help?
> >
> > This is the present configuration :
> >
> > 
> > 
> > 
> >
> > 
> > 
> > 
> >  
> >
> > Can we do anything in this configuration to get rid of the issue?
> >
> > Thanks
> > Akhil
> >
> > On Mon, Jun 19, 2017 at 6:31 PM, Oleksandr Rudyy <oru...@gmail.com>
> wrote:
> >
> >> Hi Akhil,
> >>
> >> Thanks for raising JIRA and attaching the screenshots from MAT.
> >> As per screnshot [1] it seems that heap memory was consumed by
> >> java.io.File
> >> objects. Judging by the file names, the file objects were created by log
> >> appender whilst compression broker logs.
> >>
> >> What type of file appender are you using with Qpid Broker? Is it
> >> "org.apache.log4j.QpidCompositeRollingAppender"? You can check
> >> ${QPID_HOME}/etc/log4j.xml for logging configuration?
> >> We are not aware about any defect in QpidCompositeRollingAppender which
> >> would manifest in heap memory consumption by java.io.File objects.
> >>
> >> The broker logging functionality in version 0.32 is based on log4j . It
> >> was
> >> replaced with slf4j and logback in following  6.x versions.
> >> You can consider migration to newer version of broker (6.1.3 at the
> moment
> >> of writing this email). If migration of broker is not an option, you can
> >> try replacing the log appender with another one.
> >>
> >>
> >> Kind Regards,
> >> Alex
> >>
> >>
> >> [1] https://issues.apache.org/jira/browse/QPID-7828
> >> [2] https://issues.apache.org/jira/secure/attachment/
> 12873368/image1.PNG
> >>
> >>
> >> On 19 June 2017 at 11:46, Akhil Samnotra <samnotraak...@gmail.com>
> wrote:
> >>
> >> > HI ,
> >> > I have even raised the jira but didnt got any resolution.
> >> >
> >> > Thanks
> >> > Akhil
> >> >
> >> > On Mon, Jun 19, 2017 at 1:47 PM, Oleksandr Rudyy <oru...@gmail.com>
> >> wrote:
> >> >
> >> > >

Re: QPID 0.32 going out of memory

[Oleksandr Rudyy]

Hi Akhil,

Thanks for raising JIRA and attaching the screenshots from MAT.
As per screnshot [1] it seems that heap memory was consumed by java.io.File
objects. Judging by the file names, the file objects were created by log
appender whilst compression broker logs.

What type of file appender are you using with Qpid Broker? Is it
"org.apache.log4j.QpidCompositeRollingAppender"? You can check
${QPID_HOME}/etc/log4j.xml for logging configuration?
We are not aware about any defect in QpidCompositeRollingAppender which
would manifest in heap memory consumption by java.io.File objects.

The broker logging functionality in version 0.32 is based on log4j . It was
replaced with slf4j and logback in following  6.x versions.
You can consider migration to newer version of broker (6.1.3 at the moment
of writing this email). If migration of broker is not an option, you can
try replacing the log appender with another one.


Kind Regards,
Alex


[1] https://issues.apache.org/jira/browse/QPID-7828
[2] https://issues.apache.org/jira/secure/attachment/12873368/image1.PNG


On 19 June 2017 at 11:46, Akhil Samnotra <samnotraak...@gmail.com> wrote:

> HI ,
> I have even raised the jira but didnt got any resolution.
>
> Thanks
> Akhil
>
> On Mon, Jun 19, 2017 at 1:47 PM, Oleksandr Rudyy <oru...@gmail.com> wrote:
>
> > Hi Akhil,
> >
> > The screenshots did not get through with your latest email. Could you
> > please try raising JIRA and attaching the screnshots to it?
> >
> > Kind Regards,
> > Alex
> >
> > On 17 June 2017 at 06:04, Akhil Samnotra <samnotraak...@gmail.com>
> wrote:
> >
> > > hi ,
> > >
> > > please find the screenshots attached.
> > > thanks
> > >
> > > Akhil
> > >
> > > On Sat, Jun 17, 2017 at 1:52 AM, Oleksandr Rudyy <oru...@gmail.com>
> > wrote:
> > >
> > >> Hi Akhil,
> > >> It seems attachments have been stripped off. Could you please resend
> > them
> > >> or raise a JIRA [1] and attach your screenshots to the JIRA?
> > >>
> > >> Kind Regards,
> > >> Alex
> > >>
> > >> [1] https://issues.apache.org/jira/projects/QPID
> > >>
> > >
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> > > For additional commands, e-mail: dev-h...@qpid.apache.org
> > >
> >
>

Re: QPID 0.32 going out of memory

[Oleksandr Rudyy]

Hi Akhil,

The screenshots did not get through with your latest email. Could you
please try raising JIRA and attaching the screnshots to it?

Kind Regards,
Alex

On 17 June 2017 at 06:04, Akhil Samnotra <samnotraak...@gmail.com> wrote:

> hi ,
>
> please find the screenshots attached.
> thanks
>
> Akhil
>
> On Sat, Jun 17, 2017 at 1:52 AM, Oleksandr Rudyy <oru...@gmail.com> wrote:
>
>> Hi Akhil,
>> It seems attachments have been stripped off. Could you please resend them
>> or raise a JIRA [1] and attach your screenshots to the JIRA?
>>
>> Kind Regards,
>> Alex
>>
>> [1] https://issues.apache.org/jira/projects/QPID
>>
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>

Re: QPID 0.32 going out of memory

[Oleksandr Rudyy]

Hi Akhil,
It seems attachments have been stripped off. Could you please resend them
or raise a JIRA [1] and attach your screenshots to the JIRA?

Kind Regards,
Alex

[1] https://issues.apache.org/jira/projects/QPID

Re: Support for Qpid cpp broker in java broker system tests

[Oleksandr Rudyy]

Hi Robbie,

I am sorry, I meant to send the email into users list but somehow managed
to sent it into dev :(.

Here are our current intentions regarding system tests:
 * for new system tests (whether it is AMQP 0.x or AMQP 1.0) we would like
to use AMQP management to create/change/delete pre-required entities on
broker
 * in short term we are not going to delete or refactor existing tests
 * in long term we would like to sort out our system tests and leave only
sensible tests there
 * it is unclear yet what we would be doing with JMS client tests, but,
IMHO, the system tests which are testing the client aspects only would need
to be moved into client source tree. Existing system tests are testing both
broker and client. Thus, it is difficult to separate them. We are not
planning any work in this area at the moment. The main development efforts
are concentrated on producing 7.0 release. The tests are changed on the
best effort basis: if there is an issue within the broker or tests itself
we try to fix it
* our main priority now is to make system tests running using AMQP 1.0
protocol without "boiling the ocean".

Regarding running tests against cpp broker: In my personal opinion we need
to have such tests in client source tree and broker source tree should only
contain java broker specific tests.

Kind Regards,
Alex


On 3 April 2017 at 17:46, Robbie Gemmell <robbie.gemm...@gmail.com> wrote:

> I wasn't around at the time and missed this among the deluge of
> backlogged mails when I returned. You might have had more luck using
> the users list given thats where most discussions are and theres less
> traffic to drown things out.
>
> Can you clarify some things for me. You mention wanting to use AMQP
> Management for AMQP 1.0 tests, but then later note specifically the
> Java broker supports it for 0-x too. Do you also wan't/plan to use it
> for 0-x tests as well? Do you plan to [re]move any tests that are
> mainly covering the client, since the system tests module has
> historicaly been for the combination of both rather than just the
> broker?
>
> Robbie
>
> On 3 April 2017 at 12:28, Oleksandr Rudyy <oru...@gmail.com> wrote:
> > Hi all,
> >
> > Since nobody sent any reply on my previous email I would like to re-ask
> > again whether there is any interest in running java broker system tests
> > against cpp broker?
> >
> > If there is no interest, we would like to remove the support for running
> > cpp broker with java broker system tests.
> >
> > Kind Regards,
> > Alex
> >
> >
> > On 20 March 2017 at 10:05, Oleksandr Rudyy <oru...@gmail.com> wrote:
> >
> >> Hi everybody,
> >>
> >> The existing system tests for java broker can be run against cpp
> >> broker (with some exceptions for the tests relying on java broker REST
> >> API or java broker specific features).
> >>
> >> Is there an interest to continue support of cpp broker in java broker
> >> system tests?
> >>
> >> The reasons behind this question are the following:
> >> 1)  we want reduce the maintenance efforts for the tests
> >> 2)  we want to use AMQP management for AMQP 1.0 in the system tests to
> >> create/delete/update configured entities on the broker but cpp broker
> >> does not support AMQP management whilst java broker supports it for
> >> both AMQP 1.0 and AMQP 0.x
> >>
> >> Kind Regards,
> >> Alex
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>
>

Re: Support for Qpid cpp broker in java broker system tests

[Oleksandr Rudyy]

Hi all,

Since nobody sent any reply on my previous email I would like to re-ask
again whether there is any interest in running java broker system tests
against cpp broker?

If there is no interest, we would like to remove the support for running
cpp broker with java broker system tests.

Kind Regards,
Alex


On 20 March 2017 at 10:05, Oleksandr Rudyy <oru...@gmail.com> wrote:

> Hi everybody,
>
> The existing system tests for java broker can be run against cpp
> broker (with some exceptions for the tests relying on java broker REST
> API or java broker specific features).
>
> Is there an interest to continue support of cpp broker in java broker
> system tests?
>
> The reasons behind this question are the following:
> 1)  we want reduce the maintenance efforts for the tests
> 2)  we want to use AMQP management for AMQP 1.0 in the system tests to
> create/delete/update configured entities on the broker but cpp broker
> does not support AMQP management whilst java broker supports it for
> both AMQP 1.0 and AMQP 0.x
>
> Kind Regards,
> Alex
>

[ANNOUNCE] Apache Qpid for Java 6.1.2 released

[Oleksandr Rudyy]

The Apache Qpid (http://qpid.apache.org) community is pleased to announce
the immediate availability of Apache Qpid for Java 6.1.2.

This release incorporates a number of defect fixes and enhancements in
Qpid Broker for Java.

The release is available now from our website:
http://qpid.apache.org/download.html

Binaries are also available via Maven Central:
http://qpid.apache.org/maven.html

Release notes can be found at:
http://qpid.apache.org/releases/qpid-java-6.1.2/release-notes.html

Qpid Java 6.1.2 release page can be found here:
http://qpid.apache.org/releases/qpid-java-6.1.2/index.html


Thanks to all involved,
Alex

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Support for Qpid cpp broker in java broker system tests

[Oleksandr Rudyy]

Hi everybody,

The existing system tests for java broker can be run against cpp
broker (with some exceptions for the tests relying on java broker REST
API or java broker specific features).

Is there an interest to continue support of cpp broker in java broker
system tests?

The reasons behind this question are the following:
1)  we want reduce the maintenance efforts for the tests
2)  we want to use AMQP management for AMQP 1.0 in the system tests to
create/delete/update configured entities on the broker but cpp broker
does not support AMQP management whilst java broker supports it for
both AMQP 1.0 and AMQP 0.x

Kind Regards,
Alex

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[CVE-2016-8741] Apache Qpid Broker for Java - Information Leakage

[Oleksandr Rudyy]

[CVE-2016-8741] Apache Qpid Broker for Java - Information Leakage

Vendor: The Apache Software Foundation

Versions Affected: Apache Qpid Broker for Java versions 6.0.1,
   6.0.2, 6.0.3, 6.0.4, 6.0.5, and 6.1.0

Description:

The Qpid Broker for Java can be configured to use different so
called AuthenticationProviders to handle user authentication.

Among the choices are the SCRAM-SHA-1 and SCRAM-SHA-256
AuthenticationProvider types.

It was discovered that these AuthenticationProviders prematurely
terminate the SCRAM SASL negotiation if the provided user name
does not exist thus allowing remote attacker to determine the
existence of user accounts.

The Vulnerability does not apply to AuthenticationProviders other
than SCRAM-SHA-1 and SCRAM-SHA-256.

Resolution:

Users should upgrade the Qpid Broker for Java to version 6.0.6,
6.1.1, or later (recommended).

Mitigation:

If upgrading is not possible, the vulnerability can be mitigated
by using an AuthenticationProvider other than SCRAM-SHA-1 and
SCRAM-SHA-256.

References:

https://issues.apache.org/jira/browse/QPID-7599

[ANNOUNCE] Apache Qpid for Java 6.0.6 released

[Oleksandr Rudyy]

The Apache Qpid community is pleased to announce the immediate availability
of Apache Qpid for Java 6.0.6.

This release addresses important defect fixes.

The release is available now from our website:
http://qpid.apache.org/download.html

Binaries are also available via Maven Central:
http://qpid.apache.org/maven.html

Release notes can be found at:
http://qpid.apache.org/releases/qpid-java-6.0.6/release-notes.html

Qpid Java 6.0.6 release page can be found here:
http://qpid.apache.org/releases/qpid-java-6.0.6/index.html


Thanks to all users and contributors who have helped to improve Apache Qpid
for Java.

[ANNOUNCE] Apache Qpid for Java 6.1.1 released

[Oleksandr Rudyy]

The Apache Qpid community is pleased to announce the immediate availability
of Apache Qpid for Java 6.1.1.

This release addresses important defect fixes.

The release is available now from our website:
http://qpid.apache.org/download.html

Binaries are also available via Maven Central:
http://qpid.apache.org/maven.html

Release notes can be found at:
http://qpid.apache.org/releases/qpid-java-6.1.1/release-notes.html

Qpid Java 6.1.1 release page can be found here:
http://qpid.apache.org/releases/qpid-java-6.1.1/index.html


Thanks to all users and contributors who have helped to improve Apache Qpid
for Java.

Closing connection whilst MessageListener in-flight delivery is in progress

[Oleksandr Rudyy]

Hi,

Recently I noticed that new jms client can fail to acknowledge the
message (with auto-ack delivery mode) which was in a process of
delivery with MessageListener when Connection#close() is called from
main application thread.

The exception like the one below is delivered into ExceptionListener:
Connection ExceptionListener fired, exiting.
javax.jms.IllegalStateException: The MessageConsumer is closed
at 
org.apache.qpid.jms.JmsMessageConsumer.checkClosed(JmsMessageConsumer.java:328)
at 
org.apache.qpid.jms.JmsMessageConsumer.doAckConsumed(JmsMessageConsumer.java:372)
at 
org.apache.qpid.jms.JmsMessageConsumer.access$600(JmsMessageConsumer.java:52)
at 
org.apache.qpid.jms.JmsMessageConsumer$MessageDeliverTask.run(JmsMessageConsumer.java:679)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)

Although such behavior could be considered JMS spec compliment, as the
specs states in "4.3.5 Closing a Connection" of JMS spec 1.1:
"If one or more of the connection’s session’s message listeners is processing a
message at the point when connection close is invoked, all the facilities of the
connection and its sessions must remain available to those listeners until they
return control to the JMS provider."

Thus, it seems that closing of the connection is allowed without
sending the acknowledgment, as acknowledgment is sent after the
control is returned to JMS provider.

However, from practical point of view such behavior might not be
desirable, as it causes duplicate message deliveries for those
messages not being acknowledged  on close. I would expect from the
client to acknowledge the delivered messages with
MessageConsume#onMessage before the connection close.

Are there any plans to change the client to wait for in-flight message
delivery acknowledgment  before closing the connection?

Kind Regards,
Alex

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Issue with prefetched messages not being released immediately on consumer close

[Oleksandr Rudyy]

Robbie,

I raised JIRA https://issues.apache.org/jira/browse/QPIDJMS-231 for the issue

Alex

On 7 December 2016 at 17:50, Robbie Gemmell <robbie.gemm...@gmail.com> wrote:
> On 7 December 2016 at 16:27, Oleksandr Rudyy <oru...@gmail.com> wrote:
>> Hi ,
>>
>> We were looking into failing  system tests for AMQP 1.0 and discovered
>> that transacted Consumer#close() does not release any prefetched
>> messages immediately. It seems that transactions needs to be finished
>> (committed/rolled back). As result, if another consumer is created
>> before the transaction end, it will not see the acquired messages by
>> closed consumer. Because of this issue the test
>> org.apache.qpid.test.unit.transacted.CommitRollbackTest#testSend2ThenCloseAfter1andTryAgain
>> is failing, as it creates a second consumer and tries to consume the
>> message with this consumer before the transaction for the first closed
>> consumer is committed.
>>
>> It is unclear whether it is a correct behavior or not. However, the
>> legacy JMS client for AMQP 0.x is passing the test. We have to exclude
>> the test from running on AMQP 1.0 profile.
>>
>> Shall I raise a JIRA about this issue?
>>
>> Kind Regards,
>> Alex
>>
>
> Yes, please raise a JIRA. It isnt explicitly releasing messages on
> closing the links...and its handling that particular situation by not
> actually closing the link yet, thus it will currently act as the test
> has found.
>
> Robbie
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Issue with prefetched messages not being released immediately on consumer close

[Oleksandr Rudyy]

Hi ,

We were looking into failing  system tests for AMQP 1.0 and discovered
that transacted Consumer#close() does not release any prefetched
messages immediately. It seems that transactions needs to be finished
(committed/rolled back). As result, if another consumer is created
before the transaction end, it will not see the acquired messages by
closed consumer. Because of this issue the test
org.apache.qpid.test.unit.transacted.CommitRollbackTest#testSend2ThenCloseAfter1andTryAgain
is failing, as it creates a second consumer and tries to consume the
message with this consumer before the transaction for the first closed
consumer is committed.

It is unclear whether it is a correct behavior or not. However, the
legacy JMS client for AMQP 0.x is passing the test. We have to exclude
the test from running on AMQP 1.0 profile.

Shall I raise a JIRA about this issue?

Kind Regards,
Alex

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[ANNOUNCE] Apache Qpid for Java 6.1.0 released

[Oleksandr Rudyy]

The Apache Qpid community is pleased to announce the immediate
availability of Apache Qpid for Java 6.1.0.

The release brings with it the following headline changes:

Management REST API is enhanced with new methods and features
   Query API is added allowing to search for attributes of Broker
 and Virtual Host configured objects matching given filtering criteria
   Support for Cross Origin Resource Sharing is added
   New user preferences API is re-implemented from scratch
   Message publishing via REST API is added
   Message content retrieving REST API is improved
New message consumer features are added
   Consumer priorities
   Experimental support for pulling consumers
New features and improvements are added into Web Management Console
   Dashboard and Query UI
   Improved message content preview
Over 100 bug fixes and improvements were made in 6.1.0

The release is available now from our website:
http://qpid.apache.org/download.html

Binaries are also available via Maven Central:
http://qpid.apache.org/maven.html

Release notes can be found at:
http://qpid.apache.org/releases/qpid-java-6.1.0/release-notes.html

Qpid for Java 6.1.0 release page can be found here:
http://qpid.apache.org/releases/qpid-java-6.1.0/index.html

Thanks to all involved.
Qpid Team

[ANNOUNCE] Apache Qpid for Java 6.0.5 released

[Oleksandr Rudyy]

The Apache Qpid community is pleased to announce the immediate
availability of Apache Qpid for Java 6.0.5.

This release incorporates a number of defect fixes and enhancement.

The release is available now from our website:
http://qpid.apache.org/download.html

Binaries are also available via Maven Central:
http://qpid.apache.org/maven.html

Release notes can be found at:
http://qpid.apache.org/releases/qpid-java-6.0.5/release-notes.html

Qpid for Java 6.0.5 release page can be found here:
http://qpid.apache.org/releases/qpid-java-6.0.5/index.html

Thanks to all involved.
Alex

[VOTE] Release Qpid Java 6.0.5

[Oleksandr Rudyy]

Hi all,

A release candidate for the next 6.0.5 release of the Qpid Java Components
has been created.

A number of important defect fixes and improvements have been made in this
release.
The list of changes can be found in Jira:
https://issues.apache.org/jira/issues/?jql=project%20%3D%20QPID%20AND%20fixVersion%20%3D%20qpid-java-6.0.5

Please test and vote accordingly.

The source and binary archives can be accessed here:
https://dist.apache.org/repos/dist/dev/qpid/java/6.0.5-rc1

Those files and the other maven artifacts are also staged for now at:
https://repository.apache.org/content/repositories/orgapacheqpid-1090

Kind regards
Alex

P.S. For testing of 6.0.5 maven artifacts please add the staging repo as
below:

  

  staging
  
https://repository.apache.org/content/repositories/orgapacheqpid-1090

  

Re: Proton-c build failed with error: undefined reference to `proton::timestamp::now()'

[Oleksandr Rudyy]

Robbie,
Thanks for reply.
My apologies I missed the commit fixing the issue.

Alex

On 16 September 2016 at 11:27, Robbie Gemmell <robbie.gemm...@gmail.com> wrote:
> As I've mentioned on the JIRA, it looks like this commit yesterday was
> about addressing that:
> https://git-wip-us.apache.org/repos/asf?p=qpid-proton.git;a=commit;h=44875208
>
> Robbie
>
> On 16 September 2016 at 10:28, Oleksandr Rudyy <oru...@gmail.com> wrote:
>> Hi all,
>> The proton-c build failed as part of jenkins job Qpid-Python-Java-Test
>> [1] with the following error
>>
>> Linking CXX shared library libqpid-proton-cpp.so
>> CMakeFiles/qpid-proton-cpp.dir/src/connector.cpp.o: In function
>> `proton::connector::on_transport_closed(proton::proton_event&)':
>> /home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/qpid-proton/proton-c/bindings/cpp/src/connector.cpp:83:
>> undefined reference to `proton::timestamp::now()'
>> collect2: ld returned 1 exit status
>> make[2]: *** [proton-c/bindings/cpp/libqpid-proton-cpp.so.9.0.0] Error 1
>> make[1]: *** [proton-c/bindings/cpp/CMakeFiles/qpid-proton-cpp.dir/all] 
>> Error 2
>> make: *** [all] Error 2
>>
>>
>> It looks like chrono library was not available on jenkins node and
>> now() was not defined but it was still referenced...
>>
>> The job prints names of installed packages and available libraries
>> into its log [2].
>>
>> Kind Regards,
>> Alex
>>
>> [1] 
>> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Python-Java-Test/1154/
>> [2] 
>> https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Python-Java-Test/1154/console
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
>> For additional commands, e-mail: dev-h...@qpid.apache.org
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Proton-c build failed with error: undefined reference to `proton::timestamp::now()'

[Oleksandr Rudyy]

Hi all,
The proton-c build failed as part of jenkins job Qpid-Python-Java-Test
[1] with the following error

Linking CXX shared library libqpid-proton-cpp.so
CMakeFiles/qpid-proton-cpp.dir/src/connector.cpp.o: In function
`proton::connector::on_transport_closed(proton::proton_event&)':
/home/jenkins/jenkins-slave/workspace/Qpid-Python-Java-Test/qpid-proton/proton-c/bindings/cpp/src/connector.cpp:83:
undefined reference to `proton::timestamp::now()'
collect2: ld returned 1 exit status
make[2]: *** [proton-c/bindings/cpp/libqpid-proton-cpp.so.9.0.0] Error 1
make[1]: *** [proton-c/bindings/cpp/CMakeFiles/qpid-proton-cpp.dir/all] Error 2
make: *** [all] Error 2


It looks like chrono library was not available on jenkins node and
now() was not defined but it was still referenced...

The job prints names of installed packages and available libraries
into its log [2].

Kind Regards,
Alex

[1] https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Python-Java-Test/1154/
[2] 
https://builds.apache.org/view/M-R/view/Qpid/job/Qpid-Python-Java-Test/1154/console

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Apache Qpid Java naming concerns

[Oleksandr Rudyy]

Hi all,

I believe I addressed the naming issue of Qpid  java based components.
In a number of commits under QPID-7341 [1] I changed the sources
including documentation and Qpid site to use the following names when
referring java based components:

'Apache Qpid for Java' or 'Qpid for Java' when referring all
java-based components together
'Apache Qpid Broker for Java' or 'Qpid Broker for Java' or 'Broker for
Java' when referring Java Broker
'Apache Qpid JMS Client for AMQP 0-9-1/0-10' or 'Qpid JMS Client for
AMQP 0-9-1/0-10' or 'JMS Client' or 'the Client' when referring Qpid
Java Client for AMQP 0.x.

Kind Regards,
Alex


[1] https://issues.apache.org/jira/browse/QPID-7341

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: [NOTICE] cpp and python subdirs of svn trunk have migrated to git repositories

[Oleksandr Rudyy]

Hi all,

I updated configurations for jobs "Qpid-cpp-trunk-test" and
"Qpid-Java-Cpp-Test" to get sources from new git repos.
Lorenz did the same for job "Qpid-Python-Java-Test".

The jobs are running and building.

However,  the failed tests on job "Qpid-cpp-trunk-test" do not mark the job
as failed. It seems that the same failed tests did not mark the job as
failed previously before my change.
I did not look into this problem.

Kind Regards,
Alex

[1] https://builds.apache.org/view/M-R/view/Qpid


On 5 July 2016 at 23:04, Robbie Gemmell  wrote:

> The migration to the new git repositories have now been performed:
> https://git-wip-us.apache.org/repos/asf/qpid-cpp.git
> https://git-wip-us.apache.org/repos/asf/qpid-python.git
>
> Some additional tasks still need completed now that the migration has
> been done. See the JIRAs for further details:
> https://issues.apache.org/jira/browse/INFRA-11794
> https://issues.apache.org/jira/browse/INFRA-11795
>
> I have deleted the cpp and python subdirs of svn trunk to prevent
> continued use.
>
> I have disabled the following Jenkins Jobs for now, their config still
> needs updated to reflect the changes:
> Qpid-cpp-trunk-test
> Qpid-Java-Cpp-Test
> Qpid-Python-Java-Test
>
> I also realised that the .gitignore details in the old repo was in the
> parent dir, so each of the new repos will need their own added giving
> similar effect.
>
> Robbie
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>
>

Re: [NOTICE] cease commits to cpp and python subdirs of svn trunk, migrating to git

[Oleksandr Rudyy]

Hi,

It looks like a number of commits is missed in git repo.

I tried to compile cpp sources from
https://git-wip-us.apache.org/repos/asf/qpid-cpp.git but compilation
failed.

The compilation errors are similar to the ones reported by Keith
couple days ago. The fixes have been made as part of QPID-7306.

Here is an extract from build output with compilation failures:


[ 57%] Building CXX object
src/CMakeFiles/qpidmessaging.dir/qpid/messaging/FailoverUpdates.cpp.o

cc1plus: warnings being treated as errors
In file included from
/apps/qpid/jenkins/workspace/Apache-Qpid-Cpp/src/qpid/broker/TopicExchange.h:30,
 from
/apps/qpid/jenkins/workspace/Apache-Qpid-Cpp/src/qpid/acl/AclTopicMatch.h:23,
 from
/apps/qpid/jenkins/workspace/Apache-Qpid-Cpp/src/qpid/acl/AclData.h:25,
 from
/apps/qpid/jenkins/workspace/Apache-Qpid-Cpp/src/qpid/acl/AclReader.h:30,
 from
/apps/qpid/jenkins/workspace/Apache-Qpid-Cpp/src/qpid/acl/Acl.h:25,
 from
/apps/qpid/jenkins/workspace/Apache-Qpid-Cpp/src/qpid/acl/Acl.cpp:19:
/apps/qpid/jenkins/workspace/Apache-Qpid-Cpp/src/qpid/broker/Queue.h:540:
error: ‘qpid::broker::QueueRegistry’ is already a friend of
‘qpid::broker::Queue’
[ 57%] Building CXX object
src/CMakeFiles/qpidbroker.dir/qpid/acl/AclConnectionCounter.cpp.o
[ 58%] Building CXX object
src/CMakeFiles/qpidmessaging.dir/qpid/messaging/Logger.cpp.o

make[2]: *** [src/CMakeFiles/qpidbroker.dir/qpid/acl/Acl.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs
Scanning dependencies of target qpid-txtest
[ 59%] Building CXX object
src/tests/CMakeFiles/qpid-txtest.dir/qpid-txtest.cpp.o
Scanning dependencies of target receiver
[ 59%] Building CXX object src/tests/CMakeFiles/receiver.dir/receiver.cpp.o
cc1plus: warnings being treated as errors
In file included from
/apps/qpid/jenkins/workspace/Apache-Qpid-Cpp/src/qpid/broker/TopicExchange.h:30,
 from
/apps/qpid/jenkins/workspace/Apache-Qpid-Cpp/src/qpid/acl/AclTopicMatch.h:23,
 from
/apps/qpid/jenkins/workspace/Apache-Qpid-Cpp/src/qpid/acl/AclData.h:25,
 from
/apps/qpid/jenkins/workspace/Apache-Qpid-Cpp/src/qpid/acl/AclConnectionCounter.h:27,
 from
/apps/qpid/jenkins/workspace/Apache-Qpid-Cpp/src/qpid/acl/AclConnectionCounter.cpp:22:
/apps/qpid/jenkins/workspace/Apache-Qpid-Cpp/src/qpid/broker/Queue.h:540:
error: ‘qpid::broker::QueueRegistry’ is already a friend of
‘qpid::broker::Queue’
make[2]: *** [src/CMakeFiles/qpidbroker.dir/qpid/acl/AclConnectionCounter.cpp.o]
Error 1
make[1]: *** [src/CMakeFiles/qpidbroker.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs
[ 59%] Building CXX object
src/CMakeFiles/qpidmessaging.dir/qpid/messaging/Message.cpp.o

[ 59%] Building CXX object
src/CMakeFiles/qpidmessaging.dir/qpid/messaging/Receiver.cpp.o
[ 59%] Building CXX object
src/CMakeFiles/qpidmessaging.dir/qpid/messaging/Session.cpp.o

[ 59%] Building CXX object
src/CMakeFiles/qpidmessaging.dir/qpid/messaging/Sender.cpp.o
Linking CXX executable receiver
[ 59%] Built target receiver
[ 59%] Building CXX object
src/CMakeFiles/qpidmessaging.dir/qpid/messaging/ConnectionOptions.cpp.o
[ 60%] Building CXX object
src/CMakeFiles/qpidmessaging.dir/qpid/messaging/MessageImpl.cpp.o

[ 60%] Building CXX object
src/CMakeFiles/qpidmessaging.dir/qpid/messaging/Message_io.cpp.o
[ 60%] Building CXX object
src/CMakeFiles/qpidmessaging.dir/qpid/messaging/ProtocolRegistry.cpp.o
[ 60%] Building CXX object
src/CMakeFiles/qpidmessaging.dir/qpid/messaging/amqp/EncodedMessage.cpp.o
Linking CXX executable qpid-txtest
[ 60%] Built target qpid-txtest

Linking CXX shared library libqpidmessaging.so
[ 60%] Built target qpidmessaging
make: *** [all] Error 2

Kind Regards,
Alex


On 29 June 2016 at 13:18, Robbie Gemmell  wrote:
> Hi folks,
>
> As per previous discussion/votes, the reorganised cpp and python bits
> will be migrating to their own git repositories. The migration is due
> to begin in the next hour or two.
>
> It isn't clear that the svn subdirs will actually be locked at this
> time, so please take note to cease committing to them. If they aren't
> locked (or I guess, even if they are..) we will need to decide what
> approach to take with the old dirs going forward, e.g clear the files
> out and leave a pointer file, eventually remove the dir, etc.
>
> https://issues.apache.org/jira/browse/INFRA-11794
> https://issues.apache.org/jira/browse/INFRA-11795
>
> Robbie
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

[ANNOUNCE] Apache Qpid Java 6.0.3 released

[Oleksandr Rudyy]

The Apache Qpid community is pleased to announce the immediate availability
of Apache Qpid Java 6.0.3.

This release addresses CVE-2016-3094, CVE-2016-4432 vulnerabilities and
incorporates a number of defect fixes and enhancements.

The release is available now from our website:
http://qpid.apache.org/download.html

Binaries are also available via Maven Central:
http://qpid.apache.org/maven.html

Release notes can be found at:
http://qpid.apache.org/releases/qpid-java-6.0.3/release-notes.html

Qpid Java 6.0.1 release page can be found here:
http://qpid.apache.org/releases/qpid-java-6.0.3/index.html


Thanks to all the users and contributors who have helped to improve Apache
Qpid Java.

[ANNOUNCE] Apache Qpid Java 6.0.2 released

[Oleksandr Rudyy]

The Apache Qpid community is pleased to announce the immediate availability
of Apache Qpid Java Components 6.0.2

This release incorporates a number of defect fixes and enhancement.

The release is available now from our website:
http://qpid.apache.org/download.html

Binaries are also available via Maven Central:
http://qpid.apache.org/maven.html

Release notes can be found at:
http://qpid.apache.org/releases/qpid-java-6.0.2/release-notes.html

Qpid Java 6.0.2 release page can be found here:
http://qpid.apache.org/releases/qpid-java-6.0.2/index.html

Thanks to all involved.
Alex

[ANNOUNCE] Apache Qpid Java Broker and JMS Client for AMQP 0-8..0-10 version 6.0.1 is released

[Oleksandr Rudyy]

The Apache Qpid community is pleased to announce the immediate availability
of version 6.0.1 for Apache Qpid Java Broker and JMS Client for AMQP
0-8...0-10.

This release incorporates a number of defect fixes and enhancements.

The release is available now from our website:
http://qpid.apache.org/download.html

Binaries are also available via Maven Central:
http://qpid.apache.org/maven.html

Release notes can be found at:
http://qpid.apache.org/releases/qpid-java-6.0.1/release-notes.html

Qpid Java 6.0.1 release page can be found here:
http://qpid.apache.org/releases/qpid-java-6.0.1/index.html

Thanks to all involved.
Alex

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Re: [Proposal] Roadmap for ending Java 7 support for the Java Broker and AMQP 0-x client

[Oleksandr Rudyy]

+1 to Robs suggestions

On 11 February 2016 at 15:12, Rob Godfrey  wrote:
> All,
>
> about 2 years ago we discussed the roadmap for ending support for Java 6
> [1].  In April it will be one year since Oracle ceased public support for
> Java 7.  Towards the end of this year (hopefully) Java 9 will be released.
> As such I think it is time for us to start discussing how long we will
> continue to support Java 7 as a platform for new feature releases of the
> Java Broker and the AMQP 0-x client.
>
> Our current Java roadmap[2] has us scheduled for a Q1 release of Qpid v6.1
> and a Q3 release of Qpid v7 (with a v7.1 release to follow some time after
> that).  What I would like to propose is that v6.1 will be the last feature
> release where we commit to supporting Java 7 for the Broker.  That for Qpid
> v7 we commit to supporting Java 7 and 8 as platforms for the client - but
> that the Broker will support only Java 8.  Further I propose that Qpid v8
> (release data TBD, but sometime in 2017) will support Java 8 and Java 9
> (presuming it has been released) but we will no longer support Java 7 as a
> platform for the client.
>
> To aid users who cannot upgrade from Java 7 we will commit to producing bug
> fix releases on the Qpid v6.1.x line for at least one further year (and
> probably longer) after the initial v6.1 release.
>
> In terms of drivers for ending Java 7 support... we have already seen some
> of our key dependencies (such as Jetty) drop support for Java 7.  We also
> are running into issues where the age the Java 7 platform makes it hard to
> support modern security standards, or it simply does not support APIs
> necessary for correct implementations of AMQP 1.0 semantics (e.g. Java 7
> does not provide server name identification support for TLS on the server
> side - which AMQP 1.0 requires to identify desired virtual hosts).  From
> experience, it will also become overly burdensome to start trying to
> support three different Java versions once Java 9 is released.
>
> Thoughts?
>
> Rob
>
> [1]
> http://mail-archives.apache.org/mod_mbox/qpid-users/201404.mbox/%3CCACsaS94O8g3-+895GEKE-b0sP128mMM2hsg4mjNJHr28W=b...@mail.gmail.com%3E
>
>
> [2] https://cwiki.apache.org/confluence/display/qpid/Java+Roadmap

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Question about PGP signing keys location for Qpid project

[Oleksandr Rudyy]

Robbie,
Thanks for detailed explanation. I will append my key into KEYS file.

Kind Regards,
Alex

On 2 December 2015 at 17:01, Robbie Gemmell <robbie.gemm...@gmail.com> wrote:
> On 2 December 2015 at 16:20, Oleksandr Rudyy <oru...@gmail.com> wrote:
>> Hi all,
>>
>> Whilst performing release tasks for qpid java components of version 6.0.0 I
>> realized that KEYS file [1] referred from Qpid download page [2] is
>> actually not up to date.
>>
>> As far as I understood currently public PGP signing keys for qpid project
>> are kept in [3].
>>
>> I am not sure why download page refers public keys from [1]. Is it
>> intentional?
>> If yes, what is the rationale behind that?
>> If not, we need to update download page to refer keys from [2].
>>
>> Kind Regards,
>> Alex
>>
>> [1] http://www.apache.org/dist/qpid/KEYS
>> [2] https://qpid.apache.org/download.html#verify-what-you-download
>> [3] https://people.apache.org/keys/group/qpid.asc
>
>
> Great timing, I was also planning a mail on the subject as I had
> grabbed your key from
> https://people.apache.org/keys/committer/orudyy.asc earlier to verify
> the files.
>
> Long ago, when the bits were put in place for
> https://people.apache.org/keys/ (files are available for
> individual committers, committer groups, and pmc groups) I think the
> idea was that folks could transition to using that as the source for
> their keys. Traditionally the source was just a KEYS file in the
> source repository, but this can be a little cumbersome and certainly
> becomes a bit more awkward when you have multiple repositories as we
> now do.
>
> Having a KEYS file on the main dist area (populated from the generated
> file) still seems reasonable enough given it is the primary source,
> contains the other files, and is explicitly updated. Like the sig
> files, I don't believe it gets mirrored. Pointing directly to the
> auto-generated files also seems reasonable enough (one thought that
> just popped into my mind is that people.apache.org is being
> transitioned away, with home dirs moving to home.apache.org soon, and
> other services to be addressed when the time comes, not sure if that
> will have any impact here). Both seem like improvement over keeping
> the current source file in SVN, particularly when many of the
> components now live in other repos.
>
> Robbie
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
> For additional commands, e-mail: dev-h...@qpid.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Question about PGP signing keys location for Qpid project

[Oleksandr Rudyy]

Hi all,

Whilst performing release tasks for qpid java components of version 6.0.0 I
realized that KEYS file [1] referred from Qpid download page [2] is
actually not up to date.

As far as I understood currently public PGP signing keys for qpid project
are kept in [3].

I am not sure why download page refers public keys from [1]. Is it
intentional?
If yes, what is the rationale behind that?
If not, we need to update download page to refer keys from [2].

Kind Regards,
Alex

[1] http://www.apache.org/dist/qpid/KEYS
[2] https://qpid.apache.org/download.html#verify-what-you-download
[3] https://people.apache.org/keys/group/qpid.asc

Maven parent

[Oleksandr Rudyy]

Hi guys,

We have a maven project in  Qpid svn root [1]. At the moment it does
not have much attention and care. Thus, it contains outdated
information. Only Qpid java components depend on it at the moment.

I am going to remove that dependency in qpid-java-6 and move some of
useful parent pom functionality into qpid-java pom.xml in order to
implement some urgent changes to license generation and checks
reported as blocker [2]. Otherwise, we need to release a new parent
pom version with the changes. That requires separate release process,
including voting, which is unnecessary overhead to our release
process.

When I remove the dependency to Qpid parent pom from qpid-java, it
will became unused and potentially could be deleted.

Shall we delete it? Any thoughts?

In future we are planning to split qpid-java into 2 separate projects:
qpid java broker and qpid legacy jms client. We might need parent pom
project for them but I am not sure.

Kind Regards,
Alex

[1] https://svn.apache.org/repos/asf/qpid/maven
[2] https://issues.apache.org/jira/browse/QPID-6772

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Trunk re-organisation

[Oleksandr Rudyy]

Hi,

I moved java source tree into top level [1]
Additionally, I raised an infra request to create git mirror for java
source tree [2].

Now, we need to decide how to change site generation scripts in order to
publish java release artifacts like documentation, java related site pages,
etc.

Kind Regards,
Alex

[1] https://svn.apache.org/repos/asf/qpid/java/trunk
[2] https://issues.apache.org/jira/servicedesk/customer/portal/1/INFRA-9446

Re: Trunk re-organisation

[Oleksandr Rudyy]

 One thing that just occurred to me is that by moving the java dir its
 contents will no longer be available via the git mirrors as it
 currently is, so it would need to be requested for new mirrors at
 git.apache.org and GitHub.


Hi Robbie,
I am going to request a new git mirror for java source tree as soon as I
perform the move.
It seems I need to raise a new infra request SVN to GIT MIrroring at [1].
Is anything else needs to be done for that? How did you request git mirror
for new JMS client?

Kind Regards,
Alex


[1] https://issues.apache.org/jira/servicedesk/customer/portal/1/create/17

Re: Trunk re-organisation

[Oleksandr Rudyy]

Hi,
I am going to proceed with re-organizing of java source tree tomorrow.
I created a page with possible steps to follow at [1].

Please, let me know if the sources move can impact anyone and it needs to
be delayed.

Kind Regards,
Alex

[1]
https://cwiki.apache.org/confluence/display/qpid/Move+java+source+tree+under+qpid+root

Re: Trunk re-organisation

[Oleksandr Rudyy]

Keith,
I agree it seems the good time to start changing project layout and
introduce independent sub-projects.
The proposed layout looks reasonable. Although, qpid-java sub-projects will
be split later into more sub-projects. Apart from the ones you listed on
wiki (java-broker and java-legacy-client), it seems there will be at least
one java-amqp-commons (conatining 0.8/0.9.x/0.10 AMQP classes) which can be
split into protocol based sub-modules (java-amqp-commons-0_10 and
java-amqp-commons-0_8-0_9_x).

Regarding 'Programming in Apache Qpid' docbook it can either be a separate
top-level sub-project (as it covers cpp and java legacy client) or we can
temporary move it into qpid-cpp (as the majority of content in the book is
related to cpp clients or cpp bindings based clients)

Kind Regards,
Alex


On 16 March 2015 at 18:12, Keith W keith.w...@gmail.com wrote:

 Hello all,

 I believe we reached agreement on the following thread [1] that we would
 reorganise trunk (to support independent component releases) once the 0.32
 was branched.

 Justin previously published a source tree layout proposal.  I have just
 extended it to include the Java subtree too.


 https://cwiki.apache.org/confluence/display/qpid/Source+tree+layout+proposal

 As 0.32 is branched (and at the voting stage), is there anything that
 blocks us from beginning the re-org task?  Are there comments on the
 proposed layouts?

 I am ready to work with other committers to help make sure the transition
 is a smooth one.

 cheers, Keith.


 [1]

 https://www.mail-archive.com/search?l=us...@qpid.apache.orgq=subject:%22Re%3A+Any+ETA+on+a+QPid+0.32+release%22o=newest

Re: Request for inclusion into 0.32

[Oleksandr Rudyy]

Justin,

I would like to request an inclusion of QPID-6410( [Java Broker]
Disambiguate the connection adapter name by adding a connection ID to the
name) :
https://svn.apache.org/r1661929


We ran into the issue this morning. If not fixed, there is a risk of a
dead-lock on broker side caused by the defect.
The change itself is small (the the majority of the fix is comprised of
changes to the tests ).

The changes are reviewed by Keith

Kind Regards,
Alex

On 24 February 2015 at 12:55, Justin Ross justin.r...@gmail.com wrote:

 Thanks, Keith.  It's now approved for 0.32.

 On Tue, Feb 24, 2015 at 7:50 AM, Keith W keith.w...@gmail.com wrote:

  Hi Justin
 
 
 
  On 24 February 2015 at 12:31, Justin Ross justin.r...@gmail.com wrote:
 
  The latter three are approved.
 
  On the first, QPID-6247.  You say only affects a part of Broker
  functionality responsible for writing updates to configuration files.
  This is the primary way users will store their configuration, true?  If
  so,
  that's not isolated.
 
  It's also not small.  Which leaves us with importance.  Does this
 deserve
  an exception because it's a particularly severe defect?  It looks (to
 the
  uninformed, me) like a normal priority defect.  Is it a regression?
 
 
  It is true that QPID-6247 is a long standard defect, however, with
  changes we have already made in 0.32 the severity is increased.   0.32
  brings with it the ability to upload private keys through the UI.  By
  default, these keys are stored - inlined - within the Broker's
  configuration files and are written to disk.  If we don't include
 QPID-6247
  the Broker won't preserve the file permissions on the configuration files
  through the update, and it could therefore become inadvertently readable
 by
  others.  This would represent a security issue.   Apologies, we should
 have
  identified the interdependency between this existing defect and the new
  feature earlier in the cycle.
 
  Kind regards, Keith
 
 
 
 
 

Request for inclusion into 0.32

[Oleksandr Rudyy]

Justin,
Could you please authorize an inclusion of the following into 0.32?

QPID-6247: Updates to configuration files should maintain existing file
permissions
https://svn.apache.org/r1661162
https://svn.apache.org/r1661530

The commits above allow to preserve original configuration files
permissions after updates initiated from Broker management layers. The
changes were reviewed by Keith and only affect a part of Broker
functionality responsible for writing updates to configuration files.

QPID-6364 [Java Broker] Keystore data url must be a secure attribute
https://svn.apache.org/r1661165

The change fixes an issue introduced in previous commit for the same JIRA
(which was incorporated into branch) and only affects REST management layer
of Qpid Broker. It was reviewed by Keith.

QPID-6398: [Java Broker] Update web management console UI to invoke dojo
parser.parse as a promise
https://svn.apache.org/r1661166
Fixes a bug in Java Broker web management console which was causing a
premature invocation of widgets in the UI before parsing of UI is actually
finished.
If not applied, the UI might suffer from sporadic failures. The change only
affects web management console UI. It was reviewed by Keith.

QPID-6346: [Java Broker] Fix field reference when file reader is unsupported
https://svn.apache.org/r1661207
The change fixes a bug in one of web management widgets. It is a trivial
change which does not affect Broker core functionality. The fix was
reviewed by Keith.

Kind Regards,
Alex

Re: connection refused error for a Java EE app with RabbitMQ broker, Qpid JMS client

[Oleksandr Rudyy]

Hi,

Your specified a broker host as localhost in your connection URL.
I suppose that your client application is not located on the same host
as broker. Thus, the connection cannot be established and error is
reported.
You can replace the locahost with turtle.rmq.cloudamqp.com in your
connection URL and try again.

Please, have a look at [1] for more details about Qpid connection URL format.

Kind Regards,
Alex

[1] http://qpid.apache.org/releases/qpid-0.24/programming/book/QpidJNDI.html

On 11 November 2013 23:35, beon2013 ming.li.e...@gmail.com wrote:
 In my Java EE application, I want send and receive a message using a RabbitMQ
 broker and a Qpid JMS client.


 The information about RabbitMQ broker is as follow:

 Server: turtle.rmq.cloudamqp.com
 User: tsikywzh
 Password: Z_1x359XUuKfkcK0PoohUVBWlqXtxVh
 AMQP URL:
 amqp://tsikywzh:z_1x359xuukfkck0poohuvbwlqxt...@turtle.rmq.cloudamqp.com/tsikywzh


 The code for send a message using the Qpid JMS client:

 public void sendMessage(){
 logger.log(Level.INFO, Sending message {0}, messageText);
 Properties properties = new Properties();

 properties.load(SenderBean.class.getResourceAsStream(/websimplemessage.properties));
 Context context = new InitialContext(properties);
 ConnectionFactory connectionFactory = (ConnectionFactory)
 context.lookup(qpidConnectionfactory);
 Connection connection = connectionFactory.createConnection();
 connection.start();
 Session session = connection.createSession(false,
 Session.AUTO_ACKNOWLEDGE);
 Destination destination = (Destination)
 context.lookup(topicExchange);
 MessageProducer messageProducer =
 session.createProducer(destination);
 String text = Message from producer:  + messageText;
 TextMessage message = session.createTextMessage(text);
 messageProducer.send(message);
 connection.close();
 context.close();
 }
 Which uses this Apache Qpid JNDI Properties File websimplemessage.properties
 :

 java.naming.factory.initial =
 org.apache.qpid.jndi.PropertiesFileInitialContextFactory
 connectionfactory.qpidConnectionfactory =
 amqp://tsikywzh:z_1x359xuukfkck0poohuvbwlqxt...@turtle.rmq.cloudamqp.com/tsikywzh?brokerlist='tcp://localhost:5672'
 destination.topicExchange = amq.topic

 Unfortunately, when I run the application, I get connection errors:

 SenderBean.sendMessage: Exception: javax.jms.JMSException: Error creating
 connection: Connection refused

 I am sure RabbitMQ broker is work. Maybe the Qpid JNDI properties File is
 not correct.

 How can I solve this error? Thanks



 --
 View this message in context: 
 http://apache-qpid-developers.2158895.n2.nabble.com/connection-refused-error-for-a-Java-EE-app-with-RabbitMQ-broker-Qpid-JMS-client-tp7590925.html
 Sent from the Apache Qpid developers mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
 For additional commands, e-mail: dev-h...@qpid.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Qpid java broker ACL

[Oleksandr Rudyy]

Hi Lalit,

With Qpid Java Broker ACL you can restrict the access by IP/network to
virtual hosts, for example

ACL ALLOW guest ACCESS VIRTUALHOST name=default
from_hostname=.*\.company1\.com,.*\.company1\.co\.uk
ACL DENY messaging-users ACCESS VIRTUALHOST
from_network=192.169.1.*,192.169.2.*

Queue/Exchange ACL rules do not allow to set any IP/network
restrictions. However, you can configure ACL rules to CREATE, CONSUME,
DELETE queues and PUBLISH, BIND, UNBIND, CREATE, DELETE exchanges per
user or group, for example

ACL ALLOW guest CREATE QUEUE
ACL ALLOW messaging-users CONSUME QUEUE
ACL ALLOW messaging-users DELETE QUEUE
ACL ALLOW client PUBLISH EXCHANGE name=amq.direct

Please, have a look into Java Broker Documentation at [1] for more
details about Java Broker supported ACL.

Kind Regards,
Alex

[1] 
http://qpid.apache.org/releases/qpid-0.24/java-broker/book/Java-Broker-Security-ACLs.html

On 4 October 2013 11:05,  lal...@barc.gov.in wrote:
 Dear Sir/Madam

 Is it possible to provide Queue access control(ACL) based on
 publisher/consumer/client IP address in Qpid JAVA based broker. If
 possible, what is the way out?

 Thanks in advance

 cheers
 Lalit D.


 -
 To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
 For additional commands, e-mail: dev-h...@qpid.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Welcome Pavel Moravec as a Qpid committer

[Oleksandr Rudyy]

Welcome Pavel!

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: POLL: what to do with dev list

[Oleksandr Rudyy]

2. Keep the dev list but only for traffic not relevant to users of the code

I am curious what that traffic might include?
Developer polls, organization issues? What else?

It looks like discussions about various aspects of implementation might be
interesting for the end users.


On 23 August 2013 13:50, Gordon Sim g...@redhat.com wrote:

 Please indicate your preference:

 1. Remove the dev list entirely

 2. Keep the dev list but only for traffic not relevant to users of the code

 3. Keep dev list for some wider set of traffic (please specify criteria
 you believe applies if selecting this option)

 --**--**-
 To unsubscribe, e-mail: 
 dev-unsubscribe@qpid.apache.**orgdev-unsubscr...@qpid.apache.org
 For additional commands, e-mail: dev-h...@qpid.apache.org

Re: [VOTE] Remove autotools build for C++ build

[Oleksandr Rudyy]

[X ] * When 0.25 opens after the 0.24 beta branch remove the C++

   qpid autotools build infrastructure in favour of the cmake tools.
 * A heads up message to the user mailing list.
 * Add a release note to 0.24 to say it is the last release that will
   contain an autotools build.
 * Add a release note to 0.26 to say that only cmake is available
   from this release forward
 [ ] We're not ready for this yet, here's why:

Re: [VOTE] Release 0.22 RC6 as 0.22 final

[Oleksandr Rudyy]

+1


On 26 May 2013 11:35, Justin Ross jr...@apache.org wrote:

 RC6 contains the proposed final bits for Qpid 0.22.

 If you favor making the RC6 bits into our official release, vote +1.
 If you have reason to believe RC6 is not ready for release, vote -1.

 Thanks!
 Justin

 -
 To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
 For additional commands, e-mail: dev-h...@qpid.apache.org

Re: [VOTE] Create a QPIDJMS JIRA project

[Oleksandr Rudyy]

Yes [ X ]
No [  ]


On 28 May 2013 16:05, Robbie Gemmell robbie.gemm...@gmail.com wrote:

 Following recent discussions regarding a more component-focused structure,
 and beginning work on a Proton-based AMQP 1.0 JMS client, could everyone
 please vote on the following:

 Create a QPIDJMS JIRA project and request the Subversion integration for
 it.

 Yes [  ]
 No [  ]

Re: [VOTE] Subversion to JIRA integration

[Oleksandr Rudyy]

QPID:
Yes [X ]
No [  ]

PROTON:
Yes [ X]
No [  ]


On 24 May 2013 12:03, Robbie Gemmell robbie.gemm...@gmail.com wrote:

 Hi all,

 As some of you will already know, a mail was sent to committers@a.oearlier
 outlining some of the newer services ASF infra offer that we may not know
 about. One in particular stuck out for me, a service to populate JIRAs with
 information about relavant commits to Subversion or Git. I have always
 missed the Subversion integration within JIRA since it had to be disabled
 (it seemingly doesn't work very well with repositories of the size found at
 the ASF), so I would love to get something back in this area. You can find
 the details here: http://www.apache.org/dev/svngit2jira.html

 I would like to request this for both the QPID and PROTON JIRA instances.
 They indicate they would like agreement before enabling it, as unlike the
 older integration it generates a bit of traffic by actually posting
 comments on the JIRAs, so please vote now:

 QPID:
 Yes [  ]
 No [  ]

 PROTON:
 Yes [  ]
 No [  ]


 Robbie

Re: [VOTE] Release 0.22

[Oleksandr Rudyy]

The batch and doc/hep changes have been merged into 0.22 branch.


On 24 May 2013 12:40, Robbie Gemmell robbie.gemm...@gmail.com wrote:

 I had a look and it seems reasonable, fixing the issue to the extent
 possible without substantial change and no apparent impact in other usage
 of the script which was tested. Windows users will need to quote the value,
 so I have committed another tiny change to update the docs/help to reflect
 that.

 Robbie

 On 24 May 2013 11:40, Justin Ross justin.r...@gmail.com wrote:

  I don't really object to including this.  Can we have someone with
  batch script skills take a quick look at it?
 
  Justin
 
  On Thu, May 23, 2013 at 6:28 PM, Oleksandr Rudyy oru...@gmail.com
 wrote:
   Justin,
  
   I hope it is still not too late to request the inclusion into 0.22  of
  a
   minor fix for Windows batch script to start Java Broker (
   http://svn.apache.org/r1485859  QPID-4881).
  
   We introduced new command line arguments requiring to pass an equal
   character as part of the argument but the batch script splits the
 command
   line argument with 'equal' into two arguments and removes equal
  character.
   Such arguments have to be quoted but processing of quoted arguments
   resulted in the errors.
  
   The changes fixed the processing of quoted arguments. It is a minor
 issue
   and there are some workarounds but I would like to request the
 inclusion
  of
   the fix as it is quite trivial.
  
   Kind Regards,
   Alex
  
  
  
   On 23 May 2013 22:40, Ken Giusti kgiu...@redhat.com wrote:
  
   Justin,
  
   A new RC, you say?
  
   Well, I'll just leave this little tidbit here, ya know, just in case:
  
   https://issues.apache.org/jira/browse/QPID-4883
  
   /backs slowly away from my keyboard
  
  
  
   - Original Message -
From: Justin Ross jr...@apache.org
To: dev@qpid.apache.org
Sent: Thursday, May 23, 2013 10:34:58 AM
Subject: Re: [VOTE] Release 0.22
   
This vote is withdrawn.  We'll have a new RC later today.  The only
new change will be the cmake build fix.  Once that's available, I'll
start a new vote thread.
   
Justin
   
On Wed, May 22, 2013 at 5:14 PM, Justin Ross jr...@apache.org
  wrote:
 Okay, we'll fix it tomorrow.

 On May 22, 2013 4:09 PM, Darryl L. Pierce dpie...@redhat.com
   wrote:

 On Wed, May 22, 2013 at 01:54:50PM -0400, Justin Ross wrote:
  RC5 contains the proposed final bits for Qpid 0.22.
 
  If you favor making the RC5 bits into our official release,
 vote
  +1.
  If you have reason to believe RC5 is not ready for release,
 vote
  -1.
 
  I will close this vote on Monday, 22 May.  I know that's a
 little
  brief, but I have some vacation time coming up soon, and I'm
  hoping
   to
  finish the release before I leave.

 The patches for 4344 were applied in reverse on this branch and,
  with
 the last cherry-pick, the bindings/CMakeLists.txt broke the CMake
 changes. The conditional check for Swig  1.3.32 is still in the
  file
 and needs to be deleted to fix CMake.

 This is totally my fault.

 --
 Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
 Delivering value year after year.
 Red Hat ranks #1 in value among software vendors.
 http://www.redhat.com/promo/vendor/


   
   
 -
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
   
   
  
   --
   -K
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
   For additional commands, e-mail: dev-h...@qpid.apache.org
  
  
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
  For additional commands, e-mail: dev-h...@qpid.apache.org
 
 

Re: [VOTE] Release 0.22

[Oleksandr Rudyy]

Justin,

I hope it is still not too late to request the inclusion into 0.22  of  a
minor fix for Windows batch script to start Java Broker (
http://svn.apache.org/r1485859  QPID-4881).

We introduced new command line arguments requiring to pass an equal
character as part of the argument but the batch script splits the command
line argument with 'equal' into two arguments and removes equal character.
Such arguments have to be quoted but processing of quoted arguments
resulted in the errors.

The changes fixed the processing of quoted arguments. It is a minor issue
and there are some workarounds but I would like to request the inclusion of
the fix as it is quite trivial.

Kind Regards,
Alex



On 23 May 2013 22:40, Ken Giusti kgiu...@redhat.com wrote:

 Justin,

 A new RC, you say?

 Well, I'll just leave this little tidbit here, ya know, just in case:

 https://issues.apache.org/jira/browse/QPID-4883

 /backs slowly away from my keyboard



 - Original Message -
  From: Justin Ross jr...@apache.org
  To: dev@qpid.apache.org
  Sent: Thursday, May 23, 2013 10:34:58 AM
  Subject: Re: [VOTE] Release 0.22
 
  This vote is withdrawn.  We'll have a new RC later today.  The only
  new change will be the cmake build fix.  Once that's available, I'll
  start a new vote thread.
 
  Justin
 
  On Wed, May 22, 2013 at 5:14 PM, Justin Ross jr...@apache.org wrote:
   Okay, we'll fix it tomorrow.
  
   On May 22, 2013 4:09 PM, Darryl L. Pierce dpie...@redhat.com
 wrote:
  
   On Wed, May 22, 2013 at 01:54:50PM -0400, Justin Ross wrote:
RC5 contains the proposed final bits for Qpid 0.22.
   
If you favor making the RC5 bits into our official release, vote +1.
If you have reason to believe RC5 is not ready for release, vote -1.
   
I will close this vote on Monday, 22 May.  I know that's a little
brief, but I have some vacation time coming up soon, and I'm hoping
 to
finish the release before I leave.
  
   The patches for 4344 were applied in reverse on this branch and, with
   the last cherry-pick, the bindings/CMakeLists.txt broke the CMake
   changes. The conditional check for Swig  1.3.32 is still in the file
   and needs to be deleted to fix CMake.
  
   This is totally my fault.
  
   --
   Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc.
   Delivering value year after year.
   Red Hat ranks #1 in value among software vendors.
   http://www.redhat.com/promo/vendor/
  
  
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
  For additional commands, e-mail: dev-h...@qpid.apache.org
 
 

 --
 -K

 -
 To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
 For additional commands, e-mail: dev-h...@qpid.apache.org

Re: 0.22 release update - proposed final RC4

[Oleksandr Rudyy]

Hi Justin,

I am wondering whether you have already cut RC5?

If not, I would like to request the inclusion of changes made in revision
http://svn.apache.org/r1485163 fixing QPID-4876. It is a one line change
which does not effect core broker functionality but it could potentially
save a lot of cursing and  user frustration when making mistakes on adding
of Virtual Host into Java Broker dynamically :)

If RC5 is already cut then it is fine  to not include the changes into 0.22.

Kind Regards,
Alex



On 20 May 2013 14:08, Robbie Gemmell robbie.gemm...@gmail.com wrote:

 Done.

 (As I'm sure is obvious from the JIRA and commit traffic, I also merged
 some other small bug fixes and improvements in keeping with the previous
 'break it you fix it' discussion)

 Robbie

 On 20 May 2013 11:24, Justin Ross justin.r...@gmail.com wrote:

  Please go ahead.  If we end up being ready, I'll produce the new RC later
  today.
 
  Justin
 
  On Sun, May 19, 2013 at 9:10 PM, Robbie Gemmell
  robbie.gemm...@gmail.com wrote:
   In case it isn't clear that was me effectively asking permission, as
 I'd
   rather not merge code changes to the branch unless they are going to be
   included.
  
   Robbie
  
   On 17 May 2013 16:56, Robbie Gemmell robbie.gemm...@gmail.com wrote:
  
   Hi Justin,
  
   In some final testing of the Java broker we came across an issue we
 feel
   warrants blocker status, and so would like to request another RC be
 cut
  on
   Monday before calling the vote in order to allow including the fix in
  the
   release.
  
   http://issues.apache.org/jira/browse/QPID-4858
   http://svn.apache.org/r1483866
  
   There are more specifics on the JIRA, but the short story is that due
 to
   changes made in this development cycle it became possible to configure
  the
   brokers HTTP management port(s) in an ambiguous way that suggested SSL
  was
   in use on the port when it was not, a situation we would obviously
 like
  to
   prevent for reasons.
  
   The change is fairly simple and involves removal of some inconsistency
  in
   configuration between the HTTP and non-HTTP ports, removing the
  ambiguity
   that lead to the issue. Aside from the obvious security-related
 benefit,
   making the change in this release would also be beneficial to avoid a
  need
   for explicit handling of the configuration change during upgrades to
  future
   releases.
  
   Robbie
  
   On 16 May 2013 22:46, Justin Ross jr...@apache.org wrote:
  
   Hi, everyone.  Here is RC4 from revision 1483543:
  
 http://people.apache.org/~jross/qpid-0.22-rc4/
 http://people.apache.org/~jross/qpid-0.22-rc4-testing.txt
  
   My testing on Fedora 16 x86-64 produced no failures.  Once again,
   thanks to all those who have tested previous RCs and reported the
   outcome.  Mick has posted to the list about some low-frequency
   failures in repeated test runs.  Those are important, but they are
 not
   at this point considered blockers for the release.
  
   My plan now is to let RC4 settle for a few days and wait for any
 signs
   of trouble.  If all goes well, I'll start the release vote on Monday
   next week and close it that Friday.
  
   This release candidate is signed.  The bits in RC4, if approved for
   release, will be the GA bits.
  
   Thanks!
   Justin
  
   ---
   0.22 release page: https://cwiki.apache.org/qpid/022-release.html
  
   -
   To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
   For additional commands, e-mail: dev-h...@qpid.apache.org
  
  
  
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
  For additional commands, e-mail: dev-h...@qpid.apache.org
 
 

Re: 0.22 release update - proposed final RC4

[Oleksandr Rudyy]

Justin,

Thanks for approval.
The fix (r1485163) was merged into 0.22 branch.

Kind Regards,
Alex


On 22 May 2013 13:09, Oleksandr Rudyy oru...@gmail.com wrote:

 Hi Justin,

 I am wondering whether you have already cut RC5?

 If not, I would like to request the inclusion of changes made in revision
 http://svn.apache.org/r1485163 fixing QPID-4876. It is a one line change
 which does not effect core broker functionality but it could potentially
 save a lot of cursing and  user frustration when making mistakes on adding
 of Virtual Host into Java Broker dynamically :)

 If RC5 is already cut then it is fine  to not include the changes into
 0.22.

 Kind Regards,
 Alex



 On 20 May 2013 14:08, Robbie Gemmell robbie.gemm...@gmail.com wrote:

 Done.

 (As I'm sure is obvious from the JIRA and commit traffic, I also merged
 some other small bug fixes and improvements in keeping with the previous
 'break it you fix it' discussion)

 Robbie

 On 20 May 2013 11:24, Justin Ross justin.r...@gmail.com wrote:

  Please go ahead.  If we end up being ready, I'll produce the new RC
 later
  today.
 
  Justin
 
  On Sun, May 19, 2013 at 9:10 PM, Robbie Gemmell
  robbie.gemm...@gmail.com wrote:
   In case it isn't clear that was me effectively asking permission, as
 I'd
   rather not merge code changes to the branch unless they are going to
 be
   included.
  
   Robbie
  
   On 17 May 2013 16:56, Robbie Gemmell robbie.gemm...@gmail.com
 wrote:
  
   Hi Justin,
  
   In some final testing of the Java broker we came across an issue we
 feel
   warrants blocker status, and so would like to request another RC be
 cut
  on
   Monday before calling the vote in order to allow including the fix in
  the
   release.
  
   http://issues.apache.org/jira/browse/QPID-4858
   http://svn.apache.org/r1483866
  
   There are more specifics on the JIRA, but the short story is that
 due to
   changes made in this development cycle it became possible to
 configure
  the
   brokers HTTP management port(s) in an ambiguous way that suggested
 SSL
  was
   in use on the port when it was not, a situation we would obviously
 like
  to
   prevent for reasons.
  
   The change is fairly simple and involves removal of some
 inconsistency
  in
   configuration between the HTTP and non-HTTP ports, removing the
  ambiguity
   that lead to the issue. Aside from the obvious security-related
 benefit,
   making the change in this release would also be beneficial to avoid a
  need
   for explicit handling of the configuration change during upgrades to
  future
   releases.
  
   Robbie
  
   On 16 May 2013 22:46, Justin Ross jr...@apache.org wrote:
  
   Hi, everyone.  Here is RC4 from revision 1483543:
  
 http://people.apache.org/~jross/qpid-0.22-rc4/
 http://people.apache.org/~jross/qpid-0.22-rc4-testing.txt
  
   My testing on Fedora 16 x86-64 produced no failures.  Once again,
   thanks to all those who have tested previous RCs and reported the
   outcome.  Mick has posted to the list about some low-frequency
   failures in repeated test runs.  Those are important, but they are
 not
   at this point considered blockers for the release.
  
   My plan now is to let RC4 settle for a few days and wait for any
 signs
   of trouble.  If all goes well, I'll start the release vote on Monday
   next week and close it that Friday.
  
   This release candidate is signed.  The bits in RC4, if approved for
   release, will be the GA bits.
  
   Thanks!
   Justin
  
   ---
   0.22 release page: https://cwiki.apache.org/qpid/022-release.html
  
  
 -
   To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
   For additional commands, e-mail: dev-h...@qpid.apache.org
  
  
  
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
  For additional commands, e-mail: dev-h...@qpid.apache.org
 
 

Re: [C++] build failure on RHEL5

[Oleksandr Rudyy]

Hi,

The cmake build fails with the same error:

[ 22%] Building CXX object src/CMakeFiles/qpidcommon.dir/
qpid/sys/posix/Time.o
cc1plus: warnings being treated as errors
/home/f391718/workspace/qpid/qpid/cpp/src/qpid/sys/posix/Time.cpp: In
function ‘std::istream qpid::sys::operator(std::istream,
qpid::sys::Duration)’:
/home/f391718/workspace/qpid/qpid/cpp/src/qpid/sys/posix/Time.cpp:96:
warning: passing ‘double’ for argument 1 to
‘qpid::sys::Duration::Duration(int64_t)’
/home/f391718/workspace/qpid/qpid/cpp/src/qpid/sys/posix/Time.cpp:101:
warning: passing ‘double’ for argument 1 to
‘qpid::sys::Duration::Duration(int64_t)’
/home/f391718/workspace/qpid/qpid/cpp/src/qpid/sys/posix/Time.cpp:102:
warning: passing ‘double’ for argument 1 to
‘qpid::sys::Duration::Duration(int64_t)’
/home/f391718/workspace/qpid/qpid/cpp/src/qpid/sys/posix/Time.cpp:103:
warning: passing ‘double’ for argument 1 to
‘qpid::sys::Duration::Duration(int64_t)’
/home/f391718/workspace/qpid/qpid/cpp/src/qpid/sys/posix/Time.cpp:104:
warning: passing ‘double’ for argument 1 to
‘qpid::sys::Duration::Duration(int64_t)’
make[2]: *** [src/CMakeFiles/qpidcommon.dir/qpid/sys/posix/Time.o] Error 1
make[1]: *** [src/CMakeFiles/qpidcommon.dir/all] Error 2
make: *** [all] Error 2

$ cmake --version
cmake version 2.8.4
$ cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.3 (Tikanga)
$ gcc --version
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Kind Regards,
Alex


On 23 April 2013 11:08, Robbie Gemmell robbie.gemm...@gmail.com wrote:

 Hi all,

 I am no longer able to compile the trunk C++ tree on my RHEL5 box, with
 some warnings being treated as errors and causing the build to stop. If it
 matters, this is still the Automake build as I don't have cmake installed
 on this box yet. It does work with cmake on a Ubuntu 12.04 box.

 I recalled there being some changes to the file in question late last week,
 via QPID-4748 / http://svn.apache.org/r1469661 so I tried reverting back
 to
 just before that commit and the build was then able to complete
 successfully.

 Is there a way we can make this old RHEL5 box happy again? :)

 Robbie


  g++ -DHAVE_CONFIG_H -I. -I. -I. -I../include -I../include -I. -I= -Werror
 -pedantic -Wall -Wextra -Wno-shadow -Wpointer-arith -Wcast-qual
 -Wcast-align -Wno-long-long -Wvolatile-register-var -Winvalid-pch
 -Wno-system-headers -Woverloaded-virtual -g -O2 -MT qpid/sys/posix/Time.lo
 -MD -MP -MF qpid/sys/posix/.deps/Time.Tpo -c qpid/sys/posix/Time.cpp  -fPIC
 -DPIC -o qpid/sys/posix/.libs/Time.o
 cc1plus: warnings being treated as errors
 qpid/sys/posix/Time.cpp: In function 'std::istream
 qpid::sys::operator(std::istream, qpid::sys::Duration)':
 qpid/sys/posix/Time.cpp:96: warning: passing 'double' for argument 1 to
 'qpid::sys::Duration::Duration(int64_t)'
 qpid/sys/posix/Time.cpp:101: warning: passing 'double' for argument 1 to
 'qpid::sys::Duration::Duration(int64_t)'
 qpid/sys/posix/Time.cpp:102: warning: passing 'double' for argument 1 to
 'qpid::sys::Duration::Duration(int64_t)'
 qpid/sys/posix/Time.cpp:103: warning: passing 'double' for argument 1 to
 'qpid::sys::Duration::Duration(int64_t)'
 qpid/sys/posix/Time.cpp:104: warning: passing 'double' for argument 1 to
 'qpid::sys::Duration::Duration(int64_t)'
 depbase=`echo qpid/sys/posix/Thread.lo | sed
 's|[^/]*$|.deps/|;s|\.lo$||'`; \
 if /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H
 -I. -I. -I. -I../include -I../include -I. -I=   -Werror -pedantic -Wall
 -Wextra -Wno-shadow -Wpointer-arith -Wcast-qual -Wcast-align -Wno-long-long
 -Wvolatile-register-var -Winvalid-pch -Wno-system-headers
 -Woverloaded-virtual -g -O2 -MT qpid/sys/posix/Thread.lo -MD -MP -MF
 $depbase.Tpo -c -o qpid/sys/posix/Thread.lo qpid/sys/posix/Thread.cpp; \
 then mv -f $depbase.Tpo $depbase.Plo; else rm -f
 $depbase.Tpo; exit 1; fi
 make[3]: *** [qpid/sys/posix/Time.lo] Error 1
 make[3]: *** Waiting for unfinished jobs
  g++ -DHAVE_CONFIG_H -I. -I. -I. -I../include -I../include -I. -I= -Werror
 -pedantic -Wall -Wextra -Wno-shadow -Wpointer-arith -Wcast-qual
 -Wcast-align -Wno-long-long -Wvolatile-register-var -Winvalid-pch
 -Wno-system-headers -Woverloaded-virtual -g -O2 -MT
 qpid/sys/posix/Thread.lo -MD -MP -MF qpid/sys/posix/.deps/Thread.Tpo -c
 qpid/sys/posix/Thread.cpp  -fPIC -DPIC -o qpid/sys/posix/.libs/Thread.o
 make[3]: Leaving directory `/home/gemmellr/workspace/qpid/qpid/cpp/src'
 make[2]: *** [all-recursive] Error 1
 make[2]: Leaving directory `/home/gemmellr/workspace/qpid/qpid/cpp/src'
 make[1]: *** [all] Error 2
 make[1]: Leaving directory `/home/gemmellr/workspace/qpid/qpid/cpp/src'
 make: *** [all-recursive] Error 1

More requests for inclusion into 0.22 release

[Oleksandr Rudyy]

Hi Justin,

Could you please approve the inclusion of the following into 0.22 release:

JIRA: https://issues.apache.org/jira/browse/QPID-4696
Commit: http://svn.apache.org/r1464115
Description: Addresses the review comments for  JIRA QPID-4661 commits
(modifies broker attribute editing UI to group attributes, improves
attribute descriptions, removed obsolete classes and comments, renames
constant, fixes flow control attribute validation). The changes effect
management web console and of low risk. The code is reviewed by Robbie.


JIRA: https://issues.apache.org/jira/browse/QPID-4678
Commit: http://svn.apache.org/r1463934
Description: Fixes the invocation of ACL checks twice for broker management
operations. Highly isolated and low risk.

JIRA: https://issues.apache.org/jira/browse/QPID-4695
Commit: http://svn.apache.org/r1463933
Description: Adds validation of object names in web console, prevents user
from changing object IDs in management layer. Low risk.  Very isolated.

JIRA: https://issues.apache.org/jira/browse/QPID-44694
Commit: http://svn.apache.org/r1463917
Description: Fixes broker configuration store to save object IDs for the
new broker store created from the initial store. The changes effect
configuration store and of low risk.

JIRA: https://issues.apache.org/jira/browse/QPID-4691
Commit: http://svn.apache.org/r1463626
Description: Improves broker web management UI and validation of the
attributes dependant on (or related to) keystore/truststore/peerstore. The
changes are isolated to the broker management layer and web management
console.

JIRA: https://issues.apache.org/jira/browse/QPID-4676
Commit: http://svn.apache.org/r1463353
Description: Adds system test to check external authentication when
principal name is constructed from the certificate distinguished name in
form: CN@DC1.DC2...DCn. No risk.

Kind Regards,
Alex

Requests for inclusion into the 0.22

[Oleksandr Rudyy]

Hi Justin,

I would like to request the inclusions into 0.22 release of the
commits made for the following JIRAs:

http://issues.apache.org/jira/browse/QPID-4671
https://issues.apache.org/jira/browse/QPID-4666

QPID-4671:
commit: http://svn.apache.org/r1462162
It is a trivial fix adding a check for null to prevent NPE from
occurring when null is passed.
A bunch of junit tests was committed to verify the changes.
The commit was reviewed by Robbie. No risk for inclusion.

QPID-4666:
commit: http://svn.apache.org/r1461895
Another trivial change to modify the ACL error message.  The change
have been implemented by JAkub Scholz and reviewed and committed by
Robbie. No risk for inclusion.


Kind Regards,
Alex

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: [Java] Deadlock running Java tests

[Oleksandr Rudyy]

Hi Rob,

I was able to reproduce the issue with JDK 1.7.0_14 when running
BasicAuthRestTest in a cycle. However, I was not able to reproduce it
with JDK 1.6.0_33 by running the same tests during a period of 2 days.

I raised a JIRA QPID-4660 for the issue.

Kind Regards,
Alex

On 18 March 2013 17:24, Rob Godfrey rob.j.godf...@gmail.com wrote:
 Running jdk1.7.0_06.

 I've not seen it before either, and have not been able to reproduce.
 None of my local changes touch the areas being exercised, so I don't
 think it was down to them.  Curious.

 -- Rob

 On 18 March 2013 18:09, Oleksandr Rudyy oru...@gmail.com wrote:
 Hi Rob,

 I have not seen this issue.
 Also, I tried to reproduce the issue by running the BasicAuthRestTest
 in a cycle but could not reproduce it during 1 hour of running. I
 continue running the test.

 Could you please clarify what is the version of JVM you are using?

 Alex

 On 18 March 2013 12:19, Rob Godfrey rob.j.godf...@gmail.com wrote:
 Anyone seen this deadlock (running
 org.apache.qpid.systest.rest.BasicAuthRestTest) before?

 It's in a checkout where I've been making changes, but none that I
 think would affect this code:

 [junit] Found one Java-level deadlock:
 [junit] =
 [junit] qtp1606963758-5404:
 [junit]   waiting to lock monitor 0x7f6cf00517d8 (object
 0xf847cf10, a sun.security.ssl.SSLSocketImpl),
 [junit]   which is held by Broker-Configuration-Thread
 [junit] Broker-Configuration-Thread:
 [junit]   waiting for ownable synchronizer 0xf847d0c0, (a
 java.util.concurrent.locks.ReentrantLock$NonfairSync),
 [junit]   which is held by qtp1606963758-5404
 [junit]
 [junit] Java stack information for the threads listed above:
 [junit] ===
 [junit] qtp1606963758-5404:
 [junit] at
 sun.security.ssl.SSLSocketImpl.getConnectionState(SSLSocketImpl.java:649)
 [junit] - waiting to lock 0xf847cf10 (a
 sun.security.ssl.SSLSocketImpl)
 [junit] at 
 sun.security.ssl.SSLSocketImpl.isClosed(SSLSocketImpl.java:1462)
 [junit] at java.net.Socket.getTcpNoDelay(Socket.java:953)
 [junit] at
 sun.security.ssl.BaseSSLSocketImpl.getTcpNoDelay(BaseSSLSocketImpl.java:345)
 [junit] at
 sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:819)
 [junit] at
 sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:801)
 [junit] at 
 sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122)
 [junit] - locked 0xf848aca0 (a 
 sun.security.ssl.AppOutputStream)
 [junit] at
 org.eclipse.jetty.io.ByteArrayBuffer.writeTo(ByteArrayBuffer.java:354)
 [junit] at
 org.eclipse.jetty.io.bio.StreamEndPoint.flush(StreamEndPoint.java:159)
 [junit] at
 org.eclipse.jetty.io.bio.StreamEndPoint.flush(StreamEndPoint.java:189)
 [junit] at
 org.eclipse.jetty.http.HttpGenerator.flushBuffer(HttpGenerator.java:876)
 [junit] at
 org.eclipse.jetty.http.HttpGenerator.complete(HttpGenerator.java:836)
 [junit] at
 org.eclipse.jetty.server.AbstractHttpConnection.commitResponse(AbstractHttpConnection.java:576)
 [junit] at
 org.eclipse.jetty.server.AbstractHttpConnection$Output.close(AbstractHttpConnection.java:999)
 [junit] at 
 org.eclipse.jetty.server.HttpWriter.close(HttpWriter.java:80)
 [junit] at
 org.eclipse.jetty.server.AbstractHttpConnection$1.close(AbstractHttpConnection.java:372)
 [junit] - locked 0xf8838678 (a
 org.eclipse.jetty.server.AbstractHttpConnection$OutputWriter)
 [junit] at java.io.BufferedWriter.close(BufferedWriter.java:266)
 [junit] - locked 0xf88386a8 (a
 org.eclipse.jetty.server.AbstractHttpConnection$1)
 [junit] at
 org.codehaus.jackson.impl.WriterBasedGenerator.close(WriterBasedGenerator.java:944)
 [junit] at
 org.codehaus.jackson.map.ObjectMapper._configAndWriteValue(ObjectMapper.java:2568)
 [junit] at
 org.codehaus.jackson.map.ObjectMapper.writeValue(ObjectMapper.java:2072)
 [junit] at
 org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.doGetWithSubjectAndActor(RestServlet.java:310)
  ...
 [junit] Broker-Configuration-Thread:
 [junit] at sun.misc.Unsafe.park(Native Method)
 [junit] - parking to wait for  0xf847d0c0 (a
 java.util.concurrent.locks.ReentrantLock$NonfairSync)
 [junit] at
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 [junit] at
 java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
 [junit] at
 java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
 [junit] at
 java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
 [junit

Re: [Java] Deadlock running Java tests

[Oleksandr Rudyy]

Hi Rob,

I have not seen this issue.
Also, I tried to reproduce the issue by running the BasicAuthRestTest
in a cycle but could not reproduce it during 1 hour of running. I
continue running the test.

Could you please clarify what is the version of JVM you are using?

Alex

On 18 March 2013 12:19, Rob Godfrey rob.j.godf...@gmail.com wrote:
 Anyone seen this deadlock (running
 org.apache.qpid.systest.rest.BasicAuthRestTest) before?

 It's in a checkout where I've been making changes, but none that I
 think would affect this code:

 [junit] Found one Java-level deadlock:
 [junit] =
 [junit] qtp1606963758-5404:
 [junit]   waiting to lock monitor 0x7f6cf00517d8 (object
 0xf847cf10, a sun.security.ssl.SSLSocketImpl),
 [junit]   which is held by Broker-Configuration-Thread
 [junit] Broker-Configuration-Thread:
 [junit]   waiting for ownable synchronizer 0xf847d0c0, (a
 java.util.concurrent.locks.ReentrantLock$NonfairSync),
 [junit]   which is held by qtp1606963758-5404
 [junit]
 [junit] Java stack information for the threads listed above:
 [junit] ===
 [junit] qtp1606963758-5404:
 [junit] at
 sun.security.ssl.SSLSocketImpl.getConnectionState(SSLSocketImpl.java:649)
 [junit] - waiting to lock 0xf847cf10 (a
 sun.security.ssl.SSLSocketImpl)
 [junit] at 
 sun.security.ssl.SSLSocketImpl.isClosed(SSLSocketImpl.java:1462)
 [junit] at java.net.Socket.getTcpNoDelay(Socket.java:953)
 [junit] at
 sun.security.ssl.BaseSSLSocketImpl.getTcpNoDelay(BaseSSLSocketImpl.java:345)
 [junit] at
 sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:819)
 [junit] at
 sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:801)
 [junit] at 
 sun.security.ssl.AppOutputStream.write(AppOutputStream.java:122)
 [junit] - locked 0xf848aca0 (a 
 sun.security.ssl.AppOutputStream)
 [junit] at
 org.eclipse.jetty.io.ByteArrayBuffer.writeTo(ByteArrayBuffer.java:354)
 [junit] at
 org.eclipse.jetty.io.bio.StreamEndPoint.flush(StreamEndPoint.java:159)
 [junit] at
 org.eclipse.jetty.io.bio.StreamEndPoint.flush(StreamEndPoint.java:189)
 [junit] at
 org.eclipse.jetty.http.HttpGenerator.flushBuffer(HttpGenerator.java:876)
 [junit] at
 org.eclipse.jetty.http.HttpGenerator.complete(HttpGenerator.java:836)
 [junit] at
 org.eclipse.jetty.server.AbstractHttpConnection.commitResponse(AbstractHttpConnection.java:576)
 [junit] at
 org.eclipse.jetty.server.AbstractHttpConnection$Output.close(AbstractHttpConnection.java:999)
 [junit] at 
 org.eclipse.jetty.server.HttpWriter.close(HttpWriter.java:80)
 [junit] at
 org.eclipse.jetty.server.AbstractHttpConnection$1.close(AbstractHttpConnection.java:372)
 [junit] - locked 0xf8838678 (a
 org.eclipse.jetty.server.AbstractHttpConnection$OutputWriter)
 [junit] at java.io.BufferedWriter.close(BufferedWriter.java:266)
 [junit] - locked 0xf88386a8 (a
 org.eclipse.jetty.server.AbstractHttpConnection$1)
 [junit] at
 org.codehaus.jackson.impl.WriterBasedGenerator.close(WriterBasedGenerator.java:944)
 [junit] at
 org.codehaus.jackson.map.ObjectMapper._configAndWriteValue(ObjectMapper.java:2568)
 [junit] at
 org.codehaus.jackson.map.ObjectMapper.writeValue(ObjectMapper.java:2072)
 [junit] at
 org.apache.qpid.server.management.plugin.servlet.rest.RestServlet.doGetWithSubjectAndActor(RestServlet.java:310)
  ...
 [junit] Broker-Configuration-Thread:
 [junit] at sun.misc.Unsafe.park(Native Method)
 [junit] - parking to wait for  0xf847d0c0 (a
 java.util.concurrent.locks.ReentrantLock$NonfairSync)
 [junit] at
 java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
 [junit] at
 java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
 [junit] at
 java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
 [junit] at
 java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
 [junit] at
 java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
 [junit] at
 java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
 [junit] at
 sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:799)
 [junit] at
 sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:672)
 [junit] at
 sun.security.ssl.SSLSocketImpl.sendAlert(SSLSocketImpl.java:2023)
 [junit] at 
 sun.security.ssl.SSLSocketImpl.warning(SSLSocketImpl.java:1850)
 [junit] at
 sun.security.ssl.SSLSocketImpl.closeInternal(SSLSocketImpl.java:1618)
 [junit] - locked 

Re: TransportConnection.createVMBroker(): what to use now in junit?

[Oleksandr Rudyy]

Hi,

VM transport has been removed from the broker.

In unit tests you can start broker like following:

String qpidHome = System.getProperty(user.dir);
String qpidWork = System.getProperty(java.io.tmpdir) + /qpid/work;
String configPath = qpidHome + /qpid-config.xml;
int port = getFreePort();
BrokerOptions options = new BrokerOptions();
options.setConfigFile(configPath);
options.addPort(port);

System.setProperty(QPID_HOME, qpidHome);
System.setProperty(QPID_WORK, qpidWork);
Broker broker = new Broker();
try
{
broker.startup(options);

doWork(port);
}
finally
{
broker.shutdown();
}

You need to provide a minimal broker configuration file.
I attached the working example example how to start 0.20 broker from
java code. Please, have a look into it for details.

Kind Regards,
Alex

On 3 March 2013 19:58, djames dpgja...@gmail.com wrote:
 I notices a method TransportConnection.createVMBroker(), which looked handy
 for unit testing, but I note is is not in 0.18 onwards.

 Do people now mock using mockito? Or start a java broker from the unit test?



 --
 View this message in context: 
 http://qpid.2158936.n2.nabble.com/TransportConnection-createVMBroker-what-to-use-now-in-junit-tp7589392.html
 Sent from the Apache Qpid developers mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
 For additional commands, e-mail: dev-h...@qpid.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: [VOTE] Release 0.20

[Oleksandr Rudyy]

Hi,
I successfully ran hello/drain/spout examples with 0.20 java client
and broker.  I did some smoke tests of java broker web and jmx
management UI. No issue is found.

+1

Kind Regards,
Alex

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: 0.20 release update - RC3 is out, C++ and proton problem

[Oleksandr Rudyy]

Hi Justin,

I tested RC3 builds of java client and java broker by starting the
broker and running hello, spout and drain examples. They ran
successfully without any issue.

Kind Regards,
Alex

On 18 December 2012 22:49, Justin Ross jr...@redhat.com wrote:
 Hi.  Here's a new RC from revision 1423691.  Note that it is *not* the final
 RC.

   http://people.apache.org/~jross/qpid-0.20-rc3/

 There've been just a handful of changes since RC2:

   r1418220 | rgodfrey | (Fri, 07 Dec 2012) | 2 lines
   QPID-4454: Fixes to allow to/reply-to JMS type to be carried as
   message annotations in AMQP 1.0 JMS client

   r1418544 | chug | (Fri, 07 Dec 2012) | 5 lines
   NO-JIRA: repair build for VisualStudio 2010

   r1421322 | robbie | (Thu, 13 Dec 2012) | 4 lines
   QPID-4377: add missing licence headers to various files in the Java tree

   r1423679 | jross | (Tue, 18 Dec 2012) | 1 line
   NO-JIRA: remove empty files from tree

   r1423691 | jross | (Tue, 18 Dec 2012) | 1 line
   QPID-4377: Add missing license headers to JCA files

 Which of course is very good.  I did, however, run into a problem trying to
 address Gordon's issue regarding the C++ proton-based work.  I made sure
 that latest proton was installed, and further that pkg-config could find it.
 I then created a new distribution.  I looked for and couldn't find any
 difference in the source distribution between RC2 and RC3, and it's
 furthermore not clear to me why there would be.

 I then pushed on and attempted to run configure --with-proton, discovering
 this problem:

   https://gist.github.com/4332785

 That looks like a dist issue, and I figure it's cropping up now because this
 is the first time anyone's had a chance to test --with-proton.

 I think that needs to get fixed before we release 0.20, and so one more RC
 will be required.

 Thanks!
 Justin


 -
 To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
 For additional commands, e-mail: dev-h...@qpid.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Please welcome Phil Harvey as committer

[Oleksandr Rudyy]

Welcome Phil!

Alex

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Java broker proposal: move firewall rules into ACL file (QPID-4334)

[Oleksandr Rudyy]

Hi Phil,

Existing firewall plugin denies/allows access to broker from
network/host regardless virtual host.
The suggested syntax implies that you can denies/allows access to the
broker virtual hosts instead.
Will it be possible to specify host name in the rule and restrict the
access to the specified virtual host?

Another question I have about adding predicates from-network and
from-hostname.
Why we cannot provide the network or host name pattern as part of
user/group name?
For example, using the following constructions

ACL ALLOW all/123.456.789/24 ACCESS VIRTUALHOST
ACL DENY-LOG my-user-group/.*\.uat.mycompany\.com ACCESS VIRTUALHOST

It looks like that existing ACL syntax allows to specify the user
domain after character '/'. I would prefer to use '@' for this but it
seems this character is reserved to specify the user realm.

Alex

On 25 September 2012 10:07, Phil Harvey p...@philharveyonline.com wrote:
 Thanks for the feedback guys.

 Responding to Chuck's questions:

 Your proposed syntax is basically OK. The C++ broker supports IPv4,
 IPv6, and RDMA. Could you specify the --from-network  property
 more fully?

 As suggested by Robbie, the from-network and from-hostname properties will
 retain the semantics of the similarly-named properties in the existing
 firewall plugin (https://cwiki.apache.org/qpid/firewall-configuration.html),
 such that this task is a functionally neutral refactoring.  I think any
 functional enhancements that arise (eg to match the C++ broker's firewall
 support) should be done under a separate JIRA.


 Do you think this can make it in the next release?

 Yes, I expect to submit a patch in the next few days.


 Unless there are any further objections I'm going to proceed with this
 JIRA.

 Phil


 On 25 September 2012 01:52, Robbie Gemmell robbie.gemm...@gmail.com wrote:

 Where the Java broker is concerned it wasnt moved in the timeframe of that
 mail thread simply because the ACL system in use at the time was limited
 and in need of removal more than anything else (which happened some time
 ago), so it didnt make sense to combine them at the time and it just hasn't
 happened since it did become worthwhile. Now there are new reasons it would
 be useful to combine them, to the extent it makes enough sense for us to
 combine the functionality now rather than later.

 I cant really say I recall any other discussions on this subject except the
 other postings on JIRA and/or the user list requesting the functionality it
 would offer.

 Robbie

 On 25 September 2012 01:19, Rajith Attapattu rajit...@gmail.com wrote:

  I'm not really against the change proposed by Philip.
  But wanted to highlight the history around this area, in case anybody
  remembers the reasons behind abandoning the previous effort.
  It's always best to make a decision after considering all aspects.
  I hope somebody still remembers why this didn't take place.
 
  Rajith
 
  On Mon, Sep 24, 2012 at 8:05 PM, Robbie Gemmell
  robbie.gemm...@gmail.com wrote:
   The previous thread in [1] is of little relevance now as none of the
 ACL
   code under discussion there exists anymore. It is easy enough to argue
  that
   such restrictions would are best served by a real firewall, but there
 are
   reasons it still proves useful functionality for the broker to have and
  we
   have users we want to keep supporting the functionality for, even if we
  are
   changing the config (which doesnt particularly concern me, we are
 slowly
   moving towards an end state with config on the Java broker that will
  change
   config for almost everything..making this change now will just reduce
 the
   amount of future change slightly). Ultimately the functionality already
   exists, simplistically this is just going to be tweaking where the
   implementation lives and its config, though in the end it may actually
  add
   functionality too as a side effect (e.g. user specific network
  restriction,
   which I dont think is currently supported on the Java side).
  
   The docs for the existing xml config for the Java broker effort lives
 at
   https://cwiki.apache.org/qpid/firewall-configuration.html and details
  its
   current hostname wildcarding and CIDR network matching.
  
   Robbie
  
   On 24 September 2012 21:23, Rajith Attapattu rajit...@gmail.com
 wrote:
  
   The last time this came up for discussion there was some push back on
  the
   list.
   This was proposed here [1] due to some requests from the users and
   there was even a patch for the c++ broker attached here [2]
   However this didn't go through due to some discussion that happened on
  the
   list.
   Unfortunately I can't seem to find a reference to this on the mailing
   list archives.
  
   Does anybody recall the reasons ?
  
   I vaguely remember that one of the reasons was that this could be
   handled more effectively with a firewall than ACL.
  
   [1]
  
 
 

Re: Announcing new committers

[Oleksandr Rudyy]

Carl,

Thank you very much.
I am glad to join the team.

Oleksandr (a.k.a. Alex)

On 14 September 2012 18:13, Carl Trieloff cctriel...@redhat.com wrote:

 I'm Glad to announce that Darryl Pierce and Oleksandr Rudyy where
 nominated and have accepted committership for the qpid project. Please
 join me in welcoming them as committers to Qpid.

 Darryl and Oleksandr, if you have any issues in being able to commit,
 please let me know. Note that you need to re-checkout using the https URL.

 kind regards
 Carl.


 -
 To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
 For additional commands, e-mail: dev-h...@qpid.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: 0.18 release update - proposed final RC3

[Oleksandr Rudyy]

Hi Justin,

I tested 0.18-rc3 builds of Java Broker, Java Client and  JMX
Management Console and could not find any issue with the builds.

My tests included the following:
- running spout, drain, hello examples with java client against the java broker
- creating/deleting exchanges, bindings, queues with JMX management console
- moving/copying/deleting messages with  JMX management console
- adding/deleting users with JMX management console
- creating/deleting exchanges, bindings, queues with web management console
- moving/copying/deleting messages with  web management console
- adding/deleting users with web management console

Kind Regards,
Alex

On 14 August 2012 20:32, Justin Ross jr...@redhat.com wrote:
 Hi, everyone.  All of the outstanding inclusion requests have been settled,
 and I've cut RC3 at revision 1373004.  Get it here:

   http://people.apache.org/~jross/qpid-0.18-rc3/

 This is a proposed final release candidate.  At the end of this week, if no
 new blockers have emerged, I'll open the release vote.  If the vote passes,
 I'll rebuild the release from the very same RC3 revision but without -rc3 in
 the version numbers.

 Last, I owe a big thanks to Robbie for taking on several release tasks while
 I was away.

 The proposed final 0.18 release notes are on their way.

 Thanks,
 Justin


 -
 To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
 For additional commands, e-mail: dev-h...@qpid.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Deadlock

[Oleksandr Rudyy]

Hi Eugene,

I do apologize for making you waiting with the answer. I was quite
busy with my current  tasks and did not have time to look through the
client  in order to recollect the deadlock conditions.

Regarding the deadlock scenario you have described, I believe that you
are right. I cannot see in Qpid code the conditions which might lead
into such deadlock by closing of  consumer inside of MessageListener
on 0.10 path. However, such deadlock  can  occur in a bit different
way and it is even reported in QPID-4086.

If your application is not using failover it seems it is safe.  At
least, I cannot see the deadlock conditions in the current code not
related to failover.

In case of failover,  potentially the dedlock can occur in the
following scenario when consumer is closed inside of MessageListener
(unless I missed something) :

1) Message is dispatched into MessageListener#onMessage(Message) but
MessageListener is trying to invoke the consumer close method. At this
moment in time, the dispatcher thread acquired the dispatcher lock
(AMQSession.Dispatcher._lock) and delivery lock
(AMQSession._deliveryLock) and is about to acquire the failover mutex
from BasicMessageConsumer#close()
2) At this time, the tcp connection is lost and failover is triggered
to restore the connectivity. On failover, the failover thread (which
is a receiver thread) acquires  the failover mutex before the
dispatcher thread. Than it restores the connectivity and invokes
AMQConnection#.failoverPrep()  to clean the data on connection (pls,
have a look into code in
AMQConnectionDelegate_0_10#closed(Connection))
3) AMQConnection#.failoverPrep() invokes 0.10 delegate which iterates
through the sessions and invokes failoverPrep() on each session, which
in turn calls syncDispatchQueue() method to clean the dispatcher
queue. syncDispatchQueue() sends the poisoned message into the
pre-fetched message queue and waits forever for message being consumed
in the dispatcher thread.
4) However, the dispatcher thread cannot process any message as it is
blocked in BasicMessageConsumer#close(). Thus, we have a dead lock.


Kind Regards,
Alex

On 2 August 2012 12:11, eugene eugen.ra...@gmail.com wrote:
 Well this is a bug in the libraries, I've been looking at the code and here
 is (probably obvious for you :) ) problem:

 1. Thread 1 acquires the FailoverMutex
 2. Thread 2 acquires the MessageDeliveryLock
 3. Thread 1 tries to acquire the MessageDeliveryLock
 4. Thread 2 tries to acquire the FailoverMutex

 Thus the deadlock.

 Alex, I do not think that it has anything to do with closing Consumers from
 Listeners, it's just a side effect.

 Thank You,
 Eugene.



 --
 View this message in context: 
 http://apache-qpid-developers.2158895.n2.nabble.com/Deadlock-tp7581518p7581564.html
 Sent from the Apache Qpid developers mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
 For additional commands, e-mail: dev-h...@qpid.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Deadlock

[Oleksandr Rudyy]

Hi Eugene,

What is the version of the client you are using?
Is it 0.10 client?

Kind Regards,
Alex

On 1 August 2012 11:47, eugene eugen.ra...@gmail.com wrote:
 Hello,

 We are having a DeadLock issue and it seems that this is the same bug as
 here:

 https://issues.apache.org/jira/browse/QPID-3216

 So here what the logs say:

 [2012-08-01 23:24:00.355] INFO  sample_service.SampleService
 org.apache.qpid.client.BasicMessageConsumer   Closing
 consumer:7[2130838978]
 [2012-08-01 23:24:00.355] ERROR Thread-71System.err
 Exception in thread Thread-71 java.lang.RuntimeException:
 java.lang.InterruptedException
 [2012-08-01 23:24:00.355] ERROR Thread-71System.err
 at org.apache.qpid.client.AMQSession.syncDispatchQueue(AMQSession.java:2215)
 [2012-08-01 23:24:00.355] ERROR Thread-71System.err
 at
 org.apache.qpid.client.BasicMessageConsumer_0_10.getMessageFromQueue(BasicMessageConsumer_0_10.java:436)
 [2012-08-01 23:24:00.356] ERROR Thread-71System.err
 at
 org.apache.qpid.client.BasicMessageConsumer.receive(BasicMessageConsumer.java:407)
 [2012-08-01 23:24:00.356] ERROR Thread-71System.err
 at com.moodys.msp.lb.ServiceRequestPoller.run(ServiceRequestPoller.java:43)
 [2012-08-01 23:24:00.356] ERROR Thread-71System.err
 at java.lang.Thread.run(Thread.java:680)
 [2012-08-01 23:24:00.356] ERROR Thread-71System.err
 Caused by: java.lang.InterruptedException
 [2012-08-01 23:24:00.356] ERROR Thread-71System.err
 at
 java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:979)
 [2012-08-01 23:24:00.356] ERROR Thread-71System.err
 at
 java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1281)
 [2012-08-01 23:24:00.356] ERROR Thread-71System.err
 at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:207)
 [2012-08-01 23:24:00.356] ERROR Thread-71System.err
 at org.apache.qpid.client.AMQSession.syncDispatchQueue(AMQSession.java:2211)
 [2012-08-01 23:24:00.356] ERROR Thread-71System.err
 ... 4 more

 Also here is the JConsole output for the deadlock:

 Name: Dispatcher-Channel-0
 State: BLOCKED on java.lang.Object@c58f769 owned by: main
 Total blocked: 2  Total waited: 1

 Stack trace:

 org.apache.qpid.client.BasicMessageConsumer.close(BasicMessageConsumer.java:571)
 org.apache.qpid.client.BasicMessageConsumer.close(BasicMessageConsumer.java:535)
 com.eugene.package.CallResponseListener.tryCloseMessageConsumer(CallResponseListener.java:55)
 com.eugene.package.CallResponseListener.onMessage(CallResponseListener.java:50)
 org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:725)
 org.apache.qpid.client.BasicMessageConsumer_0_10.notifyMessage(BasicMessageConsumer_0_10.java:167)
 org.apache.qpid.client.BasicMessageConsumer.notifyMessage(BasicMessageConsumer.java:699)
 org.apache.qpid.client.BasicMessageConsumer_0_10.notifyMessage(BasicMessageConsumer_0_10.java:205)
 org.apache.qpid.client.BasicMessageConsumer_0_10.notifyMessage(BasicMessageConsumer_0_10.java:47)
 org.apache.qpid.client.AMQSession$Dispatcher.notifyConsumer(AMQSession.java:3388)
 org.apache.qpid.client.AMQSession$Dispatcher.dispatchMessage(AMQSession.java:3332)
- locked java.lang.Object@22fe135d
- locked java.lang.Object@1a0283e
 org.apache.qpid.client.AMQSession$Dispatcher.access$900(AMQSession.java:3113)
 org.apache.qpid.client.AMQSession.dispatch(AMQSession.java:3106)
 org.apache.qpid.client.message.UnprocessedMessage.dispatch(UnprocessedMessage.java:55)
 org.apache.qpid.client.AMQSession$Dispatcher.run(AMQSession.java:3260)
 java.lang.Thread.run(Thread.java:680)


 And on the other side:


 Name: main
 State: BLOCKED on java.lang.Object@22fe135d owned by: Dispatcher-Channel-0
 Total blocked: 148  Total waited: 133

 Stack trace:
  org.apache.qpid.client.AMQSession.close(AMQSession.java:731)
- locked java.lang.Object@c58f769
 org.apache.qpid.client.AMQSession.close(AMQSession.java:708)
 org.apache.qpid.client.AMQSession.close(AMQSession.java:567)
 come.eugene.package.MSPConnectionImpl.close(MSPConnectionImpl.java:54)
 com.eugene.package.ToDelete.doRoundRobinTest(ToDelete.java:62)
 com.eugene.package.ToDelete.main(ToDelete.java:25)

 Any luck of that bug being closed?

 Thank You,
 Eugene.




 --
 View this message in context: 
 http://apache-qpid-developers.2158895.n2.nabble.com/Deadlock-tp7581518.html
 Sent from the Apache Qpid developers mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
 For additional commands, e-mail: dev-h...@qpid.apache.org


-

Re: Deadlock

[Oleksandr Rudyy]

Hi Eugen,

I am sorry for the late response.
There is a good chance that the issue was fixed in QPID-3911 for 0.16
qpid client.
However, I am afraid that you might run into other deadlocks by
closing the consumer from MessageListener. I would avoid doing so.

Do you have any test reproducing the issue?

Kind Regards,
Alex


On 1 August 2012 13:10, eugene eugen.ra...@gmail.com wrote:
 Yup, its 0.10



 --
 View this message in context: 
 http://apache-qpid-developers.2158895.n2.nabble.com/Deadlock-tp7581518p7581526.html
 Sent from the Apache Qpid developers mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
 For additional commands, e-mail: dev-h...@qpid.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Maven build?

[Oleksandr Rudyy]

Hi,

It looks for me that the structure of proton-j sub-project will be
quite simple and will not require the creation of complicated building
scripts similar to what we have in qpid java tree right now. I believe
that we can have 2 building systems for proton-j at least on first
stages of the project. That would allow developers to use either ant
or maven depending from their preferences.
IMHO, it should not be big overhead for the project.

Kind Regards,
Alex

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Maven build?

[Oleksandr Rudyy]

Hi,

I completely support Joseph's proposal to use maven as building system
for j-poton module.

Kind Regards,
Alex

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: 0.18 release update - RC1 is available

[Oleksandr Rudyy]

Hi Justin,

I tested RC1 builds of Java Client, Java Broker, Management Console
and could not find any issues with these builds.

Test details:

Using RC1 client successfully run Hello, Spout and Drains examples
against Java and C++ Brokers (both RC1).

Run RC1 build of Management Console against RC1 build of Java Broker
and verified that JMX operations are successfully performed.
I tested the following JMX operations:
   create queue
   delete queue
   create exchange
   bind queue
   copy messages between queues
   move messages between queues
   create/delete users

Also, I tested web management console for Java Broker and could not
find any issue there.
All operations in web management console were performed successfully.
That includes
 create queues(priority, sorted, LVQ)
 delete queue
 create exchange
 delete exchange
 bind queue
 copy/move/delete message
 create/delete users.

Kind Regards,
Alex Rudyy

On 22 July 2012 00:53, Justin jr...@redhat.com wrote:
 Hi, folks.  RC1 is ready at revision 1363863 of our product branch.
 Get it here:

   http://people.apache.org/~jross/qpid-0.18-rc1/

 There were many changes between beta and RC1:

   QPID-4118: HA does not work with authentication and authorization.
   QPID-4128: HA should not use amq.failover for replication links
   QPID-4126: HA primary times out expected backups.
   QPID-3998, QPID-3999: get the user name from
   QPID-3998, QPID-3999: System tests for Rest API, small fixups for the
   QPID-4036 QPID-4192 cluster connection leak on failed auth. merge from
   QPID-4133: (Jason Dillaman) Non-responsive peer in federated link can
   QPID-4136: HA sporadic failures in ha_tests
   QPID-4114: broker release now includes BDB if optional=true sys property
   QPID-4131: On 0-8...0-9-1 code path broker now closes the connection when
   QPID-3998: Add HTTPS support for the REST management interface
   QPID-4138: HA sporadic failure in ha_tests
   QPID-4144 HA broker deadlocks on broker::QueueRegistry lock and
   QPID-4145: HA Minor fixes to recovery
   QPID-4148: HA Not setting initial queues for new RemoteBackups
   QPID-4150: Display the name of queue type key(sortKey,priorities,lvqKey)
   QPID-4149: Add REST functionality to delete exchanges, queues and
   QPID-4151: Add validation for reserved exchange names into addExchange
   QPID-4156: HA close window for clients to connect before HA broker is
   QPID-4155 - Merged from trunk at revision 1363795.
   QPID-4158: HA transition to CATCHUP status too early; merged from 1363520
   QPID-4155 - Merged from trunk at revision 1363861.

 Testing (and feedback!) is always encouraged, but with this number of
 changes appearing after beta, we appreciate it still more.  Test it in
 your environment, and post the results to the list.

 RC2 is in about one week.  See the release page for schedule details.

 Thanks,
 Justin

 ---
 0.18 release page: https://cwiki.apache.org/qpid/018-release.html

 -
 To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
 For additional commands, e-mail: dev-h...@qpid.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

0.18 inclusion request

[Oleksandr Rudyy]

Hi Justin,

Could you also consider inclusion of commit
http://svn.apache.org/viewvc?rev=1361239view=rev
which adds the support for HTTPS protocol into Java Broker REST
interfaces and web management console?

Kind Regards,
Alex Rudyy

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Review Request: Fix for QPID-3575

[Oleksandr Rudyy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/5794/#review9055
---


Hi Rajith,

The suggested code changes looks reasonable for me.
I could not find any issue with the suggested solution.

The only thing I would like to ask is to add some tests to cover the changes.
For example, I used the following tests to test your changes with Java Broker

public class ExceptionHandlingTest extends QpidBrokerTestCase implements 
ExceptionListener
{

private AMQConnection _connection;
private AMQSession_0_10 _exceptionSession;
private AMQSession_0_10 _session;
private JMSException _exception;

public void setUp() throws Exception
{
super.setUp();
_connection = (AMQConnection) getConnection();
_connection.setExceptionListener(this);
_session = (AMQSession_0_10) _connection.createSession(false, 
Session.AUTO_ACKNOWLEDGE);
_exceptionSession = (AMQSession_0_10) _connection.createSession(false, 
Session.AUTO_ACKNOWLEDGE);
_exception = null;
}

public void testDeclareStandardEchange() throws Exception
{
Exception caughtException = null;
try
{
_exceptionSession.declareExchange(new 
AMQShortString(qpid.management), new AMQShortString(direct), false);
}
catch (Exception e)
{
e.printStackTrace();
caughtException = e;
}
assertState();
assertTrue(Unexpected exception, caughtException == null || 
caughtException instanceof AMQException);
}

public void testDeclareQueuePassiveForNonExistingQueue() throws Exception
{
Exception caughtException = null;
try
{
_exceptionSession.send0_10QueueDeclare((AMQDestination) 
getTestQueue(), _connection.getProtocolHandler(), false,
false, true);
}
catch (Exception e)
{
e.printStackTrace();
caughtException = e;
}
assertState();
assertTrue(Unexpected exception, caughtException == null || 
caughtException instanceof AMQException);
}

@Override
public void onException(JMSException exception)
{
_exception = exception;
}

private void assertState() throws Exception
{
assertFalse(Connection has been closed unexpectedly, 
_connection.isClosed());
assertFalse(Not affected session has been closed unexpectedly, 
_session.isClosed());
assertNotNull(Exception is not received, _exception);
assertTrue(Exception session has not been closed, 
_exceptionSession.isClosed());

// assert that JMS operations are performed OK on non-affected session
Destination queue = _session.createQueue(getTestQueueName());
MessageConsumer consumer = _session.createConsumer(queue);
MessageProducer producer = _session.createProducer(queue);
producer.send(_session.createTextMessage(Test));
_connection.start();
Message m = consumer.receive(1000l);
assertNotNull(Test message has not been received, m);
consumer.close();
producer.close();
}
}

I did not try to run these tests with CPP broker.

The failing test SelectorTest#testRuntimeSelectorError can be fixed by 
replacing the assert checking if connection is closed 
assertTrue(Connection should be closed, _connection.isClosed());
with assert checking if session is closed
assertTrue(Session should be closed, (AMQSession?,?)session.isClosed());


Apart from adding the tests, I do not have any other commentaries about the 
suggested changes.

- Oleksandr Rudyy


On July 6, 2012, 12:39 a.m., rajith attapattu wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/5794/
 ---
 
 (Updated July 6, 2012, 12:39 a.m.)
 
 
 Review request for qpid, Robbie Gemmell, Keith Wall, and Rob Godfrey.
 
 
 Description
 ---
 
 When a session exception is received, we notify the connection via the 
 exceptionReceived method. The connection will close all sessions for this 
 connection, but does not close the underlying Protocol connection.
 Further calls (from application code) to close the connection, does not close 
 the underlying protocol-connection as it skips this part, due to the 
 connection already being marked as closed.
 This results in leaked connections.
 
 The proposed patch does the following.
 1. When a session exception is received, it closes the Session (and the 
 consumers/producers associated with it) to prevent further use of this 
 session.
 2. It also notifies the connection, however the exception being passed, is 
 marked as a soft error, thereby preventing the connection from being marked

0.18 inclusion request

[Oleksandr Rudyy]

Hi Justin,

Could you please consider inclusions of trunk commits
http://svn.apache.org/viewvc?view=revisionrevision=1360120
and
http://svn.apache.org/viewvc?view=revisionrevision=1360121
into 0.18 ?


These 2 commits are low risk bug fixes and improvements for recently
added into Java Broker REST API and management web console.
The second commit also adds 40 system tests for the Java Broker REST API.
The functional changes are covered by these test and do not interfere
with broker core functionality

Kind Regards,
Alex Rudyy

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Binding URL Options

[Oleksandr Rudyy]

Hi Rajith,

I am sorry for a delayed reply.
Option reject_behaviour is a client setting only and it is not
passed into queue declare arguments. With reject_behaviour=server the
0-9-x client sends BasicReject commands for unacknowledged messages on
recover to reject these messages either for the entire connection
globally or only for the queues with this behaviour. With
reject_behaviour=normal 0-9-x client sends BasicRecoverSyncOk command
only on session recover.

Kind Regards,
Alex

On 15 May 2012 14:24, Rajith Attapattu rajit...@gmail.com wrote:
 Alex,

 Thanks for the explanation.
 I assume this is passed as a queue-declare argument ?

 Regards,

 Rajith


 On Tue, May 15, 2012 at 4:30 AM, Oleksandr Rudyy oru...@gmail.com wrote:

 Hi Rajith,

 Option reject_behaviour was introduced as part of work on implementing
 DLQ  functionality in java broker. This is only 0-9-1 client setting
 and it is not needed for 0-10 client.
 By default, redelivered messages are not moved into DLQ after
 exceeding Maximum redelivery attempts (for backward compatibility). In
 order to have redelivered messages to be moved into DLQ after reaching
 Maximum redelivery number the client should set
 reject_behaviour=server either as a connection option or a queue
 Binding URL option.

 Kind Regards,
 Alex



 On 14 May 2012 22:36, Rajith Attapattu rajit...@gmail.com wrote:
  Hi All,
 
  I'm trying to compile an exhaustive list of all the valid options for
  binding URL.
  Some of the options make sense while others a lot is left to be desired.
  I'd really appreciate some help in agreeing to a proper list and also
  updating the wiki for accuracy.
 
  The wiki page here
  https://cwiki.apache.org/qpid/bindingurlformat.htmldescribes the
  following options.
 
  exclusive       boolean     Is this an exclusive connection
  autodelete     boolean     Should this queue be deleted on client
  disconnection
  durable          boolean     Create a durable queue
  clientid           string         Use the following client id
  subscription  boolean     Create a subscription to this destination
  routingkey     string          Use this value as the routing key
 
  While the code has the following options,
 
  public static final String OPTION_EXCLUSIVE = exclusive;
  public static final String OPTION_AUTODELETE = autodelete;
  public static final String OPTION_DURABLE = durable;
  public static final String OPTION_BROWSE = browse;
  public static final String OPTION_CLIENTID = clientid;
  public static final String OPTION_SUBSCRIPTION = subscription;
  public static final String OPTION_ROUTING_KEY = routingkey;
  public static final String OPTION_BINDING_KEY = bindingkey;
  public static final String OPTION_REJECT_BEHAVIOUR = rejectbehaviour;
 
  (*) Multiple Binding keys can be specified.
 
  While most of the options are quite straight forward I'm trying to figure
  out the intended behaviour for a few.
 
  1.  Subscription
      What's the intended usage for subscription ?
      All though the wiki lists it as a boolean it has been used in a
 rather
  bizarre way in the BindingURLParser.java
      (All though I was the author of BindingURLParser I simply used the
  same that was there in the old code).
 
     Could we remove this option?
 
  2. Client ID
      We don't use the queue-name worked out here in anyway when we create
  the durable subscription name.
      Could we remove this option ?
 
  3. OPTION_REJECT_BEHAVIOUR
      Could somebody please explain the intended  behaviour for this option
  so I could correctly pass it when creating the address structure out of a
  BURL.
 
  Regards,
 
  Rajith

 -
 To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
 For additional commands, e-mail: dev-h...@qpid.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Binding URL Options

[Oleksandr Rudyy]

Hi Rajith,

Option reject_behaviour was introduced as part of work on implementing
DLQ  functionality in java broker. This is only 0-9-1 client setting
and it is not needed for 0-10 client.
By default, redelivered messages are not moved into DLQ after
exceeding Maximum redelivery attempts (for backward compatibility). In
order to have redelivered messages to be moved into DLQ after reaching
Maximum redelivery number the client should set
reject_behaviour=server either as a connection option or a queue
Binding URL option.

Kind Regards,
Alex



On 14 May 2012 22:36, Rajith Attapattu rajit...@gmail.com wrote:
 Hi All,

 I'm trying to compile an exhaustive list of all the valid options for
 binding URL.
 Some of the options make sense while others a lot is left to be desired.
 I'd really appreciate some help in agreeing to a proper list and also
 updating the wiki for accuracy.

 The wiki page here
 https://cwiki.apache.org/qpid/bindingurlformat.htmldescribes the
 following options.

 exclusive       boolean     Is this an exclusive connection
 autodelete     boolean     Should this queue be deleted on client
 disconnection
 durable          boolean     Create a durable queue
 clientid           string         Use the following client id
 subscription  boolean     Create a subscription to this destination
 routingkey     string          Use this value as the routing key

 While the code has the following options,

 public static final String OPTION_EXCLUSIVE = exclusive;
 public static final String OPTION_AUTODELETE = autodelete;
 public static final String OPTION_DURABLE = durable;
 public static final String OPTION_BROWSE = browse;
 public static final String OPTION_CLIENTID = clientid;
 public static final String OPTION_SUBSCRIPTION = subscription;
 public static final String OPTION_ROUTING_KEY = routingkey;
 public static final String OPTION_BINDING_KEY = bindingkey;
 public static final String OPTION_REJECT_BEHAVIOUR = rejectbehaviour;

 (*) Multiple Binding keys can be specified.

 While most of the options are quite straight forward I'm trying to figure
 out the intended behaviour for a few.

 1.  Subscription
     What's the intended usage for subscription ?
     All though the wiki lists it as a boolean it has been used in a rather
 bizarre way in the BindingURLParser.java
     (All though I was the author of BindingURLParser I simply used the
 same that was there in the old code).

    Could we remove this option?

 2. Client ID
     We don't use the queue-name worked out here in anyway when we create
 the durable subscription name.
     Could we remove this option ?

 3. OPTION_REJECT_BEHAVIOUR
     Could somebody please explain the intended  behaviour for this option
 so I could correctly pass it when creating the address structure out of a
 BURL.

 Regards,

 Rajith

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: Release artifacts (was: [VOTE] Release 0.16)

[Oleksandr Rudyy]

Justin, Robbie,

I tested Java Broker, Java Client and Management Console artefacts.

Everything worked fine for me. No issue is found.

Details of the tests:
Started Java Broker.
Created test queue using Management Console and bound that queue to
the direct exchange.
Published test messages into the test queue using Spout example.
Consumed test messages from the test queue using Drain example.
Used Management Console to verify test queue attributes before and
after publishing and consuming.

The scenario above was used to test broker with Memory message store
and Berkeley Message Store.

I have not tested maven artefacts.

Kind Regards,
Alex

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: 0.16 release update - proposed final RC is available

[Oleksandr Rudyy]

Hi Justin,

I've run some tests against the Java Broker 0-16 RC3 and encountered no issues.

Details of tests run:
used java Drain/Spout examples to publish/receive messages to/from
Java Broker. monitored queues using Java Broker Management Console.

No issues found.

Kind Regards,
Alex

-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Review Request: QPID-3911: Fix the deadlock occuring on concurrent invocation of MessageConsumer#close() and Session#rollback()

[Oleksandr Rudyy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/4546/
---

Review request for qpid, Robbie Gemmell, rajith attapattu, Keith Wall, and Rob 
Godfrey.


Summary
---

Invoking of MessageConsumer#close() and Session#rollback from a consumer 
listener results in a deadlock on 0-10 path and a timeout exception on 0-9 path

On 0-10 path the deadlock is caused by an ExecutionException sent from the 
broker in response to message.stop, message.flow commands (sent from 
Session#rollback for the suspension of the channel) when message.stop or 
message.flow command is delivered to the broker after message.cancel command 
which is sent as part of MessageConsumer#close(). Command message.cancel 
results in a deletion of a subscription on the broker side and for the 
following message.stop or message.flow command the subscription cannot be found 
and ExceutionException is reported:

org.apache.qpid.AMQException: ch=0 id=2 ExecutionException(errorCode=NOT_FOUND, 
commandId=20, classCode=4, commandCode=12, fieldIndex=0, description=not-found: 
Unknown destination 1 session=guest@QPID.89a222e3-e3ca-4aee-8e4f-a78468f4fed1 
(qpid/broker/SemanticState.cpp:569), errorInfo={}) [error code 404: not found]

The ExecutionException is sent from both Java and C++ Brokers

On receiving an ExecutionException connection tries to acquire the 
FailoverMutex in order to close itself in AMQConnection#exceptionReceived 
method.

However, the FailoverMutex is acquired in MessageConsumer#close() which is 
waiting for a release of a session dispatcher lock. The last is hold in a 
dispatcher thread. The closing of a connection occurs in a dispatcher thread 
and this results in a deadlock.


The suggested patch introduces the following changes:
 Adds synchronization on AMSession#_messageDeliveryLock into 
MessageConsumer#close() in order to block until message listener in progress 
has completed(as required in JMS javadoc for MessageConsumer#close())
 Changes the session dispatcher to stop the message delivery into consumer 
local message queue if the consumer in the process of closing. This eliminates 
the need to stop the dispatcher on rejecting pending messages for closing 
consumer.
 Removes the synchronization on a session dispatcher lock from 
AMQSession.Dispatcher#rejectPending and code to stop the dispatcher as we are 
synchronizing on a deliveryLock now and incoming messages are not dispatched 
into closing consumer anymore.
 Adds a system test to reproduce the deadlock


This addresses bug QPID-3911.
https://issues.apache.org/jira/browse/QPID-3911


Diffs
-

  /trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession.java 
1306567 
  
/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/BasicMessageConsumer.java
 1306567 
  
/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/unit/close/MessageConsumerCloseTest.java
 PRE-CREATION 

Diff: https://reviews.apache.org/r/4546/diff


Testing
---


Thanks,

Oleksandr

Re: qpid Queue DLQ

[Oleksandr Rudyy]

Hi Rugene,

With java broker you can create DLQ on creation your normal by
specifying the following arguments:

x-qpid-dlq-enabled = true
x-qpid-maximum-delivery-count=max delivery count value

Here is a java client example how to do it

final MapString,Object arguments = new HashMapString, Object();
arguments.put(x-qpid-dlq-enabled, new Boolean(true));
arguments.put(x-qpid-maximum-delivery-count, new Integer(5));
((AMQSession?,?) session).createQueue(new
AMQShortString(queueName), false, true, false, arguments);
Queue queue = session.createQueue(queueName);
((AMQSession?,?) session).declareAndBind((AMQDestination)queue);

Also, for 0-8/0-9/0-9-1 amqp java client you need to specify a client
behaviour using one of the the following options
1) System.setProperty(qpid.reject.behaviour, server); or
-Dqpid.reject.behaviour=server
2) by adding an option into connection URL rejectbehaviour='server'
3) by adding an option into destinationURL rejectbehaviour='server'

When enabled for a given queue, the DLQ feature causes generation of a
Dead Letter Exchange and a Dead Letter Queue, named according to the
convention queue_name_DLE and queue_name_DLQ. When max delivery
count limit is reached then the message is routed through the dead
letter exchange onto the DLQ and removed from the original queue.

Kind Regards,
Alex

On 12 March 2012 15:10, eugene eugen.ra...@gmail.com wrote:
 Hello,

 Is there a way to make my Queue as the Dead Letter Queue in Qpid
 programmatically? I mean I have my Queue like this:

 Queue queue =  // somehow create the queue, may be cast it to AMQueue

 and then add some kind of property to make it the Default Dead Letter Queue?

 Thank You,
 Eugene.

 --
 View this message in context: 
 http://apache-qpid-developers.2158895.n2.nabble.com/qpid-Queue-DLQ-tp7365593p7365593.html
 Sent from the Apache Qpid developers mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
 For additional commands, e-mail: dev-h...@qpid.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org

Re: [jira] [Commented] (QPID-3640) When releasing msgs, the JMS client should not mark msgs in the prefetch buffer as redelivered.

[Oleksandr Rudyy]

Hi Rajith,

I assigned DLQ JIRA to Keith for review.
Hopefully, he will commit it tomorrow in the morning (UK time).

Kind Regards,
Alex

On 24 November 2011 19:16, Rajith Attapattu (Commented) (JIRA)
j...@apache.org wrote:

    [ 
 https://issues.apache.org/jira/browse/QPID-3640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13156880#comment-13156880
  ]

 Rajith Attapattu commented on QPID-3640:
 

 I will be testing this along with the rest of my work, so if I do find any 
 issues with your patch, I can fix it. So at this point I think it's best if 
 you go ahead and commit the parts that address this specific issue.

 When releasing msgs, the JMS client should not mark msgs in the prefetch 
 buffer as redelivered.
 -

                 Key: QPID-3640
                 URL: https://issues.apache.org/jira/browse/QPID-3640
             Project: Qpid
          Issue Type: Bug
          Components: Java Client
    Affects Versions: 0.10, 0.12
            Reporter: Rajith Attapattu
            Assignee: Rajith Attapattu
             Fix For: 0.15

         Attachments: RecoveryTest.java


 When releasing messages, for ex when the application calls recover() or 
 Connection.stop(), the client marks all messages in it's prefetch buffer as 
 redelivered. This is not correct, since messages in the prefetch buffer 
 have not yet been seen (delivered) by the application.

 --
 This message is automatically generated by JIRA.
 If you think it was sent incorrectly, please contact your JIRA 
 administrators: 
 https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
 For more information on JIRA, see: http://www.atlassian.com/software/jira



 -
 Apache Qpid - AMQP Messaging Implementation
 Project:      http://qpid.apache.org
 Use/Interact: mailto:dev-subscr...@qpid.apache.org



-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: ExecutionException is sent by cpp broker in response for queue.query command for a deleted queue

[Oleksandr Rudyy]

Thanks Gordon

On 15 November 2011 09:54, Gordon Sim g...@redhat.com wrote:
 On 11/14/2011 08:25 PM, Oleksandr Rudyy wrote:

 Hi,

 I would like to bring to your attention that java test

 org.apache.qpid.test.client.destination.AddressBasedDestinationTest.testDeleteOptions
 started to fail constantly against cpp broker.

 The test is written to test a queue deletion if a delete option is
 specified in address URL.
 It tests a queue deletion for all 3 possible values of the delete
 option: always, receiver and sender.

 For all these cases test creates a producer and a consumer on test
 queues and uses queue.query command to check the queue existing
 after closing the consumer/producer.

 On closing the consumer/producer the queue is deleted and
 ExecutionResullt with QueueQueryResult object is expected to be
 received by the test in response for queue.query command.
 For delete options  'always' and 'receiver' the received response is
 as expected but for delete option 'sender' the
 ExecutionException(errorCode=RESOURCE_DELETED, description=Queue
 testQueue3 has been deleted. (qpid/broker/Queue.cpp:1415),
 errorInfo={}) is sent by the cpp broker on receiving  queue.query
 command for a deleted queue.

 The last case passed before with some sporadic failures from time to
 time but now it fails all the time.

 Here is the snippet of java code which fails

         Session jmsSession =
 _connection.createSession(false,Session.AUTO_ACKNOWLEDGE);
         MessageConsumer cons;

         

         String addr3 = ADDR:testQueue3;{create: always, delete: sender};
         AMQDestination dest = new AMQAnyDestination(addr3);
         try
         {
             cons = jmsSession.createConsumer(dest);
             MessageProducer prod = jmsSession.createProducer(dest);
             prod.close();
         }
         catch(JMSException e)
         {
             fail(Exception should not be thrown. Exception thrown is : 
 + e);
         }

         assertFalse(Queue not deleted as expected,(


 (AMQSession_0_10)jmsSession).isQueueExist(dest,(QueueNode)dest.getSourceNode(),
 true));

 The exception is not being issued by the broker in response to the query. It
 is being issued to the existing open subscriber when the queue is deleted
 from underneath it.

 -
 Apache Qpid - AMQP Messaging Implementation
 Project:      http://qpid.apache.org
 Use/Interact: mailto:dev-subscr...@qpid.apache.org



-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

ExecutionException is sent by cpp broker in response for queue.query command for a deleted queue

[Oleksandr Rudyy]

Hi,

I would like to bring to your attention that java test
org.apache.qpid.test.client.destination.AddressBasedDestinationTest.testDeleteOptions
started to fail constantly against cpp broker.

The test is written to test a queue deletion if a delete option is
specified in address URL.
It tests a queue deletion for all 3 possible values of the delete
option: always, receiver and sender.

For all these cases test creates a producer and a consumer on test
queues and uses queue.query command to check the queue existing
after closing the consumer/producer.

On closing the consumer/producer the queue is deleted and
ExecutionResullt with QueueQueryResult object is expected to be
received by the test in response for queue.query command.
For delete options  'always' and 'receiver' the received response is
as expected but for delete option 'sender' the
ExecutionException(errorCode=RESOURCE_DELETED, description=Queue
testQueue3 has been deleted. (qpid/broker/Queue.cpp:1415),
errorInfo={}) is sent by the cpp broker on receiving  queue.query
command for a deleted queue.

The last case passed before with some sporadic failures from time to
time but now it fails all the time.

Here is the snippet of java code which fails

Session jmsSession =
_connection.createSession(false,Session.AUTO_ACKNOWLEDGE);
MessageConsumer cons;



String addr3 = ADDR:testQueue3;{create: always, delete: sender};
AMQDestination dest = new AMQAnyDestination(addr3);
try
{
cons = jmsSession.createConsumer(dest);
MessageProducer prod = jmsSession.createProducer(dest);
prod.close();
}
catch(JMSException e)
{
fail(Exception should not be thrown. Exception thrown is :  + e);
}

assertFalse(Queue not deleted as expected,(

(AMQSession_0_10)jmsSession).isQueueExist(dest,(QueueNode)dest.getSourceNode(),
true));


The given above code always passes against Java broker.
I raised JIRA https://issues.apache.org/jira/browse/QPID-3576 to track
this issue.
In JIRA description I added a broker/clint log showing the commands
flow between client and broker.

Kind Regards,
Alex

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: Address node type resolution issues

[Oleksandr Rudyy]

I completely agree with the suggested approach as it will completely
remove the need to have a code which depends from the destination URL
syntax.

Kind Regards,
Alex

On 20 October 2011 11:05, Rob Godfrey rob.j.godf...@gmail.com wrote:
 Sorry for being a little late responding to this thread...

 Stepping back for a second I think it's probably worth laying out how we
 think this should work, and if we can come to agreement about that then we
 can aim to have a complete solution in place for our next release (not this
 one).

 My view (and having discussed with Rafi, I think he is on broadly the same
 page) is:

 1) The Destination object should not contain any protocol specific
 information
 2) The Destination object should not contain any information about the
 syntax used to generate it
 3) Resolution information (based on interacting with the broker) should be
 determined by, and stored in the Session/Connection (and is therefore
 potentially protocol specific)

 In practice this would mean creating factory classes to create destination
 objects. I would expect our destination object to be modelled after the
 properties defined in the addressing syntax.  Each existing syntax would
 need a parser/factory which would parse strings of the given syntax and
 create a Destination object with the appropriate properties. For BURL style
 addresses this would obviously be slightly more work as there is some
 concept translation going on.  note that with this approach it will be
 entirely possible (though not necessarily very desirable) to use both
 syntaxes with both protocols.

 I also strongly favour making the destination objects themselves immutable.

 One of the major issues of debate has been how the destination objects
 defined as are instantiated as concrete implementations of the JMS
 Destination hierarchy.  What I would suggest is the following:

 1) The implementations of classes implementing Topic/Queue are simple
 derived classes from our base Destination class with only implementations of
 extra methods such as getTopicName() and getQueueName() respectively (with
 both these simply being delegations to getName() on the base class).
 2) The factories can be told explicitly to create a Topic or a Queue from an
 address string (thus passing a string into the createQueue(..) method will
 always result in a Queue object being returned).
 3) For the ADDR syntax addresses, if the string includes an explicit node
 type, then this is used to determine which sort of instance to create. (For
 BURL syntax the existing conventions it uses should be followed)
 4) When generating destination objects from reply-to fields in incoming
 messages, the logic is necessarily protocol specific.  The 0-8/9 style
 carries a full address string, and the normal factory can be used; for 0-10
 we can use similar techniques to those that we must currently be using (i.e.
 resolution may be attempted prior to calling the factory).
 5) For all JMS defined methods which take either a queue or topic argument,
 we should ensure that we also have a method defined in our implementations
 which takes the more generic destination object (obviously calls to these
 methods may fail if it happens that the node on the broker is not suitable
 for the requested operation).

 At the end of this we should have a clean implementation where protocol
 specific features are solely in connection/Session related classes (i.e. in
 the protocol specific parts of the implementation), and address syntax parts
 are soley in the parsers for those syntaxes.

 What are people's thoughts/questions?

 Cheers,
 Rob
 On 17 October 2011 23:09, Robbie Gemmell robbie.gemm...@gmail.com wrote:

 On 17 October 2011 20:58, Rajith Attapattu rajit...@gmail.com wrote:
  On Mon, Oct 17, 2011 at 12:39 PM, Robbie Gemmell
  robbie.gemm...@gmail.com wrote:
  On 17 October 2011 16:01, Rajith Attapattu rajit...@gmail.com wrote:
  On Mon, Oct 17, 2011 at 5:54 AM, Robbie Gemmell
  robbie.gemm...@gmail.com wrote:
  Why do we resolve Address node types? This question arose during
  review of proposed updates to the Address syntax implementation for
  the Java client, but ultimately looks to be a wider question for all
  the clients and so I am asking it here outwith that review.
 
  The documentation for the Address syntax on the Qpid and MRG websites
  states that nodes can be specified as Queues or Topics, but that nodes
  are Queues by default.
 
  Throughout my reply the word 'node' means Queues  Exchanges in 0-10
 speak.
  The default applies when the node referred to by the address name does
  not exist and the client has received instructions to create it.
  (The documentation does have a lot of gaps and that's a all together a
  separate discussion :) ..)
 
 
  The client should give the same default behaviour regardless of what
  another user has done, so I dont think the above is correct behaviour.
  Whether an exchange exists with that name should be irrelevant if
  

Review Request: QPID-3532 Fix the blocking of JMS operations when failover happens

[Oleksandr Rudyy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2469/
---

Review request for qpid and rajith attapattu.


Summary
---

https://issues.apache.org/jira/browse/QPID-3532 describes some issues with 
non-blocking behaviour of 0-10 client failover.

This patch makes the 0-10 client hold the failover mutex during the failover. 
It also alters the Address resolution code to allow resolving addresses after 
failover and adds some more failover tests (inc ADDR based ones). Additionally, 
it makes the failover process notify any waiters in the session to abort and 
let failover proceed as they would otherwise prevent the failover from 
occurring until they timed out after 60 seconds.

This work does not go as far as we would like but still represents a functional 
improvement to failover. Additional improvements to the client locking model 
(such as an introduction a single connection lock) will require further 
iteration.

The patch was worked on by myself and Robbie.


This addresses bug QPID-3532.
https://issues.apache.org/jira/browse/QPID-3532


Diffs
-

  
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnection.java
 1186863 
  
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQConnectionDelegate_0_10.java
 1186863 
  
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQDestination.java
 1186863 
  
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AMQSession_0_10.java
 1186863 
  
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/BasicMessageProducer_0_10.java
 1186863 
  
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/Connection.java
 1186863 
  
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/common/src/main/java/org/apache/qpid/transport/Session.java
 1186863 
  
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/client/failover/FailoverBehaviourTest.java
 1186863 
  
http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/test-profiles/JavaPre010Excludes
 1186863 

Diff: https://reviews.apache.org/r/2469/diff


Testing
---


Thanks,

Oleksandr

Re: Review Request: QPID-3401 New class structure for address refactoring

[Oleksandr Rudyy]

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/2366/#review2589
---


There are a number of operations performed based on the Destination during 
client execution, e.g. during Consumer creation and closing, Producer creation 
and closing amongst others. Each of these might be implemented differently 
depending on the destination syntax and settings in use, and then further 
differences can emerge based on any protocol-specific requirements. Currently, 
everywhere differences relating to the syntax in use occur we generally have an 
if-else statement. This is not a maintainable implementation approach, and 
needs to be abstracted away by a common Destination model that allows grouping 
of syntax specific operations into separate classes rather than spreading 
decisions throughout the code.

The design alterations here improve on some of the deficiencies of the previous 
implementation (e.g. the policy validation no longer being within the main 
session etc implementation code), but in other ways seems worse. For example, 
it appears to result in us having Destination implementations that are both 
syntax AND protocol specific, and which have, and require, intimate knowledge 
of the Session implementation. This does not seem like progress and still 
leaves us with all the if-else statements throughout the client. Also, it seems 
that as AddressBasedDestination is not abstract, it will now be possible for 
our Destination objects to contain a delegate which implement either the JMS 
Topic or Queue interfaces, but not implement it themselves.

In order to eliminate the if-else statements for behaviour which varies 
depending on the destination syntax, we can isolate that code in specific 
delegate classes for use with Destination objects. Such delegates would 
implement a shared interface that declares the varying address related 
operations, and could exist for both BindingURL and Address based Destinations. 
The different behaviours could be contained within the destination delegates, 
however specific implementations of operations such as queue creation, queue 
deletion, subscription creation, would be would found within the 
protocol-specific session implementations that actually perform these 
operations.

The class diagram at 
https://issues.apache.org/jira/secure/attachment/12499057/model2.gif depicts 
what some of such a Destination model would look like. AMQDestination would be 
refactored such that BindingURL specific functionality and Address specific 
functionality was moved to subclasses, with all 3 being abstract, and these 
used as the basis for implementations of the Queue and Topic interfaces 
specific to each URL syntax.

Additionally, if would be nice to have immutable destination object in order to 
resolve current issues with thread safety which in turn will allow storing and 
reusing them via JNDI. 


- Oleksandr


On 2011-10-12 21:02:31, rajith attapattu wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviews.apache.org/r/2366/
 ---
 
 (Updated 2011-10-12 21:02:31)
 
 
 Review request for qpid, Gordon Sim, Robbie Gemmell, Weston Price, and Keith 
 Wall.
 
 
 Summary
 ---
 
 This patch contains the new class structure used for retrieving information 
 from addressing and creating destinations and managing it's lifecycle.
 How this code is tied to the main client is illustrated with the patch put up 
 for review at https://reviews.apache.org/r/2364/
 
 A basic class diagram for this can be found here [ 
 https://issues.apache.org/jira/secure/attachment/12498753/class_diagram.png ]
 
 In summary the goals are,
 ===
 1. Provide a proper abstraction of Queue and Topic concepts
 
 2. Provide an address format based implementation of Queue and Topic
 
 3. Hide the implementatio of the life cycle of a destination (create, delete, 
 createSubscription, deleteSubscription)
 
 4. Create a top level AddressBasedDestination class (extending from 
 AMQDestination),
 4.1 To separate the address based details from AMQQueue, AMQTopic ..etc
 4.2 To bridge btw the new code and the AMQDestination interface
 
 4. Improve the code that retrievs data from an address (a.k.a AddressHelper)
 
 5. Provide a fix for QPID-3265, QPID-3317, QPID-3271
 
 6. Implement the above with minimum disruption to regular client code.
 
 
 This addresses bug QPID-3401.
 https://issues.apache.org/jira/browse/QPID-3401
 
 
 Diffs
 -
 
   
 http://svn.apache.org/repos/asf/qpid/trunk/qpid/java/client/src/main/java/org/apache/qpid/client/AddressBasedDestination.java
  PRE-CREATION 
   
 

Re: Failover

[Oleksandr Rudyy]

Rajith,

Thanks a lot for your feedback.

Could you also have a look into the Failover Behaviour WIKI we created
to summarize the failover behaviour?


The discussion above gave us multiple options of failover behaviour.
We selected the most appropriative behaviour options among many
available and provided description of them on that WIKI.

Kind Regards,
Alex

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: Failover

[Oleksandr Rudyy]

Hi,

I created the following JIRA to track work on this issue:
https://issues.apache.org/jira/browse/QPID-3505

I have attached a patch with initial work on test cases based on the
current version of the client failover behaviour page linked below.

I would appreciate any comment on failover behaviour spec and tests
before we get too far into implementation.

Kind Regards,
Alex


On 23 September 2011 13:06, Oleksandr Rudyy oru...@gmail.com wrote:
 Based on above, me and Robbie have chosen some of options of behaviour
 on failover and conducted a draft of Qpid Client Failover Behaviour
 Spec which is available from
 https://cwiki.apache.org/confluence/display/qpid/Client+Failover+Behaviour


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: Failover

[Oleksandr Rudyy]

Based on above, me and Robbie have chosen some of options of behaviour
on failover and conducted a draft of Qpid Client Failover Behaviour
Spec which is available from
https://cwiki.apache.org/confluence/display/qpid/Client+Failover+Behaviour

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: Failover

[Oleksandr Rudyy]

Hi all,

Me and Robbie created the following draft of Failover Policy for Qpid
Java Client.

Could you please comment on it?

Qpid Java Client Failover Policy

1. Qpid client failover basic principles.
===

When connection to broker is lost a Qpid client should be able to
re-establish connection to broker if failover policy is not switched
off by specifying nofailover as a failover option in a connection
URL.

The failover functionality on Qpid client should be based on principle
stop the world.  When connection is lost and failover starts the
Qpid Client should not allow an invocation of any JMS operation which
requires sending or receiving data over the network. Such operations
should be blocked until failover functionality restores the
connectivity by using any of the supported failover methods
('singlebroker', 'roundrobin', 'failover_exchange').

On restoring connectivity blocked JMS operations should be allowed to
finish. If the failover functionality cannot re-establish the
connection a JMSException should be thrown within any JMS operation
requiring transferring data over the network.

On successful failover, it is expected that client JMS session should
restore all temporary queues(topics) if such were created before
failover.


2. Description of failover behavior for JMS operations
==

Session.commit() rollbacks transaction and throws a
TransactionRolledBackException if the session is dirty (there were
messages sent/received in the transaction) when failover occurred,
allowing the user to replay their transaction on the new Session.

Session.recover() and Message#acknowledge() should throw a
JMSException if there has been any message delivery since the last
acknowledgment was sent and failover occurred whilst the session was
'dirty'


Message consumer:

No further messages sent to the client by the old broker should be
received by the consumer after failover has occurred, only messages
sent by the new broker should be available to consumers.


Queue browser:

If failover occurred while iterating through QueueBrowser enumerations
a sub-class of NotSuchElementException should be thrown by default.



3. Issues with acknowledgments
==
1. CLIENT_ACKNOWLEDGE

The acknowledge operation should not return till all messages has
actually been acknowledged. Currently is possible for messages not
being acknowledged after invoking acknowledge operation. The
acknowledge is done lazily by acknowledgment flusher, however, this is
not what the JMS spec requires.

2.AUTO_ACKNOWLEDGE

The JMS requires that after each call to receive operation or
completion of each onMessage the received message should be
acknowledged. Currently this does not happens as the acknowledge is
done lazily by acknowledgment flusher which does not give the same
guarantee. This is in fact is DUPS_OK_ACKNOWLEDGE behavior. The
flusher thread should not be running for AUTO_ACKNOWLEDGE.

3. SESSION_TRANSACTED
Flusher thread is started but it is not really needed because
acknowledgment for transacted sessions is handled differently.
It seems that a flusher thread make sense to run in a
DUPS_OK_ACKNOWLEDGE modes only.

4. NO_ACKNOWLEDGE

The flusher thread should not be running for NO_ACKNOWLEDGE.

5. PRE_ACKNOWLEDGE

The same issue as with AUTO_ACKNOWLEDGE.
Is anybody using this mode? Does it make sense to keep it?

Kind Regards,
Alex

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org