RE: Client configuration Connection URL
Hi Rajith,
I think we as a project *must* have the same connection url/string
syntax across all clients.
I don't think this works in the WCF context. But I believe it is
merely because WCF has different conventions, not that the proposal
lacks merit in general.
In WCF, the constituents of the proposed connection string are
traditionally split apart, not least because the bits of the string
would be looked at and applied at different times.
The specifics of specifying (e.g. TLS and SASL PLAIN) connection
related parameters in the WCF/C++ client is a work in progress, so I
don't have a handy example. But as an analogy, using TLS with a
client side certificate for the WCF TCP binding:
NetTcpBinding b = new NetTcpBinding();
b.Security.Mode = SecurityMode.Transport; // versus None, i.e. no TLS
b.Security.Transport.ClientCredentialType =
TcpClientCredentialType.Certificate;
EndpointAddress a = new EndpointAddress(net.tcp://contoso.com/TcpAddress);
ChannelFactoryICalculator cf = new ChannelFactoryICalculator(b, a);
cf.Credentials.ClientCertificate.SetCertificate(
StoreLocation.LocalMachine, StoreName.My, X509FindType.FindByThumbprint,
myCertThumbprintId);
(extracted from http://msdn.microsoft.com/en-us/library/ms729700.aspx,
which contains the config file too; other WCF bindings have their own
specific XyzSecurity and XyzCredentialType classes)
There is an expectation that the transport security mode is set up in
a separate object, which is associated with the binding, and that the
credentials (if any) are associated with the channel factory (of which
there could be many for each binding instance, each with separate
credentials).
Similarly, this division flows to the config file with the security
mode and credentials separated into unrelated bindings and
behaviors XML config sections, respectively (detailed in the link
above).
This division has its detractors. Obtuse programming gymnastics can
be necessary in certain cases, such as where separate credentials are
required by separate layers of the stack (i.e. message versus
transport security, or if the messages pass through a server proxy).
However, WCF programmers are used to this paradigm.
Note that any attempt to use the System.ServiceModel.EndpointAddress
class (above) to combine these properties into a single string would
fail whenever the string fails to parse into a valid URI, long before
the Qpid transport layer gets called.
Cliff
-Original Message-
From: Rajith Attapattu [mailto:rajit...@gmail.com]
Sent: Monday, March 15, 2010 10:48 AM
To: dev@qpid.apache.org
Subject: Re: Client configuration Connection URL
On Mon, Mar 15, 2010 at 12:35 PM, Gordon Sim g...@redhat.com wrote:
On 03/11/2010 11:41 PM, Rajith Attapattu wrote:
Hi All,
Currently quite a bit of options can be configured via the Java
Connection URL, which tends to make it ungainly and quite error prone.
If we are to think in terms of a Connection String instead of a
Connection URL , then I believe we could come up with a more simpler
solution.
Therefore I'd like to make the following proposals.
1) Introduce a simple scheme for a Connection String ( inspired by
the new addressing format)
2) Also allow the ability to specify the config using a property file.
* I hate having to specify user/pass when the auth mech (ex kerberos)
is not even using it. Therefore it should be optional !
1. 0 Connection String
---
1.1 Examples
tcp://localhost
tcp://localhost:8672; {ssl: true, sasl-mech : EXTERNAL,
ssl-trust-store : ~/cert.jks ..}
tcp://host1.example.com; {user: bob, pass: nuts} ,
tcp://host2.example.com; {user: ding, pass: dong} ...
1.2 Syntax
broker [ ;options ] [ ,broker [ ;options ]] *
Where broker is::
protocol:// [ host [ : port ] ] (protocol = {tcp|vm|rdma}
The c++ client currently supports the AMQP 0-10 definition of a url syntax.
Do we want to support that more widely? It would be good to improve
consistency across clients a little.
Well my motivation behind the thread was to get this out in the open.
IMO I think we as a project *must* have the same connection url/string
syntax across all clients.
I thought I'd start with the Java side and then take it from there.
The connection URL has been used for two reasons.
1) To identify which broker(s) to connect to
2) As a configuration mechanism.
My issue is if we treat the whole thing as a URL then supporting the
latter makes the whole thing ugly and error prone.
The Java connection url is a case in point.
I would rather treat it as a connection string which consists of two
**distinct** parts.
a) A broker (identified by a URL - ex tcp://localhost:5672/vhost )
b) A bunch of key:value pairs associated with the broker url.
Based on past experience, munging them together to form a URL is a
good recipe for disaster.
The approach for specifying SSL is also different across the different
clients.
RE: Qpid Wiki in DocBook
Hi Jonathan, Great stuff! I'll try to put together some WCF/C++ client related material over the weekend. Cheers. Cliff -Original Message- From: Jonathan Robie [mailto:jonathan.ro...@redhat.com] Sent: Thursday, March 11, 2010 6:32 AM To: dev@qpid.apache.org Subject: Qpid Wiki in DocBook Here's a PDF built from the Qpid Wiki, converted to DocBook: http://people.apache.org/~jonathan/qpid-book.pdf I'm posting this now as a sign of life, to give a feel for where this is headed, and to get feedback on the organization. There are some things that still need cleaning up: - some links don't resolve properly - some formatting issues - some pages have been updated since I converted them But some of this should simply be replaced with new content - I have some existing content that we can contribute, and I'd like to start creating new content here, instead of or in addition to the Wiki. I'd also like to get some other people working on this with me. I'd particularly like to get someone to be in charge of the section on the Java Broker. Who wants to get involved in this? Jonathan - 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: QMF and .NET
The encoder is basically a map-message encoder, which would be more
generically applicable. My view would be to try and make all the
custom channel stuff as generic as possible.
Sorry, I should be more specific. When I say custom binding
and encoder I am referring to sub-classing
System.ServiceModel.Channels.Binding and
System.ServiceModel.Channels.MessageEncoder
These play an important role in converting abstract WCF Message
objects to and from the wire format. But they don't do encoding
or decoding in the sense you are thinking. They choreograph a
group of other related (and somewhat soapy) objects to do their thing
when the message is consumed (possibly way off in the future, or
never).
A map-message encoder, in the sense you are thinking, would be
separately invoked somewhere along the way (by one of those other
dancing objects). Such an encoder was already envisaged separately
from QMF and will be implemented, in any event, as part of the need
for arbitrary applications to conveniently handle Amqp types in general
and interoperate with other AMQP clients.
The patterns QMFv2 uses are going to be commonly used in other
messaging scenarios.
Agreed.
Cliff
-Original Message-
From: Gordon Sim [mailto:g...@redhat.com]
Sent: Tuesday, March 09, 2010 5:37 AM
To: dev@qpid.apache.org
Subject: Re: QMF and .NET
On 03/08/2010 09:32 PM, Cliff Jansen (Interop Systems Inc) wrote:
Hi Gordon,
I'd suggest we don't focus exclusively on 'QMF' here
I agree completely on your comments regarding generic functionality
and interoperability in the WCF C++ client, and that the need for this
is completely independent of QMFv2.
Though the need is independent, this work would (I believe) go some way
to making QMFv2 usable in .Net also. That was really the point I was making.
My point is merely in regards to Carl's original discussion regarding
various approaches to implementing QMF in .NET and the relative pros
and cons. The arguments apply equally to the Java-derived dotnet
client. Stated another way, (and while looking through a WCF tinted
lens) there are three approaches:
- as before, provide a QMF API in .NET and ignore WCF altogether
(that is, from the application's point of view; the QMF modules
could still use WCF under the hood for sending and receiving the
AMQP messages)
This sounds like the wrong approach to me.
- provide a specialized QMFv2 WCF channel layer, with custom binding
and encoder, so that low level QMF functions are exposed. The WCF
programming model would be used by the application to access
generic QMF functions that don't change between agents.
ProcessQmfSubscribeResponse(some args){
// agent just sent an update,
// do something in context of a rigid IQmfv2 contract
}
The encoder is basically a map-message encoder, which would be more
generically applicable. My view would be to try and make all the custom
channel stuff as generic as possible. The patterns QMFv2 uses are going
to be commonly used in other messaging scenarios.
- provide more specialized WCF channel layers or behaviors so that
Agent-specific contracts can be created:
factory = new ChannelfactoryIPrinterAgentService(qmfBinding,
printerAgentUri);
printerProxy = factory.CreateChannel();
n = printerProxy.GetJobCount();
And, of course, these approaches aren't mutually exclusive. Without
doing a full design and identifying all the pitfalls, my gut
recommendation would be to do approach #2 and a limited amount of #3
for simple agents. This would satisfy power programmers (who might
want to write code that isn't tied to a particular agent anyway) and
leave good bone structure for additional WCF goodies down the road.
That said, custom WCF channel stacks and encoders are non-standard WCF
topics and can be challenging even for many experienced .NET
programmers. I merely wished to reduce the terror quotient by
pointing out that some serious outages in the WCF C++ client that
would affect such work are being addressed as quickly as possible.
Cliff
-Original Message-
From: Gordon Sim [mailto:g...@redhat.com]
Sent: Monday, March 08, 2010 4:11 AM
To: dev@qpid.apache.org
Subject: Re: QMF and .NET
On 03/05/2010 08:56 AM, Cliff Jansen (Interop Systems Inc) wrote:
Hi Carl,
I've taken a look at QMFv2 and hope I understand it well enough to
give useful feedback.
On the whole, I think your characterization of the options is correct.
However, I would suggest you should not think of WCF merely as a SOAPy
WSDL provider, but more as a layered architecture. WCF could provide
a developer with direct access to low level QMF primitives that work
with QMF objects and AMQP data types, or to higher level (possibly
agent specific) RPC calls (e.g. n = HPPrinter.getJobCount();),
according to taste.
The former would work best with a custom QMF
RE: QMF and .NET
Is it on your list of things to do to add map message support for the WCF client? Yes. It is next in line right after SSL support. Cliff -Original Message- From: Carl Trieloff [mailto:cctriel...@redhat.com] Sent: Monday, March 08, 2010 7:27 AM To: dev@qpid.apache.org Subject: Re: QMF and .NET On 03/08/2010 07:11 AM, Gordon Sim wrote: On 03/05/2010 08:56 AM, Cliff Jansen (Interop Systems Inc) wrote: Hi Carl, I've taken a look at QMFv2 and hope I understand it well enough to give useful feedback. On the whole, I think your characterization of the options is correct. However, I would suggest you should not think of WCF merely as a SOAPy WSDL provider, but more as a layered architecture. WCF could provide a developer with direct access to low level QMF primitives that work with QMF objects and AMQP data types, or to higher level (possibly agent specific) RPC calls (e.g. n = HPPrinter.getJobCount();), according to taste. The former would work best with a custom QMF encoder/decoder whose job is mainly to translate between WCF XML infosets and AMQP messages (probably with the help of custom QMF object serializers). QMFv2 uses map messages. As you note below support for such messages would also enhance general interoperability between the various clients independent of QMFv2. The latter would probably require the same plus an added glue layer to match requests and responses, plus tools to convert QMF schema to WSDL. Again, this sort of thing (e.g. generic correlation, response queues etc) seems like something that is relevant more generally. You could implement the low level first, and add more and more bits of upper level icing over time. QMFv2 is designed to be much simpler to use 'directly', by which I mean that constructing, sending, anticipating, receiving and interpreting the messages is easier and will match common patterns relevant to many messaging use cases. I'd suggest we don't focus exclusively on 'QMF' here, but instead work on adding flexibility and capabilities that make the sorts of generic patterns and encodings that QMFv2 makes use of to the WCF client where they can also be used more widely. When evaluating the relative cost/benefits you should note the following in addition to the points you have already raised: - WCF is currently the top contender within the .NET community for client/server or peer to peer communication - AMQP type support, needed by QMFv2, is already planned within the WCF/C++ client for interoperability reasons (and AMQP 1.0 management) and should not need re-porting - basic features of the WCF/C++ client are still in development and the capability to provide temporary queue or ad-hoc bindings isn't expected until some time later in 0.7 I'd be keen to join in any discussions on ways to make the different clients (c++, python, jms, wcf etc) work well in a system together. We've been doing some work there already (common encoding for map messages in python, c++ and jms, a common addressing syntax etc). Cliff, Is it on your list of things to do to add map message support for the WCF client? It seems that is one of the fundemetals on the route to QMF support bit also key for inter-client interop across the type system. Carl. - 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: QMF and .NET
Hi Gordon,
I'd suggest we don't focus exclusively on 'QMF' here
I agree completely on your comments regarding generic functionality
and interoperability in the WCF C++ client, and that the need for this
is completely independent of QMFv2.
My point is merely in regards to Carl's original discussion regarding
various approaches to implementing QMF in .NET and the relative pros
and cons. The arguments apply equally to the Java-derived dotnet
client. Stated another way, (and while looking through a WCF tinted
lens) there are three approaches:
- as before, provide a QMF API in .NET and ignore WCF altogether
(that is, from the application's point of view; the QMF modules
could still use WCF under the hood for sending and receiving the
AMQP messages)
- provide a specialized QMFv2 WCF channel layer, with custom binding
and encoder, so that low level QMF functions are exposed. The WCF
programming model would be used by the application to access
generic QMF functions that don't change between agents.
ProcessQmfSubscribeResponse(some args){
// agent just sent an update,
// do something in context of a rigid IQmfv2 contract
}
- provide more specialized WCF channel layers or behaviors so that
Agent-specific contracts can be created:
factory = new ChannelfactoryIPrinterAgentService(qmfBinding,
printerAgentUri);
printerProxy = factory.CreateChannel();
n = printerProxy.GetJobCount();
And, of course, these approaches aren't mutually exclusive. Without
doing a full design and identifying all the pitfalls, my gut
recommendation would be to do approach #2 and a limited amount of #3
for simple agents. This would satisfy power programmers (who might
want to write code that isn't tied to a particular agent anyway) and
leave good bone structure for additional WCF goodies down the road.
That said, custom WCF channel stacks and encoders are non-standard WCF
topics and can be challenging even for many experienced .NET
programmers. I merely wished to reduce the terror quotient by
pointing out that some serious outages in the WCF C++ client that
would affect such work are being addressed as quickly as possible.
Cliff
-Original Message-
From: Gordon Sim [mailto:g...@redhat.com]
Sent: Monday, March 08, 2010 4:11 AM
To: dev@qpid.apache.org
Subject: Re: QMF and .NET
On 03/05/2010 08:56 AM, Cliff Jansen (Interop Systems Inc) wrote:
Hi Carl,
I've taken a look at QMFv2 and hope I understand it well enough to
give useful feedback.
On the whole, I think your characterization of the options is correct.
However, I would suggest you should not think of WCF merely as a SOAPy
WSDL provider, but more as a layered architecture. WCF could provide
a developer with direct access to low level QMF primitives that work
with QMF objects and AMQP data types, or to higher level (possibly
agent specific) RPC calls (e.g. n = HPPrinter.getJobCount();),
according to taste.
The former would work best with a custom QMF encoder/decoder whose job
is mainly to translate between WCF XML infosets and AMQP messages
(probably with the help of custom QMF object serializers).
QMFv2 uses map messages. As you note below support for such messages
would also enhance general interoperability between the various clients
independent of QMFv2.
The latter would probably require the same plus an added glue layer
to match requests and responses, plus tools to convert QMF schema to WSDL.
Again, this sort of thing (e.g. generic correlation, response queues
etc) seems like something that is relevant more generally.
You could implement the low level first, and add more and more bits of
upper level icing over time.
QMFv2 is designed to be much simpler to use 'directly', by which I mean
that constructing, sending, anticipating, receiving and interpreting the
messages is easier and will match common patterns relevant to many
messaging use cases.
I'd suggest we don't focus exclusively on 'QMF' here, but instead work
on adding flexibility and capabilities that make the sorts of generic
patterns and encodings that QMFv2 makes use of to the WCF client where
they can also be used more widely.
When evaluating the relative cost/benefits you should note the
following in addition to the points you have already raised:
- WCF is currently the top contender within the .NET community for
client/server or peer to peer communication
- AMQP type support, needed by QMFv2, is already planned within the
WCF/C++ client for interoperability reasons (and AMQP 1.0
management) and should not need re-porting
- basic features of the WCF/C++ client are still in development and
the capability to provide temporary queue or ad-hoc bindings
isn't expected until some time later in 0.7
I'd be keen to join in any discussions on ways to make the different
clients (c++, python, jms, wcf etc) work well in a system
RE: QMF and .NET
Hi Carl, I've taken a look at QMFv2 and hope I understand it well enough to give useful feedback. On the whole, I think your characterization of the options is correct. However, I would suggest you should not think of WCF merely as a SOAPy WSDL provider, but more as a layered architecture. WCF could provide a developer with direct access to low level QMF primitives that work with QMF objects and AMQP data types, or to higher level (possibly agent specific) RPC calls (e.g. n = HPPrinter.getJobCount();), according to taste. The former would work best with a custom QMF encoder/decoder whose job is mainly to translate between WCF XML infosets and AMQP messages (probably with the help of custom QMF object serializers). The latter would probably require the same plus an added glue layer to match requests and responses, plus tools to convert QMF schema to WSDL. You could implement the low level first, and add more and more bits of upper level icing over time. When evaluating the relative cost/benefits you should note the following in addition to the points you have already raised: - WCF is currently the top contender within the .NET community for client/server or peer to peer communication - AMQP type support, needed by QMFv2, is already planned within the WCF/C++ client for interoperability reasons (and AMQP 1.0 management) and should not need re-porting - basic features of the WCF/C++ client are still in development and the capability to provide temporary queue or ad-hoc bindings isn't expected until some time later in 0.7 Cliff -Original Message- From: Carl Trieloff [mailto:cctriel...@redhat.com] Sent: Wednesday, March 03, 2010 1:49 PM To: dev@qpid.apache.org Subject: QMF and .NET Options and thoughts on direction for QMF in C#. We have one impl on the native C# client for QMF v1. Question is to port this to the C++ C# wrapped impl or / and do ? First of QMF can be used in two ways, one for modelling object interactions, second doing management. In the Windows world, the most natural binding for QMF would be to have a powershell mapping. For the object mapping it is less clear. Here we could port the work done on the native C# WCF client which provides a service layer inside WCF. Pros - it works, simple. Cons, duplicates QMF logic in C# and does not map directly to the WCF WS stack. We could wrapped QMFv2 API in C#. Pros, no code duplication. Cons, as above ignores the WCF WS stack. Finally we could write a mapping from WSDL to QMF. This would mean all the WCF WS stuff would work with a QMF payload. Pros - fits into WCF service architecture, Cons - we qould be able to map QMF to WSDL, but would not be able to or it would be a large piece of work to map all of WSDL schema to QMF. (Not sure it is worth the effort.) Love to get thoughts, ideas and perspectives. Carl. - 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: Vote for 0.6 Release (Really)
There are certainly other csproj files with the license in at the top of the file - do these cause problems for MSVC? These C# project files are just XML. Putting the Apache license in an XML comment at the top of the file will not adversely affect MSVC. Cliff -Original Message- From: Gordon Sim [mailto:g...@redhat.com] Sent: Tuesday, March 02, 2010 4:20 AM To: dev@qpid.apache.org Subject: Re: Vote for 0.6 Release (Really) On 03/02/2010 09:31 AM, Robbie Gemmell wrote: I believe this means we must fix these and roll another RC before we can proceed with a vote, correct? I believe we have to fix the missing license on the source code at a minimum. I have checked in that change as r917988. On the .csproj files, I would guess that they probably do need a licence, and if most of them already include it then it seems sensible to do the rest and finish the job. Seems sensible. Is someone willing to volunteer to do that? Following Rajiths comments I'm not sure what the right approach is. There are certainly other csproj files with the license in at the top of the file - do these cause problems for MSVC? Robbie On 26 February 2010 15:25, Gordon Simg...@redhat.com wrote: snip It looks fine to me (c++ tests and python tests against the c++ broker run, python management tools run ok). Running RAT against it also looks ok except for ruby/ext/sasl/extconf.rb. That file is tiny, but it is code and it doesn't have the license at the top. (There are some csproj files in the 0-10 dotnet client that also don't have this, e.g. dotnet/client-010/client/Client.csproj, but these may not be required?) - 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 - 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: WCF/C++ client feature work for 0.7
Hi Gordon, (I need to get a better grasp of the WCF model, any good links you can suggest?) Any intro will do, but be warned that the bells and whistles above messaging will get highlighted and seemingly simple terms like client, binding, and message will have specific meaning within WCF. The easiest way to think of it is that there are two programming models. The channel model is at the lower level and has variations of send and receive that are analogous to session.messageTransfer() and localQueue.get(). WcfPerftest.cs is an example and it should be very easy to follow if you are at all familiar with the C++ perftest.cpp program. The second programming model, the service model, is built on top of that and has fancy features for handling incoming messages and imposing structure on message content to allow contracts between clients and servers and discovery of available services. But aside from providing the necessary glue between the service and channel models, the Qpid WCF client is essentially all about the lower level channel model and building an underlying WCF transport channel over AMQP. Another way to think of it is that WCF proxys and dispatchers sit above a transport channel stack that is analogous to an SVRV.3 stream, made up of channels/modules in a pipeline. Closest to the wire is the transport channel. Further up the stack can be another channel that maintains session state. In this context, a WCF binding is the description of the channel stack and its knob and dial settings. People with a messaging background often find that the WCF Message class has a couple of features that are unexpected: (a) its content can be read or written at most once (corresponding to the time the content is extracted or placed on the wire), (b) its content is notionally an abstract XML infoset. Regardless of whether you are expecting the content to be elaborate SOAP or raw binary, you must go through an XML based reader or writer to access the body. The samples both use amqp:exchange_name?routingkey=routing_key when sending and amqp:queue_name when receiving messages. How does the binding (in the AMQP sense) happen? At the moment this has to be done outside WCF using external tools like the python qpid-config command or a custom C++ program. Near term feature work will allow creating temporary queues on the fly for subscribers to topic exchanges or associating a temporary response queue with a WCF channel. Further out, the plan is to supply PowerShell commands to do more sophisticated management, which can in turn be called from GUI management consoles or invoked from within applications. How would I specify accept/acquire modes? There is no way at the moment, but the way to specify it would be as a binding property (similar to setting the prefetch limit on incoming messages). .NET Framework 4.0, which will be out soon, has a new feature called ReceiveContext which allows the application to specify acceptance of a particular message. Until then, a WCF message must be processed in the scope of a transaction to defer its acceptance/rejection (in this case at the time the transaction status is determined). How would I get access to the message properties for sent and/or received messages? The extensibility point in the WCF Message class is the Properties field which allows adding an arbitrary object (in our case an AmqpProperty). AmqpProperties amqpProperties = new AmqpProperties(); // sample AMQP property: amqpProperties.Durable = true; // arbitrary application property: DictionaryString, AmqpType amqpProperties.PropertyMap.Add(appkey1, new AmqpInt(1234)); myWcfMessage.Properties.Add(AmqpProperties, amqpProperties); I hope this helps. Cliff -Original Message- From: Gordon Sim [mailto:g...@redhat.com] Sent: Monday, February 15, 2010 11:29 AM To: dev@qpid.apache.org Subject: Re: WCF/C++ client feature work for 0.7 On 02/10/2010 07:41 AM, Cliff Jansen (Interop Systems Inc) wrote: Hi Gordon, I'd be keen to hear more of your thoughts an opinions on the new API for the c++ client. I will try to take another look at it shortly. It would be worth seeing if we can get better alignment between the examples for all languages. Agreed. I will do my best to make the upcoming interop examples resemble the main C++ and Java examples in structure as much as WCF allows. I didn't mean to imply that was a task just for you! We should work together to make sure that the various components look more like part of a coherent suite. (I need to get a better grasp of the WCF model, any good links you can suggest?) Documentation of some form would be really great [...] Absolutely. This is a known major outage and is just as high a priority for us as the functional feature work. I notice for example you use uris that look similar to the JMS binding urls. Is the same syntax supported? There are some usability issues with that format (in my opinion
RE: WCF/C++ client feature work for 0.7
Hi Gordon, I'd be keen to hear more of your thoughts an opinions on the new API for the c++ client. I will try to take another look at it shortly. It would be worth seeing if we can get better alignment between the examples for all languages. Agreed. I will do my best to make the upcoming interop examples resemble the main C++ and Java examples in structure as much as WCF allows. Documentation of some form would be really great [...] Absolutely. This is a known major outage and is just as high a priority for us as the functional feature work. I notice for example you use uris that look similar to the JMS binding urls. Is the same syntax supported? There are some usability issues with that format (in my opinion), especially when using more complex patterns. I believe there are very few similarities. The WCF model specifies the connection properties to servers (i.e. brokers) in a separate Binding which can be arbitrarily complex and already has established conventions for specifying many network related properties either programmatically or within XML config files. The actual uris in the WCF client specify the minimum to identify a queue or exchange + routing key pair. A similar mechanism, with slight variation, will probably be proposed for use with AMQP 1.0. Cliff -Original Message- From: Gordon Sim [mailto:g...@redhat.com] Sent: Friday, February 05, 2010 4:19 AM To: dev@qpid.apache.org Subject: Re: WCF/C++ client feature work for 0.7 Thanks for the info, Cliff! You've done some great work on this. On 02/04/2010 07:54 PM, Cliff Jansen (Interop Systems Inc) wrote: The existing 0.6 version of the WCF/C++ client provides basic WCF functionality. Its most significant additional feature is distributed transaction support for enterprise applications. The WCF channel portion relies on the well tested and high performance C++ native client libraries for most of the logic at the transport and session layers. The current status and future wish list are summarized in the top-level ReadMe.txt file. I'd be keen to hear more of your thoughts an opinions on the new API for the c++ client. Though the existing 0-10 specific API will remain, I anticipate improvements and added features via the new API (producer flow control for example, and it already has built in reconnection and replay logic). The long term goal of the WCF channel is to provide .NET programmers with a full featured AMQP messaging client. To maximize adoption, it uses the same programming model used by the Microsoft WCF channel implementations for messaging over MSMQ and over WebSphere MQ. To maximize functionality, it incorporates or has planned features for AMQP specific capabilities (such as local transactions which will require some magic to associate separate WCF channels with a single AMQP session). A further goal is to maximize the interoperability of the WCF channel with other AMQP clients by providing full access to AMQP types in message headers and the message body. In 0.6 it is possible to exchange int and string properties between JMS and WCF clients. Text and binary content can also be shared between clients as demonstrated by the WcfPerftest sample program. Expanding this to include all JMS message properties and supporting AMQP map messages is proposed as a high priority improvement for the WCF channel in the 0.7 timeframe (consistent with the goals of QPID-2226). It would be worth seeing if we can get better alignment between the examples for all languages. That's a great way to demonstrate the basic interoperability and is especially helpful when for clients with quite different programming models. Documentation of some form would be really great (even if its links elsewhere) on that front also. The samples are really quite different to those for the other clients. I don't have previous experience of WCF, and it may be more obvious to those that do. Even there though some description of the mapping of WCF to AMQP would be important. I notice for example you use uris that look similar to the JMS binding urls. Is the same syntax supported? There are some usability issues with that format (in my opinion), especially when using more complex patterns. - 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: Status of Windows SSL / ACL ?
Hi Kerry, By coincidence, I have gone through the certificate learning curve in the last few days. The Windows broker currently supports registry based (as opposed to file based) certificates that are in a certificate store that is scoped to the local machine (not the current user). I am not up to speed on mixing OpenSSL data files with Windows registry stores. You can try the following (with Administrator privilege) to create a new self signed cert: makecert -ss qpidstore -n CN=myserver -r -sr localmachine myserver.cer Where qpidstore is an arbitrary store name to place your qpid related cert(s) and myserver is the name the clients expect your server's common name to be. This registry entry contains the private and public keys of the certificate. myserver.cer contains the public key. You must import this into the trusted roots on Windows via certmgr for each client that needs to connect to the server. You can examine it from OpenSSL via openssl x509 -in myserver.cer -inform DER -text To run the server, again as Administrator: qpidd --ssl-cert-name myserver --ssl-cert-store qpidstore --other-args I am not aware that anyone is currently working on QPID-1842. If you have time to donate here, it would be greatly appreciated. But note: [...] I need secure broker (with clustering) on the Windows platform working in the next few months for my project here. Clustering support has not yet been ported to Windows. I am not aware that it has even been seriously scoped in terms of effort. Steve Huston would be the best source of information on this. Cliff -Original Message- From: Kerry Bonin [mailto:kerrybo...@gmail.com] Sent: Wednesday, February 03, 2010 12:43 PM To: qpid-dev Subject: Status of Windows SSL / ACL ? Hello! I had a few questions regarding the state of broker security for Windows platforms. On the SSL front, I see QPID-1403 has been resolved, and I can now build w/ BUILD_SSL enabled. What I haven't been able to get working yet is to get my broker to actually load a certificate - ::CertFindCertificateInStore fails. On this issue, do we have a known good set of instructions to generate a working system? The windows error (Cannot find object or property) is so vague I'm not sure why it isn't loading my cert. I'm generating a self-signed cert w/ openssl, loading as trusted root cert, generating a client cert w/ the CN of my node, converting to pkcs12 along w/ password free private key and importing to the personal store w/ friendly name of node, not sure what else I need to do... On the ACL front, QPID-1842 is still keeping Windows link from working. Any idea when this will be fixed? On a related note, I have time to help fix these, as I need secure broker (with clustering) on the Windows platform working in the next few months for my project here. Appreciate any pointers, and please let me know if there is anything I can do to help... Kerry Bonin Sr. Systems Architect GE Security - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: Fifth (and I hope final) Release Candidate for 0.6 qpid release
The fixes you made on my behalf look good. Thanks very much. Cliff -Original Message- From: Andrew Stitcher [mailto:astitc...@redhat.com] Sent: Tuesday, February 02, 2010 9:26 AM To: Qpid Dev List Subject: Fifth (and I hope final) Release Candidate for 0.6 qpid release I've now uploaded another release candidate for 0.6. As usual you'll find it in: http://qpid.apache.org/dist/qpid-0.6rc5 The list of issues fixed since we branched the release from trunk is: (that branch point was rc3) == qpid-0.6rc5 == QPID-2378: Necessary License files for the WCF release artifact (from Cliff Jansen) QPID-2313: Update to WCF Release notes (from Cliff Jansen) Revised release notes for 0.6 == qpid-0.6rc4 == QPID-2137 : Commit patch to address StringIndexOutOfBounds during status logging. Merge of trunk r898821. QPID-2320: merged fix from trunk to 0.6 release branch. == qpid-0.6rc3 == I think this release should fix all the problems that have been reported up to this point for the 0.6 release. Please download something and give it a smoke test. As you can see ther have only been documentation changes since rc4. So if you built and tested something successfully under rc4 then there is every reason to think it will still work. I'll leave this a day, then I will call for a release vote on this version packaged up as 0.6 if there are no reported problems. Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: 0.6RC4 available [Was: 0.6 Release - Query]
Please apply QPID-2378 to the 0.6 branch to pick up the WCF client specific release notes I'm sorry. I mean QPID-2313. Cliff -Original Message- From: Cliff Jansen (Interop Systems Inc) [mailto:v-clj...@microsoft.com] Sent: Friday, January 29, 2010 12:07 PM To: dev@qpid.apache.org; Andrew Stitcher Subject: RE: 0.6RC4 available [Was: 0.6 Release - Query] Hi Andrew, My deepest apologies for missing the Licensing files outage. I have attached patches to QPID-2378 to fix this. As I said several times before, I do not have enough time to go through and do comprehensive release notes, as I've received exactly 3 lines of release notes I've not done anything yet. Please apply QPID-2378 to the 0.6 branch to pick up the WCF client specific release notes which describe planned features, build instructions, transaction configuration settings, and known issues. Thanks. Cliff
RE: 0.6 Release Plans from now onwards
Cliff can you comment on these bugs? Are they truly as important as blocker/critical? If so unless there are patches attached to the jiras very soon I think we'll have to omit the specific WCF source code from this release [...] Agreed. These were marked as such because they would make a significant difference to early adopters and were thought to be doable *without* holding up the release. Right now, I feel comfortable about resolving QPID-2247 (and even QPID-2128) by tomorrow and QPID-2260 certainly by Thursday. The latter is very easy conceptually and boils down to testing in the various scenarios. Cliff -Original Message- From: Andrew Stitcher [mailto:astitc...@redhat.com] Sent: Tuesday, December 15, 2009 2:27 PM To: Qpid Dev List Subject: 0.6 Release Plans from now onwards As I said in my beta release message I'd like to produce a release candidate at the end of this week. On the closing bugs front there are a couple of issues still (but nothing that looks deadly as far as I can tell): Essentially we have 2 blockers and 2 critical bugs. 2 Java bugs and 2 bugs for the WCF code. QPID-2273 (http://issues.apache.org/jira/browse/QPID-2273), QPID-1830 (http://issues.apache.org/jira/browse/QPID-1830) - Aidan can you give some status on these bugs? Are they going to be finished in the next couple of days? Is there much risk in the fixes? QPID-2260 (http://issues.apache.org/jira/browse/QPID-2260), QPID-2247 (http://issues.apache.org/jira/browse/QPID-2247) - These are more problematic as they don't have anyone assigned to them. It could be that Cliff is working on them, but as he isn't a commiter he can't be assigned the bugs in Jira. Cliff can you comment on these bugs? Are they truly as important as blocker/critical? If so unless there are patches attached to the jiras very soon I think we'll have to omit the specific WCF source code from this release (of course it will still be in the big source tarball). To be honest I'm really sure it's quite mature enough in any case. Assuming that we can clear these issues up (one way or another) in the next couple of days - I plan to release rc1 on Thursday/Friday this week. I will create a (preemptive) subversion tag at that point. From that point I'd like to *freeze* checkins to the tree for 2 weeks taking us effectively to the new year. If we haven't actually voted to release by then I suggest we move the branch tag to whatever the most recent qpid checkin is and do all subsequent release work on a branch, and unfreeze the trunk. This way we should have the minimum frozen time and still be able to progress. Regards Andrew - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
WCF release artifact for 0.6
I have taken a first stab at providing the release artifact for
WCF. (QPID-2267)
Like the python and ruby cases, it consists of a static snapshot of
the relevant subdirectory.
Unlike those cases, it cannot be built by the user unless the C++
artifact is also downloaded and built to provide the necessary
qpidclient.dll, qpidcommon.dll, and C++ include files. As an
alternative, the artifact could include both the wcf subtree and the
qpid-cpp-{VER} contents in one place. However, I see little benefit
of doing so compared to downloading each separately.
Please let me know if you have a differing view.
Thanks.
RE: First Qpid 0.6 Beta Release available for download and testing
Another thing I have noticed is that there is no WCF component artifact in the beta build, is that something we plan to release with 0.6? Yes. I contacted Andrew about this yesterday. JIRA coming soon. Cliff -Original Message- From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com] Sent: Thursday, December 10, 2009 6:15 AM To: dev@qpid.apache.org Subject: RE: First Qpid 0.6 Beta Release available for download and testing I have updated the release script to set the SVN version as a property on the Ant command line and modified the ant build scripts as mentioned below. I Also updated some straggling version numbers in the Java tree for the 0.6 release. Another thing I have noticed is that there is no WCF component artifact in the beta build, is that something we plan to release with 0.6? Robbie -Original Message- From: Robbie Gemmell [mailto:robbie.gemm...@gmail.com] Sent: 09 December 2009 22:42 To: dev@qpid.apache.org Subject: RE: First Qpid 0.6 Beta Release available for download and testing You are indeed correct. I didn't actually look at the script before mentioning it as I just presumed it was the Git addition that did it hehe. Oh well, still needs fixing :) I'll look at it tomorrow, shouldn't take long to add a property check. I'll probably standardise the different areas that doo it too as I think they do it independently and slightly differently, and I recall there being an issue whereby if you dont actually have the svnversion command on your path Ant encounters an infinite loop property definition and refuses to build a second time ;) Robbie -Original Message- From: Andrew Stitcher [mailto:astitc...@redhat.com] Sent: 09 December 2009 22:24 To: dev@qpid.apache.org Subject: RE: First Qpid 0.6 Beta Release available for download and testing On Wed, 2009-12-09 at 22:01 +, Robbie Gemmell wrote: No that explains it, it's just the same effect as using git would have caused, I just assumed since you added that... :) By using svn export you don't get the .svn/ metadata directories within each directory, and so svnversion cant detect the version when run and assumes it was exported (which in this case, it actually was). I will have a look at updating the Ant scripting to allow specifying the revision to handle this. FWIW in that case this isn't a regression as I believe previous releases were produced using svn export also. A - 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: 10000 msgs limit per session
Robert Greig wrote: Having said that, I did take a look at this question (could WCF be a generic messaging API) for other reasons related to my day job a while ago and concluded that it could be. You would simply have to define some very simple contracts (e.g. with a single method StandardOneWay(Message m) and you would perhaps also need some AMQP-specific behaviours (a WCF term) to give complete flexibility. Cliff, am I right in assuming that is where you were going with the WCF client? That is a very valid way to look at it, but not because it is a stated objective of the work I have been doing, but merely because that is how WCF tends to be used in a messaging context (i.e. for MSMQ and WebSphere MQ based transports) if you are using the service model. You can also just use one-way channels to send and receive messages programmatically. WCF isn't the solution to every conceivable messaging problem, but it is a very important framework for .NET developers. It can handle many common messaging scenarios and the code under qpid/wcf tries to provide the AMQP based transport that is expected in these cases. Robert Godfrey wrote: I'm very supportive of the efforts to make available a WCF client for Qpid (and more generally, I hope, for AMQP) however I think we need to look a little more carefully about how we are going to go forward supporting .net application programmers and - something that tends to get a little lost - how we enable .net programmers to interoperate seamlessly with clients using other APIs (for example JMS - .net/WCF).. Unless there is an issue with interoperability in the case of JMS - C++ client, I think that JMS - .net/WCF interoperability should occur as a matter of course when the AmqpType sub-classes are fleshed out. Cliff -Original Message- From: Robert Greig [mailto:robert.j.gr...@gmail.com] Sent: Monday, November 30, 2009 9:44 AM To: dev@qpid.apache.org Subject: Re: 1 msgs limit per session 2009/11/30 Rafael Schloming rafa...@redhat.com: I'm not sure the stuff Cliff is working on (useful as it is) is actually a substitute for the old .NET client(s). I took a brief look at the WCF stuff as I was curious about it, and from what I could glean from the readme and the examples, it seemed more like an RPC mechanism than a messaging API. It also looked like the implementation was windows only. RPC...you mean services :-) It is certainly true that WCF is geared around building services and clients for those services, with abstractions to allow a great deal of flexibility (e.g. transport). For example, IBM have produced a WCF channel for MQ and it is heavily geared towards SOAP over JMS. Having said that, I did take a look at this question (could WCF be a generic messaging API) for other reasons related to my day job a while ago and concluded that it could be. You would simply have to define some very simple contracts (e.g. with a single method StandardOneWay(Message m) and you would perhaps also need some AMQP-specific behaviours (a WCF term) to give complete flexibility. Cliff, am I right in assuming that is where you were going with the WCF client? I do think that nothing we have under dotnet or wcf currently qualifies as production ready or supported relative to our other clients, and we should make this clear somehow, but I don't think it would be correct to deprecate the old one in favor of the new one unless I'm missing something about the new one. I think our existing .NET client is very poor and gives potential .NET users a very bad impression of the project. Do we know if anyone is actually using it successfully and is happy with it? RG - 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: 10000 msgs limit per session
Robert Greig wrote: I can see that it would be nice to have a completely managed code .NET library (for example, I think you need to be fully managed to support one click deployment?). However I can also see that leveraging the existing C++ codebase is very attractive since the core of it has been tested a lot on linux and the port of the rest is required for a Windows broker. It would be interesting to know if this is why the Microsoft guys decided to take that approach rather than rewriting the managed code client. The maturity of the C++ code base combined with its high level of developer activity and the desire to use a C++ broker were indeed major reasons for focusing on the C++ side of the house for WCF development. It is also worth pointing out that the WCF implementations from Microsoft for both MSMQ and WebSphere MQ were implemented using a managed to native interop layer and relying on the native C++ libraries (from Microsoft and IBM respectively) to do most of the heavy lifting. Consequently, using the C++ Qpid libraries in a mixed managed and native mode implementation was always viewed as a natural design choice. Cliff - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: IKVMing the Java client for .Net
Robert Greig wrote: Finally, there are performance issue with managed/non-managed heap copies in Java that makes JNI unattractive (I don't know if this applies to .NET too - although I did ask the question on this mailing list some time ago without receiving any answer). I'll take a stab at it now. This can be mitigated somewhat by asking the garbage collector to pin a managed memory location for a brief amount of time, but there are housekeeping costs associated with that too. In the current WCF implementation, there is a single copy between the binary message content in managed space and the individual AMQP message body frames in native space. A purely native Visual C++ application would have to make that same copy. But it would be spared the costs of the pinning and the numerous managed to native transitions used to monitor and control the Qpid objects that control connections, sessions, subscriptions etc. For very large messages, the overhead is small. For 100 byte sized ones it is certainly significant. Cliff -Original Message- From: Robert Greig [mailto:robert.j.gr...@gmail.com] Sent: Wednesday, January 28, 2009 12:05 PM To: dev@qpid.apache.org; cctriel...@redhat.com Subject: Re: IKVMing the Java client for .Net 2009/1/23 Carl Trieloff cctriel...@redhat.com: In a discussion with the Microsoft guys, I they where thinking of using the C++ client, with WCF on top of that. They seem to have thought about that quite a bit, so it would be good to get those comments onto the list also around this topic. Is this not going to suffer the same performance issues that Java has with JNI? (I ask that as a question, not an assertion, but I had always assumed this would apply across both platforms). In Java there is a non-trivial performance penalty copying data from the C heap to the Java heap and vice versa. This is one reason why some JDBC drivers built on top of native code perform and scale much worse than pure Java drivers (the example often benchmarked is the Oracle driver). RG - 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: [c++ cluster] User doc for persistent clusters.
The Linux C++ code base is certainly more mature, but features for Windows users are under very active development. New for 0.6 is a persistent store module, SSL support (shortly), a greatly improved build experience. Clustering support is high on the wish list, but planning and development on that front has not yet started. Cliff -Original Message- From: Alexei Sosin [mailto:al...@compatibl.com] Sent: Thursday, November 26, 2009 2:10 AM To: dev@qpid.apache.org Subject: RE: [c++ cluster] User doc for persistent clusters. I figured out recently that clustering is not supported on Windows c++ broker. Is it correct that Windows broker is for toy prototyping only, and Linux is for real projects? Is there any features-comparison chart, whatever, to know exactly what the differences are? Sorry I actually quite new to QPID. -Original Message- From: John O'Hara [mailto:john.r.oh...@gmail.com] Sent: Tuesday, November 24, 2009 10:42 PM To: dev@qpid.apache.org; 'Jonathan Robie'; 'qpid-dev-apache' Subject: RE: [c++ cluster] User doc for persistent clusters. Nice work. -Original Message- From: Alan Conway [mailto:acon...@redhat.com] Sent: 24 November 2009 15:56 To: Jonathan Robie; qpid-dev-apache Subject: [c++ cluster] User doc for persistent clusters. I put up a user view of the peristent cluster changes, coming soon. Would appreaciate any feedback on the doc or the feature it describes. http://cwiki.apache.org/confluence/display/qpid/Persistent+Cluster+Restart+D esign+Note - 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 - 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: Fwd: Requesting a project proposal for an Undergraduate 12 week project proposal
Hi Ishara, Hi Carl, Thanks a lot for your reply.I,m interested to contribute to the C# client. That would be great. I would be happy to give you any help to get started. Carl Trieloff wrote: - Cliff from Microsoft has submitted a C# client over the C++ client. This client is written in both C# (pure managed) and C++/CLI (mixed mode), so the language choice may influence which tasks are attractive to you. From qpid/wcf/ReadMe.txt: 2. Planned features (not yet available) === 1. Full AMQP type support, including maps and arrays 2. System.Transactions integration (local and distributed with dynamic escalation) 3. Prefetch window for inbound messages 4. Shared sessions 5. Connection failover with AMQP broker clusters 6. Temporary queues 7. Broker management 8. System logging and tracing 9. CMake build system support 10. Transport and message based security Carl's suggestion regarding QMF is a good one. It requires #1 as a prerequisite, but the two together should leave plenty of room for GUI flourishes too. It would be 90% C# and 10% C++/CLI (with simple boiler plate mixed mode needs). #4 is essentially straight forward, but exposes some of the nuanced differences between AMQP and WCF. Combined with #8 and some NUnit tests, this could also be a reasonable selection (99% C#). Broker management (#7), is a broader topic than QMF. If you have an interest in PowerShell programming or Management Console snap-ins, there are additional options to look at in this area. Brief notes about the others: #3 is already complete (QPID-2110). #2 should have a first cut ready in a week or so, and I am also actively working on #6. #5 requires that you have access to a Linux cluster of brokers. #9 is all about build scripts and compiler/linker options. #10 which is largely about completing missing bits in the native C++ client on Windows (SSL and SASL). Cliff -Original Message- From: ishara karunarathna [mailto:isharaar...@gmail.com] Sent: Monday, September 21, 2009 9:06 AM To: dev@qpid.apache.org; cctriel...@redhat.com Subject: Re: Fwd: Requesting a project proposal for an Undergraduate 12 week project proposal Hi Carl, Thanks a lot for your reply.I,m interested to contribute to the C# client. As I'm new to Apache Qpid I haven't proper idea on that, so can you suggest me where I can find more information on that. Regards Ishara - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: [c++] latest messaging api patch
I like the discussion on message content. Given Alan's recent suggestions, I can easily envisage how an implementation could optimize the Receiver case and lazily extract the content from the underlying protocol frames into the form required by the application, and avoid an intermediate memory copy. IstreamView(m).read(myMemPtr, m.getContentSize()); i.e., I don't just get the content, I get it where it needed to go. As a bonus, it can plug right into a decoder, again streaming straight from the protocol frames. The reverse direction is not symmetrical. If you insert content into the message (by assignment or via an ostream), how can the implementation know at this point what the frame content size will be? Message m; // set headers // insert content... but where is this message going? mySender.send(m); // frames get created here I can only see two potential solutions to the problem (being mindful of the frame set lifecycle issues that were mentioned). 1. provide a way to associate a message (or subclass, or the MessageContent) with a connection/session on creation, or prior to inserting content. Something like: Message m = mySession.CreateMessage(); 2. provide an optional pull mechanism, such as assigning an istream to the content, where the implementation can create the frames directly at the time of the Sender.send(). The former is more sensible for use with an encoder... a powerful motivation for this option. The latter compartmentalizes the performance optimization as an optional-use API and does the right thing if you send the same message over two different connections. Plus you could do cutesy things with custom istreams, such as reading from disk or a database directly into the frame set. Cliff - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: c++ messaging api: a map message example
Hi Gordon, Jonathan previously requested support for the stream operator and I've had a tentative stab at exploring what that might look like as well. In addition, I would like to see the some stream-ish functions that are friendly to char* blobs that are not null terminated. Something along the lines of: MessageContent MessageContent::write (const char* s, int n); MessageContent MessageContent::read (const char* s, int n); // + rewind() or seek As well as something like int MessageContent::size(); // (or getSize(), getLength()...) Message::Message(const char* s, int n); Note that std::string is not copy-on-write in all C++ implementations. On Windows, forcing an application to use strings for its raw data (from a char* perspective) results in needless copies of the content: string tmpdata(myBlobPtr, myBlobSize); // memory copy #1 Message m(tmpdata); // m.impl-bytes gets copy #2 when constructed // tmpdata never used again, freed when out of scope The programmer can take evasive action: Message m; // m.impl-bytes starts out as a sacrificial empty string m.getBytes().assign(myBlobPtr, myBlobSize); // just one copy but Message m(myBlobPtr, myBlobSize); might create the FrameSet directly, and cut out another middleman. Since MessageContent already has abstract content (string, MAP, and LIST), extentending the set to include char* could allow performance optimizations: For incoming messages, the actual content could be copied from the FrameSet directly to an application buffer. (This can be a win even on Linux when messages are larger than the connection's maxFrameSize.) The string form can be lazilly created when needed. For outgoing messages, the content may be placed directly in special OS memory in preparation for network transfer. Cliff -Original Message- From: Gordon Sim [mailto:g...@redhat.com] Sent: Friday, July 31, 2009 10:11 AM To: Qpid Dev; us...@qpid.apache.org Subject: c++ messaging api: a map message example Attached is a patch for a higher level, protocol independent messaging api from c++ as last discussed some months ago. I have not had much time to spend on this since then and so there is not a huge amount of change (mainly moving to a better namespace and adjusting for the revised include directory layout). There is however now an example of a sending a map message using the amqp0-10 encoding (list messages are also supported) and the message headers are now correctly sent. Jonathan previously requested support for the stream operator and I've had a tentative stab at exploring what that might look like as well. As always keen to get any feedback. I'm hoping to have more time to spend on this for the next few weeks. I'm aiming to align the c++ api with the similar work on python (at least conceptually) and to flesh out the functionality (determining how best to expose asynchronous completion of sends and acknowledgements will be a likely next step). --Gordon. - Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
RE: .Net client lib status
Ted Ross wrote: Regarding the .Net client in general... It's my understanding that there are some contributors at Microsoft that are working on this part of the code but I don't know what the status of that work is. Maybe somebody who knows will chime in. Since David Ingham has just become a proud father and is spending time with family, I will do the chiming. Microsoft's efforts are actually focused towards the qpid/cpp branch of the source code. In addition to the cmake and installation work that Steve Huston has recently done, there is ongoing work to provide a persistence layer for the C++ broker on Windows. Microsoft is also using the Qpid C++ code as a base for client support on Windows. There is work in progress to provide a .NET WCF Channel that is layered on top of the qpidclient.dll and qpidcommon.dll libraries, with support for both XML Infoset and binary encoded message formats and providing an associated resource manager for single and multi-phase transaction support. We are hopeful that this WCF Channel design will gel sufficiently in the very near future (a few weeks?) to be able to provide a detailed outline and fledgling code for review and comment by the Qpid community. Cliff -Original Message- From: Ted Ross [mailto:tr...@redhat.com] Sent: Friday, June 26, 2009 11:48 AM To: dev@qpid.apache.org Subject: Re: .Net client lib status Julien, Thanks for sending a reminder about your Jira/patch. You are using the right process, we were just a bit slow on the uptake. I'll take a look at that issue. Regarding the .Net client in general... It's my understanding that there are some contributors at Microsoft that are working on this part of the code but I don't know what the status of that work is. Maybe somebody who knows will chime in. Regards, -Ted Julien Lavigne du Cadet wrote: Dear Commiters, I wonder what the status of the .Net client lib is as I’m starting to make extensive use of it for several in-house applications. As far as I can tell, there have been minimal updates since December, except for the QMF patch. Is someone maintaining it? I discovered several potential problems in the current implementation for which I’d like to submit patches : - Fixes in the UUID class (which has very strong problems IMHO) - Adding interfaces to simplify testing - Renaming to follow the .Net convention (if that is acceptable of course) - And potentially more (for instance, I have my own partial implementation of QMF which is a lot more “.Net” oriented than the one submitted) However, I submitted a first patch to see if it would be integrated before sending more but the issue is still unresolved http://issues.apache.org/jira/browse/QPID-1897 2 weeks after. (Of course I’m perfectly happy if there’s good reason not to integrate it J) Is there a specific process I should follow to submit patches? Best regards, Julien Lavigne du Cadet __ Sent from my www.pageflakes.com startpage - 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: windows build
The protocol_gen.mak step is only required if you are building straight from the svn repository. Since you are building from the source distribution, you should just proceed to building the broker or client from the qpid.sln file in the src directory. Cliff -Original Message- From: lroloson [mailto:lrolo...@trmi.com] Sent: Monday, March 02, 2009 2:38 PM To: qpid-...@incubator.apache.org Subject: windows build I am trying to build qpid broker on XP from the qpid-cpp-M4.tar.gz download. I have been trying to follow the directions I found in the wiki here (https://issues.apache.org/jira/browse/QPID-1675), I am using Vis Studio 2008, I have installed Ruby and Python, but nmake protocol_gen.mak fails with the following; NMAKE : fatal error U1073: don't know how to make '..\..\specs\amqp.0-10-qpid-errata.xml' Stop. There are no files in ..\..\specs - where should those files come from? Any help would be appreciated -- View this message in context: http://www.nabble.com/windows-build-tp22298467p22298467.html Sent from the Qpid Developers mailing list archive at Nabble.com. - 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: C++ - Dynamic Link Libraries
Hi Danushka, That was another subject I was going to broach for M5, probably on the heels of the C++ build system. I would suggest to export the needed symbols rather than all of them if possible. I would also recommend defining the exports in source (as the Boost libraries do), rather than using a module-definition file. Regards, Cliff -Original Message- From: Danushka Menikkumbura [mailto:danus...@wso2.com] Sent: Monday, January 26, 2009 7:12 PM To: dev@qpid.apache.org Subject: C++ - Dynamic Link Libraries Hi Devs, I need to compile C++ libraries as DLLs and there is quite a bit of work in exporting symbols. Can I assume no one is working on this already?. I will start with exporting mandatory symbols. Is it useful to export each and every symbol? Thought please. Danushka -- Danushka Menikkumbura Technical Lead, WSO2 Inc. blog : http://danushka-menikkumbura.blogspot.com/ http://wso2.com/ - The Open Source SOA Company - 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
Additional Qpid C++ on Windows content
Hi all, Windows is a newly supported C++ platform in M4 and we are beginning to see some early adopters having difficulty. May I suggest a Windows area on qpid.apache.org with: - more elaborate install and run doc - clear info on differences compared to the Linux implementation i.e. X has been ported in M4, Y will be in the future - this (growing) list of tests/samples is known to work - binaries, 32 and 64 bit - possibly previewing an M5-style installer - backported M5 bug fixes for Windows (like QPID-1550 when available) - a few more Visual Studio build scripts for samples or tests Let me know if this would be useful. I would propose to do the lion's share on this with some Jiras and associated patches. Also, some of this can be staged or mirrored at a Microsoft public location if that's helpful or more appropriate. Cliff
RE: Qpid .NET Strategy - Interested ?
I would be very interested to join the conference call. Thanks. Cliff -Original Message- From: Marnie McCormack [mailto:marnie.mccorm...@googlemail.com] Sent: Thursday, January 08, 2009 1:53 AM To: qpid-...@apache.org Subject: Qpid .NET Strategy - Interested ? All, We are currently in a somewhat interesting situation wrt to .NET clients in Qpid. I thought it might be helpful to get together the group of interested parties to agree the best way forward for the existing clients, and also to do some retrospective/forward looking requirements capture to help to clarify our aims. Can you reply if you'd be interested in attending a conference call to discuss this please ? We will (of course) post the notes/actions/decisions back to the list. I'll endeavour to make the session as widely attend-able as possible. Thanks Regards, Marnie
