Re: [qpid-proton-cpp] default_container does not implement thread safety at all?

[Fj]

By the way, if anyone is interested, as a stop-gap solution I ended up just
implementing a timer-based callback reenqueuing itself every 50ms and
pulling callbacks from a properly synchronized queue and executing them on
the worker thread. It's not even that bad performance-wise, it just adds
those 50/2 ms of latency on average.

A better solution would be to do the same thing the Python binding does,
expose a Selectable interface and use it to wake up the reactor thread.

And by the way there's a thing that you might want to consider: there's a
bunch of use cases that don't need inter-thread synchronization, for
example, single-threaded workers, or multi-threaded workers that only need
to know when to stop and they know it from the socket being closed. In
those cases exposing a thread-safe Container.inject(callback) is a total
waste, because it means that everything else must constantly take locks for
no reason.

Maybe in the spirit of "you don't pay for what you don't use" the way
Python binding does it is actually fundamentally better, with an
EventInjector thingie that you can add to your Container if you want and
then call injector.inject(callback) instead of container.inject?

On Fri, Mar 24, 2017 at 3:30 PM, Alan Conway  wrote:

> On Fri, 2017-03-24 at 14:06 +0530, Venkat B wrote:
> > Good day,
> >
> > -- Forwarded message --
> > > From: Alan Conway 
> > > To: users@qpid.apache.org
> > > Cc:
> > > Bcc:
> > > Date: Wed, 22 Mar 2017 14:09:00 -0400
> > > Subject: Re: [qpid-proton-cpp] default_container does not implement
> > > thread
> > > safety at all?
> > >
> >
> > [snip]
> > >
> > > And to be clear this is abuse to hack out of a short-term hole - we
> > > will have a properly behaved solution soon.
> > >
> > >
> >
> > Do you have something that I could test?
> > The code in examples/cpp/mt does not compile out of the box on 0.17.0
> > and
> > in case it is being redesigned anyway then I would prefer to work
> > with the
> > new API.
> >
>
> I defer to astitcher on the current state of the examples. The API
> isn't changing significantly, the code in mt/broker.cpp will still be
> correct with only minor changes if any.
>
> The code in epoll_container.cpp will also still be basically unchanged
> but writing a custom container will no longer be necessary for most
> cases: the default_container will be thread-safe and we will have
> epoll-native, iocp-native and libuv flavours to cover most needs.
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
> For additional commands, e-mail: users-h...@qpid.apache.org
>
>

[VOTE] Release Qpid Java 6.0.7 (RC1)

[Keith W]

Hi all,

A release candidate for the next release (6.0.7) of the Qpid Java
Components has been created.

The list of defect fixes can be found in Jira:

https://issues.apache.org/jira/issues/?jql=project%20%3D%20QPID%20AND%20fixVersion%20%3D%20qpid-java-6.0.7

Please test and vote accordingly.

The source and binary archives can be grabbed from here:
https://dist.apache.org/repos/dist/dev/qpid/java/6.0.7-rc1

Those files and the other maven artifacts are also staged for now at:
https://repository.apache.org/content/repositories/orgapacheqpid-1107

Kind regards

P.S. If you want to test it out using maven (e.g with the examples src,
or your own things), you can temporarily add this to your poms to access
the staging repo:

  

  staging
  
https://repository.apache.org/content/repositories/orgapacheqpid-1107

  

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org

Installing apache's qpid-proton project on OS X

[Yoalli Hidalgo Pontet]

Hi QPID users,

I would love to use Apache's qpid project as part of another project I am
working on. However the installation instructions I found don't provide the
steps to install it on OS X (in my case, the version I use is OS X 10.12
Sierra):
https://github.com/apache/qpid-proton/blob/master/INSTALL.md

I have been trying to look for the required packages on homebrew and
macports (which are OS X's packet managers, like apt-get and yum on Linux),
and online. I have found some of them and I am still looking for the rest,
which is a bit hard because sometimes they a different name, or have old
sub-dependencies, etc.

If any of you has successfully installed it on OS X, could you please share
the steps with me?

Thank you in advance for your help with this request, I am really looking
forward start using qpid! :D

Yoalli

 (\ /)
(  . .)
c('')('')

Re: Java broker OOM due to DirectMemory

[Keith W]

On 25 May 2017 at 00:02, Ramayan Tiwari  wrote:
> Hi Keith,
>
> Thanks so much for the update and putting together the new version with
> enhancements to flowToDisk.

No problem at all.

Just to confirm, in order for me to get the
> broker with these fixes and also use MultiQueueConsumer, I will get 6.0.7
> version and apply QPID-7462 on it?

Yes, that's right.

> For the longer terms fix (periodically coalesce byte buffers) QPID-7753, is
> it possible to also backport that to 6.0.x branch?

We have considered that, but have decided no.   Firstly, the
coalescing work is a new approach and we need more time for testing
before we are sure it is ready for release.  Secondly, the code on
master has moved on substantially since the 6.0 branch was take (it is
now over two years).  Much of the patch would require rework.

> We are working of
> migrating all of our monitoring to use REST API, however, if its possible to
> put this fix in 6.0.x, that would be very helpful.
>
> Thanks
> Ramayan
>
>

-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org