Re: Cross-MinGW linking problem
Hi Robin, MinGW has not recently been looked at for proton. A lot of Visual Studio related contributions have been incorporated as of 0.4, which allows us to build on Windows, but work remains to get ssl support, a clean make test and a parallel CI build on Windows. Please feel free to create a JIRA for MinGW support. We would also certainly welcome any code contributions. Cliff On Mon, Apr 8, 2013 at 6:48 AM, Robin Lee robinlee.s...@gmail.com wrote: Hi, every body. I was just tring to build Proton (svn1465587) with MinGW on Fedora cross-compiling environment[1]. When linking libqpid-proton.dll, I found libqpid-proton.dll.a is missing symbols available in the dll. The linking command: /usr/bin/i686-w64-mingw32-gcc -Wl,--no-undefined -shared -o libqpid-proton.dll -Wl,--out-implib,libqpid-proton.dll.a -Wl,--major-image-version,1,--minor-image-version,0 -Wl,--whole-archive CMakeFiles/qpid-proton.dir/objects.a -Wl,--no-whole-archive -lws2_32 -lrpcrt4 -L. -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 Output of 'i686-w64-mingw32-nm objects.a' in qpid-proton.dir: http://cheeselee.fedorapeople.org/nm-qpid-proton-objects.a.txt Output of 'i686-w64-mingw32-nm libqpid-proton.dll': http://cheeselee.fedorapeople.org/nm-libqpid-proton.dll.txt Output of 'i686-w64-mingw32-nm libqpid-proton.dll.a': http://cheeselee.fedorapeople.org/nm-libqpid-proton.dll.a.txt The successive result is proton.exe failed to link, since libqpid-proton.dll.a is missing symbols. 0.4 stable also suffer this problem. Native Linux Build is smooth. [1] MinGW package list: mingw32-boost-1.50.0-1.fc18.noarch mingw32-filesystem-97-1.fc18.noarch mingw32-gcc-c++-4.7.2-7.fc18.x86_64 mingw32-bzip2-1.0.6-2.fc18.noarch mingw32-zlib-1.2.7-1.fc18.noarch mingw-binutils-generic-2.23.1-2.fc18.x86_64 mingw32-win-iconv-0.0.4-1.fc18.noarch mingw32-boost-static-1.50.0-1.fc18.noarch mingw32-headers-2.0.999-0.15.trunk.20121110.fc18.noarch mingw32-crt-2.0.999-0.16.trunk.20121110.fc18.noarch mingw32-gcc-4.7.2-7.fc18.x86_64 mingw32-pthreads-2.8.0-22.20110511cvs.fc18.noarch mingw32-binutils-2.23.1-2.fc18.x86_64 mingw32-pcre-8.31-1.fc18.noarch mingw-filesystem-base-97-1.fc18.noarch mingw32-pthreads-static-2.8.0-22.20110511cvs.fc18.noarch mingw32-cpp-4.7.2-7.fc18.x86_64
messenger routing suggestion
The idea I put forward for a change to pn_messenger_route() may have seemed not very well motivated. Here is a more complete example, and a more complete suggestion. Example === All of these nodes are Messenger nodes. 1. Sender You have a node that's a sender. It is sending to only abstract addresses. It uses its routing table to map all its abstract addresses to the same receiver -- because that receiver is where the system centralizes knowledge about changing network conditions. Sender's routing table -- COLOSSUS -- 1.2.3.4: GUARDIAN -- 1.2.3.4: HAL9000 -- 1.2.3.4: SKYNET -- 1.2.3.4: 2. Router You have a router node that is listening on 1.2.3.4: . It receives and then forwards messages. It can do this because the messages it receives from Sender still have their untranslated addresses. It has this routing table --- COLOSSUS -- 5.6.7.8:1234 COLOSSUS -- 5.6.7.9:1234 GUARDIAN -- 5.6.7.23:3456 HAL9000 -- null SKYNET -- 5.6.7.99:6969 3. Adapting to changing conditions The 'router' node can change its address translation table based on messages that it receives from other parts of the network. For example, maybe it does load-balancing this way. But in general -- it needs to change its translation table at run time because conditions in the network are changing. It is the node that encapsulates knowledge about those changes so that the rest of our nodes do not need to worry about it. They just send to COLOSSUS or whatever. This implies that we should be able to change routing dynamically. 4. Fanout Note that there are two translations for COLOSSUS. We send to both of them. ( This is a change. ) This is how we implement fanout with the address translation. 5. Load and Store Since the translation table can change due to changing network conditions, the Router node should be able to store its table to a file, and load from that file. The information that it has learned during operation is not lost. Or it can use this facility to fork off another copy of itself. 6. API changes It seems to me that the address translation functionality is potentially very powerful, with a few teensy changes. Here they are: /*= At send time, the messenger examines its translation table, and sends a copy of the message to each matching address. ( this is a change ) The address stored in the message is not changed. ( this is true now. ) =*/ /*--- Append the given translation to the list. ---*/ pn_messenger_route_add ( pn_messenger_t *messenger, const char *pattern, const char *address ); /*- If the given pattern already exists in the list, replace its first occurrence with this translation. Otherwise add this translation to the list. -*/ pn_messenger_route_replace ( pn_messenger_t *messenger, const char *pattern, const char *address ); /*- Delete the given translation from the list. ( Else, NOOP. ) -*/ pn_messenger_route_delete ( pn_messenger_t *messenger, const char *pattern, const char *address ); /*- Delete from the list all translations with this pattern. -*/ pn_messenger_route_delete_pattern ( pn_messenger_t *messenger, const char *pattern ); /*- Clear the translation table. -*/ pn_messenger_route_clear_table ( pn_messenger_t *messenger ); /*- Load from the given fp -*/ pn_messenger_route_load_table ( pn_messenger_t *messenger, FILE * fp ); /*- Store to the given fp -*/ pn_messenger_route_load_table ( pn_messenger_t *messenger, FILE * fp );
Re: Cross-MinGW linking problem
I finally make MinGW build of current trunk all done, and will figure out some patches as soon as possible. On Tuesday, April 9, 2013, Cliff Jansen cliffjan...@gmail.com wrote: Hi Robin, MinGW has not recently been looked at for proton. A lot of Visual Studio related contributions have been incorporated as of 0.4, which allows us to build on Windows, but work remains to get ssl support, a clean make test and a parallel CI build on Windows. Please feel free to create a JIRA for MinGW support. We would also certainly welcome any code contributions. Cliff On Mon, Apr 8, 2013 at 6:48 AM, Robin Lee robinlee.s...@gmail.com wrote: Hi, every body. I was just tring to build Proton (svn1465587) with MinGW on Fedora cross-compiling environment[1]. When linking libqpid-proton.dll, I found libqpid-proton.dll.a is missing symbols available in the dll. The linking command: /usr/bin/i686-w64-mingw32-gcc -Wl,--no-undefined -shared -o libqpid-proton.dll -Wl,--out-implib,libqpid-proton.dll.a -Wl,--major-image-version,1,--minor-image-version,0 -Wl,--whole-archive CMakeFiles/qpid-proton.dir/objects.a -Wl,--no-whole-archive -lws2_32 -lrpcrt4 -L. -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 Output of 'i686-w64-mingw32-nm objects.a' in qpid-proton.dir: http://cheeselee.fedorapeople.org/nm-qpid-proton-objects.a.txt Output of 'i686-w64-mingw32-nm libqpid-proton.dll': http://cheeselee.fedorapeople.org/nm-libqpid-proton.dll.txt Output of 'i686-w64-mingw32-nm libqpid-proton.dll.a': http://cheeselee.fedorapeople.org/nm-libqpid-proton.dll.a.txt The successive result is proton.exe failed to link, since libqpid-proton.dll.a is missing symbols. 0.4 stable also suffer this problem. Native Linux Build is smooth. [1] MinGW package list: mingw32-boost-1.50.0-1.fc18.noarch mingw32-filesystem-97-1.fc18.noarch mingw32-gcc-c++-4.7.2-7.fc18.x86_64 mingw32-bzip2-1.0.6-2.fc18.noarch mingw32-zlib-1.2.7-1.fc18.noarch mingw-binutils-generic-2.23.1-2.fc18.x86_64 mingw32-win-iconv-0.0.4-1.fc18.noarch mingw32-boost-static-1.50.0-1.fc18.noarch mingw32-headers-2.0.999-0.15.trunk.20121110.fc18.noarch mingw32-crt-2.0.999-0.16.trunk.20121110.fc18.noarch mingw32-gcc-4.7.2-7.fc18.x86_64 mingw32-pthreads-2.8.0-22.20110511cvs.fc18.noarch mingw32-binutils-2.23.1-2.fc18.x86_64 mingw32-pcre-8.31-1.fc18.noarch mingw-filesystem-base-97-1.fc18.noarch mingw32-pthreads-static-2.8.0-22.20110511cvs.fc18.noarch mingw32-cpp-4.7.2-7.fc18.x86_64
Re: possible cool change to pn_messenger_route()
On Tue, Apr 9, 2013 at 2:00 PM, Michael Goulish mgoul...@redhat.com wrote:
I like your pattern -- { broadcast, balance, failover } ( addr, addr,
... addr )
idea a lot better than my multiple rules w/ same pattern.
I just think runtime-adaptive address translation could be very powerful.
i.e. for failover scenario, think of (old) Qpid clustering -- when one node
failed, a new node with a new addr stands up -- and advertises its addr.
It would get added to this rule
pattern -- failover ( addr1, addr2, addr_new )
And the dead node deleted.
I agree it is a very tantalizing possibility. I think application-specific
content based routing is the killer motivating scenario as that is
something where you couldn't use a turn-key router, and also not something
you are going to do via a config file.
--Rafael
