qpid-users mailing list archives

The specification defines durability, transactions, etc. the 0-10
specification also defines
the fail-over handlers etc, for client interop which is used to in our
Active-Active cluster
implementation.
What implementation is provided for these abilities in the spec is up to
the implementer. so the list below
is covered by capabilities of the specification.
The spec then also provides mechanisms for extensions and in this area
we provide
a few like XMLExchange for XQuery routing. and a few additional queue
types like LVQ, RING
etc.
These can be used or ignored.
In terms of how helps develop Qpid, google some of the names on the
people page... you
may change your view :-)
Carl.
spaace wrote:
>> durable message support, transactions, ...
>>
>
> Thanks for the reply Carl.
>
> Are these features part of the AMQP standards or are these extensions that
> QPID has defined? I thought storage and forward was part of AMQP standards.
> Searching the archives showed me some broken test cases being reported. If
> someone has that full list it would be really helpful in making a final
> decision
>
> I was basically looking at OpenAMQ based on the info i saw on the net that
> the initial implementation of AMQP was driven by these guys and that
> JPMorgan had their first LIVE implementation running on it. Seeing how
> JPMorgan drove the initial investigation i was partial towards OpenAMQ.
>
> However i have to admit, the qpid client with OpenAMQ broker incompatibility
> possibilities does have me spooked. Is this combination even conceivable ?
> If it is not we might as well not even test the inter-broker cases and
> proceed with client and broker from the same family after evaluating basic
> feature support.
>
> Rgds
> Arun
>
> On Thu, Jan 29, 2009 at 8:26 PM, Carl Trieloff <cctrieloff@redhat.com>wrote:
>
>
>> Arun,
>>
>> I quick look at the download page will show what is compat with what
>> http://qpid.apache.org/download.html
>>
>> In terms of which way to go, obviously I would recommend a Qpid broker...
>> ok, seriously,
>> both the Qpid broker are more feature rich that OpenAMQ. For example they
>> don't have things
>> like durable message support, transactions, ...
>>
>> In terms of Java, versus C++,
>>
>> C++ is on the latest spec and fast + low latency, client side JMS
>> selectors, Federation, clustering, QMF, QMan etc.
>> Java has server side selectors for JMS, and runs on more platforms, ok I am
>> not the best to list here... but someone
>> on the list will...
>>
>> and then of course we are friendlier ... :-) lol
>> Carl.
>>
>>
>>
>> spaace wrote:
>>
>>
>>> Hello Marnie,
>>>
>>> Thanks for the quick reply. I'm basically trying to evaluate different
>>> broker implementations for my project, having decided on AMQP for its open
>>> standard. I have decided on QPID as my client and is currently evaluating
>>> the QPID Java / C++ broker and the OpenAMQ broker for the server side.
>>>
>>> However i 'm not sure what the differences are, especially wrt the "other"
>>> features like broker-to-broker connectivity, security, request and
>>> subscribtion forwarding between brokers and similar features, beyond the
>>> basic send-and-recieve. Personally conducting the entire feature testing
>>> seemed a bit daunting and hence my query.
>>>
>>> The java feature list would be really helpful in this regard. Thank you.
>>>
>>> Thanks
>>> Arun
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Jan 29, 2009 at 3:26 PM, Marnie McCormack <
>>> marnie.mccormack@googlemail.com> wrote:
>>>
>>>
>>>
>>>
>>>> Hi,
>>>>
>>>> I can give you a brief overview, and I'm sure that others (particularly
>>>> the
>>>> C++-ers) will add to this reply.
>>>>
>>>> Fundamentally, it's all about choice. Our project seeks to provide a
>>>> range
>>>> of client & broker implementations of the AMQP specification (and JMS
for
>>>> the Java elements) from which our users can select the combination best
>>>> suited to their needs.
>>>>
>>>> This project has evolved from the original contribution of the Java
>>>> broker
>>>> &
>>>> client to Apache, built as a production quality implementation of the
>>>> AMQP
>>>> specification and JMS compatible. From there, the other implementations
>>>> have
>>>> grown to provide a variety of clients, for use with existing application
>>>> architectures which mandate different languages.
>>>>
>>>> The C++ broker brings with it tuning options for different platforms, and
>>>> this is definitely something that others on this list can expand upon.
>>>> Work
>>>> is proceeding on a number of ports of the C++ broker for different
>>>> platforms. The Java broker is platform independent.
>>>> I'll pull together some additional information on the features
>>>> provided/supported by the Java Broker (as of M4) as I don't think we have
>>>> anything which reflects the current feature set, and post the link here
>>>> shortly.
>>>>
>>>> Please do let us know if there's anything you're specifically interested
>>>> in.
>>>>
>>>> Hth,
>>>> Marnie
>>>>
>>>> On Thu, Jan 29, 2009 at 8:54 AM, spaace <spaace@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>> Hi,
>>>>>
>>>>> I'm new to Qpid and have been following the threads and reading up on
>>>>> the
>>>>> docs for some time. I'm trying to decide on the brokers to be used for
a
>>>>> private project and have this doubt.
>>>>>
>>>>> Why are multiple brokers that bring with them additional compatibility
>>>>> requirements being developed by QPID ? Is it for enhancing the reach
to
>>>>> other platforms that only a particular technology might support (JMS
>>>>> etc)
>>>>> or
>>>>> is this a corporate missive from Redhat or some one else?
>>>>>
>>>>> Where can i find the information regarding ways in which the brokers
>>>>>
>>>>>
>>>>>
>>>> differ
>>>>
>>>>
>>>>
>>>>> from one another ?
>>>>>
>>>>> Regards
>>>>> Arun
>>>>>
>>>>> -----Original Message-----
>>>>> From: Marnie McCormack [mailto: ]
>>>>> Sent: Thursday, January 29, 2009 2:02 PM
>>>>> To: users@qpid.apache.org
>>>>> Subject: Re: qpid broker on windows
>>>>>
>>>>> See what you mean, thanks.
>>>>>
>>>>> The Qpid roadmap shows 0-10 implementation on the Java broker as one
of
>>>>>
>>>>>
>>>>>
>>>> our
>>>>
>>>>
>>>>
>>>>> next big ticket deliveries. This would mean that the C++ client could
>>>>>
>>>>>
>>>>>
>>>> again
>>>>
>>>>
>>>>
>>>>> interop with the Java broker.
>>>>>
>>>>> On the C# front, we are discussing on the dev list the strategic
>>>>> solution
>>>>> going forward, but again 0-10 implementation on the Java broker will
put
>>>>> the
>>>>> choice of .Net client in the user's hands.
>>>>>
>>>>> Appreciate this doesn't help now, but just for info !
>>>>>
>>>>> Regards,
>>>>> Marnie
>>>>>
>>>>> On Thu, Jan 29, 2009 at 6:41 AM, falconair <shahbazc@gmail.com>
wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Some components of my system need to interact with the broker through
>>>>>> C# (and soon C++). That is the main motivation behind using qpid,
>>>>>> rather than other jms providers.
>>>>>>
>>>>>>
>>>>>> Marnie McCormack wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> The Java broker works with the M4 Java Client and the M4 0-8
.Net
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>> client.
>>>>>>
>>>>>
>>>>>> It
>>>>>>
>>>>>>> does not yet support 0-10 features, but if you're using JMS that's
>>>>>>> probably
>>>>>>> not a major issue.
>>>>>>>
>>>>>>> Marnie
>>>>>>>
>>>>>>> On Tue, Jan 27, 2009 at 2:57 AM, Carl Trieloff
>>>>>>> <cctrieloff@redhat.com>wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> you are correct, the Java broker is not up to 0-10 yet.
>>>>>>>> Carl.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> falconair wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> I stopped using the Java broker months ago because the
latest
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> clients
>>>>>>>>
>>>>
>>>>> (java,
>>>>>
>>>>>>>>> .NET) are based on version 0-10 protocol and the only
broker which
>>>>>>>>> supports
>>>>>>>>> this version is c++. Am I wrong in my assumption? If
Java broker
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> works
>>>>>>>>
>>>>>>
>>>>>>> with m4 clients, I'm happy to switch to java for dev/test work.
>>>>>>>
>>>>>>>>>
>>>>>>>>> Marnie McCormack wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I thought it'd be useful to point out that the Qpid
Java Broker
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> comes
>>>>>>>>>
>>>>>
>>>>>> complete with a Windows startup .bat and is widely used by
>>>>>>
>>>>>>>>>>
>>>>>>>>> developers
>>>>>>>>>
>>>>>
>>>>>> on
>>>>>>
>>>>>>>>>> Windows, out of the box so to speak. It is production
proven.
>>>>>>>>>> You can find out what you need to get started with
the Java Broker
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>> at:
>>>>>>>>>
>>>>>
>>>>>> http://qpid.apache.org/getting-started-guide.html
>>>>>>
>>>>>>>>>> Please give us a shout if you need any extra info.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Marnie
>>>>>>>>>> On Sat, Jan 24, 2009 at 3:23 PM, Carl Trieloff
>>>>>>>>>> <cctrieloff@redhat.com>wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> falconair wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Another poster asked for a pre-built windows
binary of qpid
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> broker.
>>>>>>>>>>>
>>>>>
>>>>>> I'd
>>>>>>
>>>>>>>>>>>> like
>>>>>>>>>>>> to encourage the devs to provide it as well.
>>>>>>>>>>>> Since qpid is still not very well known,
I suspect it is the
>>>>>>>>>>>> down-in-the-trenches developers who are introducing
qpid to
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> their
>>>>>>>>>>>
>>>>
>>>>> companies. Almost every place I have worked, developer
>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> workstations
>>>>>>>>>>>
>>>>>
>>>>>> are
>>>>>>
>>>>>>>>>>>> windows based. In other words, devs are unlikely
to experiment
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> with
>>>>>>>>>>>
>>>>>
>>>>>> qpid
>>>>>>
>>>>>>>>>>>> if
>>>>>>>>>>>> they have to
>>>>>>>>>>>> track down a fairly large number of dependencies
and compile
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> from
>>>>>>>>>>>
>>>>
>>>>> source.
>>>>>
>>>>>>>>>>>> The problem is worse in distributed environments
where one dev
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> either
>>>>>>>>>>>
>>>>>>
>>>>>>> has to
>>>>>>>
>>>>>>>>>>>> distributed his own qpid exe or convince
other devs to build it
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> from
>>>>>>>>>>>
>>>>>
>>>>>> scratch.
>>>>>>
>>>>>>>>>>>> I think this problem will be mitigated by
amqp 0-10 java broker,
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> but
>>>>>>>>>>>
>>>>>
>>>>>> until
>>>>>>
>>>>>>>>>>>> then, pre-built binaries will be very useful.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> yes, we have started a thread on the dev list
to this end, and a
>>>>>>>>>>> version
>>>>>>>>>>> has been built for Windows. Once
>>>>>>>>>>> a few people have validated it, we can post it
to the user list.
>>>>>>>>>>>
>>>>>>>>>>> If you want to help validate the build, jump
on the dev list.
>>>>>>>>>>>
>>>>>>>>>>> Carl.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>
>>>>>
>>>>>
>>>>>> Apache Qpid - AMQP Messaging Implementation
>>>>>>
>>>>>>>>>>> Project: http://qpid.apache.org
>>>>>>>>>>> Use/Interact: mailto:users-subscribe@qpid.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://n2.nabble.com/qpid-broker-on-windows-tp2207029p2237421.html
>>>>>> Sent from the Apache Qpid users mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> Apache Qpid - AMQP Messaging Implementation
>>>>>> Project: http://qpid.apache.org
>>>>>> Use/Interact: mailto:users-subscribe@qpid.apache.org
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> Internal Virus Database is out of date.
>>>>> Checked by AVG - http://www.avg.com
>>>>> Version: 8.0.176 / Virus Database: 270.10.13/1912 - Release Date:
>>>>>
>>>>>
>>>>>
>>>> 1/23/2009
>>>>
>>>>
>>>>
>>>>> 6:54 PM
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>
>
>