Adding to previous reply, Applications gets crashed even in IDLE state i.e
not sending or receiving any message to/from broker. Just connected waiting
for an event. a
Everytime the core dump points to the same qpid::sys::Timer:run()
--
View this message in context:
http://qpid.2158936.n2.nabbl
I am using Qpid 0.24 standalone broker. Applications use Qpid C++ client APIs
( which are deprecated ) directly. I have observed this issue in 0.12
version as well.
Command to start broker
/usr/sbin/qpidd -p 5672 -d --config /etc/qpidd.conf --max-connections 5
--data-dir /tmp/qpid_data_trust
Perhaps not relevant, but I'm using a python client with a C++ broker with
the (QMF) heartbeat interval (configured in the broker) at ten seconds. I
had occasion to instrument the actual time between heartbeats, and while
usually very close to (but always longer than) ten seconds, I have seen odd
Some more information would be helpful to discover your problem:
Are you running a specific release or a private build?
Configuration details? (standalone broker, federated, clustered)
How are the brokers started?
Message pattern hints: large messages, small messages, idle?
Native C++ client
I have almost 15-20 clients running on my system. all clients use heartbeat
to detect connection failure. these clients started to get crashed randomly
after enabling heartbeat. Timeout is set to 2 sec for some app and 5 sec for
others. Below is attached core dump output. It appears to be getting
t
Trivial addition to INSTALL readme. Not critical but nice to have if
there is a need for another RC.
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
For additional commands, e-mail: users-h...@qpid.apache.org
On 05/02/2014 02:56 PM, Rafael Schloming wrote:
On Fri, May 2, 2014 at 6:00 AM, Gordon Sim wrote:
On 05/01/2014 05:25 PM, Lance D. wrote:
I have a quick question for the community. Has anyone tried Qpid on
VxWorks
(either the client or the broker)? Are there any problems with it?
I haven'
On Fri, May 2, 2014 at 6:00 AM, Gordon Sim wrote:
> On 05/01/2014 05:25 PM, Lance D. wrote:
>
>> I have a quick question for the community. Has anyone tried Qpid on
>> VxWorks
>> (either the client or the broker)? Are there any problems with it?
>>
>
> I haven't tried, but the IO used depends on
As many of you are aware, we have been working on new Maven builds for the
Java components...
Short version:
I would like us to begin using the new Maven builds for the Java components
exclusively, removing the old build system from trunk and updating the
version in the 0.28 release to signal tha
This vote is now closed. There were 5 +1 votes cast (4 binding), with no
other votes recorded. The vote has passed.
I will perform the final release steps shortly.
Robbie
On 30 April 2014 16:59, Robbie Gemmell wrote:
> HI all,
>
> It is a bit overdue that we actually publish a release version
On 05/02/2014 11:31 AM, Rob Godfrey wrote:
In case anyone missed it - yesterday it was announced that AMQP 1.0 has
achieved ISO standardisation as ISO 19464
Hurrah!
-
To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org
F
On 05/02/2014 12:23 PM, An Yang wrote:
Hi all,
I'm using CentOS 6.5, and write a demo program with C++0x thread, it should
create sender and receiver thread, but I got the followings:
$g++ -std=c++0x -pthread qpid-thread.cpp -o qpid-thread -lqpidmessaging
qpid-thread.cpp: In function 'void qpid
On 2 May 2014 11:23, Fraser Adams wrote:
> I'd be content as long as the "
>
>
> When I release the initial qpid-parent pom in the coming hours it should
> now all 'Just Work'*
>
> "
> caveat is in place :-)
>
Will be soon, releasing it shortly to the ASF repo and then its just a
maven-central s
Hi all,
I'm using CentOS 6.5, and write a demo program with C++0x thread, it should
create sender and receiver thread, but I got the followings:
$g++ -std=c++0x -pthread qpid-thread.cpp -o qpid-thread -lqpidmessaging
qpid-thread.cpp: In function 'void qpid::tests::qpidReceive()':
qpid-thread.cpp:
On 2 May 2014 12:23, Fraser Adams wrote:
> I'd be content as long as the "
>
>
> When I release the initial qpid-parent pom in the coming hours it should
> now all 'Just Work'*
>
> "
> caveat is in place :-)
>
> TBH I've been avoiding touching this on trunk whilst it was in a state of
> flux 'cau
In case anyone missed it - yesterday it was announced that AMQP 1.0 has
achieved ISO standardisation as ISO 19464
There's a press release here:
http://www.businesswire.com/news/home/20140501006061/en/ISO-IEC-Approve-OASIS-AMQP-Advanced-Message
Anyone tempted to spend CHF 198 on a copy of the I
I'd be content as long as the "
When I release the initial qpid-parent pom in the coming hours it should
now all 'Just Work'*
"
caveat is in place :-)
TBH I've been avoiding touching this on trunk whilst it was in a state
of flux 'cause I didn't want to add to the carnage, so it'll be good to
+1
Once the maven build is on trunk it'll be trivially easy to make sure that
the QMF2 plugin is kept up to date with refactorings / model changes that
are currently going on
-- Rob
On 2 May 2014 12:03, Robbie Gemmell wrote:
> Ok, I'd like to merge the maven build for the QMF bits to trunk no
Ok, I'd like to merge the maven build for the QMF bits to trunk now for a
couple of reasons:
- The existing Ant build (in addition to the code) has presumably been
broken by recent build related changes made in the main java tree on trunk.
- When I release the initial qpid-parent pom in the coming
On 05/01/2014 05:25 PM, Lance D. wrote:
I have a quick question for the community. Has anyone tried Qpid on VxWorks
(either the client or the broker)? Are there any problems with it?
I haven't tried, but the IO used depends on platform and at present
there is an epoll based solution for linux,
20 matches
Mail list logo
