There are a couple of elements in the JMSConduit code on the trunk that are
troublesome.
First of all there is the use of the outstandingAsync data member. Effectively
it keeps track of outstanding async calls. If the number of outstanding async
calls is 0 then it proceeds to shutdown the asyn
Hi
>
>
> >
> > 3. Part of 2 (prioritize) : Please consider allocating time on ensuring
> > that
> > a CXF (programmatic) user can vouch for a consumer automatically. If
> > Autonomous profile can help then it is fine but I'd appreciate you
> thinking
> > abut it more, looks like this issue has not
Thanks for remarks.
My comments below.
W dniu 16 kwietnia 2010 15:24 użytkownik Sergey Beryozkin <
sberyoz...@gmail.com> napisał:
> Hi Łukasz
>
> Apologies for a delay, I've been very busy this week but I'll get up to
> speed by the time the project starts and hopefully will be able to talk the
>
Dan,
Understood. However, in the case when the MessageID is used as the
CorrelationID you must have a listener per invocation to support the asynch
case as you must select specifically for the exact MessageID of the invocation.
So it seems that we do one of the following 3 things:
1)Not support
Seumas,
The point is that in an async case, we do NOT want threads being consumed for
a receive if at all possible. At Progress, we had a particular customer that
would have several THOUSAND outstanding async calls at any given time. We
could not have threads and such stuck on those. Th
Actually, if you set the JMSListener to the appropriate cache level, it will
not cache the consumer which means a consumer is created for every receive().
This allows for dynamically modifying the message selector which is used when a
new consumer is created. There is a bit of overhead to do it
Hi Tomasz
If you can, please experiment with RSSBandit Atom reader on Windows, I used
it when testing Atom logging feeds and I thought it was quite close to how
I'd expect the views be partitioned.
The left hand panel lists the individual CXF endpoint feeds, a user will
create new subscriptions b
Hi Łukasz
Apologies for a delay, I've been very busy this week but I'll get up to
speed by the time the project starts and hopefully will be able to talk the
same OAuth language with you :-).
Here is the main points which I'd appreciate you addressing further, when
working on fine-tuning the prop
If the JMSListener is the Spring DefaultMessageListenerContainer, I
doubt you can change the listener's message selector at the runtime.
So I suggest to create a receive task with jms message selector to
receive the response, and use a thread pool to run these receive task.
Willem
Seumas Sol
Hi Willem,
One more thing. With respect to using a workqueue I don't think it really
solves the issue. The JMSListener essentially already uses its own workqueue to
listen asynchronously for replies. The real issue is to minimize the number of
JMSListeners required to handle the asynch scenario.
Hi Willem,
Thanks for the feedback. I agree about with your comment about the messiness of
a TLS approach for handling the asynchronous reply scenario. A workqueue or
listener pool would be preferable. I think the approach I may take for now is
to simply support MesssageID as CorrelationID on 2.
Hi Seumas,
I also would prefer a property to activate the message id pattern. So I
think we should use the same property on trunk and the branches.
I really don´t like how the code on the trunk developed recently. On
2.2.x it was quite understandable while I must say I am not sure I
completely
12 matches
Mail list logo
