"bela" wrote :
|
| 10Mpbs ? You're going to get 1MB/sec throughput max.
|
| If you run only on the local box, set UDP.bind_addr to 127.0.0.1, to circumvent
the NIC entirely. Also add a multicast route that actually points to your loopback
device.
| I suggest you take the NIC down for
Hi Bela,
Thanks for your quick reply
I started with SLJMS. Could run the examples. InteractiveJMSClient with
Producder/Subscriber.
But, I am not clear how to use it for my needs.
1. If I have 3 Java Progs running on 3 Different machines what they shud do to use
SLJMS and communicate with each
If performances degrades with the number of clients, and you're using multicast, my
first intuition would be that NAKACK does a lot of retransmission.
Bela, doesn't NAKACK have debugging statements that get triggered by retransmission?
You can enable debugging for NAKACK and see if this is the
anonymous wrote : NW - 10 mbit but the tests are just on my local machine
|
10Mpbs ? You're going to get 1MB/sec throughput max.
If you run only on the local box, set UDP.bind_addr to 127.0.0.1, to circumvent the
NIC entirely. Also add a multicast route that actually points to your loopba
"bela" wrote :
| I see. Maybe hold off a bit more, until Ovidiu has experimented with it some more;
he does have JGroups knowledge. So how important is the bare-bones stack to you right
now ? Can you live with fc-fast.xml for now (of course, after you get 1000 msgs/sec) ?
|
If I got 1000 m
"bela" wrote :
| Use of Serializable will probably be removed from MessageImpl (replaced by
Externalizable, if possible). Serialization will exert some penalty, but what numbers
did you get anyway for the pubsub test ? I'm also curious about HW/SW/JDK/NW.
|
Here are my numbers:
HW - Dell
anonymous wrote : If I add that then it complains of another dependency:
| ChannelException: JChannel(): java.lang.Exception: Configurator.sanityCheck():
event GET_DIGEST_STATE is required by STATE_TRANSFER, but not provided by any of the
layers below
I see. Maybe hold off a bit more, until O
anonymous wrote :
| class ObjectMessageImpl extends MessageImpl implements ObjectMessage, Serializable
{
Use of Serializable will probably be removed from MessageImpl (replaced by
Externalizable, if possible). Serialization will exert some penalty, but what numbers
did you get anyway for the
"bela" wrote : [
|
| Hmm, it takes a bit of experimenting with this. Ovidiu, do you want to do it ?
|
| Regarding state transfer: just add STATE_TRANSFER on top of your bare bones stack
(copy the tag from, say, fc-fast.xml).
|
|
If I add that then it complains of another depende
"bela" wrote : [
| I wasn't aware Ovidiu has added ObjectMsg support yet. Are you using serialization
or externalization ? You mentioned you have ca 1-2K worth of data/msg ?
| Bela
I implemented it myself just to get things running locally with my copy. There may be
a more optimal way of im
The protorype doesn't do any message acknowledgement at application level.
The stack is configured with pbcast.NAKACK.
Interesting.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3827450#3827450";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=repl
"ggimler" wrote : I just tried a quick test with just text messages with the
fc-fast.xml. Messages/second decrease with each subscriber. This seems
counter-intuitive to using multicast. It's behaving like TCP. Am I the only one
seeing this?
You should see almost no degradation. Maybe we'r
Yes, I'll do that (experimenting). I'll get back with conclusions.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3827439#3827439";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3827439>Reply
to the post
"ggimler" wrote : anonymous wrote :
| | Use the fc-fast protocol; I tested this on my home system, and got about 1600
msgs/sec.
| | fc-fast uses flow control, so it is very good when having *sustained* load
over an extended period of time. But I'm sure you could optimize even more if you
"ggimler" wrote : I tried the bare-bones.xml file for jgroups - it doesn't work for
sljms. I get the following:
|
| [java] WARN 10:18:16,964 [main] (Trace.java:387) - fetching state will fail as
state transfer is not supported. Add one of the STATE_TRANSFER protocols to your
protocol spe
It is counter-intuitive, indeed.
I'll try to do some more extensive tesing myself with both text and byte messages
today or maybe tomorrow and I'll get back to you.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3827424#3827424";>View
the original post
http://www.jboss.org/index.html
I just tried a quick test with just text messages with the fc-fast.xml.
Messages/second decrease with each subscriber. This seems counter-intuitive to using
multicast. It's behaving like TCP. Am I the only one seeing this?
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3827420#38
anonymous wrote :
| Use the fc-fast protocol; I tested this on my home system, and got about 1600
msgs/sec.
| fc-fast uses flow control, so it is very good when having *sustained* load over an
extended period of time. But I'm sure you could optimize even more if you know the
type of app (wh
I tried the bare-bones.xml file for jgroups - it doesn't work for sljms. I get the
following:
[java] WARN 10:18:16,964 [main] (Trace.java:387) - fetching state will fail as state
transfer is not supported. Add one of the STATE_TRANSFER protocols to your protocol
specification
http://www.jbo
Use the fc-fast protocol; I tested this on my home system, and got about 1600 msgs/sec.
fc-fast uses flow control, so it is very good when having *sustained* load over an
extended period of time. But I'm sure you could optimize even more if you know the
type of app (which you do).
Bela
http://w
"ggimler" wrote : I guess another way of posing my question would be. If I didn't
care about reliability and only about performance, how would I configure these
protocol stacks with the optimal configuration? What is the bare bones required?
There is a bare-bone.xml file in the JGroups distro,
"ggimler" wrote : If describing my data may help with optimizing the protocol stack...
|
| I'm primarily sending radar state information. Just for a rough estimate, I
serialized the objects to a file (I know this isn't the most accurate way of getting
the true size of the objects) but they
Are you experimenting just with hardware multicast or you bridge messages over to a
TCP-based group?
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3827313#3827313";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3827313>Reply
to the post
I have not bridged between protocol stacks yet. I was planning on doing so for
firewall traversal but haven't reached that point yet. I'd like to get some good
numbers with the closest thing to pure multicast right now and then move from there.
http://www.jboss.org/index.html?module=bb&op=view
If describing my data may help with optimizing the protocol stack...
I'm primarily sending radar state information. Just for a rough estimate, I
serialized the objects to a file (I know this isn't the most accurate way of getting
the true size of the objects) but they range from 1.3kb - 2.0kb s
I guess another way of posing my question would be. If I didn't care about
reliability and only about performance, how would I configure these protocol stacks
with the optimal configuration? What is the bare bones required?
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3827303#38273
sljms.xml is identical to default.xml from JGroup's conf directory. It is the standard
multicast stack JGroups comes with.
fc-fast.xml is a variation of the above, in that it enables bundling (UDP protocol
waits until it has a buffer full of data or a timer expires, and then sends data on
the
I implemented the ObjectMessage (simple enough) just so I could run some tests. Is it
possible to change the protocol stack for optimization and do the minimal
configuration to increase performance? Every time I take out a protol on the stack it
seems to complain. The JGroups documentation wa
It is trivial. Support for all JMS Message types will be added in the next release.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3827155#3827155";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3827155>Reply
to the post
--
It appears one can't send objects over the sljms implementation. Are there plans to
add this soon? I only see text messages right now. Is this something trivial to
implement?
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3827154#3827154";>View
the original post
http://www.jboss
Ovidiuf,
Thank you for the good documentation and the new version of the serverless JMS. I
am anxious to work with this new code base this week.
If I may inquire, I'd like to know if you would be willing to receive code
contributions? We can talk about this offline if that's appropriate?
The serverless jms release has also been made availble from the JBossMQ section of the
sourceforge JBoss project page:
http://sourceforge.net/project/showfiles.php?group_id=22866&package_id=26210&release_id=224938
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3826628#3826628";>View
Release 0.1.2 is available at:
http://www.feodorov.com/tmp/sljms-0.1.2.tar.gz
The master documentation file is doc/index.html
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3826617#3826617";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=38
A version that contains everything you need to experiment with your "relaying"
solution is ready to be released. I don't want to call it 0.2. Not that the name
matters, anyway, but 0.2 was supposed to include persistent delivery, and I am still
working on that.
I will post the URL on the forum
Will the new version 0.2 be released today or some time next week? Perhaps it's
already been released and I don't know where to look to get it?
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3826527#3826527";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting
Sounds great! I look forward to trying this out next week. If you could give me some
instructions on how/where to get the 0.2 when you release it, I would appreciate it.
Thanks.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825509#3825509";>View
the original post
http://www.jb
Your solution is in principle correct, and, oddly enough, almost possible to implement
with the current alpha release.
Basically, you'll have to write a "bridge client", that creates two connections to two
different serverless JMS providers. The first one runs over the multicast domain and
the
So let me ask you this...
Is it currently possible to send that JMS through a firewall? Can I send it multicast
and rebroadcast unicast and vice versa or is that impossible in the 0.2? Would there
be a significant development effort to do this?
Here's what I'm thinking and perhaps what I coul
The current implementation uses only one "control channel" per Connection. All
channels must be configured the same way (same stack configuration file) in order to
join the group. Control traffic and payload traffic share the channel.
A very sensible idea is to use a different channel or more, w
Is there some date in mind for releasing a non-beta version? I'm assuming 0.2 still
means in the beta stage? Thanks.
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825243#3825243";>View
the original post
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3825243>Repl
Thanks for the quick reply. What can I expect in this new implementation? Will true
hardware multicast be available with the JMS? When can I expect an officially stable
release?
Am I currently multicasting with that old version? Can I get some documentation?
http://www.jboss.org/index.ht
Don't use the old impl; Ovidiu is working on a new implementation. He will post a
first prototype in 1-2 weeks (I'm actually playing with it as we speak).
Bela
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3825004#3825004";>View
the original post
http://www.jboss.org/index.html?modu
Nevermind. Looks like the Synch client was what I wanted. However, I'm still
wondering if I'm using multicast or not. This GMS output with addresses not in the
multicast range lead me to believe I'm not multicasting. Is there some way to turn
this on in the jgroups configuration? Thanks.
h
43 matches
Mail list logo
