Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #20711 > unrolled thread

JMS vs Sockets -- bandwidth, size, speed, etc.

Back to article view | Back to comp.lang.java.programmer

Contents

  JMS vs Sockets -- bandwidth, size, speed, etc. me2 <winona_whitener@yahoo.com> - 2012-12-26 13:26 -0800
    Re: JMS vs Sockets -- bandwidth, size, speed, etc. Lew <lewbloch@gmail.com> - 2012-12-26 13:35 -0800
    Re: JMS vs Sockets -- bandwidth, size, speed, etc. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-26 19:00 -0500
      Re: JMS vs Sockets -- bandwidth, size, speed, etc. mcheung63@gmail.com - 2012-12-26 20:46 -0800
        Re: JMS vs Sockets -- bandwidth, size, speed, etc. Lew <lewbloch@gmail.com> - 2012-12-26 20:53 -0800
        Re: JMS vs Sockets -- bandwidth, size, speed, etc. Robert Klemme <shortcutter@googlemail.com> - 2012-12-27 14:45 +0100
        Re: JMS vs Sockets -- bandwidth, size, speed, etc. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-27 13:26 -0500
          Re: JMS vs Sockets -- bandwidth, size, speed, etc. Mark <i@dontgetlotsofspamanymore.invalid> - 2013-01-08 09:28 +0000
            Re: JMS vs Sockets -- bandwidth, size, speed, etc. Arne Vajhøj <arne@vajhoej.dk> - 2013-01-08 19:54 -0500
      Re: JMS vs Sockets -- bandwidth, size, speed, etc. Sven Köhler <remove-sven.koehler@gmail.com> - 2012-12-27 14:26 +0100
        Re: JMS vs Sockets -- bandwidth, size, speed, etc. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-27 13:18 -0500
          Re: JMS vs Sockets -- bandwidth, size, speed, etc. Sven Köhler <remove-sven.koehler@gmail.com> - 2012-12-27 19:47 +0100
            Re: JMS vs Sockets -- bandwidth, size, speed, etc. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-27 14:09 -0500
    Re: JMS vs Sockets -- bandwidth, size, speed, etc. Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2012-12-26 23:35 -0800
      Re: JMS vs Sockets -- bandwidth, size, speed, etc. Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-27 07:13 -0400
        Re: JMS vs Sockets -- bandwidth, size, speed, etc. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-27 13:25 -0500
        Re: JMS vs Sockets -- bandwidth, size, speed, etc. Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2012-12-28 00:59 -0800
          Re: JMS vs Sockets -- bandwidth, size, speed, etc. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-28 10:59 -0500
            Re: JMS vs Sockets -- bandwidth, size, speed, etc. Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2012-12-28 12:19 -0800
              Re: JMS vs Sockets -- bandwidth, size, speed, etc. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-28 23:46 -0500
                Re: JMS vs Sockets -- bandwidth, size, speed, etc. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-28 23:49 -0500
          Re: JMS vs Sockets -- bandwidth, size, speed, etc. Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-29 08:30 -0400
            Re: JMS vs Sockets -- bandwidth, size, speed, etc. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-29 20:31 -0500
              Re: JMS vs Sockets -- bandwidth, size, speed, etc. Joerg Meier <joergmmeier@arcor.de> - 2013-01-01 23:25 +0100
                Re: JMS vs Sockets -- bandwidth, size, speed, etc. "John B. Matthews" <nospam@nospam.invalid> - 2013-01-01 18:18 -0500
      Re: JMS vs Sockets -- bandwidth, size, speed, etc. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-27 13:22 -0500
    Re: JMS vs Sockets -- bandwidth, size, speed, etc. me2 <winona_whitener@yahoo.com> - 2012-12-28 07:25 -0800
      Re: JMS vs Sockets -- bandwidth, size, speed, etc. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-28 10:50 -0500
        Re: JMS vs Sockets -- bandwidth, size, speed, etc. me2 <winona_whitener@yahoo.com> - 2012-12-28 08:44 -0800
          Re: JMS vs Sockets -- bandwidth, size, speed, etc. Arne Vajhøj <arne@vajhoej.dk> - 2012-12-29 20:52 -0500
      Re: JMS vs Sockets -- bandwidth, size, speed, etc. Lew <lewbloch@gmail.com> - 2012-12-28 13:24 -0800
      Re: JMS vs Sockets -- bandwidth, size, speed, etc. Arved Sandstrom <asandstrom2@eastlink.ca> - 2012-12-29 08:48 -0400
    Re: JMS vs Sockets -- bandwidth, size, speed, etc. me 2 <winona_whitener@yahoo.com> - 2013-01-07 13:01 -0800
      Re: JMS vs Sockets -- bandwidth, size, speed, etc. Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2013-01-07 13:09 -0800
      Re: JMS vs Sockets -- bandwidth, size, speed, etc. Arne Vajhøj <arne@vajhoej.dk> - 2013-01-07 20:02 -0500
        Re: JMS vs Sockets -- bandwidth, size, speed, etc. Gene Wirchenko <genew@telus.net> - 2013-01-07 18:42 -0800
          Re: JMS vs Sockets -- bandwidth, size, speed, etc. Arne Vajhøj <arne@vajhoej.dk> - 2013-01-07 22:07 -0500
      Re: JMS vs Sockets -- bandwidth, size, speed, etc. Robert Klemme <shortcutter@googlemail.com> - 2013-01-08 00:00 -0800
      Re: JMS vs Sockets -- bandwidth, size, speed, etc. Roedy Green <see_website@mindprod.com.invalid> - 2013-01-11 01:07 -0800
        Re: JMS vs Sockets -- bandwidth, size, speed, etc. Lew <lewbloch@gmail.com> - 2013-01-11 11:04 -0800
        Re: JMS vs Sockets -- bandwidth, size, speed, etc. Arne Vajhøj <arne@vajhoej.dk> - 2013-01-11 20:09 -0500

Page 1 of 3  [1] 2 3  Next page →

#20711 — JMS vs Sockets -- bandwidth, size, speed, etc.

Greetings,

I am a newbie to JMS and would appreciate some advice.

Has anyone compared JMS to socket programming?  If I have N number of clients that need to connect to and send messages to 1 server, what is the comparison?  I would guess that sockets--direct from a client to the server--would be the fastest for speed and maybe take the least bandwidth.  But I would expect that there would only be negligible size increases for the JMS overhead once the connection was established and I would expect that a pub-sub topic would be able to smoke through sending the N number of clients messages, rather than loop through the connections/sockets and sending the message to each of them.

Has anyone else looked at this?  I'm going through the exercise to set up a JMS server, but I thought maybe someone else could point me in the right direction.

Cheers,
me2

[toc] | [next] | [standalone]

#20712

me2 wrote:
> Has anyone compared JMS to socket programming?  If I have N number of clients 
> that need to connect to and send messages to 1 server, what is the 
> comparison?  I would guess that sockets--direct from a client to the server--
> would be the fastest for speed and maybe take the least bandwidth.  But I 
> would expect that 

Beware expectations.

> there would only be negligible size increases for the JMS overhead once the 
> connection was established and I would expect that a pub-sub topic would be 
> able to smoke through sending the N number of clients messages, rather than 
> loop through the connections/sockets and sending the message to each of them.

Apples vs. oranges.

JMS uses what under the hood?

Well, sometimes sockets but that depends. For certain processes you might 
see in-memory transfers.

Or shared memory.

And how much speed do you need, and do you need it in development to get 
correct operation, or at runtime to get wrong operation quicker?

How much time and money and aggravation are you willing to spend re-inventing
messaging?

> Has anyone else looked at this?  I'm going through the exercise to set up a 
> JMS server, but I thought maybe someone else could point me in the right 
> direction.

The only way to compare speed is to measure actual implementations.

And you might be measuring the wrong thing.

Plus, socket implementations can be very naive. NIO or threads?

Under what loads? How much competition for resources? With what latencies?

How much speed do you need? How much safety?

Who pays for support when there are problems?

How will it scale? How much does it even need to scale?

You've been asking the wrong questions for this stage, I'm advising.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#20713

On 12/26/2012 4:26 PM, me2 wrote:
> I am a newbie to JMS and would appreciate some advice.
>
> Has anyone compared JMS to socket programming?  If I have N number of
> clients that need to connect to and send messages to 1 server, what
> is the comparison?  I would guess that sockets--direct from a client
> to the server--would be the fastest for speed and maybe take the
> least bandwidth.  But I would expect that there would only be
> negligible size increases for the JMS overhead once the connection
> was established and I would expect that a pub-sub topic would be able
> to smoke through sending the N number of clients messages, rather
> than loop through the connections/sockets and sending the message to
> each of them.
>
> Has anyone else looked at this?  I'm going through the exercise to
> set up a JMS server, but I thought maybe someone else could point me
> in the right direction.

If you are moving data between two systems connected via
a TCP/IP network, then you will be using sockets.

So the question is whether to use socket API or JMS API.
A third option would be RMI.

It is obvious that adding layers on top of sockets can
not produce something faster than optimal usage of
sockets. There will be somewhere between utterly insignificant
and completely devastating overhead by adding an extra layer.

If you want to know for sure then measure in your specific
context.

But I am surprised that you only seem to focus on
the performance aspect.

The differences in functionality provided seem
much more important to me.

async only or also sync request-response?
Java SE daemon or Java EE app as server?
support for non-Java clients or servers?
need for transactions?
need for redundancy?

Arne

[toc] | [prev] | [next] | [standalone]

#20716

I believe socket has the best performance, i tried to user socket and pipeline to send data to a c++ program, socket win.

[toc] | [prev] | [next] | [standalone]

#20717

On Wednesday, December 26, 2012 8:46:02 PM UTC-8, mche...@gmail.com wrote:
> I believe socket has the best performance, i [sic] tried to user [huh?] 
> socket and pipeline to send data to a c++ [sic] program, socket win [sic].

Sorry, "pipeline"? 

How does that compare to, say, a JMS in-memory transfer?

Under what conditions did you do the measurements?

What was your definition of "win"?

Did your C++ program do anything significant with the data? Under 
what load? What competing loads? How many clients? Any threading issues?

Your post provides so little detail as to be effectively useless.

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#20726

On 27.12.2012 05:46, mcheung63@gmail.com wrote:
> I believe socket has the best performance, i tried to user socket and
> pipeline to send data to a c++ program, socket win.

That statement is pretty meaningless.  First, we do not know what you 
did, i.e. what you measured.  Then, you did not make any statement 
whatsoever how big the difference is.  Third, engineers usually deal 
with tradeoffs: it could well be that 5% performance penalty is well 
worth the 5 weeks savings in development time to implement your own 
protocol using a socket.  (Eventually you may find out that by that time 
the 5% performance reduction is actually a 10% performance advantage 
because your home grown version is slower because of some quirk in your 
own implementation.)

Kind regards

	robert

-- 
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[toc] | [prev] | [next] | [standalone]

#20732

On 12/26/2012 11:46 PM, mcheung63@gmail.com wrote:
> I believe socket has the best performance, i tried to user socket and pipeline to send data to a c++ program, socket win.

Hmmm.

How did you test JMS from C++?

:-)

Arne

[toc] | [prev] | [next] | [standalone]

#21204

On Thu, 27 Dec 2012 13:26:31 -0500, Arne Vajhøj <arne@vajhoej.dk>
wrote:

>On 12/26/2012 11:46 PM, mcheung63@gmail.com wrote:
>> I believe socket has the best performance, i tried to user socket and pipeline to send data to a c++ program, socket win.
>
>Hmmm.
>
>How did you test JMS from C++?
>
>:-)

e.g. ActiveMQ-CPP
-- 
(\__/)  M.
(='.'=) If a man stands in a forest and no woman is around
(")_(") is he still wrong?

[toc] | [prev] | [next] | [standalone]

#21231

On 1/8/2013 4:28 AM, Mark wrote:
> On Thu, 27 Dec 2012 13:26:31 -0500, Arne Vajhøj <arne@vajhoej.dk>
> wrote:
>> On 12/26/2012 11:46 PM, mcheung63@gmail.com wrote:
>>> I believe socket has the best performance, i tried to user socket and pipeline to send data to a c++ program, socket win.
>>
>> Hmmm.
>>
>> How did you test JMS from C++?
>>
>> :-)
>
> e.g. ActiveMQ-CPP

Most message queues has a C/C++ client lib.

But JMS ...

Arne

[toc] | [prev] | [next] | [standalone]

#20724

Am 27.12.2012 01:00, schrieb Arne Vajhøj:
> So the question is whether to use socket API or JMS API.
> A third option would be RMI.

If performance is a concern, better not use RMI. One call to a method
(e.g. in order to deliver some data to the peer) will always take at
least one roundtrip, as the caller side has to wait until the method
(even if it is void) returns.

A fourth option is to use object serialization without RMI, i.e.
ObjectOutputStream and ObjectInputStream. It is worth it, if your
protocol allows you to send multiple objects (or messages for that
matter) without having to wait for a reply.


Regards,
  Sven

[toc] | [prev] | [next] | [standalone]

#20729

On 12/27/2012 8:26 AM, Sven Köhler wrote:
> Am 27.12.2012 01:00, schrieb Arne Vajhøj:
>> So the question is whether to use socket API or JMS API.
>> A third option would be RMI.
>
> If performance is a concern, better not use RMI. One call to a method
> (e.g. in order to deliver some data to the peer) will always take at
> least one roundtrip, as the caller side has to wait until the method
> (even if it is void) returns.

If the requirements are for true async, then RMI is not a good fit
as it is always sync request-response.

> A fourth option is to use object serialization without RMI, i.e.
> ObjectOutputStream and ObjectInputStream. It is worth it, if your
> protocol allows you to send multiple objects (or messages for that
> matter) without having to wait for a reply.

I am not sure that I would count that as a distinct option.

The socket option will need something on top of it.

PrintWriter/BufferedReader
ObjectInputStream/ObjectOutputStream
DataInputStream/DataOutputStream
etc.

Arne

[toc] | [prev] | [next] | [standalone]

#20733

Am 27.12.2012 19:18, schrieb Arne Vajhøj:
> On 12/27/2012 8:26 AM, Sven Köhler wrote:
> 
>> A fourth option is to use object serialization without RMI, i.e.
>> ObjectOutputStream and ObjectInputStream. It is worth it, if your
>> protocol allows you to send multiple objects (or messages for that
>> matter) without having to wait for a reply.
> 
> I am not sure that I would count that as a distinct option.
> 
> The socket option will need something on top of it.

I see your point.
Maybe, I just met too many people overlooking that option.

[toc] | [prev] | [next] | [standalone]

#20735

On 12/27/2012 1:47 PM, Sven Köhler wrote:
> Am 27.12.2012 19:18, schrieb Arne Vajhøj:
>> On 12/27/2012 8:26 AM, Sven Köhler wrote:
>>> A fourth option is to use object serialization without RMI, i.e.
>>> ObjectOutputStream and ObjectInputStream. It is worth it, if your
>>> protocol allows you to send multiple objects (or messages for that
>>> matter) without having to wait for a reply.
>>
>> I am not sure that I would count that as a distinct option.
>>
>> The socket option will need something on top of it.
>
> I see your point.
> Maybe, I just met too many people overlooking that option.

It can certainly be convenient.

I have used it a lot myself.

Arne

[toc] | [prev] | [next] | [standalone]

#20719

In article <94fcfac6-eff5-4e84-956a-8a7970867867@googlegroups.com>,
 me2 <winona_whitener@yahoo.com> wrote:

> Greetings,
> 
> I am a newbie to JMS and would appreciate some advice.
> 
> Has anyone compared JMS to socket programming?  If I have N number of clients 
> that need to connect to and send messages to 1 server, what is the 
> comparison?  I would guess that sockets--direct from a client to the 
> server--would be the fastest for speed and maybe take the least bandwidth.  
> But I would expect that there would only be negligible size increases for the 
> JMS overhead once the connection was established and I would expect that a 
> pub-sub topic would be able to smoke through sending the N number of clients 
> messages, rather than loop through the connections/sockets and sending the 
> message to each of them.
> 
> Has anyone else looked at this?  I'm going through the exercise to set up a 
> JMS server, but I thought maybe someone else could point me in the right 
> direction.
> 
> Cheers,
> me2

JMS is about topic management, queue management, message persistence, 
and reliable distribution in a complex environment prone to failures.  
If you don't need any of that, like a log host, you'll be much happier 
with a plain socket.  If you do need that stuff you probably want a JMS 
implementation rather than writing it yourself.

JMS services are typically very heavy weight.  Memory and disk space are 
needed to buffer data to nodes that temporarily fall behind or go 
offline.  Configuration can take a while too.
-- 
I will not see posts from Google because I must filter them as spam

[toc] | [prev] | [next] | [standalone]

#20723

On 12/27/2012 03:35 AM, Kevin McMurtrie wrote:
> In article <94fcfac6-eff5-4e84-956a-8a7970867867@googlegroups.com>,
>   me2 <winona_whitener@yahoo.com> wrote:
>
>> Greetings,
>>
>> I am a newbie to JMS and would appreciate some advice.
>>
>> Has anyone compared JMS to socket programming?  If I have N number of clients
>> that need to connect to and send messages to 1 server, what is the
>> comparison?  I would guess that sockets--direct from a client to the
>> server--would be the fastest for speed and maybe take the least bandwidth.
>> But I would expect that there would only be negligible size increases for the
>> JMS overhead once the connection was established and I would expect that a
>> pub-sub topic would be able to smoke through sending the N number of clients
>> messages, rather than loop through the connections/sockets and sending the
>> message to each of them.
>>
>> Has anyone else looked at this?  I'm going through the exercise to set up a
>> JMS server, but I thought maybe someone else could point me in the right
>> direction.
>>
>> Cheers,
>> me2
>
> JMS is about topic management, queue management, message persistence,
> and reliable distribution in a complex environment prone to failures.
> If you don't need any of that, like a log host, you'll be much happier
> with a plain socket.  If you do need that stuff you probably want a JMS
> implementation rather than writing it yourself.
>
> JMS services are typically very heavy weight.  Memory and disk space are
> needed to buffer data to nodes that temporarily fall behind or go
> offline.  Configuration can take a while too.
>
It's funny how people can come at things from a different perspective. 
In my world messaging providers like JMS providers or WMQ (and JMS and 
MQ clients) are _lightweight_. I actually stopped and tried to process 
your "novel" concept for a few seconds. :-)

AHS

[toc] | [prev] | [next] | [standalone]

#20731

On 12/27/2012 6:13 AM, Arved Sandstrom wrote:
> On 12/27/2012 03:35 AM, Kevin McMurtrie wrote:
>> JMS is about topic management, queue management, message persistence,
>> and reliable distribution in a complex environment prone to failures.
>> If you don't need any of that, like a log host, you'll be much happier
>> with a plain socket.  If you do need that stuff you probably want a JMS
>> implementation rather than writing it yourself.
>>
>> JMS services are typically very heavy weight.  Memory and disk space are
>> needed to buffer data to nodes that temporarily fall behind or go
>> offline.  Configuration can take a while too.
>>
> It's funny how people can come at things from a different perspective.
> In my world messaging providers like JMS providers or WMQ (and JMS and
> MQ clients) are _lightweight_. I actually stopped and tried to process
> your "novel" concept for a few seconds. :-)

JMS can be what you make it be.

A non-persisted non-transactional queue with sender and
receiver in same JVM and a clustered persisted transactional
with XA queue with queue, sender and receiver in 3 different
JVM's are pretty different in relation to overhead and
infrastructure requirements.

Arne

[toc] | [prev] | [next] | [standalone]

#20752

In article <c3WCs.31155$tG.11699@newsfe15.iad>,
 Arved Sandstrom <asandstrom2@eastlink.ca> wrote:

> On 12/27/2012 03:35 AM, Kevin McMurtrie wrote:
> > In article <94fcfac6-eff5-4e84-956a-8a7970867867@googlegroups.com>,
> >   me2 <winona_whitener@yahoo.com> wrote:
> >
> >> Greetings,
> >>
> >> I am a newbie to JMS and would appreciate some advice.
> >>
> >> Has anyone compared JMS to socket programming?  If I have N number of 
> >> clients
> >> that need to connect to and send messages to 1 server, what is the
> >> comparison?  I would guess that sockets--direct from a client to the
> >> server--would be the fastest for speed and maybe take the least bandwidth.
> >> But I would expect that there would only be negligible size increases for 
> >> the
> >> JMS overhead once the connection was established and I would expect that a
> >> pub-sub topic would be able to smoke through sending the N number of 
> >> clients
> >> messages, rather than loop through the connections/sockets and sending the
> >> message to each of them.
> >>
> >> Has anyone else looked at this?  I'm going through the exercise to set up 
> >> a
> >> JMS server, but I thought maybe someone else could point me in the right
> >> direction.
> >>
> >> Cheers,
> >> me2
> >
> > JMS is about topic management, queue management, message persistence,
> > and reliable distribution in a complex environment prone to failures.
> > If you don't need any of that, like a log host, you'll be much happier
> > with a plain socket.  If you do need that stuff you probably want a JMS
> > implementation rather than writing it yourself.
> >
> > JMS services are typically very heavy weight.  Memory and disk space are
> > needed to buffer data to nodes that temporarily fall behind or go
> > offline.  Configuration can take a while too.
> >
> It's funny how people can come at things from a different perspective. 
> In my world messaging providers like JMS providers or WMQ (and JMS and 
> MQ clients) are _lightweight_. I actually stopped and tried to process 
> your "novel" concept for a few seconds. :-)
> 
> AHS

They're almost lightweight without the high reliability options, but 
those are the same options that cause people to choose JMS rather than 
an in-house solution.  FFMQ is a lightweight codebase but it's still 
going to hit disk I/O fairly hard.  ActiveMQ is a resource-consuming 
beast when faced with reliable delivery to clients that are lagging.  
ActiveMQ also has dependencies on half the Internet so it's prone to 
creating library conflicts.
-- 
I will not see posts from Google because I must filter them as spam

[toc] | [prev] | [next] | [standalone]

#20760

On 12/28/2012 3:59 AM, Kevin McMurtrie wrote:
> In article <c3WCs.31155$tG.11699@newsfe15.iad>,
>   Arved Sandstrom <asandstrom2@eastlink.ca> wrote:
>> On 12/27/2012 03:35 AM, Kevin McMurtrie wrote:
>>> JMS services are typically very heavy weight.  Memory and disk space are
>>> needed to buffer data to nodes that temporarily fall behind or go
>>> offline.  Configuration can take a while too.
>>>
>> It's funny how people can come at things from a different perspective.
>> In my world messaging providers like JMS providers or WMQ (and JMS and
>> MQ clients) are _lightweight_. I actually stopped and tried to process
>> your "novel" concept for a few seconds. :-)
>
> They're almost lightweight without the high reliability options, but
> those are the same options that cause people to choose JMS rather than
> an in-house solution.

That may be how you use message queue solutions.

But there are other that use message queues without the
reliability options.

>                                     ActiveMQ is a resource-consuming
> beast when faced with reliable delivery to clients that are lagging.
> ActiveMQ also has dependencies on half the Internet so it's prone to
> creating library conflicts.

????

How?

The ActiveMQ jars and the applications jars should not be
mixed at all. Either different JVM or different apps within the
same app server. Only exception I can think of is embedded
inside an SE app, which is not a common scenario.

Arne

[toc] | [prev] | [next] | [standalone]

#20774

In article <50ddc1ef$0$281$14726298@news.sunsite.dk>,
 Arne Vajhøj <arne@vajhoej.dk> wrote:

> On 12/28/2012 3:59 AM, Kevin McMurtrie wrote:
> > In article <c3WCs.31155$tG.11699@newsfe15.iad>,
> >   Arved Sandstrom <asandstrom2@eastlink.ca> wrote:
> >> On 12/27/2012 03:35 AM, Kevin McMurtrie wrote:
> >>> JMS services are typically very heavy weight.  Memory and disk space are
> >>> needed to buffer data to nodes that temporarily fall behind or go
> >>> offline.  Configuration can take a while too.
> >>>
> >> It's funny how people can come at things from a different perspective.
> >> In my world messaging providers like JMS providers or WMQ (and JMS and
> >> MQ clients) are _lightweight_. I actually stopped and tried to process
> >> your "novel" concept for a few seconds. :-)
> >
> > They're almost lightweight without the high reliability options, but
> > those are the same options that cause people to choose JMS rather than
> > an in-house solution.
> 
> That may be how you use message queue solutions.
> 
> But there are other that use message queues without the
> reliability options.
> 
> >                                     ActiveMQ is a resource-consuming
> > beast when faced with reliable delivery to clients that are lagging.
> > ActiveMQ also has dependencies on half the Internet so it's prone to
> > creating library conflicts.
> 
> ????
> 
> How?
> 
> The ActiveMQ jars and the applications jars should not be
> mixed at all. Either different JVM or different apps within the
> same app server. Only exception I can think of is embedded
> inside an SE app, which is not a common scenario.
> 
> Arne

I agree about how it should work but there is no minimal ActiveMQ 
client.  The best you can do is a trial-and-error process to create 
exclusion lists in Ivy/Maven rather than pulling down the full client 
JAR.
-- 
I will not see posts from Google because I must filter them as spam

[toc] | [prev] | [next] | [standalone]

#20786

On 12/28/2012 3:19 PM, Kevin McMurtrie wrote:
> In article <50ddc1ef$0$281$14726298@news.sunsite.dk>,
>   Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 12/28/2012 3:59 AM, Kevin McMurtrie wrote:
>>> In article <c3WCs.31155$tG.11699@newsfe15.iad>,
>>>    Arved Sandstrom <asandstrom2@eastlink.ca> wrote:
>>>> On 12/27/2012 03:35 AM, Kevin McMurtrie wrote:
>>>>> JMS services are typically very heavy weight.  Memory and disk space are
>>>>> needed to buffer data to nodes that temporarily fall behind or go
>>>>> offline.  Configuration can take a while too.
>>>>>
>>>> It's funny how people can come at things from a different perspective.
>>>> In my world messaging providers like JMS providers or WMQ (and JMS and
>>>> MQ clients) are _lightweight_. I actually stopped and tried to process
>>>> your "novel" concept for a few seconds. :-)
>>>
>>> They're almost lightweight without the high reliability options, but
>>> those are the same options that cause people to choose JMS rather than
>>> an in-house solution.
>>
>> That may be how you use message queue solutions.
>>
>> But there are other that use message queues without the
>> reliability options.
>>
>>>                                      ActiveMQ is a resource-consuming
>>> beast when faced with reliable delivery to clients that are lagging.
>>> ActiveMQ also has dependencies on half the Internet so it's prone to
>>> creating library conflicts.
>>
>> ????
>>
>> How?
>>
>> The ActiveMQ jars and the applications jars should not be
>> mixed at all. Either different JVM or different apps within the
>> same app server. Only exception I can think of is embedded
>> inside an SE app, which is not a common scenario.
>
> I agree about how it should work but there is no minimal ActiveMQ
> client.  The best you can do is a trial-and-error process to create
> exclusion lists in Ivy/Maven rather than pulling down the full client
> JAR.

The client code can obviously not be separated from the app.

But my experience is rather different.

The all jar and a SLF logger and it works.

And the all jar only contains ActiveMQ, KahaDB and some SLF API.

Very far from half the internet.

Arne

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web