You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@qpid.apache.org by ft420 <ar...@gmail.com> on 2009/03/20 07:33:28 UTC

send/receive to/from remote machine

Is it possible to send/receive etc to/from remote machine as in MSMQ?
what is the procedure for the same?

While running the broker -p option allows me to listen on port other than
5672 but if i want to change the ip also how to do the same as by default it
takes 127.0.0.1 ip...

the client api documentation doesnot have explaination for the apis
provieded... for example i wanted Label feature hence i was checking
MessageProperties class there are quite a few options like MessageId, AppId
etc but was unable to understand which option is actually equivalent to
Label option in MSMQ?? 

Thanks
-- 
View this message in context: http://n2.nabble.com/send-receive-to-from-remote-machine-tp2507392p2507392.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.


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


Re: persistence plug-in

Posted by ft420 <ar...@gmail.com>.
Please let me know your mail id where i can contact you....

ft420 wrote:
> Hi,
>
> Giving you brief of what all steps have been executed uptill now to use qpid
>
> As mentioned earlier we are using RHEL5, Kernel release 2.6.18-8.el5. 
>
> boost, e2fsprogs, pkgconfig, ruby & python packages that are available with RHEL dvd have been installed on the system.
>
> We have downloaded QPID from http://www.apache.org/dist/qpid/M4/qpid-cpp-M4.tar.gz link for c++ broker/client.
>
> Have downloaded all the files from the link http://anonsvn.jboss.org/repos/rhmessaging/store/trunk/cpp/ that you provided so as to create durable queue.
>
> configure file was created when on executing ./bootstrap
> Please let me know if i have gone wrong in any of the above steps...
>
> At your end which plug-in do you use to create the durable queues?
>
>   
mrgstore.so

> Is there any single tar file for the same? Or is there any persistence library available?
>
>   

They are rebuilt for RHEL, if you need info on that, mail me directly

regards
Carl.

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




-- 
View this message in context: http://n2.nabble.com/send-receive-to-from-remote-machine-tp2507392p2553534.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.


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


Re: persistence plug-in

Posted by Carl Trieloff <cc...@redhat.com>.
ft420 wrote:
> Hi,
>
> Giving you brief of what all steps have been executed uptill now to use qpid
>
> As mentioned earlier we are using RHEL5, Kernel release 2.6.18-8.el5. 
>
> boost, e2fsprogs, pkgconfig, ruby & python packages that are available with RHEL dvd have been installed on the system.
>
> We have downloaded QPID from http://www.apache.org/dist/qpid/M4/qpid-cpp-M4.tar.gz link for c++ broker/client.
>
> Have downloaded all the files from the link http://anonsvn.jboss.org/repos/rhmessaging/store/trunk/cpp/ that you provided so as to create durable queue.
>
> configure file was created when on executing ./bootstrap
> Please let me know if i have gone wrong in any of the above steps...
>
> At your end which plug-in do you use to create the durable queues?
>
>   
mrgstore.so

> Is there any single tar file for the same? Or is there any persistence library available?
>
>   

They are rebuilt for RHEL, if you need info on that, mail me directly

regards
Carl.

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


persistence plug-in

Posted by ft420 <ar...@gmail.com>.
Hi,

Giving you brief of what all steps have been executed uptill now to use qpid

As mentioned earlier we are using RHEL5, Kernel release 2.6.18-8.el5. 

boost, e2fsprogs, pkgconfig, ruby & python packages that are available with RHEL dvd have been installed on the system.

We have downloaded QPID from http://www.apache.org/dist/qpid/M4/qpid-cpp-M4.tar.gz link for c++ broker/client.

Have downloaded all the files from the link http://anonsvn.jboss.org/repos/rhmessaging/store/trunk/cpp/ that you provided so as to create durable queue.

configure file was created when on executing ./bootstrap
Please let me know if i have gone wrong in any of the above steps...

At your end which plug-in do you use to create the durable queues?

Is there any single tar file for the same? Or is there any persistence library available?


Awaiting your solution...
Thanks
-- 
View this message in context: http://n2.nabble.com/send-receive-to-from-remote-machine-tp2507392p2536825.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.


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


RE: autoconf issue? (was Re: send/receive to/from remote machine)

Posted by ft420 <ar...@gmail.com>.
below statement is at line 19936 in configure file
test $fail = &amp;&amp;

As per youre suggestion i did try && instead of & but still the error persists.. :(


> ft420 wrote:
> > Hi Gordon,
> > 
> > I hope you checked the flow of what happens when 
> ./configure is done... 
> > If possible please let me know solution for the same... 
> 
> It has me stumped at present I'm afraid. It looks to me like its an 
> issue with autoconf but I couldn't swear to it. Any experts 
> on the list able to comment?

Expert, I am not. But can you please look at your configure file line
19936 and see if there really is &amp; there? It should be simply &&

-Steve

> > ./bootstrap works properly but ./configure gives problem. 
> Please find below whatever is displayed when i execute ./configure 
> > 
> > [root@FTCPU1452 cpp]# ./configure
> > checking for a BSD-compatible install... /usr/bin/install -c
> > checking whether build environment is sane... yes
> > checking for gawk... gawk
> > checking whether make sets $(MAKE)... yes
> > checking for style of include used by make... GNU
> > checking for gcc... gcc
> > checking for C compiler default output file name... a.out
> > checking whether the C compiler works... yes
> > checking whether we are cross compiling... no
> > checking for suffix of executables... 
> > checking for suffix of object files... o
> > checking whether we are using the GNU C compiler... yes
> > checking whether gcc accepts -g... yes
> > checking for gcc option to accept ANSI C... none needed
> > checking dependency style of gcc... gcc3
> > checking whether gcc and cc understand -c and -o together... yes
> > checking for g++... g++
> > checking whether we are using the GNU C++ compiler... yes
> > checking whether g++ accepts -g... yes
> > checking dependency style of g++... gcc3
> > checking how to run the C preprocessor... gcc -E
> > checking for egrep... grep -E
> > checking for AIX... no
> > checking for ANSI C header files... yes
> > checking for sys/types.h... yes
> > checking for sys/stat.h... yes
> > checking for stdlib.h... yes
> > checking for string.h... yes
> > checking for memory.h... yes
> > checking for strings.h... yes
> > checking for inttypes.h... yes
> > checking for stdint.h... yes
> > checking for unistd.h... yes
> > checking minix/config.h usability... no
> > checking minix/config.h presence... no
> > checking for minix/config.h... no
> > checking whether it is safe to define __EXTENSIONS__... yes
> > checking whether compiler accepts -Werror... yes
> > checking whether compiler accepts -pedantic... yes
> > checking whether compiler accepts -Wall... yes
> > checking whether compiler accepts -Wextra... yes
> > checking whether compiler accepts -Wno-shadow... yes
> > checking whether compiler accepts -Wpointer-arith... yes
> > checking whether compiler accepts -Wcast-qual... yes
> > checking whether compiler accepts -Wcast-align... yes
> > checking whether compiler accepts -Wno-long-long... yes
> > checking whether compiler accepts -Wvolatile-register-var... yes
> > checking whether compiler accepts -Winvalid-pch... yes
> > checking whether compiler accepts -Wno-system-headers... yes
> > checking build system type... i686-redhat-linux-gnu
> > checking host system type... i686-redhat-linux-gnu
> > checking for a sed that does not truncate output... /bin/sed
> > checking for ld used by gcc... /usr/bin/ld
> > checking if the linker (/usr/bin/ld) is GNU ld... yes
> > checking for /usr/bin/ld option to reload object files... -r
> > checking for BSD-compatible nm... /usr/bin/nm -B
> > checking whether ln -s works... yes
> > checking how to recognise dependent libraries... pass_all
> > checking dlfcn.h usability... yes
> > checking dlfcn.h presence... no
> > configure: WARNING: dlfcn.h: accepted by the compiler, 
> rejected by the preprocessor!
> > configure: WARNING: dlfcn.h: proceeding with the compiler's result
> > checking for dlfcn.h... yes
> > checking how to run the C++ preprocessor... g++ -E
> > checking for g77... no
> > checking for f77... no
> > checking for xlf... no
> > checking for frt... no
> > checking for pgf77... no
> > checking for fort77... no
> > checking for fl32... no
> > checking for af77... no
> > checking for f90... no
> > checking for xlf90... no
> > checking for pgf90... no
> > checking for epcf90... no
> > checking for f95... f95
> > checking whether we are using the GNU Fortran 77 compiler... yes
> > checking whether f95 accepts -g... yes
> > checking the maximum length of command line arguments... 32768
> > checking command to parse /usr/bin/nm -B output from gcc 
> object... ok
> > checking for objdir... .libs
> > checking for ar... ar
> > checking for ranlib... ranlib
> > checking for strip... strip
> > checking if gcc supports -fno-rtti -fno-exceptions... no
> > checking for gcc option to produce PIC... -fPIC
> > checking if gcc PIC flag -fPIC works... yes
> > checking if gcc static flag -static works... yes
> > checking if gcc supports -c -o file.o... yes
> > checking whether the gcc linker (/usr/bin/ld) supports 
> shared libraries... yes
> > checking whether -lc should be explicitly linked in... no
> > checking dynamic linker characteristics... GNU/Linux ld.so
> > checking how to hardcode library paths into programs... immediate
> > checking whether stripping libraries is possible... yes
> > checking if libtool supports shared libraries... yes
> > checking whether to build shared libraries... yes
> > checking whether to build static libraries... no
> > configure: creating libtool
> > appending configuration tag "CXX" to libtool
> > checking for ld used by g++... /usr/bin/ld
> > checking if the linker (/usr/bin/ld) is GNU ld... yes
> > checking whether the g++ linker (/usr/bin/ld) supports 
> shared libraries... yes
> > checking for g++ option to produce PIC... -fPIC
> > checking if g++ PIC flag -fPIC works... yes
> > checking if g++ static flag -static works... yes
> > checking if g++ supports -c -o file.o... yes
> > checking whether the g++ linker (/usr/bin/ld) supports 
> shared libraries... yes
> > checking dynamic linker characteristics... GNU/Linux ld.so
> > checking how to hardcode library paths into programs... immediate
> > appending configuration tag "F77" to libtool
> > checking if libtool supports shared libraries... yes
> > checking whether to build shared libraries... yes
> > checking whether to build static libraries... no
> > checking for f95 option to produce PIC... -fPIC
> > checking if f95 PIC flag -fPIC works... yes
> > checking if f95 static flag -static works... yes
> > checking if f95 supports -c -o file.o... yes
> > checking whether the f95 linker (/usr/bin/ld) supports 
> shared libraries... yes
> > checking dynamic linker characteristics... GNU/Linux ld.so
> > checking how to hardcode library paths into programs... immediate
> > ./configure: line 19936: syntax error near unexpected token `&'
> > ./configure: line 19936: `  test $fail = 1 &amp;&amp;'
> > 
> > 
> > hopefully this will give you idea regarding where the problem
is....
> > 
> > Thanks
> > 
> > 
> > 
> 
> 
>
---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
> 


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




-- 
View this message in context: http://n2.nabble.com/send-receive-to-from-remote-machine-tp2507392p2536513.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.


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


RE: autoconf issue? (was Re: send/receive to/from remote machine)

Posted by Steve Huston <sh...@riverace.com>.
> ft420 wrote:
> > Hi Gordon,
> > 
> > I hope you checked the flow of what happens when 
> ./configure is done... 
> > If possible please let me know solution for the same... 
> 
> It has me stumped at present I'm afraid. It looks to me like its an 
> issue with autoconf but I couldn't swear to it. Any experts 
> on the list able to comment?

Expert, I am not. But can you please look at your configure file line
19936 and see if there really is &amp; there? It should be simply &&

-Steve

> > ./bootstrap works properly but ./configure gives problem. 
> Please find below whatever is displayed when i execute ./configure 
> > 
> > [root@FTCPU1452 cpp]# ./configure
> > checking for a BSD-compatible install... /usr/bin/install -c
> > checking whether build environment is sane... yes
> > checking for gawk... gawk
> > checking whether make sets $(MAKE)... yes
> > checking for style of include used by make... GNU
> > checking for gcc... gcc
> > checking for C compiler default output file name... a.out
> > checking whether the C compiler works... yes
> > checking whether we are cross compiling... no
> > checking for suffix of executables... 
> > checking for suffix of object files... o
> > checking whether we are using the GNU C compiler... yes
> > checking whether gcc accepts -g... yes
> > checking for gcc option to accept ANSI C... none needed
> > checking dependency style of gcc... gcc3
> > checking whether gcc and cc understand -c and -o together... yes
> > checking for g++... g++
> > checking whether we are using the GNU C++ compiler... yes
> > checking whether g++ accepts -g... yes
> > checking dependency style of g++... gcc3
> > checking how to run the C preprocessor... gcc -E
> > checking for egrep... grep -E
> > checking for AIX... no
> > checking for ANSI C header files... yes
> > checking for sys/types.h... yes
> > checking for sys/stat.h... yes
> > checking for stdlib.h... yes
> > checking for string.h... yes
> > checking for memory.h... yes
> > checking for strings.h... yes
> > checking for inttypes.h... yes
> > checking for stdint.h... yes
> > checking for unistd.h... yes
> > checking minix/config.h usability... no
> > checking minix/config.h presence... no
> > checking for minix/config.h... no
> > checking whether it is safe to define __EXTENSIONS__... yes
> > checking whether compiler accepts -Werror... yes
> > checking whether compiler accepts -pedantic... yes
> > checking whether compiler accepts -Wall... yes
> > checking whether compiler accepts -Wextra... yes
> > checking whether compiler accepts -Wno-shadow... yes
> > checking whether compiler accepts -Wpointer-arith... yes
> > checking whether compiler accepts -Wcast-qual... yes
> > checking whether compiler accepts -Wcast-align... yes
> > checking whether compiler accepts -Wno-long-long... yes
> > checking whether compiler accepts -Wvolatile-register-var... yes
> > checking whether compiler accepts -Winvalid-pch... yes
> > checking whether compiler accepts -Wno-system-headers... yes
> > checking build system type... i686-redhat-linux-gnu
> > checking host system type... i686-redhat-linux-gnu
> > checking for a sed that does not truncate output... /bin/sed
> > checking for ld used by gcc... /usr/bin/ld
> > checking if the linker (/usr/bin/ld) is GNU ld... yes
> > checking for /usr/bin/ld option to reload object files... -r
> > checking for BSD-compatible nm... /usr/bin/nm -B
> > checking whether ln -s works... yes
> > checking how to recognise dependent libraries... pass_all
> > checking dlfcn.h usability... yes
> > checking dlfcn.h presence... no
> > configure: WARNING: dlfcn.h: accepted by the compiler, 
> rejected by the preprocessor!
> > configure: WARNING: dlfcn.h: proceeding with the compiler's result
> > checking for dlfcn.h... yes
> > checking how to run the C++ preprocessor... g++ -E
> > checking for g77... no
> > checking for f77... no
> > checking for xlf... no
> > checking for frt... no
> > checking for pgf77... no
> > checking for fort77... no
> > checking for fl32... no
> > checking for af77... no
> > checking for f90... no
> > checking for xlf90... no
> > checking for pgf90... no
> > checking for epcf90... no
> > checking for f95... f95
> > checking whether we are using the GNU Fortran 77 compiler... yes
> > checking whether f95 accepts -g... yes
> > checking the maximum length of command line arguments... 32768
> > checking command to parse /usr/bin/nm -B output from gcc 
> object... ok
> > checking for objdir... .libs
> > checking for ar... ar
> > checking for ranlib... ranlib
> > checking for strip... strip
> > checking if gcc supports -fno-rtti -fno-exceptions... no
> > checking for gcc option to produce PIC... -fPIC
> > checking if gcc PIC flag -fPIC works... yes
> > checking if gcc static flag -static works... yes
> > checking if gcc supports -c -o file.o... yes
> > checking whether the gcc linker (/usr/bin/ld) supports 
> shared libraries... yes
> > checking whether -lc should be explicitly linked in... no
> > checking dynamic linker characteristics... GNU/Linux ld.so
> > checking how to hardcode library paths into programs... immediate
> > checking whether stripping libraries is possible... yes
> > checking if libtool supports shared libraries... yes
> > checking whether to build shared libraries... yes
> > checking whether to build static libraries... no
> > configure: creating libtool
> > appending configuration tag "CXX" to libtool
> > checking for ld used by g++... /usr/bin/ld
> > checking if the linker (/usr/bin/ld) is GNU ld... yes
> > checking whether the g++ linker (/usr/bin/ld) supports 
> shared libraries... yes
> > checking for g++ option to produce PIC... -fPIC
> > checking if g++ PIC flag -fPIC works... yes
> > checking if g++ static flag -static works... yes
> > checking if g++ supports -c -o file.o... yes
> > checking whether the g++ linker (/usr/bin/ld) supports 
> shared libraries... yes
> > checking dynamic linker characteristics... GNU/Linux ld.so
> > checking how to hardcode library paths into programs... immediate
> > appending configuration tag "F77" to libtool
> > checking if libtool supports shared libraries... yes
> > checking whether to build shared libraries... yes
> > checking whether to build static libraries... no
> > checking for f95 option to produce PIC... -fPIC
> > checking if f95 PIC flag -fPIC works... yes
> > checking if f95 static flag -static works... yes
> > checking if f95 supports -c -o file.o... yes
> > checking whether the f95 linker (/usr/bin/ld) supports 
> shared libraries... yes
> > checking dynamic linker characteristics... GNU/Linux ld.so
> > checking how to hardcode library paths into programs... immediate
> > ./configure: line 19936: syntax error near unexpected token `&'
> > ./configure: line 19936: `  test $fail = 1 &amp;&amp;'
> > 
> > 
> > hopefully this will give you idea regarding where the problem
is....
> > 
> > Thanks
> > 
> > 
> > 
> 
> 
>
---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
> 


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


autoconf issue? (was Re: send/receive to/from remote machine)

Posted by Gordon Sim <gs...@redhat.com>.
ft420 wrote:
> Hi Gordon,
> 
> I hope you checked the flow of what happens when ./configure is done... 
> If possible please let me know solution for the same... 

It has me stumped at present I'm afraid. It looks to me like its an 
issue with autoconf but I couldn't swear to it. Any experts on the list 
able to comment?

> ./bootstrap works properly but ./configure gives problem. Please find below whatever is displayed when i execute ./configure 
> 
> [root@FTCPU1452 cpp]# ./configure
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking for style of include used by make... GNU
> checking for gcc... gcc
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables... 
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc accepts -g... yes
> checking for gcc option to accept ANSI C... none needed
> checking dependency style of gcc... gcc3
> checking whether gcc and cc understand -c and -o together... yes
> checking for g++... g++
> checking whether we are using the GNU C++ compiler... yes
> checking whether g++ accepts -g... yes
> checking dependency style of g++... gcc3
> checking how to run the C preprocessor... gcc -E
> checking for egrep... grep -E
> checking for AIX... no
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking minix/config.h usability... no
> checking minix/config.h presence... no
> checking for minix/config.h... no
> checking whether it is safe to define __EXTENSIONS__... yes
> checking whether compiler accepts -Werror... yes
> checking whether compiler accepts -pedantic... yes
> checking whether compiler accepts -Wall... yes
> checking whether compiler accepts -Wextra... yes
> checking whether compiler accepts -Wno-shadow... yes
> checking whether compiler accepts -Wpointer-arith... yes
> checking whether compiler accepts -Wcast-qual... yes
> checking whether compiler accepts -Wcast-align... yes
> checking whether compiler accepts -Wno-long-long... yes
> checking whether compiler accepts -Wvolatile-register-var... yes
> checking whether compiler accepts -Winvalid-pch... yes
> checking whether compiler accepts -Wno-system-headers... yes
> checking build system type... i686-redhat-linux-gnu
> checking host system type... i686-redhat-linux-gnu
> checking for a sed that does not truncate output... /bin/sed
> checking for ld used by gcc... /usr/bin/ld
> checking if the linker (/usr/bin/ld) is GNU ld... yes
> checking for /usr/bin/ld option to reload object files... -r
> checking for BSD-compatible nm... /usr/bin/nm -B
> checking whether ln -s works... yes
> checking how to recognise dependent libraries... pass_all
> checking dlfcn.h usability... yes
> checking dlfcn.h presence... no
> configure: WARNING: dlfcn.h: accepted by the compiler, rejected by the preprocessor!
> configure: WARNING: dlfcn.h: proceeding with the compiler's result
> checking for dlfcn.h... yes
> checking how to run the C++ preprocessor... g++ -E
> checking for g77... no
> checking for f77... no
> checking for xlf... no
> checking for frt... no
> checking for pgf77... no
> checking for fort77... no
> checking for fl32... no
> checking for af77... no
> checking for f90... no
> checking for xlf90... no
> checking for pgf90... no
> checking for epcf90... no
> checking for f95... f95
> checking whether we are using the GNU Fortran 77 compiler... yes
> checking whether f95 accepts -g... yes
> checking the maximum length of command line arguments... 32768
> checking command to parse /usr/bin/nm -B output from gcc object... ok
> checking for objdir... .libs
> checking for ar... ar
> checking for ranlib... ranlib
> checking for strip... strip
> checking if gcc supports -fno-rtti -fno-exceptions... no
> checking for gcc option to produce PIC... -fPIC
> checking if gcc PIC flag -fPIC works... yes
> checking if gcc static flag -static works... yes
> checking if gcc supports -c -o file.o... yes
> checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
> checking whether -lc should be explicitly linked in... no
> checking dynamic linker characteristics... GNU/Linux ld.so
> checking how to hardcode library paths into programs... immediate
> checking whether stripping libraries is possible... yes
> checking if libtool supports shared libraries... yes
> checking whether to build shared libraries... yes
> checking whether to build static libraries... no
> configure: creating libtool
> appending configuration tag "CXX" to libtool
> checking for ld used by g++... /usr/bin/ld
> checking if the linker (/usr/bin/ld) is GNU ld... yes
> checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
> checking for g++ option to produce PIC... -fPIC
> checking if g++ PIC flag -fPIC works... yes
> checking if g++ static flag -static works... yes
> checking if g++ supports -c -o file.o... yes
> checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
> checking dynamic linker characteristics... GNU/Linux ld.so
> checking how to hardcode library paths into programs... immediate
> appending configuration tag "F77" to libtool
> checking if libtool supports shared libraries... yes
> checking whether to build shared libraries... yes
> checking whether to build static libraries... no
> checking for f95 option to produce PIC... -fPIC
> checking if f95 PIC flag -fPIC works... yes
> checking if f95 static flag -static works... yes
> checking if f95 supports -c -o file.o... yes
> checking whether the f95 linker (/usr/bin/ld) supports shared libraries... yes
> checking dynamic linker characteristics... GNU/Linux ld.so
> checking how to hardcode library paths into programs... immediate
> ./configure: line 19936: syntax error near unexpected token `&'
> ./configure: line 19936: `  test $fail = 1 &amp;&amp;'
> 
> 
> hopefully this will give you idea regarding where the problem is....
> 
> Thanks
> 
> 
> 


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


Re: send/receive to/from remote machine

Posted by ft420 <ar...@gmail.com>.
Hi Gordon,

I hope you checked the flow of what happens when ./configure is done... 
If possible please let me know solution for the same... 


./bootstrap works properly but ./configure gives problem. Please find below whatever is displayed when i execute ./configure 

[root@FTCPU1452 cpp]# ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking dependency style of gcc... gcc3
checking whether gcc and cc understand -c and -o together... yes
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C preprocessor... gcc -E
checking for egrep... grep -E
checking for AIX... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether compiler accepts -Werror... yes
checking whether compiler accepts -pedantic... yes
checking whether compiler accepts -Wall... yes
checking whether compiler accepts -Wextra... yes
checking whether compiler accepts -Wno-shadow... yes
checking whether compiler accepts -Wpointer-arith... yes
checking whether compiler accepts -Wcast-qual... yes
checking whether compiler accepts -Wcast-align... yes
checking whether compiler accepts -Wno-long-long... yes
checking whether compiler accepts -Wvolatile-register-var... yes
checking whether compiler accepts -Winvalid-pch... yes
checking whether compiler accepts -Wno-system-headers... yes
checking build system type... i686-redhat-linux-gnu
checking host system type... i686-redhat-linux-gnu
checking for a sed that does not truncate output... /bin/sed
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
checking how to recognise dependent libraries... pass_all
checking dlfcn.h usability... yes
checking dlfcn.h presence... no
configure: WARNING: dlfcn.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: dlfcn.h: proceeding with the compiler's result
checking for dlfcn.h... yes
checking how to run the C++ preprocessor... g++ -E
checking for g77... no
checking for f77... no
checking for xlf... no
checking for frt... no
checking for pgf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for f90... no
checking for xlf90... no
checking for pgf90... no
checking for epcf90... no
checking for f95... f95
checking whether we are using the GNU Fortran 77 compiler... yes
checking whether f95 accepts -g... yes
checking the maximum length of command line arguments... 32768
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC
checking if g++ PIC flag -fPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
appending configuration tag "F77" to libtool
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for f95 option to produce PIC... -fPIC
checking if f95 PIC flag -fPIC works... yes
checking if f95 static flag -static works... yes
checking if f95 supports -c -o file.o... yes
checking whether the f95 linker (/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
./configure: line 19936: syntax error near unexpected token `&'
./configure: line 19936: `  test $fail = 1 &amp;&amp;'


hopefully this will give you idea regarding where the problem is....

Thanks



-- 
View this message in context: http://n2.nabble.com/send-receive-to-from-remote-machine-tp2507392p2532446.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.


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


Re: send/receive to/from remote machine

Posted by ft420 <ar...@gmail.com>.
./bootstrap works properly but ./configure gives problem. Please find below whatever is displayed when i execute ./configure 

[root@FTCPU1452 cpp]# ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables... 
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking dependency style of gcc... gcc3
checking whether gcc and cc understand -c and -o together... yes
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking how to run the C preprocessor... gcc -E
checking for egrep... grep -E
checking for AIX... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking minix/config.h usability... no
checking minix/config.h presence... no
checking for minix/config.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether compiler accepts -Werror... yes
checking whether compiler accepts -pedantic... yes
checking whether compiler accepts -Wall... yes
checking whether compiler accepts -Wextra... yes
checking whether compiler accepts -Wno-shadow... yes
checking whether compiler accepts -Wpointer-arith... yes
checking whether compiler accepts -Wcast-qual... yes
checking whether compiler accepts -Wcast-align... yes
checking whether compiler accepts -Wno-long-long... yes
checking whether compiler accepts -Wvolatile-register-var... yes
checking whether compiler accepts -Winvalid-pch... yes
checking whether compiler accepts -Wno-system-headers... yes
checking build system type... i686-redhat-linux-gnu
checking host system type... i686-redhat-linux-gnu
checking for a sed that does not truncate output... /bin/sed
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking whether ln -s works... yes
checking how to recognise dependent libraries... pass_all
checking dlfcn.h usability... yes
checking dlfcn.h presence... no
configure: WARNING: dlfcn.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: dlfcn.h: proceeding with the compiler's result
checking for dlfcn.h... yes
checking how to run the C++ preprocessor... g++ -E
checking for g77... no
checking for f77... no
checking for xlf... no
checking for frt... no
checking for pgf77... no
checking for fort77... no
checking for fl32... no
checking for af77... no
checking for f90... no
checking for xlf90... no
checking for pgf90... no
checking for epcf90... no
checking for f95... f95
checking whether we are using the GNU Fortran 77 compiler... yes
checking whether f95 accepts -g... yes
checking the maximum length of command line arguments... 32768
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for objdir... .libs
checking for ar... ar
checking for ranlib... ranlib
checking for strip... strip
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC
checking if gcc PIC flag -fPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
configure: creating libtool
appending configuration tag "CXX" to libtool
checking for ld used by g++... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC
checking if g++ PIC flag -fPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
appending configuration tag "F77" to libtool
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
checking for f95 option to produce PIC... -fPIC
checking if f95 PIC flag -fPIC works... yes
checking if f95 static flag -static works... yes
checking if f95 supports -c -o file.o... yes
checking whether the f95 linker (/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
./configure: line 19936: syntax error near unexpected token `&'
./configure: line 19936: `  test $fail = 1 &amp;&amp;'


hopefully this will give you idea regarding where the problem is....

Thanks

-- 
View this message in context: http://n2.nabble.com/send-receive-to-from-remote-machine-tp2507392p2532082.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.


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


Re: send/receive to/from remote machine

Posted by Gordon Sim <gs...@redhat.com>.
ft420 wrote:
> I am using RedHat 5. Please let me know what has to be done on RHEL5?

Sorry, I misread! On RHEL5 all you should require is ./bootstrap 
./configure and then make. Certainly that works for me.

I have never seen the error you reported and am at a lost to suggest 
what it might be I'm afraid.

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


Re: send/receive to/from remote machine

Posted by ft420 <ar...@gmail.com>.
I am using RedHat 5. Please let me know what has to be done on RHEL5?



ft420 wrote:
> Linux version 2.6.18-8.el5  RedHat 4.1.1-52

Ah, there is a special patch that needs to be applied for rhel4. You can 
get that (along with the README in the rhel4-support directory that is 
part of your checkout.

(Basically you need to first go into that directory and run make apply, 
then come back out and ./configure then make again).

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




-- 
View this message in context: http://n2.nabble.com/send-receive-to-from-remote-machine-tp2507392p2531021.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.


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


Re: send/receive to/from remote machine

Posted by Gordon Sim <gs...@redhat.com>.
ft420 wrote:
> Linux version 2.6.18-8.el5  RedHat 4.1.1-52

Ah, there is a special patch that needs to be applied for rhel4. You can 
get that (along with the README in the rhel4-support directory that is 
part of your checkout.

(Basically you need to first go into that directory and run make apply, 
then come back out and ./configure then make again).

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


Re: send/receive to/from remote machine

Posted by ft420 <ar...@gmail.com>.
Linux version 2.6.18-8.el5  RedHat 4.1.1-52


ft420 wrote:
> autoconf --version reports 2.59

Thats the same as mine, so shouldn't be a problem.

> platform being used is Linux.

Which distribution and version?

> _________________________________________________________________
> 
> what about 2 queuries ??
> 1. do we have to cancel the subscription always if yes or not why so? if not in all cases then in which all cases do we have to cancel the subscription? 

No, you don't have to cancel the subscription, but then the broker may 
be sending you messages after you've stopped being interested in them.

> 2. I was trying to send/recv  messages continuously from producer/listener respectively but after few seconds the system hangs... is it because of accept overhead that is required after every message? 

Get pstack traces for the producer and listener, that will help diagnose 
the issue here. This is certainly not simply due to sending accepts.

If you have test code you could create a Jira and attach it there.



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




-- 
View this message in context: http://n2.nabble.com/send-receive-to-from-remote-machine-tp2507392p2527128.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.


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


Re: send/receive to/from remote machine

Posted by Gordon Sim <gs...@redhat.com>.
ft420 wrote:
> autoconf --version reports 2.59

Thats the same as mine, so shouldn't be a problem.

> platform being used is Linux.

Which distribution and version?

> _________________________________________________________________
> 
> what about 2 queuries ??
> 1. do we have to cancel the subscription always if yes or not why so? if not in all cases then in which all cases do we have to cancel the subscription? 

No, you don't have to cancel the subscription, but then the broker may 
be sending you messages after you've stopped being interested in them.

> 2. I was trying to send/recv  messages continuously from producer/listener respectively but after few seconds the system hangs... is it because of accept overhead that is required after every message? 

Get pstack traces for the producer and listener, that will help diagnose 
the issue here. This is certainly not simply due to sending accepts.

If you have test code you could create a Jira and attach it there.



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


Re: send/receive to/from remote machine

Posted by ft420 <ar...@gmail.com>.
autoconf --version reports 2.59
platform being used is Linux.
_________________________________________________________________

what about 2 queuries ??
1. do we have to cancel the subscription always if yes or not why so? if not in all cases then in which all cases do we have to cancel the subscription? 
2. I was trying to send/recv  messages continuously from producer/listener respectively but after few seconds the system hangs... is it because of accept overhead that is required after every message? 
what to do if i want continuous send/recv & good performance factor? 
________________________________________________________________________________

-- 
View this message in context: http://n2.nabble.com/send-receive-to-from-remote-machine-tp2507392p2526991.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.


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


Re: send/receive to/from remote machine

Posted by Gordon Sim <gs...@redhat.com>.
ft420 wrote:
> I did try following steps:
> ./bootstrap then
> ./configure which gives following error::
> ./configure: line 19936: syntax error near unexpected token `&'
> ./configure: line 19936: `  test $fail = 1 &amp;&amp;'

I don't actually know what that could be; it may be the version of 
autotools you have. What does autoconf --version report? And what 
platform are you building on?

Ideally there would be a source distribution for that module you could 
use but at present there isn't.



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


Re: send/receive to/from remote machine

Posted by ft420 <ar...@gmail.com>.
hi Gordon
Please solve this query also... 
I am waiting for your solution on this query....
Thanks


I did try following steps:
./bootstrap then
./configure which gives following error::
./configure: line 19936: syntax error near unexpected token `&'
./configure: line 19936: `  test $fail = 1 &amp;&amp;'

_________________________________________________________________________________________

i did following 
Subscription s = subscriptions.subscribe(local_queue, "my_local_queue"); //here subscriptions is SubscriptionManager object while local_queue is Localqueue object.. 
://reading messages
:
s.cancel();
this is working i.e. now its not throwing warning and closing down.. 
2 queuries 
1. do we have to cancel the subscription always if yes or not why so? if not in all cases then in which all cases do we have to cancel the subscription?
2. I was trying to send/recv  messages continuously from producer/listener respectively but after few seconds the system hangs... is it because of accept overhead that is required after every message? 
what to do if i want continuous send/recv & good performance factor?


-- 
View this message in context: http://n2.nabble.com/send-receive-to-from-remote-machine-tp2507392p2526807.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.


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


Re: send/receive to/from remote machine

Posted by ft420 <ar...@gmail.com>.
I did try following steps:
<br>./bootstrap then
<br>./configure which gives following error::
<br>./configure: line 19936: syntax error near unexpected token `&'
<br>./configure: line 19936: ` &nbsp;test $fail = 1 &amp;&amp;'
<br><br>_________________________________________________________________________________________
<br><br>i did following 
<br>Subscription s = subscriptions.subscribe(local_queue, &quot;my_local_queue&quot;); //here subscriptions is SubscriptionManager object while local_queue is Localqueue object.. 
<br>://reading messages
<br>:
<br>s.cancel();
<br>this is working i.e. now its not throwing warning and closing down.. 
<br>2 queuries 
<br>1. do we have to cancel the subscription always if yes or not why so? if not in all cases then in which all cases do we have to cancel the subscription?
<br>2. I was trying to send/recv &nbsp;messages continuously from producer/listener respectively but after few seconds the system hangs... is it because of accept overhead that is required after every message? 
<br>what to do if i want continuous send/recv & good performance factor?
-- 
View this message in context: http://n2.nabble.com/send-receive-to-from-remote-machine-tp2507392p2524835.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.


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


Re: send/receive to/from remote machine

Posted by Carl Trieloff <cc...@redhat.com>.
Aidan Skinner wrote:
> On Mon, Mar 23, 2009 at 12:09 PM, Gordon Sim <gs...@redhat.com> wrote:
>   
>> ft420 wrote:
>>     
>>> do you mean without persistence plugin creating durable queue is not
>>> possible?
>>>       
>> No, unfortunately not. We do want a plugin that can be part of Qpid but it
>> would have to rely only on ASF compatible libraries and no-one has yet had
>> time to create one. Would be a great project for anyone looking for
>> something to do :-)
>>     
>
> It's probably worth putting this up as a GSoC idea.

There is only a small piece of code in that code base that still uses 
DBD, to store the exchange, queue and binding definitions
so if that where removed it could be licensed ASL.

Carl.

Re: send/receive to/from remote machine

Posted by Aidan Skinner <ai...@apache.org>.
On Mon, Mar 23, 2009 at 12:09 PM, Gordon Sim <gs...@redhat.com> wrote:
> ft420 wrote:
>>
>> do you mean without persistence plugin creating durable queue is not
>> possible?
>
> No, unfortunately not. We do want a plugin that can be part of Qpid but it
> would have to rely only on ASF compatible libraries and no-one has yet had
> time to create one. Would be a great project for anyone looking for
> something to do :-)

It's probably worth putting this up as a GSoC idea.

- Aidan
-- 
Apache Qpid - World Domination through Advanced Message Queueing
http://qpid.apache.org

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


Re: send/receive to/from remote machine

Posted by Gordon Sim <gs...@redhat.com>.
ft420 wrote:
> do you mean without persistence plugin creating durable queue is not
> possible?

No, unfortunately not. We do want a plugin that can be part of Qpid but 
it would have to rely only on ASF compatible libraries and no-one has 
yet had time to create one. Would be a great project for anyone looking 
for something to do :-)

> what to do with the files at the link you have mentioned in your
> earlier post?

Checkout from svn and then if you have Qpid installed just run 
./bootstrap && ./configure && make and it will build a msgstore.so in 
lib/.libs which you can then load using the --load-module option for qpidd.

> i did save all the files in store folder following the same directory
> structure as at the link..
> 
> One more problem: 
> I modified the producer in /example/direct to send messages continuosly.
> then modified the listener to get only 1000 messages synchronously. 
> i executed following::
> ./my_producer
> ./my_listener on cmd1 and ./my_listener on cmd2
> 
> Now listener throws following warning continuosly and close down:-
> warning Ignoring frame while closing connection: Frame [Bbe: channel=2:
> {MessageTrandferBody: destination=message_queue: accept-mode=0:
> acquire-mode=0: }]

Try canceling your subscription before closing.

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


Re: send/receive to/from remote machine

Posted by ft420 <ar...@gmail.com>.
do you mean without persistence plugin creating durable queue is not
possible? what to do with the files at the link you have mentioned in your
earlier post?
i did save all the files in store folder following the same directory
structure as at the link..

One more problem: 
I modified the producer in /example/direct to send messages continuosly.
then modified the listener to get only 1000 messages synchronously. 
i executed following::
./my_producer
./my_listener on cmd1 and ./my_listener on cmd2

Now listener throws following warning continuosly and close down:-
warning Ignoring frame while closing connection: Frame [Bbe: channel=2:
{MessageTrandferBody: destination=message_queue: accept-mode=0:
acquire-mode=0: }]

I was doing this test to check if i can get/send from/to same queue at same
time from different applications.

i did try out  browse/send from/to same queue at same time from separate
applications and this works...
Please help...
Thanks


Gordon Sim wrote:
> 
> ft420 wrote:
>> thanks a lot. I tried both PRE_ACQUIRED & NOT_ACQUIRED. Is there any
>> performance overhead involved in any of these 2 options?
> 
> I doubt either option is as fast as the common path (which is where most 
> optimisation has focused so far). I'd suggest trying it out to see if it 
> meets the performance requirements you have and let us know what you find.
> 
>> Also i wanted to know whether ACCEPT_MODE_EXPLICIT/ACCEPT_MODE_NONE has
>> any
>> performance overhead? 
> 
> Yes, there will be an overhead from accepting messages. However if you 
> do this at a wide enough interval (e.g. every 100 or so messages), it is 
> not that great (can't give you any precise figures though).
> 
>> Is there any document available that gives performance overheads of
>> options
>> that we use?
> 
> Not really. Again, probably the best things is to try out options for 
> your specific cases.
> 
>> I was trying to declare a durable queue. I did following:
>> :
>> :
>> session.queueDeclare(arg::queue="myqueue", arg::durable=true);
>> :
>> :
>> 
>> steps ::
>> ./qpidd -p 5004 --auth no
>> ./my_queue //declares the queues
>> ./my_producer // sends the messages to the queue
>> ./browse // browses the messages 
>> 
>> now i stop the broker i.e. ctrl+c on the cmd prompt where ./qpidd is
>> running 
>> start the broker again i.e. ./qpidd -p 5004  --auth no
>> ./browse //gives error Queue not found
> 
> Do you have a persistence plugin loaded? There is no such plugin yet 
> available as part of the qpid project, but there is one available from:
> 
> http://anonsvn.jboss.org/repos/rhmessaging/store/trunk/cpp/
> 
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
> 
> 
> 

-- 
View this message in context: http://n2.nabble.com/send-receive-to-from-remote-machine-tp2507392p2520669.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.


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


Re: send/receive to/from remote machine

Posted by Gordon Sim <gs...@redhat.com>.
ft420 wrote:
> thanks a lot. I tried both PRE_ACQUIRED & NOT_ACQUIRED. Is there any
> performance overhead involved in any of these 2 options?

I doubt either option is as fast as the common path (which is where most 
optimisation has focused so far). I'd suggest trying it out to see if it 
meets the performance requirements you have and let us know what you find.

> Also i wanted to know whether ACCEPT_MODE_EXPLICIT/ACCEPT_MODE_NONE has any
> performance overhead? 

Yes, there will be an overhead from accepting messages. However if you 
do this at a wide enough interval (e.g. every 100 or so messages), it is 
not that great (can't give you any precise figures though).

> Is there any document available that gives performance overheads of options
> that we use?

Not really. Again, probably the best things is to try out options for 
your specific cases.

> I was trying to declare a durable queue. I did following:
> :
> :
> session.queueDeclare(arg::queue="myqueue", arg::durable=true);
> :
> :
> 
> steps ::
> ./qpidd -p 5004 --auth no
> ./my_queue //declares the queues
> ./my_producer // sends the messages to the queue
> ./browse // browses the messages 
> 
> now i stop the broker i.e. ctrl+c on the cmd prompt where ./qpidd is running 
> start the broker again i.e. ./qpidd -p 5004  --auth no
> ./browse //gives error Queue not found

Do you have a persistence plugin loaded? There is no such plugin yet 
available as part of the qpid project, but there is one available from:

http://anonsvn.jboss.org/repos/rhmessaging/store/trunk/cpp/

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


Re: send/receive to/from remote machine

Posted by ft420 <ar...@gmail.com>.
thanks a lot. I tried both PRE_ACQUIRED & NOT_ACQUIRED. Is there any
performance overhead involved in any of these 2 options?
Also i wanted to know whether ACCEPT_MODE_EXPLICIT/ACCEPT_MODE_NONE has any
performance overhead? 
Is there any document available that gives performance overheads of options
that we use?

I was trying to declare a durable queue. I did following:
:
:
session.queueDeclare(arg::queue="myqueue", arg::durable=true);
:
:

steps ::
./qpidd -p 5004 --auth no
./my_queue //declares the queues
./my_producer // sends the messages to the queue
./browse // browses the messages 

now i stop the broker i.e. ctrl+c on the cmd prompt where ./qpidd is running 
start the broker again i.e. ./qpidd -p 5004  --auth no
./browse //gives error Queue not found

Please let me know if i m going wrong anywhere
Thanks


Gordon Sim wrote:
> 
> ft420 wrote:
>> I did following:
>> connection.open(host, port);
>> Session session = connection.newSession();
>>                         :
>>                         :
>>                         :
>> SubscriptionManager sub(session);
>> sub.setAcquireMode(ACQUIRE_MODE_PRE_ACQUIRED);
>> 
>> for (uint i = 0; i < queueMsgCnt; i++)
>> {
>>     sub.get(message, "myqueue");
>>     cout << "Message is " << message.getData() << endl;
>> }
>> 
>> But this get() call on SubscriptionManager object removes message from
>> queue
>> instead of just peeking/browsing it from queue.
> 
> Yes, I don't think I like the default acquire mode on the subscription 
> manager and certainly the get() method ignores it anyway.
> 
>> Please let me know where am i going wrong?? how to use
>> ACQUIRE_MODE_PRE_ACQUIRED for peeking/browsing messages??
> 
> Option 1: browsing using NOT_ACQUIRED
> 
> SubscriptionManager sub(session);
> SubscriptionSettings settings;
> settings.acquireMode = ACQUIRE_MODE_NOT_ACQUIRED;
> LocalQueue incoming;
> sub.subscribe(incoming, "myqueue", settings);
> ....
> for (uint i = 0; i < queueMsgCnt; i++)
> {
>      incoming.get(message);
>      cout << "Message is " << message.getData() << endl;
> }
> 
> Option 2: releasing PRE_ACQUIREd messages:
> 
> SubscriptionManager sub(session);
> SubscriptionSettings settings;
> settings.acquireMode = ACQUIRE_MODE_PRE_ACQUIRED;
> settings.autoAck = 0;
> LocalQueue incoming;
> Subscription s = sub.subscribe(incoming, "myqueue", settings);
> ....
> for (uint i = 0; i < queueMsgCnt; i++)
> {
>      incoming.get(message);
>      cout << "Message is " << message.getData() << endl;
> }
> s.cancel();
> s.release(s.getUnaccepted());//messages are left on the queue
> 
> (You can use a MessageListener instead of the LocalQueue if you prefer a 
> push style interface to the pull style above).
> 
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
> 
> 
> 

-- 
View this message in context: http://n2.nabble.com/send-receive-to-from-remote-machine-tp2507392p2519819.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.


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


Re: send/receive to/from remote machine

Posted by Gordon Sim <gs...@redhat.com>.
ft420 wrote:
> I did following:
> connection.open(host, port);
> Session session = connection.newSession();
>                         :
>                         :
>                         :
> SubscriptionManager sub(session);
> sub.setAcquireMode(ACQUIRE_MODE_PRE_ACQUIRED);
> 
> for (uint i = 0; i < queueMsgCnt; i++)
> {
>     sub.get(message, "myqueue");
>     cout << "Message is " << message.getData() << endl;
> }
> 
> But this get() call on SubscriptionManager object removes message from queue
> instead of just peeking/browsing it from queue.

Yes, I don't think I like the default acquire mode on the subscription 
manager and certainly the get() method ignores it anyway.

> Please let me know where am i going wrong?? how to use
> ACQUIRE_MODE_PRE_ACQUIRED for peeking/browsing messages??

Option 1: browsing using NOT_ACQUIRED

SubscriptionManager sub(session);
SubscriptionSettings settings;
settings.acquireMode = ACQUIRE_MODE_NOT_ACQUIRED;
LocalQueue incoming;
sub.subscribe(incoming, "myqueue", settings);
....
for (uint i = 0; i < queueMsgCnt; i++)
{
     incoming.get(message);
     cout << "Message is " << message.getData() << endl;
}

Option 2: releasing PRE_ACQUIREd messages:

SubscriptionManager sub(session);
SubscriptionSettings settings;
settings.acquireMode = ACQUIRE_MODE_PRE_ACQUIRED;
settings.autoAck = 0;
LocalQueue incoming;
Subscription s = sub.subscribe(incoming, "myqueue", settings);
....
for (uint i = 0; i < queueMsgCnt; i++)
{
     incoming.get(message);
     cout << "Message is " << message.getData() << endl;
}
s.cancel();
s.release(s.getUnaccepted());//messages are left on the queue

(You can use a MessageListener instead of the LocalQueue if you prefer a 
push style interface to the pull style above).

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


Re: send/receive to/from remote machine

Posted by ft420 <ar...@gmail.com>.
I did following:
connection.open(host, port);
Session session = connection.newSession();
                        :
                        :
                        :
SubscriptionManager sub(session);
sub.setAcquireMode(ACQUIRE_MODE_PRE_ACQUIRED);

for (uint i = 0; i < queueMsgCnt; i++)
{
    sub.get(message, "myqueue");
    cout << "Message is " << message.getData() << endl;
}

But this get() call on SubscriptionManager object removes message from queue
instead of just peeking/browsing it from queue.

Please let me know where am i going wrong?? how to use
ACQUIRE_MODE_PRE_ACQUIRED for peeking/browsing messages??

Thanks 


Gordon Sim wrote:
> 
> ft420 wrote:
>> Actually that will not solve my purpose as in my case same application
>> sends
>> out messages with different labels so i want specifically label
>> functionality only...
> 
> Thats ok, the producer can send messages with different routing keys 
> used for each. The routing key only dictates which consumers get the 
> different messages.
> 
> Perhaps I am misunderstanding your issue though.
> 
>> Also please tel me why are AppId, UserId, CorrelationId & MessageId
>> provided???
> 
> AppId is not terribly well defined but could be used to indicate the 
> 'application' for which the message was created,
> UserId can be used to indicate the original publishers identity,
> CorrelationId is often used to correlate requests to responses in a two 
> way conversation,
> MessageId is simply a unique identifier for a message.
> 
>> what about Peek functionality in qpid? my application requires that i
>> just
>> want to read the data from queue without deleting it from the queue. just
>> as
>> peek in MSMQ... getDate() returns then data in queue but also at the same
>> time removes it from the queue...
> 
> Yes you can create a subscriber with ACQUIRE_MODE_NOT_ACQUIRED and the 
> message will be available for other subscribers. You could also use 
> ACQUIRE_MODE_PRE_ACQUIRED which essentially 'locks' the message and then 
> simply release the message making it available again.
> 
> 
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
> 
> 
> 

-- 
View this message in context: http://n2.nabble.com/send-receive-to-from-remote-machine-tp2507392p2509299.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.


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


Re: send/receive to/from remote machine

Posted by Gordon Sim <gs...@redhat.com>.
ft420 wrote:
> Actually that will not solve my purpose as in my case same application sends
> out messages with different labels so i want specifically label
> functionality only...

Thats ok, the producer can send messages with different routing keys 
used for each. The routing key only dictates which consumers get the 
different messages.

Perhaps I am misunderstanding your issue though.

> Also please tel me why are AppId, UserId, CorrelationId & MessageId
> provided???

AppId is not terribly well defined but could be used to indicate the 
'application' for which the message was created,
UserId can be used to indicate the original publishers identity,
CorrelationId is often used to correlate requests to responses in a two 
way conversation,
MessageId is simply a unique identifier for a message.

> what about Peek functionality in qpid? my application requires that i just
> want to read the data from queue without deleting it from the queue. just as
> peek in MSMQ... getDate() returns then data in queue but also at the same
> time removes it from the queue...

Yes you can create a subscriber with ACQUIRE_MODE_NOT_ACQUIRED and the 
message will be available for other subscribers. You could also use 
ACQUIRE_MODE_PRE_ACQUIRED which essentially 'locks' the message and then 
simply release the message making it available again.


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


Re: send/receive to/from remote machine

Posted by ft420 <ar...@gmail.com>.
Actually that will not solve my purpose as in my case same application sends
out messages with different labels so i want specifically label
functionality only...
Also please tel me why are AppId, UserId, CorrelationId & MessageId
provided???
what about Peek functionality in qpid? my application requires that i just
want to read the data from queue without deleting it from the queue. just as
peek in MSMQ... getDate() returns then data in queue but also at the same
time removes it from the queue...




Gordon Sim wrote:
> 
> ft420 wrote:
>> okie so you mean if i want to get messages on basis on its label say only
>> messages with HELLO label will be received else all will be discarded
>> then
>> on sender side i need to set 
>> message.getHeader().setString("Label", "HELLO"); 
>> 
>> and 
>> on receiver side 
>> put output of message.getHeader().getString("Label") in conditional
> 
> If you simply want to route messages based on some fixed labeling, you 
> can use the routing key.
> 
> E.g. on sender side published message will have the routing key set to 
> HELLO:
> 
> message.getDeliveryProperties().setRoutingkey("HELLO");
> 
> and on the receiver:
> 
> session.queueDeclare(arg::queue="my-queue",
>                       arg::exclusive=true,
>                       arg::autoDelete=true);
> 
> session.exchangeBind(arg::exchange="amq.direct",
>                       arg::queue="my-queue",
>                       arg::bindingKey="HELLO");
> 
> and then subscribe a listener to my-queue and you will receive any 
> messages published with routing-key == HELLO.
> 
> (If you want the queue to remain after the consuming client exits, 
> remove the exclusive and autoDelete arguments in the queue declare).
> 
> You might also like to have a look at the some of the examples for other 
> patterns of use.
> 
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
> 
> 
> 

-- 
View this message in context: http://n2.nabble.com/send-receive-to-from-remote-machine-tp2507392p2508233.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.


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


Re: send/receive to/from remote machine

Posted by Gordon Sim <gs...@redhat.com>.
ft420 wrote:
> okie so you mean if i want to get messages on basis on its label say only
> messages with HELLO label will be received else all will be discarded then
> on sender side i need to set 
> message.getHeader().setString("Label", "HELLO"); 
> 
> and 
> on receiver side 
> put output of message.getHeader().getString("Label") in conditional

If you simply want to route messages based on some fixed labeling, you 
can use the routing key.

E.g. on sender side published message will have the routing key set to 
HELLO:

message.getDeliveryProperties().setRoutingkey("HELLO");

and on the receiver:

session.queueDeclare(arg::queue="my-queue",
                      arg::exclusive=true,
                      arg::autoDelete=true);

session.exchangeBind(arg::exchange="amq.direct",
                      arg::queue="my-queue",
                      arg::bindingKey="HELLO");

and then subscribe a listener to my-queue and you will receive any 
messages published with routing-key == HELLO.

(If you want the queue to remain after the consuming client exits, 
remove the exclusive and autoDelete arguments in the queue declare).

You might also like to have a look at the some of the examples for other 
patterns of use.

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


Re: send/receive to/from remote machine

Posted by ft420 <ar...@gmail.com>.
okie so you mean if i want to get messages on basis on its label say only
messages with HELLO label will be received else all will be discarded then
on sender side i need to set 
message.getHeader().setString("Label", "HELLO"); 

and 
on receiver side 
put output of message.getHeader().getString("Label") in conditional
statement right??
then why is get/set AppiId, UserId, CorrelationId & MessageId provided? what
is their usage?

I was searching for peek functionality of MSMQ in qpid but could not get
it... does qpid provide peeking functionality of MSMQ by some other name?



Gordon Sim wrote:
> 
> ft420 wrote:
>> Is it possible to send/receive etc to/from remote machine as in MSMQ?
>> what is the procedure for the same?
>> 
>> While running the broker -p option allows me to listen on port other than
>> 5672 but if i want to change the ip also how to do the same as by default
>> it
>> takes 127.0.0.1 ip...
> 
> The broker will listen on all interfaces. All you then need to do is 
> specify the correct hostname/ip address and port in your client program.
> 
> If you look at the examples, they accept the host and port as the first 
> and second command line arguments.
> 
>> the client api documentation doesnot have explaination for the apis
>> provieded... for example i wanted Label feature hence i was checking
>> MessageProperties class there are quite a few options like MessageId,
>> AppId
>> etc but was unable to understand which option is actually equivalent to
>> Label option in MSMQ?? 
> 
> You can set any property in the application headers of the message as a 
> key-value pair.
> 
> E.g. for the c++ client:
> 
>    message.getHeaders().setString("Label","xyz");
> 
> or
> 
>    message.getHeaders().setInt("Label",973987528);
> 
> ---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:users-subscribe@qpid.apache.org
> 
> 
> 

-- 
View this message in context: http://n2.nabble.com/send-receive-to-from-remote-machine-tp2507392p2508049.html
Sent from the Apache Qpid users mailing list archive at Nabble.com.


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


Re: send/receive to/from remote machine

Posted by Gordon Sim <gs...@redhat.com>.
ft420 wrote:
> Is it possible to send/receive etc to/from remote machine as in MSMQ?
> what is the procedure for the same?
> 
> While running the broker -p option allows me to listen on port other than
> 5672 but if i want to change the ip also how to do the same as by default it
> takes 127.0.0.1 ip...

The broker will listen on all interfaces. All you then need to do is 
specify the correct hostname/ip address and port in your client program.

If you look at the examples, they accept the host and port as the first 
and second command line arguments.

> the client api documentation doesnot have explaination for the apis
> provieded... for example i wanted Label feature hence i was checking
> MessageProperties class there are quite a few options like MessageId, AppId
> etc but was unable to understand which option is actually equivalent to
> Label option in MSMQ?? 

You can set any property in the application headers of the message as a 
key-value pair.

E.g. for the c++ client:

   message.getHeaders().setString("Label","xyz");

or

   message.getHeaders().setInt("Label",973987528);

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