You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@qpid.apache.org by rg...@apache.org on 2007/02/06 12:45:20 UTC
svn commit: r504087 - in
/incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests:
client_test.cpp topic_listener.cpp topic_publisher.cpp topictest
Author: rgreig
Date: Tue Feb 6 03:45:19 2007
New Revision: 504087
URL: http://svn.apache.org/viewvc?view=rev&rev=504087
Log:
(Submitted by Rupert Smith) Added virtual hosts in order to run tests against Java broker.
Modified:
incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/client_test.cpp
incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/topic_listener.cpp
incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/topic_publisher.cpp
incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/topictest
Modified: incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/client_test.cpp
URL: http://svn.apache.org/viewvc/incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/client_test.cpp?view=diff&rev=504087&r1=504086&r2=504087
==============================================================================
--- incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/client_test.cpp (original)
+++ incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/client_test.cpp Tue Feb 6 03:45:19 2007
@@ -68,7 +68,7 @@
Connection con(argc > 1);
string host("localhost");
- con.open(host);
+ con.open(host, 5672, "guest", "guest", "/test");
std::cout << "Opened connection." << std::endl;
//Create and open a channel on the connection through which
Modified: incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/topic_listener.cpp
URL: http://svn.apache.org/viewvc/incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/topic_listener.cpp?view=diff&rev=504087&r1=504086&r2=504087
==============================================================================
--- incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/topic_listener.cpp (original)
+++ incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/topic_listener.cpp Tue Feb 6 03:45:19 2007
@@ -103,7 +103,7 @@
}else{
try{
Connection connection(args.getTrace());
- connection.open(args.getHost(), args.getPort());
+ connection.open(args.getHost(), args.getPort(), "guest", "guest", "/test");
Channel channel(args.getTransactional(), args.getPrefetch());
connection.openChannel(&channel);
Modified: incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/topic_publisher.cpp
URL: http://svn.apache.org/viewvc/incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/topic_publisher.cpp?view=diff&rev=504087&r1=504086&r2=504087
==============================================================================
--- incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/topic_publisher.cpp (original)
+++ incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/topic_publisher.cpp Tue Feb 6 03:45:19 2007
@@ -118,7 +118,7 @@
}else{
try{
Connection connection(args.getTrace());
- connection.open(args.getHost(), args.getPort());
+ connection.open(args.getHost(), args.getPort(), "guest", "guest", "/test");
Channel channel(args.getTransactional(), args.getPrefetch());
connection.openChannel(&channel);
Modified: incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/topictest
URL: http://svn.apache.org/viewvc/incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/topictest?view=diff&rev=504087&r1=504086&r2=504087
==============================================================================
--- incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/topictest (original)
+++ incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/topictest Tue Feb 6 03:45:19 2007
@@ -1,42 +1,42 @@
-#!/bin/bash
-# Run the c++ or java topic test
-
-. `dirname $0`/env
-
-# Edit parameters here:
-
-# Big test:
-# LISTENERS=10
-# MESSAGES=10000
-# BATCHES=20
-
-LISTENERS=10
-MESSAGES=2000
-BATCHES=10
-
-cppcmds() {
- LISTEN_CMD=topic_listener
- PUBLISH_CMD="topic_publisher -messages $MESSAGES -batches $BATCHES -subscribers $LISTENERS"
-}
-
-javacmds() {
- DEF=-Damqj.logging.level="error"
- LISTEN_CMD="qpid-run $DEF org.apache.qpid.topic.Listener"
- PUBLISH_CMD="qpid-run $DEF org.apache.qpid.topic.Publisher -messages $MESSAGES -batch $BATCHES -clients $LISTENERS"
-}
-
-case $1 in
- c) cppcmds ;;
- j) javacmds ;;
- *) cppcmds ;;
-esac
-
-for ((i=$LISTENERS ; i--; )); do
- $LISTEN_CMD > /dev/null 2>&1 &
-done
-sleep 1
-echo $PUBLISH_CMD $OPTIONS
-
-STATS=~/bin/topictest.times
-echo "---- topictest `date`" >> $STATS
-$PUBLISH_CMD $OPTIONS | tee -a $STATS
+#!/bin/bash
+# Run the c++ or java topic test
+
+. `dirname $0`/env
+
+# Edit parameters here:
+
+# Big test:
+# LISTENERS=10
+# MESSAGES=10000
+# BATCHES=20
+
+LISTENERS=10
+MESSAGES=2000
+BATCHES=10
+
+cppcmds() {
+ LISTEN_CMD=./topic_listener
+ PUBLISH_CMD="./topic_publisher -messages $MESSAGES -batches $BATCHES -subscribers $LISTENERS"
+}
+
+javacmds() {
+ DEF=-Damqj.logging.level="error"
+ LISTEN_CMD="qpid-run $DEF org.apache.qpid.topic.Listener"
+ PUBLISH_CMD="qpid-run $DEF org.apache.qpid.topic.Publisher -messages $MESSAGES -batch $BATCHES -clients $LISTENERS"
+}
+
+case $1 in
+ c) cppcmds ;;
+ j) javacmds ;;
+ *) cppcmds ;;
+esac
+
+for ((i=$LISTENERS ; i--; )); do
+ $LISTEN_CMD > /dev/null 2>&1 &
+done
+sleep 1
+echo $PUBLISH_CMD $OPTIONS
+
+STATS=~/bin/topictest.times
+echo "---- topictest `date`" >> $STATS
+$PUBLISH_CMD $OPTIONS | tee -a $STATS
Re: svn commit: r504087 - in /incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests: client_test.cpp topic_listener.cpp topic_publisher.cpp topictest
Posted by Rupert Smith <ru...@googlemail.com>.
The perils of cygwin. Will correct line ends.
On 2/6/07, Gordon Sim <gs...@redhat.com> wrote:
>
> rgreig@apache.org wrote:
> > Author: rgreig
> > Date: Tue Feb 6 03:45:19 2007
> > New Revision: 504087
> >
> > URL: http://svn.apache.org/viewvc?view=rev&rev=504087
> > Log:
> > (Submitted by Rupert Smith) Added virtual hosts in order to run tests
> against Java broker.
> >
> > Modified:
> >
> incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/client_test.cpp
> >
> incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/topic_listener.cpp
> >
> incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/topic_publisher.cpp
> >
> incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/topictest
>
> I think we should have a default virtual host, that is always available
> regardless of config (AMQP used to specify one I think, but no longer
> does). That way the simple case works without messing around with
> virtual host setup and makes the tests easier to use against different
> brokers. We could additionally make the vhost settable from the command
> line if necessary.
>
> All we need to agree is what the default is and we can the change the
> c++ client to use that instead of '/'.
>
> BTW, the topictest script seems to have been committed back in DOS
> format (presumably a result of an erroneous eol style property, I guess
> we want to set LF on this or at least native?).
>
Re: svn commit: r504087 - in /incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests: client_test.cpp topic_listener.cpp topic_publisher.cpp topictest
Posted by Robert Godfrey <ro...@gmail.com>.
Note - for the InVM tests it doesn't use the config file, but a hardcoded
config which only has the virtualhost "test" defined.
Whe I did the virtualhost changes I tried to change all the "testpath"s to
"test"s, at least in the tests that were run by Maven. I apologize that I
almost certainly missed out the examples.
-- Rob
Re: svn commit: r504087 - in /incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests: client_test.cpp topic_listener.cpp topic_publisher.cpp topictest
Posted by Bhupendra Bhardwaj <bh...@gmail.com>.
"test" is more intutive.
Regards,
Bhupendra
On 2/6/07, Marnie McCormack <ma...@googlemail.com> wrote:
>
> I think we'd need to define a default though ? There are three vh's in the
> java broker cfg at the moment.
>
> M
>
>
> On 2/6/07, Gordon Sim <gs...@redhat.com> wrote:
> >
> > Marnie McCormack wrote:
> > > I think some of the java test classes use 'testpath' for virtual host
> > and
> > > existing examples/docs use that one too.
> > >
> > > However, we currently have a virtual host called 'test' defined in the
> > > config.xml.
> > >
> > > I don't have a strong opinion about which we use - but let's pick one.
> >
> > How about the using the empty string? i.e. if no virtual host is
> > specified, use the default. That would make things easier and more
> > intuitive 'out-of-the-box' in my opinion.
> >
>
RE: Default virtual host (was Re: svn commit: r504087)
Posted by Tomas Restrepo <to...@devdeo.com>.
Robert,
> To be completely clear, for the "default" virtual host, are we talking
> about
>
> i) A virtual host with name "", completely separate from all other virtual
> hosts
>
> or
>
> ii) A mapping from one of the specified named virtual hosts to the default
> "" name (i.e. the same virtaul host is addressed by multiple names).
>
> Option i) is anaologous to the default exchange I think. Option ii) is
> more
> like what you expect in Apache HTTPD type config (where you can map many
> names to the same virtual host).
>
> I prefer ii) but i) is more "AMQP" ...
>From a pragmatic point of view, either option would appear exactly the same
to the client in general terms (I think), so it really could be something
decided by the implementation (and not necessarily explicitly defined by the
spec).
That said, I personally prefer option ii) as well, because if there ever
comes a time where more stuff is attached to the virtual host than just a
name, it would be simpler to support, I think.
Tomas Restrepo
tomas.restrepo@devdeo.com
http://www.winterdom.com/weblog/
Re: Default virtual host (was Re: svn commit: r504087)
Posted by Marnie McCormack <ma...@googlemail.com>.
I agree - the vh is incidental to the queues-at-broker-startup definition.
It's just the only thing I know of where users really 'see' vhs apart from
connection urls :-)
M
On 2/8/07, Gordon Sim <gs...@redhat.com> wrote:
>
> Marnie McCormack wrote:
> > I guess it boils down to how users will utilise the virtual hosts. At
> > present, the only *really* useful feature around virtual hosts (afaik)
> is
> > the ability to create queues/topics to be created on broker startup -
> the
> > real purpose of virtualhosts.xml on the java broker side.
>
> That's not really a feature of virtual hosts per se though is it? The
> only thing they bring is effectively separate namespaces for queues and
> exchanges so an exchange in one virtual host with a given name is a
> different instance from an exchange with the same name in another
> virtual host.
>
> > I just thought that an empty string is a little confusing in terms of a
> > 'name' for a virtual host. Would be nicer imho to mark a defined vh as
> > default in the config.xml and use that where no vh specified on the
> > connection url ?
>
> That would be fine with me. As Tomas pointed out there will not be a
> great deal of difference between the two options from a clients
> perspective. The only issue is that a client using the default virtual
> host by name and a client not specifying one are actually sharing the
> namespace. I don't think that is a big problem myself.
>
Re: Default virtual host (was Re: svn commit: r504087)
Posted by Gordon Sim <gs...@redhat.com>.
Marnie McCormack wrote:
> I guess it boils down to how users will utilise the virtual hosts. At
> present, the only *really* useful feature around virtual hosts (afaik) is
> the ability to create queues/topics to be created on broker startup - the
> real purpose of virtualhosts.xml on the java broker side.
That's not really a feature of virtual hosts per se though is it? The
only thing they bring is effectively separate namespaces for queues and
exchanges so an exchange in one virtual host with a given name is a
different instance from an exchange with the same name in another
virtual host.
> I just thought that an empty string is a little confusing in terms of a
> 'name' for a virtual host. Would be nicer imho to mark a defined vh as
> default in the config.xml and use that where no vh specified on the
> connection url ?
That would be fine with me. As Tomas pointed out there will not be a
great deal of difference between the two options from a clients
perspective. The only issue is that a client using the default virtual
host by name and a client not specifying one are actually sharing the
namespace. I don't think that is a big problem myself.
Re: Default virtual host (was Re: svn commit: r504087)
Posted by Robert Greig <ro...@gmail.com>.
On 08/02/07, Marnie McCormack <ma...@googlemail.com> wrote:
> I just thought that an empty string is a little confusing in terms of a
> 'name' for a virtual host. Would be nicer imho to mark a defined vh as
> default in the config.xml and use that where no vh specified on the
> connection url ?
I think that is the best approach, and it fits with the web server
analogy (for what that's worth).
RG
Re: Default virtual host (was Re: svn commit: r504087)
Posted by Marnie McCormack <ma...@googlemail.com>.
I guess it boils down to how users will utilise the virtual hosts. At
present, the only *really* useful feature around virtual hosts (afaik) is
the ability to create queues/topics to be created on broker startup - the
real purpose of virtualhosts.xml on the java broker side.
I just thought that an empty string is a little confusing in terms of a
'name' for a virtual host. Would be nicer imho to mark a defined vh as
default in the config.xml and use that where no vh specified on the
connection url ?
Marnie
On 2/6/07, Robert Godfrey <ro...@gmail.com> wrote:
>
> > From a pragmatic point of view, either option would appear exactly the
> > same
> > to the client in general terms (I think), so it really could be
> something
> > decided by the implementation (and not necessarily explicitly defined by
> > the
> > spec).
>
>
>
> As long as all clients were set up the same way... if some were using ""
> and
> some were using <actualname>, then obviously the beviour would be
> different
> in the two cases.
>
> That said, I personally prefer option ii) as well, because if there ever
> > comes a time where more stuff is attached to the virtual host than just
> a
> > name, it would be simpler to support, I think.
>
>
>
> I think the issue is that the whole purpose of virtual hosts is somewhat
> unclear. I think the general idea is to be along the same lines as
> virtual
> hosts in an http server, so the virtual host might well be seen as
> something
> like the dns name or ip address + port that the client knows the server as
> (before proxying etc). In that case there is very likely the case where
> you
> want to map many names to a single virtual host... however in this
> scenario
> you would very definitely also want the client to be populating the
> virtual
> hosts parameter on every connection open.
>
> -- Rob
>
Re: Default virtual host (was Re: svn commit: r504087)
Posted by Robert Godfrey <ro...@gmail.com>.
> From a pragmatic point of view, either option would appear exactly the
> same
> to the client in general terms (I think), so it really could be something
> decided by the implementation (and not necessarily explicitly defined by
> the
> spec).
As long as all clients were set up the same way... if some were using "" and
some were using <actualname>, then obviously the beviour would be different
in the two cases.
That said, I personally prefer option ii) as well, because if there ever
> comes a time where more stuff is attached to the virtual host than just a
> name, it would be simpler to support, I think.
I think the issue is that the whole purpose of virtual hosts is somewhat
unclear. I think the general idea is to be along the same lines as virtual
hosts in an http server, so the virtual host might well be seen as something
like the dns name or ip address + port that the client knows the server as
(before proxying etc). In that case there is very likely the case where you
want to map many names to a single virtual host... however in this scenario
you would very definitely also want the client to be populating the virtual
hosts parameter on every connection open.
-- Rob
Re: Default virtual host (was Re: svn commit: r504087)
Posted by Robert Godfrey <ro...@gmail.com>.
Yes - I agree... empty string is better. Indeed I would go so far as to say
the spec should be changed to remove the need for a leading forward-slash in
a virtual host name (it is just a wasted-byte!). Banning forward slashes
altogether from the name would be even better :-)
To be completely clear, for the "default" virtual host, are we talking about
i) A virtual host with name "", completely separate from all other virtual
hosts
or
ii) A mapping from one of the specified named virtual hosts to the default
"" name (i.e. the same virtaul host is addressed by multiple names).
Option i) is anaologous to the default exchange I think. Option ii) is more
like what you expect in Apache HTTPD type config (where you can map many
names to the same virtual host).
I prefer ii) but i) is more "AMQP" ...
- Rob
On 06/02/07, Gordon Sim <gs...@redhat.com> wrote:
>
> Alan Conway wrote:
> > I'll JIRA for the C++ client to default to the empty string, unless
> > someone knows why "/" is a reasonable default for a virtual host name.
>
> Once upon a time the AMQP spec stated that all virtual hosts had to
> start with a '/' and that all brokers should support '/' (the default)
> and '/sandbox' (for conformance testing!).
>
> That is by way of background explanation only and is no longer the case.
> I agree that the empty string is better.
>
Re: Default virtual host (was Re: svn commit: r504087)
Posted by Gordon Sim <gs...@redhat.com>.
Alan Conway wrote:
> I'll JIRA for the C++ client to default to the empty string, unless
> someone knows why "/" is a reasonable default for a virtual host name.
Once upon a time the AMQP spec stated that all virtual hosts had to
start with a '/' and that all brokers should support '/' (the default)
and '/sandbox' (for conformance testing!).
That is by way of background explanation only and is no longer the case.
I agree that the empty string is better.
Re: Default virtual host (was Re: svn commit: r504087)
Posted by Alan Conway <ac...@redhat.com>.
On Tue, 2007-02-06 at 17:35 +0000, Gordon Sim wrote:
> Tomas Restrepo wrote:
> > It sounds to me like what people might want is to have the broker
> > configuration specify which of the configured virtual hosts will be the
> > default. That way, if the client doesn't specify a virtual host during
> > connection, it gets attached to whatever was configured as the default host.
> > No?
>
> That sounds like a good idea to me. From an interoperability pov I just
> don't want to have to configure clients and brokers to explicitly use a
> specific virtual host even in cases where they don't need them. Using an
> empty string in the client when it doesn't care seems nice and easy.
That's consistent with the strategy for exchanges - there's the
"nameless" default exchange for publishes with an empty exchange name.
I'll JIRA for the C++ client to default to the empty string, unless
someone knows why "/" is a reasonable default for a virtual host name.
Re: Default virtual host (was Re: svn commit: r504087)
Posted by Gordon Sim <gs...@redhat.com>.
Tomas Restrepo wrote:
> It sounds to me like what people might want is to have the broker
> configuration specify which of the configured virtual hosts will be the
> default. That way, if the client doesn't specify a virtual host during
> connection, it gets attached to whatever was configured as the default host.
> No?
That sounds like a good idea to me. From an interoperability pov I just
don't want to have to configure clients and brokers to explicitly use a
specific virtual host even in cases where they don't need them. Using an
empty string in the client when it doesn't care seems nice and easy.
RE: Default virtual host (was Re: svn commit: r504087)
Posted by Tomas Restrepo <to...@devdeo.com>.
> Personally I think that's a little confusing, and I *think* we're using
the
> vh name in the env path for BDBStore and certainly for vh config in
> config.xml and virtualhosts.xml. We're providing three vhs in the default
> java broker config.
It sounds to me like what people might want is to have the broker
configuration specify which of the configured virtual hosts will be the
default. That way, if the client doesn't specify a virtual host during
connection, it gets attached to whatever was configured as the default host.
No?
Tomas Restrepo
tomas.restrepo@devdeo.com
http://www.winterdom.com/weblog/
Re: Default virtual host (was Re: svn commit: r504087)
Posted by Marnie McCormack <ma...@googlemail.com>.
Personally I think that's a little confusing, and I *think* we're using the
vh name in the env path for BDBStore and certainly for vh config in
config.xml and virtualhosts.xml. We're providing three vhs in the default
java broker config.
Unless I've misunderstood what you mean ?
M
On 2/6/07, Gordon Sim <gs...@redhat.com> wrote:
>
> Marnie McCormack wrote:
> > I think we'd need to define a default though ? There are three vh's in
> the
> > java broker cfg at the moment.
>
> Can the default not be the empty string?
>
Default virtual host (was Re: svn commit: r504087)
Posted by Gordon Sim <gs...@redhat.com>.
Marnie McCormack wrote:
> I think we'd need to define a default though ? There are three vh's in the
> java broker cfg at the moment.
Can the default not be the empty string?
Re: svn commit: r504087 - in /incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests: client_test.cpp topic_listener.cpp topic_publisher.cpp topictest
Posted by Marnie McCormack <ma...@googlemail.com>.
I think we'd need to define a default though ? There are three vh's in the
java broker cfg at the moment.
M
On 2/6/07, Gordon Sim <gs...@redhat.com> wrote:
>
> Marnie McCormack wrote:
> > I think some of the java test classes use 'testpath' for virtual host
> and
> > existing examples/docs use that one too.
> >
> > However, we currently have a virtual host called 'test' defined in the
> > config.xml.
> >
> > I don't have a strong opinion about which we use - but let's pick one.
>
> How about the using the empty string? i.e. if no virtual host is
> specified, use the default. That would make things easier and more
> intuitive 'out-of-the-box' in my opinion.
>
Re: svn commit: r504087 - in /incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests:
client_test.cpp topic_listener.cpp topic_publisher.cpp topictest
Posted by Gordon Sim <gs...@redhat.com>.
Marnie McCormack wrote:
> I think some of the java test classes use 'testpath' for virtual host and
> existing examples/docs use that one too.
>
> However, we currently have a virtual host called 'test' defined in the
> config.xml.
>
> I don't have a strong opinion about which we use - but let's pick one.
How about the using the empty string? i.e. if no virtual host is
specified, use the default. That would make things easier and more
intuitive 'out-of-the-box' in my opinion.
Re: svn commit: r504087 - in /incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests: client_test.cpp topic_listener.cpp topic_publisher.cpp topictest
Posted by Marnie McCormack <ma...@googlemail.com>.
Hi,
I think some of the java test classes use 'testpath' for virtual host and
existing examples/docs use that one too.
However, we currently have a virtual host called 'test' defined in the
config.xml.
I don't have a strong opinion about which we use - but let's pick one.
Thoughts ?
Thanks,
Marnie
On 2/6/07, Gordon Sim <gs...@redhat.com> wrote:
>
> rgreig@apache.org wrote:
> > Author: rgreig
> > Date: Tue Feb 6 03:45:19 2007
> > New Revision: 504087
> >
> > URL: http://svn.apache.org/viewvc?view=rev&rev=504087
> > Log:
> > (Submitted by Rupert Smith) Added virtual hosts in order to run tests
> against Java broker.
> >
> > Modified:
> >
> incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/client_test.cpp
> >
> incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/topic_listener.cpp
> >
> incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/topic_publisher.cpp
> >
> incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/topictest
>
> I think we should have a default virtual host, that is always available
> regardless of config (AMQP used to specify one I think, but no longer
> does). That way the simple case works without messing around with
> virtual host setup and makes the tests easier to use against different
> brokers. We could additionally make the vhost settable from the command
> line if necessary.
>
> All we need to agree is what the default is and we can the change the
> c++ client to use that instead of '/'.
>
> BTW, the topictest script seems to have been committed back in DOS
> format (presumably a result of an erroneous eol style property, I guess
> we want to set LF on this or at least native?).
>
Re: svn commit: r504087 - in /incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests:
client_test.cpp topic_listener.cpp topic_publisher.cpp topictest
Posted by Gordon Sim <gs...@redhat.com>.
rgreig@apache.org wrote:
> Author: rgreig
> Date: Tue Feb 6 03:45:19 2007
> New Revision: 504087
>
> URL: http://svn.apache.org/viewvc?view=rev&rev=504087
> Log:
> (Submitted by Rupert Smith) Added virtual hosts in order to run tests against Java broker.
>
> Modified:
> incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/client_test.cpp
> incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/topic_listener.cpp
> incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/topic_publisher.cpp
> incubator/qpid/branches/perftesting_persistent/qpid/cpp/tests/topictest
I think we should have a default virtual host, that is always available
regardless of config (AMQP used to specify one I think, but no longer
does). That way the simple case works without messing around with
virtual host setup and makes the tests easier to use against different
brokers. We could additionally make the vhost settable from the command
line if necessary.
All we need to agree is what the default is and we can the change the
c++ client to use that instead of '/'.
BTW, the topictest script seems to have been committed back in DOS
format (presumably a result of an erroneous eol style property, I guess
we want to set LF on this or at least native?).