[jira] Commented: (QPID-1777) JNDI problem with white spaces

[Rajith Attapattu (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689805#action_12689805
 ] 

Rajith Attapattu commented on QPID-1777:


A fix for this has been committed into Qpid trunk at rev 758820.
A test case for this will be commited shortly and will be back ported to the M5 
branch subjected to the release managers approval.

> JNDI problem with white spaces
> --
>
> Key: QPID-1777
> URL: https://issues.apache.org/jira/browse/QPID-1777
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
> Environment: all
>Reporter: Ffrench Mathilde
>
> When I declare this JNDI queue :
> queue. = 
> The queue "physical_queue  " is created and it's 
> impossible to remove it after 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: [0.5] Release Candidate

[Martin Ritchie]

2009/3/26 Steve Huston :
> Hi Martin,
>
> Question...
>
>> I believe that the major blocking issues for 0.5 are close to being
>> resolved. If anyone has any blocking issues that they need included
> in
>> 0.5 now would be the time to say.
>
> What does QPID-1749 (https://issues.apache.org/jira/browse/QPID-1749)
> "Create c++ client example package" include?

Good question, I thought it would be just the c++ example source files
and the relevant build scripts to work in conjunction with the client
package.

>> I am aiming to start creating RCs next Friday with the packages we
>> have ready to go. If there is a package listed as a sub task of
>> QPID-1746 that you would really like to ship as part of 0.5 then you
>> have till Friday to get that change in to the branch.
>
> Ok... I'm working on a Windows installer. Is the building/processing
> of that installer something you want in the svn repo by next Friday? I
> was assuming that I'd probably wait until the 0.5 release was done,
> grab it, build it, package it. Is this what you were thinking?

Either works for me. If you want the installer to be part of 0.5 then
it needs to be in the repo. I think that having the artefacts will be
a major leap forward so they could be built from the RCs later.

If we go with the build later option and if you are building those
artefacts will need to get your pgp keys added to the Apache ring of
trust so we can vote on and host the binaries.

hth

Martin

> Thanks,
> -Steve
>
>
> -
> Apache Qpid - AMQP Messaging Implementation
> Project:  http://qpid.apache.org
> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>
>



-- 
Martin Ritchie

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

RE: Exception thrown from qpidcommon.dll on windows

[Shan Wang]

Hi Steve,

I built 0.5-release and it has exactly the same problem.

What did you mean by building qpidcommon/client as static lib? I wonder
if I have made any mistakes during builing process.


Thanks,
Shan

BTW there is a minor problem for 0.5-release windows build: it seems the
solution hasn't put the header files under gen/ directory to
deploy/include, so it was complaining about missing files like
"qpid/framing/amqp_structs.h"








-Original Message-
From: Steve Huston [mailto:shus...@riverace.com] 
Sent: 26 March 2009 18:37
To: dev@qpid.apache.org
Subject: RE: Exception thrown from qpidcommon.dll on windows

Hi Shan,

The case I tried is:

Simple program runs, calls LoadLibrary to load messaging.dll which is
linked with qpidclient.dll and qpidcommon.dll.

This failed with qpidcommon/client built as static libs because of the
TSS issue you refer to. When qpidcommon/client built as DLLs,
everything works.

Let me know...

-Steve

--
Steve Huston, Riverace Corporation
Check out my networked programming blog at
http://stevehuston.wordpress.com/


> -Original Message-
> From: Shan Wang [mailto:shan.w...@igindex.co.uk] 
> Sent: Thursday, March 26, 2009 2:18 PM
> To: dev@qpid.apache.org
> Subject: RE: Exception thrown from qpidcommon.dll on windows
> 
> 
> Hi Steve,
> 
> Have you explicitly tried to use LoadLibrary() (or other load
function
> if in another language) to load the DLL which contains
qpidcommon.dll
> and qpidclient.dll? According to MSDN, TSS should NOT work in 
> this case.
> 
> I tried the following:
> 
> 1). Test.exe -> MyCppQpidWrapper.dll -> qpidcommon.dll and
> qpidclient.dll
> In this case everything is fine.
> 
> 2). In a tcl console, Load MyTclQpidWrapper.dll -> 
> MyCppQpidWrapper.dll
> -> qpidcommon.dll and qpidclient.dll
> In this case the tcl program crashes.
> 
> I'll try the 0.5 branch, but if the code in AysncIO.cpp is 
> the same then
> I don't expect this problem to go away.
> 
> 
> Thanks,
> Shan
> 
> 
> 
> -Original Message-
> From: Steve Huston [mailto:shus...@riverace.com] 
> Sent: 26 March 2009 17:24
> To: dev@qpid.apache.org
> Subject: RE: Exception thrown from qpidcommon.dll on windows
> 
> Hi Shan,
> 
> > Thanks for the reply.
> 
> You're welcome.
> 
> > But this may be a different problem. After searched on 
> > internet I think
> > this problem was from the QPID_TSS declaration in 
> > AsynchIO.cpp, which is __declspec(thread) on windows. 
> 
> Right.
> 
> > MSDN said thread local storage can only work when a dll is 
> > linked to an
> > executable. If loadLibrary() is used to load the dll, an 
> > system failure
> > will occur. And this is exactly what happened in my program. I
made
> a
> > Tcl wrapper of qpid API and tried to load the dll within tcl, 
> > then I got
> > the exception said the program is trying to access memory
0x00.
> 
> I have seen this happen in a situation where a DLL was built that
> included the qpid libs as static, then the DLL was loaded
dynamically
> at run-time - then this exact crash occurred.
> 
> However, that situation was resolved when qpidclient and qpidcommon
> were built as DLLs and linked to the dynamically-loaded DLL.
> 
> > So basically on any windows system prior to Vista, qpid c++ client
> can
> > not be used as a plugin to another program.
> 
> I don't think this is the case... I tried this scenario with what's
on
> the 0.5-release branch and it worked. I recommend you try it as
well.
> 
> > I had a quick look in your
> > JIRA but didn't find a project for this. Now I'm trying to rebuild
> the
> > client lib without QPID_TSS and assumingly variables like
> > threadWriteTotal will only be used by one thread, I will be 
> > able to get around this issue.
> 
> The TSS usage is in qpidcommon.dll, though, which also runs in the
> broker using multiple threads.
> 
> The only way to avoid the __declspec(thread) is the create the TSS
> slots as needed at run time.
> 
> But, again, please try this with the 0.5-release branch and let us
> know how it goes.
> 
> -Steve
> 
> > -Original Message-
> > From: Steve Huston [mailto:shus...@riverace.com] 
> > Sent: 26 March 2009 14:41
> > To: dev@qpid.apache.org
> > Subject: RE: Exception thrown from qpidcommon.dll on windows
> > 
> > Hi Shan,
> > 
> > You may be seeing the affects of QPID-1550
> > (https://issues.apache.org/jira/browse/QPID-1550)
> > 
> > The QPID-1673 branch has been merged to trunk - I recommend you
> either
> > switch to trunk, use the 0.5-release branch (which is close to
being
> > M5), or wait for the 0.5 (M5) release. QPID-1550 is fixed in all
of
> > those.
> > 
> > -Steve
> > 
> > --
> > Steve Huston, Riverace Corporation
> > Check out my networked programming blog at
> > http://stevehuston.wordpress.com/
> > 
> > 
> > > -Original Message-
> > > From: Shan Wang [mailto:shan.w...@igindex.co.uk] 
> > > Sent: Thursday, March 26, 2009 8:32 AM
> > > To: dev@qpid.apache.org
> > > Subject: Exception thrown from qpidcommon.dll on w

async server core in qpid code

[James Mansion]

This code (Poller etc) is currently in common (at least on Windows) - which
also has a pile of AMQP-specific code.

Would anyone (else) like to have an organisation which would see it
usable as a simple general-purpose server core?  Not least, this would
make it easier to test and measure it, or develop alternative 
implementations

(eg one using Boost asio, or a direct threaded implementation, or one using
libevent or libev).

James


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: AMQP 1.0

[Robert Greig]

2009/3/26 James Mansion :

> I'm surprised about that.  Do you think jdbc provides similar portability?
>  The
> API might be pretty common, but there is no way on earth that makes
> non-trivial
> code portable between Sybase and PostgreSQL, for example - and nor even
> does sticking hibernate on top to generate SQL for you help either, for that
> matter.
> In that particular case the Big Deal will be the concurrency model more than
> anything else, followed by subtleties relating to careful use of
> update-in-place
> and index coverage (from the perspective of starting with Sybase anyway).

I don't think JDBC is really the same - as you say the SQL differences
and differences in locking model and the like are often significant
between database vendors.

Although there are clearly differences between messaging middleware
products, my experience is that many applications only use the basic
JMS API and don't rely on subtle semantics of the underlying broker
implementation.

> I would have thought that differences in the semantics of message ack
> batching,
> fan-out, authentication, subscription etc will be subtle but ultimately
> irreconcilable,
> and the ability to use a familiar JMS API will be a portability benefit in
> theory more
> than in practice.

Differences in areas such as authentication are certainly expected
(and not really covered by the JMS spec) but only affect a tiny part
of the code. Most apps can use the JMS transaction model or message
ack model.

I have ported apps between a few major messaging providers with success.

> Time will tell.  Clearly there is a body that want JMS with an ability to
> get at
> AMQP facilities, and a body that want to write an AMQP application that
> happens to use Java.

As I've argued before in this forum and elsewhere, an "extended JMS"
model can offer a good path for people who want to use JMS and
occasionally exploit a JMS-specific feature.

RG

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Re: AMQP 1.0

[James Mansion]

Robert Greig wrote:

JMS may not be perfect but I can just about guarantee that most of the
apps written in Java for Qpid using the JMS API will work just fine
when we release a Qpid broker than supports the 1-0 protocol. Who's
feeling confident about Python??
  
I'm surprised about that.  Do you think jdbc provides similar 
portability?  The
API might be pretty common, but there is no way on earth that makes 
non-trivial

code portable between Sybase and PostgreSQL, for example - and nor even
does sticking hibernate on top to generate SQL for you help either, for 
that matter.

In that particular case the Big Deal will be the concurrency model more than
anything else, followed by subtleties relating to careful use of 
update-in-place

and index coverage (from the perspective of starting with Sybase anyway).

I would have thought that differences in the semantics of message ack 
batching,
fan-out, authentication, subscription etc will be subtle but ultimately 
irreconcilable,
and the ability to use a familiar JMS API will be a portability benefit 
in theory more

than in practice.

Time will tell.  Clearly there is a body that want JMS with an ability 
to get at

AMQP facilities, and a body that want to write an AMQP application that
happens to use Java.




-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Commented: (QPID-1770) JMS: No useful exception thrown when message is sent to full queue

[Jeff Stein (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-1770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689689#action_12689689
 ] 

Jeff Stein commented on QPID-1770:
--

Ah, I see.  Thank you for your help!

> JMS: No useful exception thrown when message is sent to full queue
> --
>
> Key: QPID-1770
> URL: https://issues.apache.org/jira/browse/QPID-1770
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Affects Versions: M4
> Environment: Redhat with C++ broker
>Reporter: Jeff Stein
>Assignee: Rajith Attapattu
>Priority: Critical
> Fix For: 0.5
>
>
> In JMS, when a message is sent when a queue is already at its maximum size, 
> nothing happens for 60 seconds.  The program just hangs there.  Then, 
> suddenly, these two exceptions are thrown:
> org.apache.qpid.transport.SessionException: timed out waiting for session to 
> become open (state=DETACHED)
>   at org.apache.qpid.transport.Session.invoke(Session.java:442)
>   at 
> org.apache.qpid.transport.SessionInvoker.messageTransfer(SessionInvoker.java:96)
>   at 
> org.apache.qpid.client.BasicMessageProducer_0_10.sendMessage(BasicMessageProducer_0_10.java:160)
>   at 
> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:465)
>   at 
> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:420)
>   at 
> org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:289)
>   at Producer.runTest(Producer.java:135)
>   at Producer.main(Producer.java:64)
> Producer: Caught an Exception: javax.jms.JMSException: Exception when sending 
> message
> javax.jms.JMSException: Exception when sending message
>   at 
> org.apache.qpid.client.BasicMessageProducer_0_10.sendMessage(BasicMessageProducer_0_10.java:173)
>   at 
> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:465)
>   at 
> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:420)
>   at 
> org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:289)
>   at Producer.runTest(Producer.java:135)
>   at Producer.main(Producer.java:64)
> This is in contrast to, for example, a Python qpid producer, which will throw 
> an exception as soon as the queue is full, and it will be very specific about 
> the problem, telling you the queue is too full, which message overfilled it, 
> etc.
> I tested this using a hacked up version of the direct producer/consumer JMS 
> example.  Just run the producer (without the consumer running) long enough 
> with large enough messages so that it will reach the maximum queue size, and 
> you should be able to see it. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Commented: (QPID-1770) JMS: No useful exception thrown when message is sent to full queue

[Rajith Attapattu (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-1770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689671#action_12689671
 ] 

Rajith Attapattu commented on QPID-1770:


The send in the JMS client is not synchronous. So you wouldn't get notify on 
the N-th message transfer.
By the time you receive the exception you may have put a few more transfers on 
the wire.

If you want the N-th message transfer to fail then you need to do synchronous 
publish.
If you are using a durable queue and have marked your messages persistent, then 
you could use
-Dsync_publish=persistent or add sync_publish=persistent to the connection URL.
else you could use
-Dsync_publish=all or add sync_publish=all to the connection URL.
Please note that sync publish is very slow compared to async publishing.

> JMS: No useful exception thrown when message is sent to full queue
> --
>
> Key: QPID-1770
> URL: https://issues.apache.org/jira/browse/QPID-1770
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Affects Versions: M4
> Environment: Redhat with C++ broker
>Reporter: Jeff Stein
>Assignee: Rajith Attapattu
>Priority: Critical
> Fix For: 0.5
>
>
> In JMS, when a message is sent when a queue is already at its maximum size, 
> nothing happens for 60 seconds.  The program just hangs there.  Then, 
> suddenly, these two exceptions are thrown:
> org.apache.qpid.transport.SessionException: timed out waiting for session to 
> become open (state=DETACHED)
>   at org.apache.qpid.transport.Session.invoke(Session.java:442)
>   at 
> org.apache.qpid.transport.SessionInvoker.messageTransfer(SessionInvoker.java:96)
>   at 
> org.apache.qpid.client.BasicMessageProducer_0_10.sendMessage(BasicMessageProducer_0_10.java:160)
>   at 
> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:465)
>   at 
> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:420)
>   at 
> org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:289)
>   at Producer.runTest(Producer.java:135)
>   at Producer.main(Producer.java:64)
> Producer: Caught an Exception: javax.jms.JMSException: Exception when sending 
> message
> javax.jms.JMSException: Exception when sending message
>   at 
> org.apache.qpid.client.BasicMessageProducer_0_10.sendMessage(BasicMessageProducer_0_10.java:173)
>   at 
> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:465)
>   at 
> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:420)
>   at 
> org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:289)
>   at Producer.runTest(Producer.java:135)
>   at Producer.main(Producer.java:64)
> This is in contrast to, for example, a Python qpid producer, which will throw 
> an exception as soon as the queue is full, and it will be very specific about 
> the problem, telling you the queue is too full, which message overfilled it, 
> etc.
> I tested this using a hacked up version of the direct producer/consumer JMS 
> example.  Just run the producer (without the consumer running) long enough 
> with large enough messages so that it will reach the maximum queue size, and 
> you should be able to see it. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Issue Comment Edited: (QPID-1770) JMS: No useful exception thrown when message is sent to full queue

[Jeff Stein (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-1770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689658#action_12689658
 ] 

Jeff Stein edited comment on QPID-1770 at 3/26/09 2:12 PM:
---

I've downloaded trunk, and while I am seeing the new, fixed exceptions, the 
timing seems off.  If the message that exceeds the queue size is message number 
N, the exception appears to only get thrown when I send message number N+1.  
For example, say queue limit is 100k, and the queue is current 99k.  When I 
send message N of 2k, no exception is thrown, even though it has exceed the 
queue size limit and the message is rejected by the queue.  Then, when I send 
the next message (N+1) of 2k, the exception is thrown.  

In contrast, the Python client seems to throw the exception at message number 
N, which seems more intuitive to me.

Is this a bug in trunk?

  was (Author: jmstein):
I've downloaded trunk, and while I am seeing exceptions, the timing seems 
off.  If the message that exceeds the queue size is message number N, the 
exception appears to only get thrown when I send message number N+1.  For 
example, say queue limit is 100k, and the queue is current 99k.  When I send 
message N of 2k, no exception is thrown, even though it has exceed the queue 
size limit and the message is rejected by the queue.  Then, when I send the 
next message (N+1) of 2k, the exception is thrown.  

In contrast, the Python client seems to throw the exception at message number 
N, which seems more intuitive to me.

Is this a bug in trunk?
  
> JMS: No useful exception thrown when message is sent to full queue
> --
>
> Key: QPID-1770
> URL: https://issues.apache.org/jira/browse/QPID-1770
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Affects Versions: M4
> Environment: Redhat with C++ broker
>Reporter: Jeff Stein
>Assignee: Rajith Attapattu
>Priority: Critical
> Fix For: 0.5
>
>
> In JMS, when a message is sent when a queue is already at its maximum size, 
> nothing happens for 60 seconds.  The program just hangs there.  Then, 
> suddenly, these two exceptions are thrown:
> org.apache.qpid.transport.SessionException: timed out waiting for session to 
> become open (state=DETACHED)
>   at org.apache.qpid.transport.Session.invoke(Session.java:442)
>   at 
> org.apache.qpid.transport.SessionInvoker.messageTransfer(SessionInvoker.java:96)
>   at 
> org.apache.qpid.client.BasicMessageProducer_0_10.sendMessage(BasicMessageProducer_0_10.java:160)
>   at 
> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:465)
>   at 
> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:420)
>   at 
> org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:289)
>   at Producer.runTest(Producer.java:135)
>   at Producer.main(Producer.java:64)
> Producer: Caught an Exception: javax.jms.JMSException: Exception when sending 
> message
> javax.jms.JMSException: Exception when sending message
>   at 
> org.apache.qpid.client.BasicMessageProducer_0_10.sendMessage(BasicMessageProducer_0_10.java:173)
>   at 
> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:465)
>   at 
> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:420)
>   at 
> org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:289)
>   at Producer.runTest(Producer.java:135)
>   at Producer.main(Producer.java:64)
> This is in contrast to, for example, a Python qpid producer, which will throw 
> an exception as soon as the queue is full, and it will be very specific about 
> the problem, telling you the queue is too full, which message overfilled it, 
> etc.
> I tested this using a hacked up version of the direct producer/consumer JMS 
> example.  Just run the producer (without the consumer running) long enough 
> with large enough messages so that it will reach the maximum queue size, and 
> you should be able to see it. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Commented: (QPID-1765) C++ unit tests won't run on Windows

[Steve Huston (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689660#action_12689660
 ] 

Steve Huston commented on QPID-1765:


Committed on trunk, r758852. Pending on 0.5-release.

> C++ unit tests won't run on Windows
> ---
>
> Key: QPID-1765
> URL: https://issues.apache.org/jira/browse/QPID-1765
> Project: Qpid
>  Issue Type: Bug
>Affects Versions: 0.5
> Environment: Windows, Visual Studio 2008
>Reporter: Steve Huston
> Attachments: SocketProxy.h.diff
>
>
> The C++ unit_tests test suite won't run correctly on Windows. The main issue 
> is that the SocketProxy class, used as a relay between client and broker that 
> can be programmed to drop data or close a connection at an inopportune time, 
> uses the Poller class in a way that's incompatible with the Windows 
> IocpPoller.
> The Poller class is used to react to events on the sockets being used, but 
> the SocketProxy class then expects to perform the needed send/recv operations 
> directly on the Socket classes. However, the Windows Poller class reacts to 
> I/O completions, not possibilities, so it's not compatible with the approach 
> taken by SocketProxy.
> I tried replacing this with AsynchIO use... too messy and leaky.
> I have an approach working that uses select() instead of the Poller. It's 
> portable, even if a bit trickier to use correctly than Poller. Patch 
> forthcoming.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Commented: (QPID-1770) JMS: No useful exception thrown when message is sent to full queue

[Jeff Stein (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-1770?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689658#action_12689658
 ] 

Jeff Stein commented on QPID-1770:
--

I've downloaded trunk, and while I am seeing exceptions, the timing seems off.  
If the message that exceeds the queue size is message number N, the exception 
appears to only get thrown when I send message number N+1.  For example, say 
queue limit is 100k, and the queue is current 99k.  When I send message N of 
2k, no exception is thrown, even though it has exceed the queue size limit and 
the message is rejected by the queue.  Then, when I send the next message (N+1) 
of 2k, the exception is thrown.  

In contrast, the Python client seems to throw the exception at message number 
N, which seems more intuitive to me.

Is this a bug in trunk?

> JMS: No useful exception thrown when message is sent to full queue
> --
>
> Key: QPID-1770
> URL: https://issues.apache.org/jira/browse/QPID-1770
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Affects Versions: M4
> Environment: Redhat with C++ broker
>Reporter: Jeff Stein
>Assignee: Rajith Attapattu
>Priority: Critical
> Fix For: 0.5
>
>
> In JMS, when a message is sent when a queue is already at its maximum size, 
> nothing happens for 60 seconds.  The program just hangs there.  Then, 
> suddenly, these two exceptions are thrown:
> org.apache.qpid.transport.SessionException: timed out waiting for session to 
> become open (state=DETACHED)
>   at org.apache.qpid.transport.Session.invoke(Session.java:442)
>   at 
> org.apache.qpid.transport.SessionInvoker.messageTransfer(SessionInvoker.java:96)
>   at 
> org.apache.qpid.client.BasicMessageProducer_0_10.sendMessage(BasicMessageProducer_0_10.java:160)
>   at 
> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:465)
>   at 
> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:420)
>   at 
> org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:289)
>   at Producer.runTest(Producer.java:135)
>   at Producer.main(Producer.java:64)
> Producer: Caught an Exception: javax.jms.JMSException: Exception when sending 
> message
> javax.jms.JMSException: Exception when sending message
>   at 
> org.apache.qpid.client.BasicMessageProducer_0_10.sendMessage(BasicMessageProducer_0_10.java:173)
>   at 
> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:465)
>   at 
> org.apache.qpid.client.BasicMessageProducer.sendImpl(BasicMessageProducer.java:420)
>   at 
> org.apache.qpid.client.BasicMessageProducer.send(BasicMessageProducer.java:289)
>   at Producer.runTest(Producer.java:135)
>   at Producer.main(Producer.java:64)
> This is in contrast to, for example, a Python qpid producer, which will throw 
> an exception as soon as the queue is full, and it will be very specific about 
> the problem, telling you the queue is too full, which message overfilled it, 
> etc.
> I tested this using a hacked up version of the direct producer/consumer JMS 
> example.  Just run the producer (without the consumer running) long enough 
> with large enough messages so that it will reach the maximum queue size, and 
> you should be able to see it. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Commented: (QPID-1769) 64 kilobyte messages not dequeued immediately when messageConsumer.receive is called

[Rajith Attapattu (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689646#action_12689646
 ] 

Rajith Attapattu commented on QPID-1769:


Thank you for trying out Qpid and no need to appologize.
I found some other issue while trying to test the two issues reported by you.

> 64 kilobyte messages not dequeued immediately when messageConsumer.receive is 
> called
> 
>
> Key: QPID-1769
> URL: https://issues.apache.org/jira/browse/QPID-1769
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Affects Versions: M4
> Environment: Redhat
>Reporter: Jeff Stein
>Priority: Critical
> Attachments: Consumer.java, Producer.java
>
>
> I'm running into a bug where, when I send messages 64 kilobytes long via a 
> JMS producer, and retrieve them via a JMS consumer, it appears they are not 
> dequeued until much later (even though the consumer is somehow still reading 
> the messages).  It is probably dequeueing finally when connection.close() or 
> ctx.close() is called.  I've concluded this is the situation, because:
> (A) The message number that overflows the queue is the same as the queue size 
> divided by the message size (i.e., all the messages are still in the queue 
> when the overflow happens).
> (B) The qpid-queue-stats program shows no dequeueing occuring.
> (C) When I make a simple consumer to run against the 64k message producer, it 
> receives the messages, despite no actual dequeueing occuring in the queue.  
> The last thing it does is hang on messageConsumer.receive(), and the read 
> messages are never dequeued.
> (D) When I modify the simple consumer from (C) to timeout after 30 seconds 
> (messageConsumer.receive(3)), and it reaches the end of the program by 
> timing out, the dequeues occurs all at once suddenly.
> (E) This occurs even when I take it down to about 50 messages per second--no 
> dequeueing occurs until after the timeout mentioned in (D).
> This has the effect of causing my queue to fill up.  Note that I do not have 
> this problem when sending messages that are 32 kilobytes long and 
> smaller--messages dequeue normally at those sizes.
> I tried to replicate this behavior in the Python client, but the Python 
> client seemed to handle 64k messages without any problems.
> Note that I am running against the C++ broker and my queue size limit is 100 
> megabytes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Commented: (QPID-1769) 64 kilobyte messages not dequeued immediately when messageConsumer.receive is called

[Jeff Stein (JIRA)]

[ 
https://issues.apache.org/jira/browse/QPID-1769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689639#action_12689639
 ] 

Jeff Stein commented on QPID-1769:
--

I adjusted the max_prefetch and everything works fine now with the large 
messages.  Thank you for the help, and sorry for the non-bug bug.

> 64 kilobyte messages not dequeued immediately when messageConsumer.receive is 
> called
> 
>
> Key: QPID-1769
> URL: https://issues.apache.org/jira/browse/QPID-1769
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Client
>Affects Versions: M4
> Environment: Redhat
>Reporter: Jeff Stein
>Priority: Critical
> Attachments: Consumer.java, Producer.java
>
>
> I'm running into a bug where, when I send messages 64 kilobytes long via a 
> JMS producer, and retrieve them via a JMS consumer, it appears they are not 
> dequeued until much later (even though the consumer is somehow still reading 
> the messages).  It is probably dequeueing finally when connection.close() or 
> ctx.close() is called.  I've concluded this is the situation, because:
> (A) The message number that overflows the queue is the same as the queue size 
> divided by the message size (i.e., all the messages are still in the queue 
> when the overflow happens).
> (B) The qpid-queue-stats program shows no dequeueing occuring.
> (C) When I make a simple consumer to run against the 64k message producer, it 
> receives the messages, despite no actual dequeueing occuring in the queue.  
> The last thing it does is hang on messageConsumer.receive(), and the read 
> messages are never dequeued.
> (D) When I modify the simple consumer from (C) to timeout after 30 seconds 
> (messageConsumer.receive(3)), and it reaches the end of the program by 
> timing out, the dequeues occurs all at once suddenly.
> (E) This occurs even when I take it down to about 50 messages per second--no 
> dequeueing occurs until after the timeout mentioned in (D).
> This has the effect of causing my queue to fill up.  Note that I do not have 
> this problem when sending messages that are 32 kilobytes long and 
> smaller--messages dequeue normally at those sizes.
> I tried to replicate this behavior in the Python client, but the Python 
> client seemed to handle 64k messages without any problems.
> Note that I am running against the C++ broker and my queue size limit is 100 
> megabytes.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

RE: [0.5] Release Candidate

[Steve Huston]

Hi Martin,

Question... 

> I believe that the major blocking issues for 0.5 are close to being
> resolved. If anyone has any blocking issues that they need included
in
> 0.5 now would be the time to say.

What does QPID-1749 (https://issues.apache.org/jira/browse/QPID-1749)
"Create c++ client example package" include?

> I am aiming to start creating RCs next Friday with the packages we
> have ready to go. If there is a package listed as a sub task of
> QPID-1746 that you would really like to ship as part of 0.5 then you
> have till Friday to get that change in to the branch.

Ok... I'm working on a Windows installer. Is the building/processing
of that installer something you want in the svn repo by next Friday? I
was assuming that I'd probably wait until the 0.5 release was done,
grab it, build it, package it. Is this what you were thinking?

Thanks,
-Steve


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

RE: Question on process - re QPID-1765

[Steve Huston]

Ok, then...

I want to merge in QPID-1765 to 0.5-release and trunk before the end
of Friday Mar 27. I'm going to run another round of tests on RHEL 5
and Windows on the 0.5-release branch with this patch included, then
commit it unless I hear concerns before then.

Thanks,
-Steve

> -Original Message-
> From: Carl Trieloff [mailto:cctriel...@redhat.com] 
> Sent: Wednesday, March 25, 2009 4:58 PM
> To: dev@qpid.apache.org
> Subject: Re: Question on process - re QPID-1765
> 
> 
> 
> Steve,
> 
> best is to say. "I want to merge this, please raise any 
> issues before X 
> if you have any concerns"
> 
> Then wait the 2 days and merge if there are no concerns
> 
> Carl.
> 
> 
> Steve Huston wrote:
> > Hi,
> >
> > I would like some direction on how to proceed with QPID-1765. It's
a
> > patch for the C++ unit tests that allows most of them to run on
> > Windows. It also affects non-Windows builds, but I've been running
> > nightly tests on RHEL 5 with success.
> >
> > It would be nice to get it in M5, but it's not related to 
> getting Qpid
> > functionality fixed, so is only useful to users who want to run
unit
> > tests.
> >
> > What's generally the process, timing, etc. for checking 
> things in near
> > a release?
> >
> > Thanks,
> > -Steve
> >
> >
> > 
>
-
> > Apache Qpid - AMQP Messaging Implementation
> > Project:  http://qpid.apache.org
> > Use/Interact: mailto:dev-subscr...@qpid.apache.org
> >
> >   
> 
> 
>
-
> Apache Qpid - AMQP Messaging Implementation
> Project:  http://qpid.apache.org
> Use/Interact: mailto:dev-subscr...@qpid.apache.org
> 


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

RE: Exception thrown from qpidcommon.dll on windows

[Steve Huston]

Hi Shan,

The case I tried is:

Simple program runs, calls LoadLibrary to load messaging.dll which is
linked with qpidclient.dll and qpidcommon.dll.

This failed with qpidcommon/client built as static libs because of the
TSS issue you refer to. When qpidcommon/client built as DLLs,
everything works.

Let me know...

-Steve

--
Steve Huston, Riverace Corporation
Check out my networked programming blog at
http://stevehuston.wordpress.com/


> -Original Message-
> From: Shan Wang [mailto:shan.w...@igindex.co.uk] 
> Sent: Thursday, March 26, 2009 2:18 PM
> To: dev@qpid.apache.org
> Subject: RE: Exception thrown from qpidcommon.dll on windows
> 
> 
> Hi Steve,
> 
> Have you explicitly tried to use LoadLibrary() (or other load
function
> if in another language) to load the DLL which contains
qpidcommon.dll
> and qpidclient.dll? According to MSDN, TSS should NOT work in 
> this case.
> 
> I tried the following:
> 
> 1). Test.exe -> MyCppQpidWrapper.dll -> qpidcommon.dll and
> qpidclient.dll
> In this case everything is fine.
> 
> 2). In a tcl console, Load MyTclQpidWrapper.dll -> 
> MyCppQpidWrapper.dll
> -> qpidcommon.dll and qpidclient.dll
> In this case the tcl program crashes.
> 
> I'll try the 0.5 branch, but if the code in AysncIO.cpp is 
> the same then
> I don't expect this problem to go away.
> 
> 
> Thanks,
> Shan
> 
> 
> 
> -Original Message-
> From: Steve Huston [mailto:shus...@riverace.com] 
> Sent: 26 March 2009 17:24
> To: dev@qpid.apache.org
> Subject: RE: Exception thrown from qpidcommon.dll on windows
> 
> Hi Shan,
> 
> > Thanks for the reply.
> 
> You're welcome.
> 
> > But this may be a different problem. After searched on 
> > internet I think
> > this problem was from the QPID_TSS declaration in 
> > AsynchIO.cpp, which is __declspec(thread) on windows. 
> 
> Right.
> 
> > MSDN said thread local storage can only work when a dll is 
> > linked to an
> > executable. If loadLibrary() is used to load the dll, an 
> > system failure
> > will occur. And this is exactly what happened in my program. I
made
> a
> > Tcl wrapper of qpid API and tried to load the dll within tcl, 
> > then I got
> > the exception said the program is trying to access memory
0x00.
> 
> I have seen this happen in a situation where a DLL was built that
> included the qpid libs as static, then the DLL was loaded
dynamically
> at run-time - then this exact crash occurred.
> 
> However, that situation was resolved when qpidclient and qpidcommon
> were built as DLLs and linked to the dynamically-loaded DLL.
> 
> > So basically on any windows system prior to Vista, qpid c++ client
> can
> > not be used as a plugin to another program.
> 
> I don't think this is the case... I tried this scenario with what's
on
> the 0.5-release branch and it worked. I recommend you try it as
well.
> 
> > I had a quick look in your
> > JIRA but didn't find a project for this. Now I'm trying to rebuild
> the
> > client lib without QPID_TSS and assumingly variables like
> > threadWriteTotal will only be used by one thread, I will be 
> > able to get around this issue.
> 
> The TSS usage is in qpidcommon.dll, though, which also runs in the
> broker using multiple threads.
> 
> The only way to avoid the __declspec(thread) is the create the TSS
> slots as needed at run time.
> 
> But, again, please try this with the 0.5-release branch and let us
> know how it goes.
> 
> -Steve
> 
> > -Original Message-
> > From: Steve Huston [mailto:shus...@riverace.com] 
> > Sent: 26 March 2009 14:41
> > To: dev@qpid.apache.org
> > Subject: RE: Exception thrown from qpidcommon.dll on windows
> > 
> > Hi Shan,
> > 
> > You may be seeing the affects of QPID-1550
> > (https://issues.apache.org/jira/browse/QPID-1550)
> > 
> > The QPID-1673 branch has been merged to trunk - I recommend you
> either
> > switch to trunk, use the 0.5-release branch (which is close to
being
> > M5), or wait for the 0.5 (M5) release. QPID-1550 is fixed in all
of
> > those.
> > 
> > -Steve
> > 
> > --
> > Steve Huston, Riverace Corporation
> > Check out my networked programming blog at
> > http://stevehuston.wordpress.com/
> > 
> > 
> > > -Original Message-
> > > From: Shan Wang [mailto:shan.w...@igindex.co.uk] 
> > > Sent: Thursday, March 26, 2009 8:32 AM
> > > To: dev@qpid.apache.org
> > > Subject: Exception thrown from qpidcommon.dll on windows
> > > 
> > > 
> > > Hi All,
> > > 
> > >  
> > > 
> > > I built a client dll from QPID-1673 branch(which I believe is 
> > > the first
> > > usable windows dll branch). In the beginning everything seems 
> > > fine, then
> > > I found this exception thrown somewhere from qpidcommon.dll, and
> the
> > > call stack is shown below:
> > > 
> > >  
> > > 
> > >  
> > > 
> > > qpidcommon.dll!qpid::sys::windows::AsynchIO::writeComplete()  +
> 0x46
> > > bytes  C++
> > > 
> > > qpidcommon.dll!qpid::sys::windows::AsynchIO::completion()  + 
> > > 0x12f bytes
> > > C++
> > > 
> > > qpidcommon.dll!boost::detail::function::void

RE: Exception thrown from qpidcommon.dll on windows

[Shan Wang]

Hi Steve,

Have you explicitly tried to use LoadLibrary() (or other load function
if in another language) to load the DLL which contains qpidcommon.dll
and qpidclient.dll? According to MSDN, TSS should NOT work in this case.

I tried the following:

1). Test.exe -> MyCppQpidWrapper.dll -> qpidcommon.dll and
qpidclient.dll
In this case everything is fine.

2). In a tcl console, Load MyTclQpidWrapper.dll -> MyCppQpidWrapper.dll
-> qpidcommon.dll and qpidclient.dll
In this case the tcl program crashes.

I'll try the 0.5 branch, but if the code in AysncIO.cpp is the same then
I don't expect this problem to go away.


Thanks,
Shan



-Original Message-
From: Steve Huston [mailto:shus...@riverace.com] 
Sent: 26 March 2009 17:24
To: dev@qpid.apache.org
Subject: RE: Exception thrown from qpidcommon.dll on windows

Hi Shan,

> Thanks for the reply.

You're welcome.

> But this may be a different problem. After searched on 
> internet I think
> this problem was from the QPID_TSS declaration in 
> AsynchIO.cpp, which is __declspec(thread) on windows. 

Right.

> MSDN said thread local storage can only work when a dll is 
> linked to an
> executable. If loadLibrary() is used to load the dll, an 
> system failure
> will occur. And this is exactly what happened in my program. I made
a
> Tcl wrapper of qpid API and tried to load the dll within tcl, 
> then I got
> the exception said the program is trying to access memory 0x00.

I have seen this happen in a situation where a DLL was built that
included the qpid libs as static, then the DLL was loaded dynamically
at run-time - then this exact crash occurred.

However, that situation was resolved when qpidclient and qpidcommon
were built as DLLs and linked to the dynamically-loaded DLL.

> So basically on any windows system prior to Vista, qpid c++ client
can
> not be used as a plugin to another program.

I don't think this is the case... I tried this scenario with what's on
the 0.5-release branch and it worked. I recommend you try it as well.

> I had a quick look in your
> JIRA but didn't find a project for this. Now I'm trying to rebuild
the
> client lib without QPID_TSS and assumingly variables like
> threadWriteTotal will only be used by one thread, I will be 
> able to get around this issue.

The TSS usage is in qpidcommon.dll, though, which also runs in the
broker using multiple threads.

The only way to avoid the __declspec(thread) is the create the TSS
slots as needed at run time.

But, again, please try this with the 0.5-release branch and let us
know how it goes.

-Steve

> -Original Message-
> From: Steve Huston [mailto:shus...@riverace.com] 
> Sent: 26 March 2009 14:41
> To: dev@qpid.apache.org
> Subject: RE: Exception thrown from qpidcommon.dll on windows
> 
> Hi Shan,
> 
> You may be seeing the affects of QPID-1550
> (https://issues.apache.org/jira/browse/QPID-1550)
> 
> The QPID-1673 branch has been merged to trunk - I recommend you
either
> switch to trunk, use the 0.5-release branch (which is close to being
> M5), or wait for the 0.5 (M5) release. QPID-1550 is fixed in all of
> those.
> 
> -Steve
> 
> --
> Steve Huston, Riverace Corporation
> Check out my networked programming blog at
> http://stevehuston.wordpress.com/
> 
> 
> > -Original Message-
> > From: Shan Wang [mailto:shan.w...@igindex.co.uk] 
> > Sent: Thursday, March 26, 2009 8:32 AM
> > To: dev@qpid.apache.org
> > Subject: Exception thrown from qpidcommon.dll on windows
> > 
> > 
> > Hi All,
> > 
> >  
> > 
> > I built a client dll from QPID-1673 branch(which I believe is 
> > the first
> > usable windows dll branch). In the beginning everything seems 
> > fine, then
> > I found this exception thrown somewhere from qpidcommon.dll, and
the
> > call stack is shown below:
> > 
> >  
> > 
> >  
> > 
> > qpidcommon.dll!qpid::sys::windows::AsynchIO::writeComplete()  +
0x46
> > bytes  C++
> > 
> > qpidcommon.dll!qpid::sys::windows::AsynchIO::completion()  + 
> > 0x12f bytes
> > C++
> > 
> > qpidcommon.dll!boost::detail::function::void_function_obj_invo
> > ker1 > ::_bi::bind_t > nditionPri
> > vate,qpid::sys::AsynchIoResult
> > *>,boost::_bi::list2 > itionPriva
> > te *>,boost::arg<1> > >,void,qpid::sys::AsynchIoResult
*>::invoke()
> +
> > 0x10 bytes C++
> > 
> > qpidcommon.dll!boost::function1 > &,std::allocator >::operator()()  + 0x4e
bytes
> > C++
> > 
> > qpidcommon.dll!qpid::sys::AsynchWriteResult::complete()  + 0x18
> bytes
> > C++
> > 
> > qpidcommon.dll!qpid::sys::AsynchResult::success()  + 0x15 bytes
C++
> > 
> > qpidcommon.dll!qpid::sys::Poller::wait()  + 0xd3 bytes
C++
> > 
> > qpidcommon.dll!qpid::sys::Poller::run()  + 0x29 bytes
C++
> > 
> > qpidclient.dll!qpid::client::TCPConnector::run()  + 0x11c bytes
> > C++
> > 
> > msvcr90.dll!785838bb()  
> > 
> >  [Frames below may be incorrect and/or missing, no symbols loaded
> for
> > msvcr90.dll]   
> > 
> > qpidcommon.dll!`anonymous namespace'::runRunnable()  + 0xb bytes
> > C++
> > 
> >  
> > 
> >  

RE: Exception thrown from qpidcommon.dll on windows

[Steve Huston]

Hi Shan,

> Thanks for the reply.

You're welcome.

> But this may be a different problem. After searched on 
> internet I think
> this problem was from the QPID_TSS declaration in 
> AsynchIO.cpp, which is __declspec(thread) on windows. 

Right.

> MSDN said thread local storage can only work when a dll is 
> linked to an
> executable. If loadLibrary() is used to load the dll, an 
> system failure
> will occur. And this is exactly what happened in my program. I made
a
> Tcl wrapper of qpid API and tried to load the dll within tcl, 
> then I got
> the exception said the program is trying to access memory 0x00.

I have seen this happen in a situation where a DLL was built that
included the qpid libs as static, then the DLL was loaded dynamically
at run-time - then this exact crash occurred.

However, that situation was resolved when qpidclient and qpidcommon
were built as DLLs and linked to the dynamically-loaded DLL.

> So basically on any windows system prior to Vista, qpid c++ client
can
> not be used as a plugin to another program.

I don't think this is the case... I tried this scenario with what's on
the 0.5-release branch and it worked. I recommend you try it as well.

> I had a quick look in your
> JIRA but didn't find a project for this. Now I'm trying to rebuild
the
> client lib without QPID_TSS and assumingly variables like
> threadWriteTotal will only be used by one thread, I will be 
> able to get around this issue.

The TSS usage is in qpidcommon.dll, though, which also runs in the
broker using multiple threads.

The only way to avoid the __declspec(thread) is the create the TSS
slots as needed at run time.

But, again, please try this with the 0.5-release branch and let us
know how it goes.

-Steve

> -Original Message-
> From: Steve Huston [mailto:shus...@riverace.com] 
> Sent: 26 March 2009 14:41
> To: dev@qpid.apache.org
> Subject: RE: Exception thrown from qpidcommon.dll on windows
> 
> Hi Shan,
> 
> You may be seeing the affects of QPID-1550
> (https://issues.apache.org/jira/browse/QPID-1550)
> 
> The QPID-1673 branch has been merged to trunk - I recommend you
either
> switch to trunk, use the 0.5-release branch (which is close to being
> M5), or wait for the 0.5 (M5) release. QPID-1550 is fixed in all of
> those.
> 
> -Steve
> 
> --
> Steve Huston, Riverace Corporation
> Check out my networked programming blog at
> http://stevehuston.wordpress.com/
> 
> 
> > -Original Message-
> > From: Shan Wang [mailto:shan.w...@igindex.co.uk] 
> > Sent: Thursday, March 26, 2009 8:32 AM
> > To: dev@qpid.apache.org
> > Subject: Exception thrown from qpidcommon.dll on windows
> > 
> > 
> > Hi All,
> > 
> >  
> > 
> > I built a client dll from QPID-1673 branch(which I believe is 
> > the first
> > usable windows dll branch). In the beginning everything seems 
> > fine, then
> > I found this exception thrown somewhere from qpidcommon.dll, and
the
> > call stack is shown below:
> > 
> >  
> > 
> >  
> > 
> > qpidcommon.dll!qpid::sys::windows::AsynchIO::writeComplete()  +
0x46
> > bytes  C++
> > 
> > qpidcommon.dll!qpid::sys::windows::AsynchIO::completion()  + 
> > 0x12f bytes
> > C++
> > 
> > qpidcommon.dll!boost::detail::function::void_function_obj_invo
> > ker1 > ::_bi::bind_t > nditionPri
> > vate,qpid::sys::AsynchIoResult
> > *>,boost::_bi::list2 > itionPriva
> > te *>,boost::arg<1> > >,void,qpid::sys::AsynchIoResult
*>::invoke()
> +
> > 0x10 bytes C++
> > 
> > qpidcommon.dll!boost::function1 > &,std::allocator >::operator()()  + 0x4e
bytes
> > C++
> > 
> > qpidcommon.dll!qpid::sys::AsynchWriteResult::complete()  + 0x18
> bytes
> > C++
> > 
> > qpidcommon.dll!qpid::sys::AsynchResult::success()  + 0x15 bytes
C++
> > 
> > qpidcommon.dll!qpid::sys::Poller::wait()  + 0xd3 bytes
C++
> > 
> > qpidcommon.dll!qpid::sys::Poller::run()  + 0x29 bytes
C++
> > 
> > qpidclient.dll!qpid::client::TCPConnector::run()  + 0x11c bytes
> > C++
> > 
> > msvcr90.dll!785838bb()  
> > 
> >  [Frames below may be incorrect and/or missing, no symbols loaded
> for
> > msvcr90.dll]   
> > 
> > qpidcommon.dll!`anonymous namespace'::runRunnable()  + 0xb bytes
> > C++
> > 
> >  
> > 
> >  
> > 
> > Does anyone have a idea what is this about?
> > 
> >  
> > 
> >  
> > 
> > Thanks and Regards,
> > 
> > Shan
> > 
> > The information contained in this email is strictly 
> > confidential and for the use of the addressee only, unless 
> > otherwise indicated. If you are not the intended recipient, 
> > please do not read, copy, use or disclose to others this 
> > message or any attachment. Please also notify the sender by 
> > replying to this email or by telephone (+44 (0)20 7896 0011) 
> > and then delete the email and any copies of it. Opinions, 
> > conclusions (etc.) that do not relate to the official 
> > business of this company shall be understood as neither given 
> > nor endorsed by it. IG Index plc is a company registered in 
> > England and Wales under number 01190902. VAT registration 
> > nu

RE: Exception thrown from qpidcommon.dll on windows

[Shan Wang]

I found the JIRA regarding to these QPID_TSS:
https://issues.apache.org/jira/browse/QPID-1160



-Original Message-
From: Shan Wang [mailto:shan.w...@igindex.co.uk] 
Sent: 26 March 2009 16:32
To: dev@qpid.apache.org
Subject: RE: Exception thrown from qpidcommon.dll on windows

Hi Steve,

Thanks for the reply.

But this may be a different problem. After searched on internet I think
this problem was from the QPID_TSS declaration in AsynchIO.cpp, which is
__declspec(thread) on windows. 

MSDN said thread local storage can only work when a dll is linked to an
executable. If loadLibrary() is used to load the dll, an system failure
will occur. And this is exactly what happened in my program. I made a
Tcl wrapper of qpid API and tried to load the dll within tcl, then I got
the exception said the program is trying to access memory 0x00.

So basically on any windows system prior to Vista, qpid c++ client can
not be used as a plugin to another program. I had a quick look in your
JIRA but didn't find a project for this. Now I'm trying to rebuild the
client lib without QPID_TSS and assumingly variables like
threadWriteTotal will only be used by one thread, I will be able to get
around this issue.


Regards,
Shan

 

-Original Message-
From: Steve Huston [mailto:shus...@riverace.com] 
Sent: 26 March 2009 14:41
To: dev@qpid.apache.org
Subject: RE: Exception thrown from qpidcommon.dll on windows

Hi Shan,

You may be seeing the affects of QPID-1550
(https://issues.apache.org/jira/browse/QPID-1550)

The QPID-1673 branch has been merged to trunk - I recommend you either
switch to trunk, use the 0.5-release branch (which is close to being
M5), or wait for the 0.5 (M5) release. QPID-1550 is fixed in all of
those.

-Steve

--
Steve Huston, Riverace Corporation
Check out my networked programming blog at
http://stevehuston.wordpress.com/


> -Original Message-
> From: Shan Wang [mailto:shan.w...@igindex.co.uk] 
> Sent: Thursday, March 26, 2009 8:32 AM
> To: dev@qpid.apache.org
> Subject: Exception thrown from qpidcommon.dll on windows
> 
> 
> Hi All,
> 
>  
> 
> I built a client dll from QPID-1673 branch(which I believe is 
> the first
> usable windows dll branch). In the beginning everything seems 
> fine, then
> I found this exception thrown somewhere from qpidcommon.dll, and the
> call stack is shown below:
> 
>  
> 
>  
> 
> qpidcommon.dll!qpid::sys::windows::AsynchIO::writeComplete()  + 0x46
> bytes  C++
> 
> qpidcommon.dll!qpid::sys::windows::AsynchIO::completion()  + 
> 0x12f bytes
> C++
> 
> qpidcommon.dll!boost::detail::function::void_function_obj_invo
> ker1 ::_bi::bind_t nditionPri
> vate,qpid::sys::AsynchIoResult
> *>,boost::_bi::list2 itionPriva
> te *>,boost::arg<1> > >,void,qpid::sys::AsynchIoResult *>::invoke()
+
> 0x10 bytes C++
> 
> qpidcommon.dll!boost::function1 &,std::allocator >::operator()()  + 0x4e bytes
> C++
> 
> qpidcommon.dll!qpid::sys::AsynchWriteResult::complete()  + 0x18
bytes
> C++
> 
> qpidcommon.dll!qpid::sys::AsynchResult::success()  + 0x15 bytes C++
> 
> qpidcommon.dll!qpid::sys::Poller::wait()  + 0xd3 bytes  C++
> 
> qpidcommon.dll!qpid::sys::Poller::run()  + 0x29 bytes   C++
> 
> qpidclient.dll!qpid::client::TCPConnector::run()  + 0x11c bytes
> C++
> 
> msvcr90.dll!785838bb()  
> 
>  [Frames below may be incorrect and/or missing, no symbols loaded
for
> msvcr90.dll]   
> 
> qpidcommon.dll!`anonymous namespace'::runRunnable()  + 0xb bytes
> C++
> 
>  
> 
>  
> 
> Does anyone have a idea what is this about?
> 
>  
> 
>  
> 
> Thanks and Regards,
> 
> Shan
> 
> The information contained in this email is strictly 
> confidential and for the use of the addressee only, unless 
> otherwise indicated. If you are not the intended recipient, 
> please do not read, copy, use or disclose to others this 
> message or any attachment. Please also notify the sender by 
> replying to this email or by telephone (+44 (0)20 7896 0011) 
> and then delete the email and any copies of it. Opinions, 
> conclusions (etc.) that do not relate to the official 
> business of this company shall be understood as neither given 
> nor endorsed by it. IG Index plc is a company registered in 
> England and Wales under number 01190902. VAT registration 
> number 761 2978 07. Registered Office: Friars House, 157-168 
> Blackfriars Road, London SE1 8EZ. Authorised and regulated by 
> the Financial Services Authority. FSA Register number 114059.
> 


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

The information contained in this email is strictly confidential and for
the use of the addressee only, unless otherwise indicated. If you are
not the intended recipient, please do not read, copy, use or disclose to
others this message or any attachment. Please also notify the sender by
replying to this email or by telephone 

[0.5] Release Candidate

[Martin Ritchie]

Hi,

I believe that the major blocking issues for 0.5 are close to being
resolved. If anyone has any blocking issues that they need included in
0.5 now would be the time to say.

I am aiming to start creating RCs next Friday with the packages we
have ready to go. If there is a package listed as a sub task of
QPID-1746 that you would really like to ship as part of 0.5 then you
have till Friday to get that change in to the branch.

If we can still push to get all the issues assigned to 0.5 closed out
that would be great.
https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=true&&pid=12310520&status=1&status=3&status=4&fixfor=12313597&sorter/field=assignee&sorter/order=ASC&sorter/field=issuekey&sorter/order=ASC&sorter/field=priority&sorter/order=DESC

Regards

Martin
-- 
Martin Ritchie

-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Updated: (QPID-1776) Java server does not interpolate variables under all circumstances

[Aidan Skinner (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aidan Skinner updated QPID-1776:


Status: Ready To Review  (was: In Progress)

> Java server does not interpolate variables under all circumstances
> --
>
> Key: QPID-1776
> URL: https://issues.apache.org/jira/browse/QPID-1776
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.5
>Reporter: Aidan Skinner
>Assignee: Aidan Skinner
>Priority: Critical
> Fix For: 0.5
>
>
> The ${var} substitution in the config file does not seem to work in all 
> circumstances, such as being passed to the stores.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Assigned: (QPID-1776) Java server does not interpolate variables under all circumstances

[Aidan Skinner (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aidan Skinner reassigned QPID-1776:
---

Assignee: Martin Ritchie  (was: Aidan Skinner)

Hi Martin,

please review this change. 

Thanks,

- Aidan

> Java server does not interpolate variables under all circumstances
> --
>
> Key: QPID-1776
> URL: https://issues.apache.org/jira/browse/QPID-1776
> Project: Qpid
>  Issue Type: Bug
>  Components: Java Broker
>Affects Versions: 0.5
>Reporter: Aidan Skinner
>Assignee: Martin Ritchie
>Priority: Critical
> Fix For: 0.5
>
>
> The ${var} substitution in the config file does not seem to work in all 
> circumstances, such as being passed to the stores.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

[jira] Updated: (QPID-1746) 0.5 Package generation

[Martin Ritchie (JIRA)]

 [ 
https://issues.apache.org/jira/browse/QPID-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Martin Ritchie updated QPID-1746:
-

Priority: Major  (was: Blocker)

Down grading from blocker as if we don't get the sub tasks finished then we 
just won't be able to release that component package.

> 0.5 Package generation
> --
>
> Key: QPID-1746
> URL: https://issues.apache.org/jira/browse/QPID-1746
> Project: Qpid
>  Issue Type: Task
>  Components: Build Tools
>Reporter: Martin Ritchie
> Fix For: 0.5
>
>
> Package list discussed on Qpid Dev.
> - Single Source package
> - C++ Source package
> - Binary Packages for
>  + Brokers
>   + C++
> - Windows only from Qpid, simply link to other downstream binary
> builds for other platforms
>   + Java
>  + Client and Example Package
>   + C++
> - Windows only from Qpid, simply link to other downstream binary
> builds for other platforms
>   + C# (0-8,0-10)
>   + Java
>   + Python
>   + Ruby
> + Management
>  - Eclipse JMX Console
>+ Win
>+ Linux
>+ OS X
>  - JMX Command Line Tool
>  - QMan / WsDmAdapter
>  - QMF Command line tools

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

RE: Exception thrown from qpidcommon.dll on windows

[Shan Wang]

Hi Steve,

Thanks for the reply.

But this may be a different problem. After searched on internet I think
this problem was from the QPID_TSS declaration in AsynchIO.cpp, which is
__declspec(thread) on windows. 

MSDN said thread local storage can only work when a dll is linked to an
executable. If loadLibrary() is used to load the dll, an system failure
will occur. And this is exactly what happened in my program. I made a
Tcl wrapper of qpid API and tried to load the dll within tcl, then I got
the exception said the program is trying to access memory 0x00.

So basically on any windows system prior to Vista, qpid c++ client can
not be used as a plugin to another program. I had a quick look in your
JIRA but didn't find a project for this. Now I'm trying to rebuild the
client lib without QPID_TSS and assumingly variables like
threadWriteTotal will only be used by one thread, I will be able to get
around this issue.


Regards,
Shan

 

-Original Message-
From: Steve Huston [mailto:shus...@riverace.com] 
Sent: 26 March 2009 14:41
To: dev@qpid.apache.org
Subject: RE: Exception thrown from qpidcommon.dll on windows

Hi Shan,

You may be seeing the affects of QPID-1550
(https://issues.apache.org/jira/browse/QPID-1550)

The QPID-1673 branch has been merged to trunk - I recommend you either
switch to trunk, use the 0.5-release branch (which is close to being
M5), or wait for the 0.5 (M5) release. QPID-1550 is fixed in all of
those.

-Steve

--
Steve Huston, Riverace Corporation
Check out my networked programming blog at
http://stevehuston.wordpress.com/


> -Original Message-
> From: Shan Wang [mailto:shan.w...@igindex.co.uk] 
> Sent: Thursday, March 26, 2009 8:32 AM
> To: dev@qpid.apache.org
> Subject: Exception thrown from qpidcommon.dll on windows
> 
> 
> Hi All,
> 
>  
> 
> I built a client dll from QPID-1673 branch(which I believe is 
> the first
> usable windows dll branch). In the beginning everything seems 
> fine, then
> I found this exception thrown somewhere from qpidcommon.dll, and the
> call stack is shown below:
> 
>  
> 
>  
> 
> qpidcommon.dll!qpid::sys::windows::AsynchIO::writeComplete()  + 0x46
> bytes  C++
> 
> qpidcommon.dll!qpid::sys::windows::AsynchIO::completion()  + 
> 0x12f bytes
> C++
> 
> qpidcommon.dll!boost::detail::function::void_function_obj_invo
> ker1 ::_bi::bind_t nditionPri
> vate,qpid::sys::AsynchIoResult
> *>,boost::_bi::list2 itionPriva
> te *>,boost::arg<1> > >,void,qpid::sys::AsynchIoResult *>::invoke()
+
> 0x10 bytes C++
> 
> qpidcommon.dll!boost::function1 &,std::allocator >::operator()()  + 0x4e bytes
> C++
> 
> qpidcommon.dll!qpid::sys::AsynchWriteResult::complete()  + 0x18
bytes
> C++
> 
> qpidcommon.dll!qpid::sys::AsynchResult::success()  + 0x15 bytes C++
> 
> qpidcommon.dll!qpid::sys::Poller::wait()  + 0xd3 bytes  C++
> 
> qpidcommon.dll!qpid::sys::Poller::run()  + 0x29 bytes   C++
> 
> qpidclient.dll!qpid::client::TCPConnector::run()  + 0x11c bytes
> C++
> 
> msvcr90.dll!785838bb()  
> 
>  [Frames below may be incorrect and/or missing, no symbols loaded
for
> msvcr90.dll]   
> 
> qpidcommon.dll!`anonymous namespace'::runRunnable()  + 0xb bytes
> C++
> 
>  
> 
>  
> 
> Does anyone have a idea what is this about?
> 
>  
> 
>  
> 
> Thanks and Regards,
> 
> Shan
> 
> The information contained in this email is strictly 
> confidential and for the use of the addressee only, unless 
> otherwise indicated. If you are not the intended recipient, 
> please do not read, copy, use or disclose to others this 
> message or any attachment. Please also notify the sender by 
> replying to this email or by telephone (+44 (0)20 7896 0011) 
> and then delete the email and any copies of it. Opinions, 
> conclusions (etc.) that do not relate to the official 
> business of this company shall be understood as neither given 
> nor endorsed by it. IG Index plc is a company registered in 
> England and Wales under number 01190902. VAT registration 
> number 761 2978 07. Registered Office: Friars House, 157-168 
> Blackfriars Road, London SE1 8EZ. Authorised and regulated by 
> the Financial Services Authority. FSA Register number 114059.
> 


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

The information contained in this email is strictly confidential and for the 
use of the addressee only, unless otherwise indicated. If you are not the 
intended recipient, please do not read, copy, use or disclose to others this 
message or any attachment. Please also notify the sender by replying to this 
email or by telephone (+44 (0)20 7896 0011) and then delete the email and any 
copies of it. Opinions, conclusions (etc.) that do not relate to the official 
business of this company shall be understood as neither given nor endorsed by 
it. IG Index plc is a company registered in England and Wales under

Re: Possible T-shirt image

[Lahiru Gunathilake]

Hi Carl,


> let's make them... hand them out at apachecon

Were you able to make it happen. I'm excited to get a Qpid T-shirt :-)

Lahiru

>
>
>
> Mark Atwell wrote:
>
>> Great work Michael!
>>
>> I like the idea! Though currently it looks (to me) a little like a ray -
>> i.e. a sting-ray or eagle-ray. Admittedly this appeals to me - I'm an
>> underwater photographer - look for me on Flickr.
>>
>> However, if the blue bit could be made to stretch up and down a bit more
>> to
>> be the same size as the right-hand chevron, it would it look more
>> arrow-like
>> i.e. something like:
>>
>> =>>
>>
>> I'm no graphic artist!
>>
>> Actually thinking about it, also making the above change might also ape
>> the
>> classic 'fast-forward' symbol so it could subliminally imply speed (but
>> crucially without any formal commitment! :o) ?
>>
>> Perhaps placing the arrow above or below the words would allow it to point
>> to a nearby colleague a la the original T-shirt.
>>
>> Thoughts?
>>
>>  -- Mark
>>
>>
>> On Sat, Jan 31, 2009 at 8:06 AM, Lahiru Gunathilake > >wrote:
>>
>>
>>
>>> That's pretty good. I prefer to change the colors of the logo, but we
>>> have
>>> to keep AMQP colors which is not that colorful :-(
>>>
>>> Lahiru
>>>
>>> On Sat, Jan 31, 2009 at 12:02 AM, michael goulish >>
>>>
 wrote:
  Oops, thanks.
 How about this:

 https://issues.apache.org/jira/browse/QPID-1624



 On Fri, 2009-01-30 at 23:55 -0800, Lahiru Gunathilake wrote:


> Hi Michael,
>
> I think attachments are not allowed in the list. You have to upload it
>
>
 in
>>>
>>>
 to


> somewhere and send us the link.
>
> Lahiru
>
> On Fri, Jan 30, 2009 at 11:51 PM, michael goulish  wrote:
>
>
>
>> here's a concept for a t-shirt image based on the "i'm with qpid"
>>
>>
> slogan


> (attached)
>>
>> :-)
>>
>>
>>
>>
>>
>>
>> -
>> Apache Qpid - AMQP Messaging Implementation
>> Project:  http://qpid.apache.org
>> Use/Interact: mailto:dev-subscr...@qpid.apache.org
>>
>>
>>
>
>
>
 -
 Apache Qpid - AMQP Messaging Implementation
 Project:  http://qpid.apache.org
 Use/Interact: mailto:dev-subscr...@qpid.apache.org




>>>  --
>>> Apache Qpid, Worlds dominant messaging middleware..!!!
>>>
>>>
>>>
>>
>>
>>
>
>


-- 
Apache Qpid, Worlds dominant messaging middleware..!!!

RE: Exception thrown from qpidcommon.dll on windows

[Steve Huston]

Hi Shan,

You may be seeing the affects of QPID-1550
(https://issues.apache.org/jira/browse/QPID-1550)

The QPID-1673 branch has been merged to trunk - I recommend you either
switch to trunk, use the 0.5-release branch (which is close to being
M5), or wait for the 0.5 (M5) release. QPID-1550 is fixed in all of
those.

-Steve

--
Steve Huston, Riverace Corporation
Check out my networked programming blog at
http://stevehuston.wordpress.com/


> -Original Message-
> From: Shan Wang [mailto:shan.w...@igindex.co.uk] 
> Sent: Thursday, March 26, 2009 8:32 AM
> To: dev@qpid.apache.org
> Subject: Exception thrown from qpidcommon.dll on windows
> 
> 
> Hi All,
> 
>  
> 
> I built a client dll from QPID-1673 branch(which I believe is 
> the first
> usable windows dll branch). In the beginning everything seems 
> fine, then
> I found this exception thrown somewhere from qpidcommon.dll, and the
> call stack is shown below:
> 
>  
> 
>  
> 
> qpidcommon.dll!qpid::sys::windows::AsynchIO::writeComplete()  + 0x46
> bytes  C++
> 
> qpidcommon.dll!qpid::sys::windows::AsynchIO::completion()  + 
> 0x12f bytes
> C++
> 
> qpidcommon.dll!boost::detail::function::void_function_obj_invo
> ker1 ::_bi::bind_t nditionPri
> vate,qpid::sys::AsynchIoResult
> *>,boost::_bi::list2 itionPriva
> te *>,boost::arg<1> > >,void,qpid::sys::AsynchIoResult *>::invoke()
+
> 0x10 bytes C++
> 
> qpidcommon.dll!boost::function1 &,std::allocator >::operator()()  + 0x4e bytes
> C++
> 
> qpidcommon.dll!qpid::sys::AsynchWriteResult::complete()  + 0x18
bytes
> C++
> 
> qpidcommon.dll!qpid::sys::AsynchResult::success()  + 0x15 bytes C++
> 
> qpidcommon.dll!qpid::sys::Poller::wait()  + 0xd3 bytes  C++
> 
> qpidcommon.dll!qpid::sys::Poller::run()  + 0x29 bytes   C++
> 
> qpidclient.dll!qpid::client::TCPConnector::run()  + 0x11c bytes
> C++
> 
> msvcr90.dll!785838bb()  
> 
>  [Frames below may be incorrect and/or missing, no symbols loaded
for
> msvcr90.dll]   
> 
> qpidcommon.dll!`anonymous namespace'::runRunnable()  + 0xb bytes
> C++
> 
>  
> 
>  
> 
> Does anyone have a idea what is this about?
> 
>  
> 
>  
> 
> Thanks and Regards,
> 
> Shan
> 
> The information contained in this email is strictly 
> confidential and for the use of the addressee only, unless 
> otherwise indicated. If you are not the intended recipient, 
> please do not read, copy, use or disclose to others this 
> message or any attachment. Please also notify the sender by 
> replying to this email or by telephone (+44 (0)20 7896 0011) 
> and then delete the email and any copies of it. Opinions, 
> conclusions (etc.) that do not relate to the official 
> business of this company shall be understood as neither given 
> nor endorsed by it. IG Index plc is a company registered in 
> England and Wales under number 01190902. VAT registration 
> number 761 2978 07. Registered Office: Friars House, 157-168 
> Blackfriars Road, London SE1 8EZ. Authorised and regulated by 
> the Financial Services Authority. FSA Register number 114059.
> 


-
Apache Qpid - AMQP Messaging Implementation
Project:  http://qpid.apache.org
Use/Interact: mailto:dev-subscr...@qpid.apache.org

Exception thrown from qpidcommon.dll on windows

[Shan Wang]

Hi All,

 

I built a client dll from QPID-1673 branch(which I believe is the first
usable windows dll branch). In the beginning everything seems fine, then
I found this exception thrown somewhere from qpidcommon.dll, and the
call stack is shown below:

 

 

qpidcommon.dll!qpid::sys::windows::AsynchIO::writeComplete()  + 0x46
bytes  C++

qpidcommon.dll!qpid::sys::windows::AsynchIO::completion()  + 0x12f bytes
C++

qpidcommon.dll!boost::detail::function::void_function_obj_invoker1,boost::_bi::list2,boost::arg<1> > >,void,qpid::sys::AsynchIoResult *>::invoke()  +
0x10 bytes C++

qpidcommon.dll!boost::function1 >::operator()()  + 0x4e bytes
C++

qpidcommon.dll!qpid::sys::AsynchWriteResult::complete()  + 0x18 bytes
C++

qpidcommon.dll!qpid::sys::AsynchResult::success()  + 0x15 bytes C++

qpidcommon.dll!qpid::sys::Poller::wait()  + 0xd3 bytes  C++

qpidcommon.dll!qpid::sys::Poller::run()  + 0x29 bytes   C++

qpidclient.dll!qpid::client::TCPConnector::run()  + 0x11c bytes
C++

msvcr90.dll!785838bb()  

 [Frames below may be incorrect and/or missing, no symbols loaded for
msvcr90.dll]   

qpidcommon.dll!`anonymous namespace'::runRunnable()  + 0xb bytes
C++

 

 

Does anyone have a idea what is this about?

 

 

Thanks and Regards,

Shan

The information contained in this email is strictly confidential and for the 
use of the addressee only, unless otherwise indicated. If you are not the 
intended recipient, please do not read, copy, use or disclose to others this 
message or any attachment. Please also notify the sender by replying to this 
email or by telephone (+44 (0)20 7896 0011) and then delete the email and any 
copies of it. Opinions, conclusions (etc.) that do not relate to the official 
business of this company shall be understood as neither given nor endorsed by 
it. IG Index plc is a company registered in England and Wales under number 
01190902. VAT registration number 761 2978 07. Registered Office: Friars House, 
157-168 Blackfriars Road, London SE1 8EZ. Authorised and regulated by the 
Financial Services Authority. FSA Register number 114059.