qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kerry Bonin (JIRA)" <qpid-...@incubator.apache.org>
Subject [jira] Commented: (QPID-2199) Federation connections initiated from windows brokers stuck in "connecting" state
Date Fri, 23 Apr 2010 15:20:50 GMT

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

Kerry Bonin commented on QPID-2199:
-----------------------------------

I'm looking at ways to fix this...

The cleanest fix would appear to be to generalize the Posix version so it runs on Windows.
 The main problem I've seen so far with that approach is the Posix code uses thread local
storage, which is unusable on Windows (if the code could run in a DLL loaded with LoadLibrary
on OS's before Vista or Server 2008, see http://msdn2.microsoft.com/en-us/library/2s9wt68x.aspx
for details.)  Simplest way to address that would seem to add these variables to the AsynchIO
class and lock before use.  For now I'll copy the Posix version over the Windows version and
see about making the changes there.  Comments appreciated!

Kerry

> Federation connections initiated from windows brokers stuck in "connecting" state
> ---------------------------------------------------------------------------------
>
>                 Key: QPID-2199
>                 URL: https://issues.apache.org/jira/browse/QPID-2199
>             Project: Qpid
>          Issue Type: Bug
>          Components: C++ Broker
>    Affects Versions: 0.5
>         Environment: Windows XP, qpid 0.5 from .msi installer, hosts scengsrv and jlaughlin,
qpidbroker.exe running under cmd.exe, other tools running under cygwin
> Ubuntu Hardy, qpid 0.5 compiled from source with unused return value patches, host santa-anna
>            Reporter: Jeff Laughlin
>         Attachments: linux.cap, linux.out, windows.cap, windows.out
>
>
> My Windows broker can't establish federation link to other brokers running on windows
or linux; links remain in "connecting" state forever. Packet sniffer reveals strange and inconsistent
things. Linux broker can successfully establish links to windows brokers, however. Python
client tools seems to work fine with both windows and linux brokers, from both cygwin python
and linux python.
> Here's a terminal session transcript that illustrates this behavior. I'm starting with
two fresh instances of qpid on two different windows hosts, jlaughlin and scengsrv. Both have
been configured with a durable alarms exchange and durable alarmd queue that have been bound
together.
> First I try to create the link in push mode, so qpid-route is commanding jlaughlin (the
localhost) to establish a link to scengsrv
> jlaughlin@jlaughlin ~/Downloads/qpid-0.5/python/commands
> $ python2.5 qpid-route queue add scengsrv jlaughlin alarms alarmd --ack 1 --src-local
> After a  moment I check my links
> jlaughlin@jlaughlin ~/Downloads/qpid-0.5/python/commands
> $ python2.5 qpid-route link list
> Host            Port    Transport Durable  State             Last Error
> =============================================================================
> scengsrv        5672    tcp          N     Connecting        
> Hm it's still connecting. Wait a few moments.
> jlaughlin@jlaughlin ~/Downloads/qpid-0.5/python/commands
> $ python2.5 qpid-route link list
> Host            Port    Transport Durable  State             Last Error
> =============================================================================
> scengsrv        5672    tcp          N     Connecting        
> Still connecting. Darn. Lets try going the other way, commanding scengsrv to link to
jlaughlin.
> jlaughlin@jlaughlin ~/Downloads/qpid-0.5/python/commands
> $ python2.5 qpid-route queue add scengsrv jlaughlin alarms alarmd --ack 1           

> jlaughlin@jlaughlin ~/Downloads/qpid-0.5/python/commands
> $ python2.5 qpid-route link list scengsrv
> Host            Port    Transport Durable  State             Last Error
> =============================================================================
> jlaughlin       5672    tcp          N     Connecting        
> Still no good.
> Now lets try commanding jlaughlin to connect to my linux box, santa-anna
> jlaughlin@jlaughlin ~/Downloads/qpid-0.5/python/commands
> $ python2.5 qpid-route queue add santa-anna jlaughlin alarms alarmd --ack 1 --src-local
> jlaughlin@jlaughlin ~/Downloads/qpid-0.5/python/commands
> $ python2.5 qpid-route link list         
> Host            Port    Transport Durable  State             Last Error
> =============================================================================
> santa-anna      5672    tcp          N     Connecting        
> jlaughlin@jlaughlin ~/Downloads/qpid-0.5/python/commands
> $ python2.5 qpid-route link list 
> Host            Port    Transport Durable  State             Last Error
> =============================================================================
> santa-anna      5672    tcp          N     Connecting        
> Negative, ghost rider, the pattern is full.
> Enough of this, lets command the linux host, santa-anna, to connect to my jlaughlin windows
host:
> jlaughlin@jlaughlin ~/Downloads/qpid-0.5/python/commands
> $ python2.5 qpid-route queue add santa-anna jlaughlin alarms alarmd --ack 1         
  
> jlaughlin@jlaughlin ~/Downloads/qpid-0.5/python/commands
> $ python2.5 qpid-route link list santa-anna
> Host            Port    Transport Durable  State             Last Error
> =============================================================================
> jlaughlin       5672    tcp          N     Operational       
> It works! Yay Linux! Still why is the windows client behaving so poorly?

-- 
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-subscribe@qpid.apache.org


Mime
View raw message