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 <[email protected]>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 <
[email protected]> 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 <[email protected]> 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: [email protected]
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 <[email protected]> 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
<[email protected]>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
<[email protected]>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:[email protected]
--
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:[email protected]
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
