You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Alexei Sosin <al...@compatibl.com> on 2009/11/30 12:14:20 UTC
10000 msgs limit per session
I noted that there is a limitation in .Net client, to receive 10 000 messages only per session. Client just stops receiving them after this number has passed.
Digging into the 0-10 client code, there is a line in ClientSession.cs:
messageFlow(queue, MessageCreditUnit.MESSAGE, 10000);
So the worj-around for me is that client should count messages and re-create session once it hits the limit.
But, why this limitation is there? I see no such limits mentioned in AMQP spec.
--Alexei
yahoo: alexei.sosin
mts: 6021715
Re: dotnet/wcf roadmap (was Re: 10000 msgs limit per session)
Posted by Rajith Attapattu <ra...@gmail.com>.
On Mon, Nov 30, 2009 at 11:56 AM, Rafael Schloming <ra...@redhat.com> wrote:
> Carl Trieloff wrote:
>>
>> Robert Godfrey wrote:
>>>
>>>
>>> 2009/11/30 Carl Trieloff <cctrieloff@redhat.com
>>> <ma...@redhat.com>>
>>>
>>> Aidan Skinner wrote:
>>>
>>> On Mon, Nov 30, 2009 at 2:11 PM, Carl Trieloff
>>> <cctrieloff@redhat.com <ma...@redhat.com>> wrote:
>>> The old 0-10 version that is pure .NET (0.5) or the
>>> updated version that
>>> Cliff has been working extensively on (coming in 0.6 from
>>> trunk)?
>>>
>>> Sorry if this is confusing, we should deprecate the old
>>> one from the source
>>> tree...
>>>
>>> I'm really not sure about deprecating the 0-10 one. It's had some
>>> testing and maintanance, and the new one lacks a few important
>>> features such as not being portable to other .Net implementations.
>>>
>>>
>>> We should track it somehow to know when the new client supersedes
>>> the current
>>> one in completeness.
>>>
>>> Carl.
>>>
>>>
>>> I'm not sure how useful a metric this is as I would argue that none of
>>> our .net clients have been completely production ready (as Rafi pointed out
>>> earlier). Furthermore my understanding was that the client currently being
>>> developed cannot easily be ported to run on .net platforms other than
>>> Windows (i.e. it will no be available to users of Mono) and therefore cannot
>>> completely supersede the existing C# based client in that way .
>>> 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)..
>>> We collectively have a better understanding of how we expect .net users
>>> (across all platforms) to interact with other AMQP clients and the messaging
>>> patterns they use. until we have that I don't think we can say that any of
>>> our .net clients is the way forward.
>>
>> Underling my question is, is our goal that the new client will do
>> everything the old one does and replace it ?
>>
>> My understanding was yes... sounds like a thread of discussion is needed.
>
> I think there has understandably been an implicit assumption that we want
> fewer than three separate incompatible, incomplete, and partially
> overlapping implementations in the .net/WCF area, however there hasn't
> really been any discussion about how to achieve that.
>
> I'm not a WCF expert, but reading the wikipedia page makes me think that WCF
> isn't quite the same thing as a messaging API, and I'm concerned that having
> only a WCF implementation will not afford C# users the same capabilities
> present in our other clients. My impression is that WCF is actually more
> akin to QMF than to our messaging APIs, i.e. a framework built on top of
> messaging rather than a messaging API in and of itself.
I think we probably need to have a discussion about the strategy
around supporting our .NET users.
I don't think we do have a clear concise document that explains what
our position as project is w.r.t to .NET support.
One of the goals of Qpid is to have a consistent set of API's across
all languages.
However for Java we have JMS as the API, as that is the standard Java API.
We may in the future provide a non JMS API similar to the new
python/c++ APIs that are being worked out.
WCF seems to be the standard communications framework in the windows
.NET 3.0 environment.
And I believe what Cliff has done is to provide an AMQP adapter for WCF.
I think from a .NET on windows developers perspective, this piece
seems as valuable as JMS for a Java user.
However as many pointed out this will not work outside of a windows environment.
So in that sense the WCF adapter is not a replacement for the existing
.NET client.
If I am not mistaken, the existing .NET client can be run on windows
as well as mono.
However this client suffers from neglect as it really doesn't have an
owner/maintainer.
Perhaps it's worthwhile answering the following questions.
1. Now as a project do we want to support both a WCF adapter and .NET client?
2. If so do we have enough resources and know how to maintain both ?
3. If we don't can we discontinue until we get enough resources. IMO
it's best to not support at all rather than having something that's
half baked and buggy due to no maintenance.
4. If we decide to have .NET client that runs on windows and mono then
how should the API look like? I'd argue it should be similar to the
current effort undertaken in python and C++.
Regards,
Rajith
> --Rafael
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
dotnet/wcf roadmap (was Re: 10000 msgs limit per session)
Posted by Rafael Schloming <ra...@redhat.com>.
Carl Trieloff wrote:
> Robert Godfrey wrote:
>>
>>
>> 2009/11/30 Carl Trieloff <cctrieloff@redhat.com
>> <ma...@redhat.com>>
>>
>> Aidan Skinner wrote:
>>
>> On Mon, Nov 30, 2009 at 2:11 PM, Carl Trieloff
>> <cctrieloff@redhat.com <ma...@redhat.com>> wrote:
>>
>> The old 0-10 version that is pure .NET (0.5) or the
>> updated version that
>> Cliff has been working extensively on (coming in 0.6 from
>> trunk)?
>>
>> Sorry if this is confusing, we should deprecate the old
>> one from the source
>> tree...
>>
>>
>> I'm really not sure about deprecating the 0-10 one. It's had some
>> testing and maintanance, and the new one lacks a few important
>> features such as not being portable to other .Net
>> implementations.
>>
>>
>>
>> We should track it somehow to know when the new client supersedes
>> the current
>> one in completeness.
>>
>> Carl.
>>
>>
>> I'm not sure how useful a metric this is as I would argue that none of
>> our .net clients have been completely production ready (as Rafi
>> pointed out earlier). Furthermore my understanding was that the
>> client currently being developed cannot easily be ported to run on
>> .net platforms other than Windows (i.e. it will no be available to
>> users of Mono) and therefore cannot completely supersede the existing
>> C# based client in that way .
>> 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)..
>> We collectively have a better understanding of how we expect .net
>> users (across all platforms) to interact with other AMQP clients and
>> the messaging patterns they use. until we have that I don't think we
>> can say that any of our .net clients is the way forward.
>
> Underling my question is, is our goal that the new client will do
> everything the old one does and replace it ?
>
> My understanding was yes... sounds like a thread of discussion is needed.
I think there has understandably been an implicit assumption that we
want fewer than three separate incompatible, incomplete, and partially
overlapping implementations in the .net/WCF area, however there hasn't
really been any discussion about how to achieve that.
I'm not a WCF expert, but reading the wikipedia page makes me think that
WCF isn't quite the same thing as a messaging API, and I'm concerned
that having only a WCF implementation will not afford C# users the same
capabilities present in our other clients. My impression is that WCF is
actually more akin to QMF than to our messaging APIs, i.e. a framework
built on top of messaging rather than a messaging API in and of itself.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Carl Trieloff <cc...@redhat.com>.
Robert Godfrey wrote:
>
>
> 2009/11/30 Carl Trieloff <cctrieloff@redhat.com
> <ma...@redhat.com>>
>
> Aidan Skinner wrote:
>
> On Mon, Nov 30, 2009 at 2:11 PM, Carl Trieloff
> <cctrieloff@redhat.com <ma...@redhat.com>> wrote:
>
>
> The old 0-10 version that is pure .NET (0.5) or the
> updated version that
> Cliff has been working extensively on (coming in 0.6 from
> trunk)?
>
> Sorry if this is confusing, we should deprecate the old
> one from the source
> tree...
>
>
>
> I'm really not sure about deprecating the 0-10 one. It's had some
> testing and maintanance, and the new one lacks a few important
> features such as not being portable to other .Net implementations.
>
>
>
>
> We should track it somehow to know when the new client supersedes
> the current
> one in completeness.
>
> Carl.
>
>
> I'm not sure how useful a metric this is as I would argue that none of
> our .net clients have been completely production ready (as Rafi
> pointed out earlier). Furthermore my understanding was that the
> client currently being developed cannot easily be ported to run on
> .net platforms other than Windows (i.e. it will no be available to
> users of Mono) and therefore cannot completely supersede the existing
> C# based client in that way .
>
> 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)..
>
> We collectively have a better understanding of how we expect .net
> users (across all platforms) to interact with other AMQP clients and
> the messaging patterns they use. until we have that I don't think we
> can say that any of our .net clients is the way forward.
Underling my question is, is our goal that the new client will do
everything the old one does and replace it ?
My understanding was yes... sounds like a thread of discussion is needed.
Carl.
Re: 10000 msgs limit per session
Posted by Robert Greig <ro...@gmail.com>.
2009/12/2 Rafael Schloming <ra...@redhat.com>:
>> If your goal is to deliver a robust .NET client on a single platform
>> in a short timeframe going down a non-managed hybrid route doesn't to
>> me appear unreasonable.
>
> I don't think anyone has said that its an unreasonable approach if you only
> care about supporting windows. The question is whether or not that goal
> meshes particularly well with the goals of the qpid project.
Having a goal is fine, but there is the practical question about the
allocation of scarce resources. I think we all agree that a pure
managed code solution is attractive for a number of reasons, but
getting a Windows broker plus a very robust WCF client in as short a
period as possible is taking the project significantly forward.
If a vendor in my day job told me that they could deliver a .NET
client that I needed in 3 months but it only worked on Windows or I
could wait 6 months and get one that could (maybe) run on Mono I know
which one I would choose.
> I hesitate to speak for Gordon, but since he's on vacation I'll go out on a
> limb and say that while there is still more work to do, the C++ API should
> be implemented enough to support the stuff that the WCF impl is doing and a
> fair bit more AFAICT.
This would definitely be worth pursuing - it would be good to get a
view on what the user demand is from the various commercial vendors of
AMQP products.
RG
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Rafael Schloming <ra...@redhat.com>.
Robert Greig wrote:
> 2009/12/1 Robert Godfrey <ro...@gmail.com>:
>
>>> IKVM is a way of running Java. I have no idea whether IKVM implements
>>> enough of the JDK libraries to enable the Qpid Java client to run
>>> under it but let's assume for the moment that it does. Further, let us
>>> assume that some important change in 0.6 or another upcoming release
>>> breaks that. Do we say that we should not proceed with that change
>>> because IKVM isn't supported?
>>>
>> Not quite the same thing is it? A better analogy might be to imagine that
>> the JMS client required the use of the compiled C++ libraries and say we
>> only supported Java on Windows and Linux... I think that to have implemented
>> the JMS client in that way would have been a poor choice.
>
> Well, my point was that IKVM is a very small niche platform only
> likely to be of interest to a tiny percentage of users. While I accept
> that mono is a bit bigger than IKVM I'd still argue it's small enough
> not to put any special effort into supporting.
FWIW, I never intended to suggest we should go out of our way to support
mono specifically. I just meant that we should probably target dotnet as
a platform rather than windows. If the code didn't work on mono due to a
mono bug, I wouldn't really be bothered. The fact that it can't work on
mono because of the way its written is a different issue.
> As I mentioned, I agree that cet. par a managed code .NET client would
> be better but I think the analogy with JMS isn't quite right because
> we're starting from a different position. When we built the JMS client
> there was no stable C++ client on any platform. It is also true that
> for Java there were several platforms we needed to support out of the
> box. 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).
>
> If your goal is to deliver a robust .NET client on a single platform
> in a short timeframe going down a non-managed hybrid route doesn't to
> me appear unreasonable.
I don't think anyone has said that its an unreasonable approach if you
only care about supporting windows. The question is whether or not that
goal meshes particularly well with the goals of the qpid project.
>>> I think it (fairly obviously) depends on the demands of our users (and
>>> our perceptions of those demands). How many people want a .NET client
>>> that doesn't work on any platform versus a WCF platform that works on
>>> Windows?
>>>
>>>
>> These goals shouldn't be contradictory.
>
> Unless (perhaps) you add a time/cost goal into the mix. Although I
> concede that I haven't done a detailed analysis on that personally.
>
>> I think the above (building WCF on top of a lower level messaging API)
>> should be our goal. And further we should attempt to make that lower level
>> API as independent as possible of particular AMQP versions (given the
>> upcoming release - hopefully - of AMQP v1.0).
>>
>> My understanding is that Gordon, Rafi and others have been working hard on
>> defining an abstract messaging API not bound to a particular version of AMQP
>> but informed by AMQPs capabilities. Further that the C++ and Python clients
>> will be implementing this API so that each of these clients will implement a
>> common API (obvious language differences aside). I do not think it an
>> unreasonable goal that we implement such a common low-level API across all
>> our clients; and build things such as JMS and WCF on top of those (expecting
>> that 90% of the user population in those languages would use the WCF or JMS
>> api). Having such a common low level API would also, one hopes, make it
>> easier to transfer from a non-managed code underlying library to a managed
>> code library for .net.
>
> I agree that it would be very much worth exploring this. Once the
> common API is implemented in C++ it should be no problem to expose
> that directly in .NET :-)
I hesitate to speak for Gordon, but since he's on vacation I'll go out
on a limb and say that while there is still more work to do, the C++ API
should be implemented enough to support the stuff that the WCF impl is
doing and a fair bit more AFAICT.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Robert Greig <ro...@gmail.com>.
2009/12/1 Robert Godfrey <ro...@gmail.com>:
>> IKVM is a way of running Java. I have no idea whether IKVM implements
>> enough of the JDK libraries to enable the Qpid Java client to run
>> under it but let's assume for the moment that it does. Further, let us
>> assume that some important change in 0.6 or another upcoming release
>> breaks that. Do we say that we should not proceed with that change
>> because IKVM isn't supported?
>>
> Not quite the same thing is it? A better analogy might be to imagine that
> the JMS client required the use of the compiled C++ libraries and say we
> only supported Java on Windows and Linux... I think that to have implemented
> the JMS client in that way would have been a poor choice.
Well, my point was that IKVM is a very small niche platform only
likely to be of interest to a tiny percentage of users. While I accept
that mono is a bit bigger than IKVM I'd still argue it's small enough
not to put any special effort into supporting.
As I mentioned, I agree that cet. par a managed code .NET client would
be better but I think the analogy with JMS isn't quite right because
we're starting from a different position. When we built the JMS client
there was no stable C++ client on any platform. It is also true that
for Java there were several platforms we needed to support out of the
box. 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).
If your goal is to deliver a robust .NET client on a single platform
in a short timeframe going down a non-managed hybrid route doesn't to
me appear unreasonable.
>> I think it (fairly obviously) depends on the demands of our users (and
>> our perceptions of those demands). How many people want a .NET client
>> that doesn't work on any platform versus a WCF platform that works on
>> Windows?
>>
>>
> These goals shouldn't be contradictory.
Unless (perhaps) you add a time/cost goal into the mix. Although I
concede that I haven't done a detailed analysis on that personally.
> I think the above (building WCF on top of a lower level messaging API)
> should be our goal. And further we should attempt to make that lower level
> API as independent as possible of particular AMQP versions (given the
> upcoming release - hopefully - of AMQP v1.0).
>
> My understanding is that Gordon, Rafi and others have been working hard on
> defining an abstract messaging API not bound to a particular version of AMQP
> but informed by AMQPs capabilities. Further that the C++ and Python clients
> will be implementing this API so that each of these clients will implement a
> common API (obvious language differences aside). I do not think it an
> unreasonable goal that we implement such a common low-level API across all
> our clients; and build things such as JMS and WCF on top of those (expecting
> that 90% of the user population in those languages would use the WCF or JMS
> api). Having such a common low level API would also, one hopes, make it
> easier to transfer from a non-managed code underlying library to a managed
> code library for .net.
I agree that it would be very much worth exploring this. Once the
common API is implemented in C++ it should be no problem to expose
that directly in .NET :-)
RG
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Rajith Attapattu <ra...@gmail.com>.
On Wed, Dec 2, 2009 at 6:35 PM, Rafael Schloming <ra...@redhat.com> wrote:
> Rajith Attapattu wrote:
>>
>> The patches got neglected probably bcos we don't have an owner for the
>> .NET implementation.
>> Tomas who contributed the initial stuff and Arnaud who did the
>> subsequent stuff are no longer with the project.
>> So there's no owner to actively maintain the code or look at patches
>> and apply them.
>>
>> This situation will probably continue until we manage to find somebody
>> with suitable skills who is willing to champion this effort.
>
> I'm aware of the history. What I was wondering is why hasn't Julien become
> that person instead of being forced to fork the implementation and maintain
> it on his own.
Yes it seems we have let go of an opportunity to recruit a potential
maintainer for the .NET client.
Aidan is there a possibility of speaking to this person and trying to
get him back into the project ?
> --Rafael
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Virgoss <vi...@gmail.com>.
Returning to the main topic of the thread. Here is a message by Gordon Sim
from the other thread:
In AMQP 0-10 there are two levels of acknowledgement. The first involves
accepting the message and your example code does that through the
_session.messageAccept(_range);
requests. Additionally there is a session level confirmation of
completion. This completion controls flow control (as well as being used
for managing session state).
If your subscription is using windowing flow mode, then sending the
completions is required.
To send the completion I believe the following line alongside any
messageAccept will work:
_session.sessionCompleted(_range);
Calling _session.sessionCompleted(_range) solves the problem with the 10000
messages limit.
--
View this message in context: http://n2.nabble.com/10000-msgs-limit-per-session-tp4087077p4434866.html
Sent from the Apache Qpid developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Rajith Attapattu <ra...@gmail.com>.
Hey Great work in committing the patches.
I see Julian had submitted another patch.
Thanks for coaxing him to work with Qpid again.
Looking at the volume of the patches it seems he cares about the C#
client quite a bit.
It would be great if you could persuade him to be the owner/maintainer
for the .C# client.
Rajith
On Wed, Dec 2, 2009 at 6:54 PM, Aidan Skinner <ai...@gmail.com> wrote:
> On Wed, Dec 2, 2009 at 11:49 PM, Steve Huston <sh...@riverace.com> wrote:
>
>> Indeed.
>>
>> Does anyone have a relationship with Julien who may encourage him to
>> rejoin the trunk?
>
> I'm talking to him via the magic of twitter. Step 1: integrate the
> patches on Jira.
>
> - Aidan
> --
> Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
> "A witty saying proves nothing" - Voltaire
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Aidan Skinner <ai...@gmail.com>.
On Wed, Dec 2, 2009 at 11:49 PM, Steve Huston <sh...@riverace.com> wrote:
> Indeed.
>
> Does anyone have a relationship with Julien who may encourage him to
> rejoin the trunk?
I'm talking to him via the magic of twitter. Step 1: integrate the
patches on Jira.
- Aidan
--
Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
"A witty saying proves nothing" - Voltaire
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: 10000 msgs limit per session
Posted by Steve Huston <sh...@riverace.com>.
> -----Original Message-----
> From: Rafael Schloming [mailto:rafaels@redhat.com]
> Sent: Wednesday, December 02, 2009 6:35 PM
> To: dev@qpid.apache.org
> Subject: Re: 10000 msgs limit per session
>
>
> Rajith Attapattu wrote:
> > The patches got neglected probably bcos we don't have an
> owner for the
> > .NET implementation.
> > Tomas who contributed the initial stuff and Arnaud who did the
> > subsequent stuff are no longer with the project.
> > So there's no owner to actively maintain the code or look at
patches
> > and apply them.
> >
> > This situation will probably continue until we manage to
> find somebody
> > with suitable skills who is willing to champion this effort.
>
> I'm aware of the history. What I was wondering is why hasn't Julien
> become that person instead of being forced to fork the
implementation
> and maintain it on his own.
Indeed.
Does anyone have a relationship with Julien who may encourage him to
rejoin the trunk?
-Steve
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Rafael Schloming <ra...@redhat.com>.
Rajith Attapattu wrote:
> The patches got neglected probably bcos we don't have an owner for the
> .NET implementation.
> Tomas who contributed the initial stuff and Arnaud who did the
> subsequent stuff are no longer with the project.
> So there's no owner to actively maintain the code or look at patches
> and apply them.
>
> This situation will probably continue until we manage to find somebody
> with suitable skills who is willing to champion this effort.
I'm aware of the history. What I was wondering is why hasn't Julien
become that person instead of being forced to fork the implementation
and maintain it on his own.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Rajith Attapattu <ra...@gmail.com>.
On Wed, Dec 2, 2009 at 6:21 PM, Rafael Schloming <ra...@redhat.com> wrote:
> Robert Godfrey wrote:
>>
>> 2009/12/3 Aidan Skinner <ai...@gmail.com>
>>
>>> On Wed, Dec 2, 2009 at 11:00 PM, Robert Greig <ro...@gmail.com>
>>> wrote:
>>>>
>>>> 2009/12/2 Aidan Skinner <ai...@gmail.com>:
>>>>
>>>>>> But not enough demand for it to translate into any emails to our dev
>>>>>> lists asking for assistance (as far as I can recall).
>>>>>
>>>>> Memories are fallible things. Search works much better. It's amazing
>>>>> what you find.
>>>>
>>>> I think you know perfectly well I was referring to anyone from the
>>>> Mono project asking for assistance implementing System.Messaging using
>>>> Qpid.
>>>
>>> No, actually, I thought you were referring to wanting to use the .Net
>>> client on Mono period-fullstop.
>>>
>>> If you're interested, the System.Messaging related discussion were
>>> mostly on the mono mailling lists:
>>>
>>> http://www.mail-archive.com/mono-devel-list@lists.ximian.com/msg16641.html
>>>
>>> I'm not quite sure when they switched to Rabbit, but it seems
>>> reasonably complete: http://www.mono-project.com/SystemMessaging
>>>
>>> Of course, it doesn't work with any of the Qpid brokers because we're
>>> not compatible with AMQP 0-8 as published.
>>>
>>>
>> As an aside - we should really try to fix that and detect people using
>> "real" 0-8...
>>
>> Hopefully if they update the code to speak 0-9-1 then it'll work with our
>> Java Broker.
>>
>> It is a realy shame that Qpid cannot provide a .net client that speaks all
>> AMQP versions that would meet the Mono guys' needs
>
> To reiterate Aidan's point from a few emails ago, a quick look at JIRA for
> the dotnet component[1] reveals a large number of patches that have sat
> neglected for six months.
>
> This is really shockingly bad and puts another spin on all the "there is no
> interest in dotnet" arguments. There is clearly outside interest in the
> dotnet client, given that there is interest inside qpid as well, one wonders
> why this has happened.
The patches got neglected probably bcos we don't have an owner for the
.NET implementation.
Tomas who contributed the initial stuff and Arnaud who did the
subsequent stuff are no longer with the project.
So there's no owner to actively maintain the code or look at patches
and apply them.
This situation will probably continue until we manage to find somebody
with suitable skills who is willing to champion this effort.
> --Rafael
>
> [1]
> https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=12310520&sorter/order=DESC&sorter/field=priority&resolution=-1&component=12311527
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
--
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Carl Trieloff <cc...@redhat.com>.
>
> From the user perspective, we basically need a messaging solution, which is a)robust b)have a nice dotnet client for Windows c)have a nice C++ client for Linux.
>
> I believe, this is the most common scenario imaginable. Everything else, like Mono compliance or fanciness of WCF are somewhat secondary goals, though possible and desired.
>
> For the moment, as I can understand from reading this list, on Windows we can only make use of either half-ready dotnet client or try C++ Interop. But the most possible scenario is that we opt for RabbitMQ instead which seem to provide all the basic connectivity that is really really needed.
Alexei,
If you have the a few cycles it would be great to also get your feedback
on the WCF client Cliff has been working on for the 0.6 release in
process. I also see that Adian (thanks) has been committing the patches
for 0-10 pure C# client so I think there will be two pretty good options
from the project in 0.6.
I.e. we would love to have you as a happy Qpid user, so let us know how
we can make you successful .... and maybe one day join the project if
you get sucked in :-)
The additional question for the qpid project is how we iterate these
forward, which we should start another thread on.
Carl.
RE: 10000 msgs limit per session
Posted by Alexei Sosin <al...@compatibl.com>.
Rafael Schlomingwrote:
> To reiterate Aidan's point from a few emails ago, a quick look at JIRA
> for the dotnet component[1] reveals a large number of patches that have
> sat neglected for six months.
> This is really shockingly bad and puts another spin on all the "there is
> no interest in dotnet" arguments. There is clearly outside interest in
> the dotnet client, given that there is interest inside qpid as well, one
> wonders why this has happened.
> --Rafael
>From the user perspective, we basically need a messaging solution, which is a)robust b)have a nice dotnet client for Windows c)have a nice C++ client for Linux.
I believe, this is the most common scenario imaginable. Everything else, like Mono compliance or fanciness of WCF are somewhat secondary goals, though possible and desired.
For the moment, as I can understand from reading this list, on Windows we can only make use of either half-ready dotnet client or try C++ Interop. But the most possible scenario is that we opt for RabbitMQ instead which seem to provide all the basic connectivity that is really really needed.
Alexei
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Rafael Schloming <ra...@redhat.com>.
Robert Godfrey wrote:
> 2009/12/3 Aidan Skinner <ai...@gmail.com>
>
>> On Wed, Dec 2, 2009 at 11:00 PM, Robert Greig <ro...@gmail.com>
>> wrote:
>>> 2009/12/2 Aidan Skinner <ai...@gmail.com>:
>>>
>>>>> But not enough demand for it to translate into any emails to our dev
>>>>> lists asking for assistance (as far as I can recall).
>>>> Memories are fallible things. Search works much better. It's amazing
>>>> what you find.
>>> I think you know perfectly well I was referring to anyone from the
>>> Mono project asking for assistance implementing System.Messaging using
>>> Qpid.
>> No, actually, I thought you were referring to wanting to use the .Net
>> client on Mono period-fullstop.
>>
>> If you're interested, the System.Messaging related discussion were
>> mostly on the mono mailling lists:
>> http://www.mail-archive.com/mono-devel-list@lists.ximian.com/msg16641.html
>>
>> I'm not quite sure when they switched to Rabbit, but it seems
>> reasonably complete: http://www.mono-project.com/SystemMessaging
>>
>> Of course, it doesn't work with any of the Qpid brokers because we're
>> not compatible with AMQP 0-8 as published.
>>
>>
> As an aside - we should really try to fix that and detect people using
> "real" 0-8...
>
> Hopefully if they update the code to speak 0-9-1 then it'll work with our
> Java Broker.
>
> It is a realy shame that Qpid cannot provide a .net client that speaks all
> AMQP versions that would meet the Mono guys' needs
To reiterate Aidan's point from a few emails ago, a quick look at JIRA
for the dotnet component[1] reveals a large number of patches that have
sat neglected for six months.
This is really shockingly bad and puts another spin on all the "there is
no interest in dotnet" arguments. There is clearly outside interest in
the dotnet client, given that there is interest inside qpid as well, one
wonders why this has happened.
--Rafael
[1]
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=12310520&sorter/order=DESC&sorter/field=priority&resolution=-1&component=12311527
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Robert Godfrey <ro...@gmail.com>.
2009/12/3 Aidan Skinner <ai...@gmail.com>
> On Wed, Dec 2, 2009 at 11:00 PM, Robert Greig <ro...@gmail.com>
> wrote:
> > 2009/12/2 Aidan Skinner <ai...@gmail.com>:
> >
> >>> But not enough demand for it to translate into any emails to our dev
> >>> lists asking for assistance (as far as I can recall).
> >>
> >> Memories are fallible things. Search works much better. It's amazing
> >> what you find.
> >
> > I think you know perfectly well I was referring to anyone from the
> > Mono project asking for assistance implementing System.Messaging using
> > Qpid.
>
> No, actually, I thought you were referring to wanting to use the .Net
> client on Mono period-fullstop.
>
> If you're interested, the System.Messaging related discussion were
> mostly on the mono mailling lists:
> http://www.mail-archive.com/mono-devel-list@lists.ximian.com/msg16641.html
>
> I'm not quite sure when they switched to Rabbit, but it seems
> reasonably complete: http://www.mono-project.com/SystemMessaging
>
> Of course, it doesn't work with any of the Qpid brokers because we're
> not compatible with AMQP 0-8 as published.
>
>
As an aside - we should really try to fix that and detect people using
"real" 0-8...
Hopefully if they update the code to speak 0-9-1 then it'll work with our
Java Broker.
It is a realy shame that Qpid cannot provide a .net client that speaks all
AMQP versions that would meet the Mono guys' needs
-- Rob
Re: 10000 msgs limit per session
Posted by Aidan Skinner <ai...@gmail.com>.
On Wed, Dec 2, 2009 at 11:00 PM, Robert Greig <ro...@gmail.com> wrote:
> 2009/12/2 Aidan Skinner <ai...@gmail.com>:
>
>>> But not enough demand for it to translate into any emails to our dev
>>> lists asking for assistance (as far as I can recall).
>>
>> Memories are fallible things. Search works much better. It's amazing
>> what you find.
>
> I think you know perfectly well I was referring to anyone from the
> Mono project asking for assistance implementing System.Messaging using
> Qpid.
No, actually, I thought you were referring to wanting to use the .Net
client on Mono period-fullstop.
If you're interested, the System.Messaging related discussion were
mostly on the mono mailling lists:
http://www.mail-archive.com/mono-devel-list@lists.ximian.com/msg16641.html
I'm not quite sure when they switched to Rabbit, but it seems
reasonably complete: http://www.mono-project.com/SystemMessaging
Of course, it doesn't work with any of the Qpid brokers because we're
not compatible with AMQP 0-8 as published.
- Aidan
--
Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
"A witty saying proves nothing" - Voltaire
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Robert Greig <ro...@gmail.com>.
2009/12/2 Aidan Skinner <ai...@gmail.com>:
>> But not enough demand for it to translate into any emails to our dev
>> lists asking for assistance (as far as I can recall).
>
> Memories are fallible things. Search works much better. It's amazing
> what you find.
I think you know perfectly well I was referring to anyone from the
Mono project asking for assistance implementing System.Messaging using
Qpid.
RG
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Aidan Skinner <ai...@gmail.com>.
On Wed, Dec 2, 2009 at 8:41 PM, Robert Greig <ro...@gmail.com> wrote:
> 2009/12/2 Aidan Skinner <ai...@gmail.com>:
>
>> Well, discounting myself (I have a half-baked^Wimplemented system to
>> manage my music using AMQP and Banshee), it's shipped in downstream
>> distros (eg. SLES10) and there was an effort to implement
>> System.Messaging for Mono on top of Qpid but that was ditched for
>> RabbitMQ. So there's clearly some demand for it, although potentially
>> stymied by some FAIL on our part.
>
> But not enough demand for it to translate into any emails to our dev
> lists asking for assistance (as far as I can recall).
Memories are fallible things. Search works much better. It's amazing
what you find.
For instance, I did one yesterday on this very topic and found some
awesome patches we'd ignored for 6 months. The original contributor,
quite understandably, forked the .Net client as a result.
Want to help integrate them into the tree?
- Aidan
--
Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
"A witty saying proves nothing" - Voltaire
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: 10000 msgs limit per session
Posted by "Cliff Jansen (Interop Systems Inc)" <v-...@microsoft.com>.
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-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Robert Greig <ro...@gmail.com>.
2009/12/2 Aidan Skinner <ai...@gmail.com>:
> Well, discounting myself (I have a half-baked^Wimplemented system to
> manage my music using AMQP and Banshee), it's shipped in downstream
> distros (eg. SLES10) and there was an effort to implement
> System.Messaging for Mono on top of Qpid but that was ditched for
> RabbitMQ. So there's clearly some demand for it, although potentially
> stymied by some FAIL on our part.
But not enough demand for it to translate into any emails to our dev
lists asking for assistance (as far as I can recall).
RG
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Aidan Skinner <ai...@gmail.com>.
On Tue, Dec 1, 2009 at 9:24 PM, Robert Greig <ro...@gmail.com> wrote:
> 2009/12/1 Rafael Schloming <ra...@redhat.com>:
>
>> I think the point for this thread is that if it is windows-only then it
>> isn't really a substitute for the existing dotnet clients which work (in as
>> much as they have ever worked) on mono.
>
> Well that assumes that running on mono is a goal? Do we have any users
> of the .NET client on Mono?
Well, discounting myself (I have a half-baked^Wimplemented system to
manage my music using AMQP and Banshee), it's shipped in downstream
distros (eg. SLES10) and there was an effort to implement
System.Messaging for Mono on top of Qpid but that was ditched for
RabbitMQ. So there's clearly some demand for it, although potentially
stymied by some FAIL on our part.
> 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.
TBH the problem, as Rafi points out, is not so much the
"built-on-top-of-C++-client" nature (although that would prevent
deployment as part of a Silverlight/Moonlight app, or as an iPhone
application via MonoTouch) but that the glue is pretty tightly couple
to both Windows and the Microsoft CLR implementation. It reaches into
it in fundamentally unportable ways, particularly around the locking
abstractions.
- Aidan
--
Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
"A witty saying proves nothing" - Voltaire
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Carl Trieloff <cc...@redhat.com>.
Robert Godfrey wrote:
> 2009/12/1 Robert Greig <ro...@gmail.com>
>
>
>> 2009/12/1 Rafael Schloming <ra...@redhat.com>:
>>
>>
>>> I think the point for this thread is that if it is windows-only then it
>>> isn't really a substitute for the existing dotnet clients which work (in
>>>
>> as
>>
>>> much as they have ever worked) on mono.
>>>
>> Well that assumes that running on mono is a goal? Do we have any users
>> of the .NET client on Mono?
>>
>> IKVM is a way of running Java. I have no idea whether IKVM implements
>> enough of the JDK libraries to enable the Qpid Java client to run
>> under it but let's assume for the moment that it does. Further, let us
>> assume that some important change in 0.6 or another upcoming release
>> breaks that. Do we say that we should not proceed with that change
>> because IKVM isn't supported?
>>
>>
>>
> Not quite the same thing is it? A better analogy might be to imagine that
> the JMS client required the use of the compiled C++ libraries and say we
> only supported Java on Windows and Linux... I think that to have implemented
> the JMS client in that way would have been a poor choice.
>
If there are a lot of devs/ users that want it that and put the effort
in to build such a thing and maintain it, for
example create a c++ shim for JMS for RDMA/IB. And a strong community
forms then why not?
I.e. Those that do have more say in the definition of the model, and the
debate conclusion should come
from those investigating into the module being invested in. I.e. if a
set of people show up and make IKVM
work and support it, why not?
Does this invalidate another client that is also being actively
maintained, that is clearly no.
Carl.
Re: 10000 msgs limit per session
Posted by Robert Godfrey <ro...@gmail.com>.
2009/12/1 Robert Greig <ro...@gmail.com>
> 2009/12/1 Rafael Schloming <ra...@redhat.com>:
>
> > I think the point for this thread is that if it is windows-only then it
> > isn't really a substitute for the existing dotnet clients which work (in
> as
> > much as they have ever worked) on mono.
>
> Well that assumes that running on mono is a goal? Do we have any users
> of the .NET client on Mono?
>
> IKVM is a way of running Java. I have no idea whether IKVM implements
> enough of the JDK libraries to enable the Qpid Java client to run
> under it but let's assume for the moment that it does. Further, let us
> assume that some important change in 0.6 or another upcoming release
> breaks that. Do we say that we should not proceed with that change
> because IKVM isn't supported?
>
>
Not quite the same thing is it? A better analogy might be to imagine that
the JMS client required the use of the compiled C++ libraries and say we
only supported Java on Windows and Linux... I think that to have implemented
the JMS client in that way would have been a poor choice.
> I think it (fairly obviously) depends on the demands of our users (and
> our perceptions of those demands). How many people want a .NET client
> that doesn't work on any platform versus a WCF platform that works on
> Windows?
>
>
These goals shouldn't be contradictory.
> > So the question in both cases is whether or not there is a good reason
> for
> > the code (both the WCF impl and the C++ broker) to be platform specific.
>
> 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.
>
>
If I was doing this work, that may well be the way I attempted to first
implement the WCF client also; and I'm in no way arguing that this code
shouldn't form part of the Qpid project.
I think a fully managed solution would be superior however, and would also
have the not inconsiderable advantage that it (and its tests) could be more
easily run by the great number of Qpid developers who do not use Windows as
their operating system.
> 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.
>
>
Agreed.
Going back to an earlier part of this thread, Rafi and you had the following
exchange:
> > I can see how you might be able to accomplish some of the same sorts of
> > things as a messaging API in this way, however I'm somewhat skeptical
that
> > the result would be equivalent to a complete messaging API, or that we'd
end
> > up with something that would appeal to our users.
> I think this is a good point. In my opinion MSFT didn't do a great job
> of System.Messaging when they first did it (i.e. long before WCF)
> because it was very tightly coupled to MSMQ so there isn't really a
> decent non-implementation-specific messaging API in .NET. WCF does I
> think attempt to address that in a very generic way - but maybe it is
> too generic to be useful for people who do want a low-level messaging
> API.
> > Even if it would work, this approach seems somewhat inside out. Why not
have
> > a dotnet messaging API and build out a WCF transport on top of that
rather
> > than having a private messaging API that is internal to the WCF
messaging
> > implementation which is then reexposed via special service contracts.
> This is what IBM have done - they have a messaging API that is not
> unlike JMS and on top of that they have built their WCF channel which
> is specifically aimed at providing SOAP over MQ.
I think the above (building WCF on top of a lower level messaging API)
should be our goal. And further we should attempt to make that lower level
API as independent as possible of particular AMQP versions (given the
upcoming release - hopefully - of AMQP v1.0).
My understanding is that Gordon, Rafi and others have been working hard on
defining an abstract messaging API not bound to a particular version of AMQP
but informed by AMQPs capabilities. Further that the C++ and Python clients
will be implementing this API so that each of these clients will implement a
common API (obvious language differences aside). I do not think it an
unreasonable goal that we implement such a common low-level API across all
our clients; and build things such as JMS and WCF on top of those (expecting
that 90% of the user population in those languages would use the WCF or JMS
api). Having such a common low level API would also, one hopes, make it
easier to transfer from a non-managed code underlying library to a managed
code library for .net.
Cheers,
Rob
Re: 10000 msgs limit per session
Posted by Robert Greig <ro...@gmail.com>.
2009/12/1 Rafael Schloming <ra...@redhat.com>:
> I think the point for this thread is that if it is windows-only then it
> isn't really a substitute for the existing dotnet clients which work (in as
> much as they have ever worked) on mono.
Well that assumes that running on mono is a goal? Do we have any users
of the .NET client on Mono?
IKVM is a way of running Java. I have no idea whether IKVM implements
enough of the JDK libraries to enable the Qpid Java client to run
under it but let's assume for the moment that it does. Further, let us
assume that some important change in 0.6 or another upcoming release
breaks that. Do we say that we should not proceed with that change
because IKVM isn't supported?
I think it (fairly obviously) depends on the demands of our users (and
our perceptions of those demands). How many people want a .NET client
that doesn't work on any platform versus a WCF platform that works on
Windows?
> So the question in both cases is whether or not there is a good reason for
> the code (both the WCF impl and the C++ broker) to be platform specific.
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.
RG
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Rafael Schloming <ra...@redhat.com>.
Robert Greig wrote:
> 2009/11/30 Rafael Schloming <ra...@redhat.com>:
>
>> I have no doubt that a suitably motivated individual could get this stuff
>> working on mono, and even make it production ready. The tricky part is
>> finding enough suitably motivated individuals to do this and to keep fixing
>> it when it breaks. Given our history with the first two dotnet clients, I'm
>> very wary of taking on another attempt lightly.
>
> Well, I can see that the advantage of basing it on the C++ client is
> that we already have that working on linux and Windows. So the only
> bit that is not managed code from your original list is the C++ code
> specific to the interop, which is very small. I suppose the question
> is whether anyone cares about it running on Mono - if anyone does
> they'll volunteer to make it work in the same way that anyone who
> wants the C++ broker to run on (say) MacOS will do so.
I think the point for this thread is that if it is windows-only then it
isn't really a substitute for the existing dotnet clients which work (in
as much as they have ever worked) on mono.
There is of course the larger point about how we as a project should
deal with platform specific code/functionality. Personally I think that
given that we're a messaging project and the point of messaging is to
hook together heterogeneous systems, we should in general strive to
provide access to functionality from as many different environments as
possible.
So the question in both cases is whether or not there is a good reason
for the code (both the WCF impl and the C++ broker) to be platform specific.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Robert Greig <ro...@gmail.com>.
2009/11/30 Rafael Schloming <ra...@redhat.com>:
> I have no doubt that a suitably motivated individual could get this stuff
> working on mono, and even make it production ready. The tricky part is
> finding enough suitably motivated individuals to do this and to keep fixing
> it when it breaks. Given our history with the first two dotnet clients, I'm
> very wary of taking on another attempt lightly.
Well, I can see that the advantage of basing it on the C++ client is
that we already have that working on linux and Windows. So the only
bit that is not managed code from your original list is the C++ code
specific to the interop, which is very small. I suppose the question
is whether anyone cares about it running on Mono - if anyone does
they'll volunteer to make it work in the same way that anyone who
wants the C++ broker to run on (say) MacOS will do so.
RG
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Rafael Schloming <ra...@redhat.com>.
Robert Greig wrote:
> 2009/11/30 Robert Godfrey <ro...@gmail.com>:
>
>> I'm not sure how useful a metric this is as I would argue that none of our
>> .net clients have been completely production ready (as Rafi pointed out
>> earlier).
>
> That must be a contender for the understatement of the month prize on
> this mailing list...
>
>> Furthermore my understanding was that the client currently being
>> developed cannot easily be ported to run on .net platforms other than
>> Windows (i.e. it will no be available to users of Mono) and therefore cannot
>> completely supersede the existing C# based client in that way .
>
> I am not sure why this would be the case. I have never attempted to
> use WCF on Mono but from the project page it does sound like a lot of
> it is implemented, and probably enough to get the Qpid channel
> working:
>
> http://www.mono-project.com/WCF
>
> There is some of C++ in the qpid channel too, which clearly isn't
> portable but from a quick glance at it, it doesn't look like it would
> be beyond a suitably motivated individual to make it cross-platform.
My point about the WCF adapter being windows only was not in regard to
WCF in general, but just about the implementation. Specifically the
ReadMe.txt lists the following prerequisites:
1. Qpid C++ client and common libraries for Windows including BOOST
Ensure the location of the Boost library (e.g. %BOOST_ROOT%\lib) is
included in your PATH environment variable.
2. .NET Framework 3.5 SP1
Install the .NET Framework from http://www.microsoft.com/net/
3. Windows SDK
Install the Windows SDK for the version of Windows that you are using
from http://msdn.microsoft.com/en-us/windows/bb980924.aspx
I have no doubt that a suitably motivated individual could get this
stuff working on mono, and even make it production ready. The tricky
part is finding enough suitably motivated individuals to do this and to
keep fixing it when it breaks. Given our history with the first two
dotnet clients, I'm very wary of taking on another attempt lightly.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Robert Greig <ro...@gmail.com>.
2009/11/30 Robert Godfrey <ro...@gmail.com>:
> I'm not sure how useful a metric this is as I would argue that none of our
> .net clients have been completely production ready (as Rafi pointed out
> earlier).
That must be a contender for the understatement of the month prize on
this mailing list...
> Furthermore my understanding was that the client currently being
> developed cannot easily be ported to run on .net platforms other than
> Windows (i.e. it will no be available to users of Mono) and therefore cannot
> completely supersede the existing C# based client in that way .
I am not sure why this would be the case. I have never attempted to
use WCF on Mono but from the project page it does sound like a lot of
it is implemented, and probably enough to get the Qpid channel
working:
http://www.mono-project.com/WCF
There is some of C++ in the qpid channel too, which clearly isn't
portable but from a quick glance at it, it doesn't look like it would
be beyond a suitably motivated individual to make it cross-platform.
> 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)..
I think this is something where WCF's flexibility be shown to be a
good thing, but I'll leave someone more qualified than I am to give a
definitive answer. I agree that the mapping needs to be documented,
and any WCF behaviours etc standardised.
RG
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Robert Godfrey <ro...@gmail.com>.
2009/11/30 Carl Trieloff <cc...@redhat.com>
> Aidan Skinner wrote:
>
>> On Mon, Nov 30, 2009 at 2:11 PM, Carl Trieloff <cc...@redhat.com>
>> wrote:
>>
>>
>>> The old 0-10 version that is pure .NET (0.5) or the updated version that
>>> Cliff has been working extensively on (coming in 0.6 from trunk)?
>>>
>>> Sorry if this is confusing, we should deprecate the old one from the
>>> source
>>> tree...
>>>
>>>
>>
>> I'm really not sure about deprecating the 0-10 one. It's had some
>> testing and maintanance, and the new one lacks a few important
>> features such as not being portable to other .Net implementations.
>>
>>
>>
>
> We should track it somehow to know when the new client supersedes the
> current
> one in completeness.
>
> Carl.
>
I'm not sure how useful a metric this is as I would argue that none of our
.net clients have been completely production ready (as Rafi pointed out
earlier). Furthermore my understanding was that the client currently being
developed cannot easily be ported to run on .net platforms other than
Windows (i.e. it will no be available to users of Mono) and therefore cannot
completely supersede the existing C# based client in that way .
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)..
We collectively have a better understanding of how we expect .net users
(across all platforms) to interact with other AMQP clients and the messaging
patterns they use. until we have that I don't think we can say that any of
our .net clients is the way forward.
Cheers,
Rob
Re: 10000 msgs limit per session
Posted by Carl Trieloff <cc...@redhat.com>.
Aidan Skinner wrote:
> On Mon, Nov 30, 2009 at 2:11 PM, Carl Trieloff <cc...@redhat.com> wrote:
>
>> The old 0-10 version that is pure .NET (0.5) or the updated version that
>> Cliff has been working extensively on (coming in 0.6 from trunk)?
>>
>> Sorry if this is confusing, we should deprecate the old one from the source
>> tree...
>>
>
> I'm really not sure about deprecating the 0-10 one. It's had some
> testing and maintanance, and the new one lacks a few important
> features such as not being portable to other .Net implementations.
>
>
We should track it somehow to know when the new client supersedes the
current
one in completeness.
Carl.
Re: 10000 msgs limit per session
Posted by Aidan Skinner <ai...@gmail.com>.
On Mon, Nov 30, 2009 at 2:11 PM, Carl Trieloff <cc...@redhat.com> wrote:
>
> The old 0-10 version that is pure .NET (0.5) or the updated version that
> Cliff has been working extensively on (coming in 0.6 from trunk)?
>
> Sorry if this is confusing, we should deprecate the old one from the source
> tree...
I'm really not sure about deprecating the 0-10 one. It's had some
testing and maintanance, and the new one lacks a few important
features such as not being portable to other .Net implementations.
- Aidan
--
Apache Qpid - AMQP, JMS, other messaging love http://qpid.apache.org
"A witty saying proves nothing" - Voltaire
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: 10000 msgs limit per session
Posted by Alexei Sosin <al...@compatibl.com>.
I'm not sure, I use the one that is in archive on Downloads page http://www.apache.org/dist/qpid/0.5/qpid-dotnet-0-10-0.5.zip
I guess, it's 0.5
As for sources, I look in to the https://svn.apache.org/repos/asf/qpid/trunk/qpid/dotnet/client-010 in svn, it seems to be the same as dll was built from.
From: Carl Trieloff [mailto:cctrieloff@redhat.com]
Sent: Monday, November 30, 2009 4:12 PM
To: Alexei Sosin
Cc: dev@qpid.apache.org
Subject: Re: 10000 msgs limit per session
The old 0-10 version that is pure .NET (0.5) or the updated version that Cliff has been working extensively on (coming in 0.6 from trunk)?
Sorry if this is confusing, we should deprecate the old one from the source tree...
Carl.
Alexei Sosin wrote:
I use 0-10 client, and the dll version is 1.0.0.0
By the way, it contains a bug in Client.close() for sure, because it hangs indefinitely (but that's another story)
-----Original Message-----
From: Carl Trieloff [mailto:cctrieloff@redhat.com]
Sent: Monday, November 30, 2009 3:25 PM
To: dev@qpid.apache.org<ma...@qpid.apache.org>
Cc: Cliff Jansen (Interop Systems Inc)
Subject: Re: 10000 msgs limit per session
Sounds like a bug, which version of .NET client are you using?
Carl.
Alexei Sosin wrote:
I noted that there is a limitation in .Net client, to receive 10 000 messages only per session. Client just stops receiving them after this number has passed.
Digging into the 0-10 client code, there is a line in ClientSession.cs:
messageFlow(queue, MessageCreditUnit.MESSAGE, 10000);
So the worj-around for me is that client should count messages and re-create session once it hits the limit.
But, why this limitation is there? I see no such limits mentioned in AMQP spec.
--Alexei
yahoo: alexei.sosin
mts: 6021715
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Robert Greig <ro...@gmail.com>.
2009/11/30 Robert Greig <ro...@gmail.com>:
> I think this is a good point. In my opinion MSFT didn't do a great job
> of System.Messaging when they first did it (i.e. long before WCF)
> because it was very tightly coupled to MSMQ so there isn't really a
> decent non-implementation-specific messaging API in .NET. WCF does I
> think attempt to address that in a very generic way - but maybe it is
> too generic to be useful for people who do want a low-level messaging
> API.
Following on from the above, I came across this:
http://www.mono-project.com/SystemMessaging
I haven't examined the mapping in detail but it is perhaps worth a closer look.
RG
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Robert Greig <ro...@gmail.com>.
2009/11/30 Rafael Schloming <ra...@redhat.com>:
> What I meant specifically was that you don't seem to have direct control
> over creating, sending, receiving, or acknowledging messages. These would
> seem to be something the framework does for you based off of a combination
> of metadata and application-specific interfaces.
Well, you do have control but it's through what they call behaviours,
which as you say are driven by metadata and framework interfaces. So
it's certainly less direct, but not unpleasant unless you don't like
metadata.
> I can see how you might be able to accomplish some of the same sorts of
> things as a messaging API in this way, however I'm somewhat skeptical that
> the result would be equivalent to a complete messaging API, or that we'd end
> up with something that would appeal to our users.
I think this is a good point. In my opinion MSFT didn't do a great job
of System.Messaging when they first did it (i.e. long before WCF)
because it was very tightly coupled to MSMQ so there isn't really a
decent non-implementation-specific messaging API in .NET. WCF does I
think attempt to address that in a very generic way - but maybe it is
too generic to be useful for people who do want a low-level messaging
API.
> Even if it would work, this approach seems somewhat inside out. Why not have
> a dotnet messaging API and build out a WCF transport on top of that rather
> than having a private messaging API that is internal to the WCF messaging
> implementation which is then reexposed via special service contracts.
This is what IBM have done - they have a messaging API that is not
unlike JMS and on top of that they have built their WCF channel which
is specifically aimed at providing SOAP over MQ.
RG
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Rafael Schloming <ra...@redhat.com>.
Robert Greig wrote:
> 2009/11/30 Rafael Schloming <ra...@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" :-)
What I meant specifically was that you don't seem to have direct control
over creating, sending, receiving, or acknowledging messages. These
would seem to be something the framework does for you based off of a
combination of metadata and application-specific interfaces.
> 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.
I can see how you might be able to accomplish some of the same sorts of
things as a messaging API in this way, however I'm somewhat skeptical
that the result would be equivalent to a complete messaging API, or that
we'd end up with something that would appeal to our users.
Even if it would work, this approach seems somewhat inside out. Why not
have a dotnet messaging API and build out a WCF transport on top of that
rather than having a private messaging API that is internal to the WCF
messaging implementation which is then reexposed via special service
contracts.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: 10000 msgs limit per session
Posted by "Cliff Jansen (Interop Systems Inc)" <v-...@microsoft.com>.
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.greig@gmail.com]
Sent: Monday, November 30, 2009 9:44 AM
To: dev@qpid.apache.org
Subject: Re: 10000 msgs limit per session
2009/11/30 Rafael Schloming <ra...@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-subscribe@qpid.apache.org
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Robert Greig <ro...@gmail.com>.
2009/11/30 Rafael Schloming <ra...@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-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Rafael Schloming <ra...@redhat.com>.
Carl Trieloff wrote:
>
> The old 0-10 version that is pure .NET (0.5) or the updated version that
> Cliff has been working extensively on (coming in 0.6 from trunk)?
>
> Sorry if this is confusing, we should deprecate the old one from the
> source tree...
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.
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.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Carl Trieloff <cc...@redhat.com>.
The old 0-10 version that is pure .NET (0.5) or the updated version that
Cliff has been working extensively on (coming in 0.6 from trunk)?
Sorry if this is confusing, we should deprecate the old one from the
source tree...
Carl.
Alexei Sosin wrote:
> I use 0-10 client, and the dll version is 1.0.0.0
>
>
> By the way, it contains a bug in Client.close() for sure, because it hangs indefinitely (but that's another story)
>
> -----Original Message-----
> From: Carl Trieloff [mailto:cctrieloff@redhat.com]
> Sent: Monday, November 30, 2009 3:25 PM
> To: dev@qpid.apache.org
> Cc: Cliff Jansen (Interop Systems Inc)
> Subject: Re: 10000 msgs limit per session
>
>
> Sounds like a bug, which version of .NET client are you using?
>
> Carl.
>
> Alexei Sosin wrote:
>
>> I noted that there is a limitation in .Net client, to receive 10 000 messages only per session. Client just stops receiving them after this number has passed.
>> Digging into the 0-10 client code, there is a line in ClientSession.cs:
>> messageFlow(queue, MessageCreditUnit.MESSAGE, 10000);
>>
>> So the worj-around for me is that client should count messages and re-create session once it hits the limit.
>>
>> But, why this limitation is there? I see no such limits mentioned in AMQP spec.
>>
>> --Alexei
>> yahoo: alexei.sosin
>> mts: 6021715
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project: http://qpid.apache.org
> Use/Interact: mailto:dev-subscribe@qpid.apache.org
>
>
RE: 10000 msgs limit per session
Posted by Alexei Sosin <al...@compatibl.com>.
I use 0-10 client, and the dll version is 1.0.0.0
By the way, it contains a bug in Client.close() for sure, because it hangs indefinitely (but that's another story)
-----Original Message-----
From: Carl Trieloff [mailto:cctrieloff@redhat.com]
Sent: Monday, November 30, 2009 3:25 PM
To: dev@qpid.apache.org
Cc: Cliff Jansen (Interop Systems Inc)
Subject: Re: 10000 msgs limit per session
Sounds like a bug, which version of .NET client are you using?
Carl.
Alexei Sosin wrote:
> I noted that there is a limitation in .Net client, to receive 10 000 messages only per session. Client just stops receiving them after this number has passed.
> Digging into the 0-10 client code, there is a line in ClientSession.cs:
> messageFlow(queue, MessageCreditUnit.MESSAGE, 10000);
>
> So the worj-around for me is that client should count messages and re-create session once it hits the limit.
>
> But, why this limitation is there? I see no such limits mentioned in AMQP spec.
>
> --Alexei
> yahoo: alexei.sosin
> mts: 6021715
>
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Carl Trieloff <cc...@redhat.com>.
Sounds like a bug, which version of .NET client are you using?
Carl.
Alexei Sosin wrote:
> I noted that there is a limitation in .Net client, to receive 10 000 messages only per session. Client just stops receiving them after this number has passed.
> Digging into the 0-10 client code, there is a line in ClientSession.cs:
> messageFlow(queue, MessageCreditUnit.MESSAGE, 10000);
>
> So the worj-around for me is that client should count messages and re-create session once it hits the limit.
>
> But, why this limitation is there? I see no such limits mentioned in AMQP spec.
>
> --Alexei
> yahoo: alexei.sosin
> mts: 6021715
>
>
>
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Rafael Schloming <ra...@redhat.com>.
Alan Conway wrote:
> On 11/30/2009 06:14 AM, Alexei Sosin wrote:
>> I noted that there is a limitation in .Net client, to receive 10 000
>> messages only per session. Client just stops receiving them after
>> this number has passed.
>> Digging into the 0-10 client code, there is a line in ClientSession.cs:
>> messageFlow(queue, MessageCreditUnit.MESSAGE, 10000);
>>
>> So the worj-around for me is that client should count messages and
>> re-create session once it hits the limit.
>>
>> But, why this limitation is there? I see no such limits mentioned in
>> AMQP spec.
>>
> Don't know anything about .NET but that's an AMQP flow control command
> containing the limit. It means the client should not receive more than
> 10000 *unacknowledged* messages. If your client acknowledges messages as
> it receives them then it should continue to receive messages. You can
> set flow control to unlimited but your client needs to acknowledge
> messages in any case for them to be removed from the queue. You can set
> your subscription such that no acknowledgment is required but I don't
> know the .NET API to do so.
This is correct assuming that the flow mode is set to window. If the
flow mode is set to credit then there would need to be another
messageFlow somewhere in order to get more than 10000 messages.
--Rafael
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
RE: 10000 msgs limit per session
Posted by Alexei Sosin <al...@compatibl.com>.
I send acknowledge for lists of 500 messages.
So it is probably, bug in client's Session implementation, the way it interprets server responses.
-----Original Message-----
From: Alan Conway [mailto:aconway@redhat.com]
Sent: Monday, November 30, 2009 4:02 PM
To: dev@qpid.apache.org
Subject: Re: 10000 msgs limit per session
On 11/30/2009 06:14 AM, Alexei Sosin wrote:
> I noted that there is a limitation in .Net client, to receive 10 000 messages only per session. Client just stops receiving them after this number has passed.
> Digging into the 0-10 client code, there is a line in ClientSession.cs:
> messageFlow(queue, MessageCreditUnit.MESSAGE, 10000);
>
> So the worj-around for me is that client should count messages and re-create session once it hits the limit.
>
> But, why this limitation is there? I see no such limits mentioned in AMQP spec.
>
Don't know anything about .NET but that's an AMQP flow control command
containing the limit. It means the client should not receive more than 10000
*unacknowledged* messages. If your client acknowledges messages as it receives
them then it should continue to receive messages. You can set flow control to
unlimited but your client needs to acknowledge messages in any case for them to
be removed from the queue. You can set your subscription such that no
acknowledgment is required but I don't know the .NET API to do so.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org
Re: 10000 msgs limit per session
Posted by Alan Conway <ac...@redhat.com>.
On 11/30/2009 06:14 AM, Alexei Sosin wrote:
> I noted that there is a limitation in .Net client, to receive 10 000 messages only per session. Client just stops receiving them after this number has passed.
> Digging into the 0-10 client code, there is a line in ClientSession.cs:
> messageFlow(queue, MessageCreditUnit.MESSAGE, 10000);
>
> So the worj-around for me is that client should count messages and re-create session once it hits the limit.
>
> But, why this limitation is there? I see no such limits mentioned in AMQP spec.
>
Don't know anything about .NET but that's an AMQP flow control command
containing the limit. It means the client should not receive more than 10000
*unacknowledged* messages. If your client acknowledges messages as it receives
them then it should continue to receive messages. You can set flow control to
unlimited but your client needs to acknowledge messages in any case for them to
be removed from the queue. You can set your subscription such that no
acknowledgment is required but I don't know the .NET API to do so.
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org