On 18 March 2016 at 12:15, Matthew Karlsen wrote:
> Hello All,
>
> We have a queue running in HornetQ 2.4.0 (embedded within Wildfly), with a
> Proton-J 0.12.0 client periodically connecting to this queue.
>
> If HornetQ stops or becomes unavailable when the Proton-J client is running,
> the Pro
At a client site. Incorporating QPID as a solution to their messaging
requirements. One of the existing requirements is to support a small set of
synchronous processes.
Team has been in discussion if using the direct receive and/or send can satisfy
this requirement.
The discussion has fo
On Thu, 2016-03-17 at 17:09 -0400, Alan Conway wrote:
> The proton::container is single threaded, once you call run() you
> can't
> interact with it from other threads.
>
> I'd like to propose a "function injection" interface. I think the
> analogous thing could be done for all the languages. The
Hi,
I am seeing the below issue which is highlighted in red.
#./qpidd -v
*./qpidd: symbol lookup error: ./qpidd: undefined symbol:
_ZN4qpid3sys7AbsTime5EpochEv*
#cat /etc/redhat-release
CentOS Linux release 7.1.1503 (Core)
#rpm -qa | grep qpid
qpid-proton-c-0.10-2.el7.x86_64
qpid-cpp-client-0.3
On Thu, 2016-03-17 at 16:39 +0530, Kaushal Shriyan wrote:
> ...Further to the earlier post, please find the below pastebin
>
> http://sprunge.us/EfAI pastebin for ldd -d -r
> /opt/apigee4/share/apache-qpid/sbin/qpidd
I'm a little puzzled by this and by what you are attempting to do.
Are you buil
On Wed, 2016-03-16 at 20:16 +, Gordon Sim wrote:
> On 16/03/16 15:51, Flores, Paul A. wrote:
> >
> > The discussion has focused on the following:
> >
> > path 1: use request/reply "framework" with requester explicitly
> > listening for the reply, blocking processing until reply has been
> > r
Hello All,
We have a queue running in HornetQ 2.4.0 (embedded within Wildfly), with a
Proton-J 0.12.0 client periodically connecting to this queue.
If HornetQ stops or becomes unavailable when the Proton-J client is running,
the Proton-J client continually generates exceptions similar to that b
The proton::container is single threaded, once you call run() you can't
interact with it from other threads.
I'd like to propose a "function injection" interface. I think the
analogous thing could be done for all the languages. The Go binding
already has this mechanism.
The idea is to provide a t
Hi Julien,
it's definitely a bug, and your analysis is correct - that codepath occurs
when a connection is first being established. After the initial exchange of
credential information the client identifies the virtual host it wishes to
use, at this point the broker "moves" the connection from a b
Hi Julien,
Those docs are discussing the AMQP 0-x JMS client I believe. I know
you were asking about the AMQP 1.0 JMS clients recently, so if you are
using those then the details wont be applicable, particularly around
log messages.
In terms of queue flow control, governing ability to send works
On Thu, Mar 17, 2016 at 1:12 PM, Kaushal Shriyan
wrote:
> Hi,
>
> I am seeing the below issue which is highlighted in red.
>
> #./qpidd -v
> *./qpidd: symbol lookup error: ./qpidd: undefined symbol:
> _ZN4qpid3sys7AbsTime5EpochEv*
>
> #cat /etc/redhat-release
> CentOS Linux release 7.1.1503 (Core
Hi,
Short update: I just realised that the broker only crashes in this situation
when a client tries to connect.
I had a client running that tried to (re-)connect to the broker regularly.
After stopping the client, I was able to start the broker, log in with the web
management console and star
Why do we get this error in cpp qpid logs?
Starting Qpid AMQP daemon: Daemon startup failed: Queue
ax-q-axgroup029-dl: recoverQueues() failed: jexception 0x0205
jcntl::recover() threw JERR_JCNTL_RECOVERJFULL: Journal data files
full, cannot write. (MessageStoreImpl.cpp:826)
Thanks,
Ram
On 16/03/16 15:51, Flores, Paul A. wrote:
The discussion has focused on the following:
path 1: use request/reply "framework" with requester explicitly listening for
the reply, blocking processing until reply has been received.
This pattern is used a lot (including in all the management tools
No, there is not currently a configurable send timeout implemented on
the client. I've opened QPIDJMS-157 to track the feature request. You
can configure the failover bits to give up after some number of attempts
currently which would cause the sends to break.
On 03/16/2016 06:02 AM, Julien
Hi,
I'm currently trying to configure flow control on queue level as described in
[1].
I tried the following:
- Create a queue, set flow control settings: capacity = 1024, resume capacity =
512 (I also tried with capacity = 10240, resume capacity = 5120 and capacity =
102400, resume capacity
Hi Tim,
Thank you for the answer and the issue.
Best regards,
Julien
Avitech GmbH
Engineering AxL
Tel.: +49 (0)7541/282-177
Fax: +49 (0)7541/282-199
e-mail: julien.cha...@avitech.aero
Avitech GmbH
Principal Office: Bahnhofplatz 1 | 88045 Fr
Hi,
I ran into a strange behaviour of the java broker I'd like to report.
I did the following:
- Change the flow control of a queue in the web management console. An info
tells me that I have to restart the vhost so that changes will have effect
- Stop the vhost (default) in the web management
On Thu, Mar 17, 2016 at 9:53 PM, Andrew Stitcher
wrote:
> On Thu, 2016-03-17 at 16:39 +0530, Kaushal Shriyan wrote:
> > ...Further to the earlier post, please find the below pastebin
> >
> > http://sprunge.us/EfAI pastebin for ldd -d -r
> > /opt/apigee4/share/apache-qpid/sbin/qpidd
>
> I'm a litt
19 matches
Mail list logo
