. juin 2003 21:08
To: [EMAIL PROTECTED]
Subject: RE: Antwort: RE: [JBoss-dev] JBossMQ rewrite
As Bela and I have recently discussed with Tom Elrod, we all
think that
exposing JavaGroups as a transport of the remoting framework
is indeed the best
approach. However, I struggle with how
]
Kopie:
Thema:RE: [JBoss-dev] JBossMQ rewrite
JBossMQthe current code basewill continue to ship with JBoss 3.2 which is,
and will remain for some time, the production version. Therefore, making
changes to the current code base IS NOT worthless. However, I am working on
a brand new
Hi Ulf,
(2) message redelivery / message throttling clustering / failover
since Nathan's design is based on JavaGroups, these issues are
JavaGroups issues:
- Message retransmission is handled by JavaGroups.
- Failover: what do you understand by failover ?
- Throttling: we are working on a
: [EMAIL PROTECTED]
15.06.2003 00:00
Bitte antworten an jboss-development
An: [EMAIL PROTECTED]
Kopie:
Thema: RE: [JBoss-dev] JBossMQ rewrite
JBossMQ?the current code base?will continue to ship with JBoss 3.2 which
is,
and will remain for some time
PROTECTED] On
Behalf Of Nathan Phelps
Sent: Saturday, June 14, 2003 6:00 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] JBossMQ rewrite
JBossMQthe current code basewill continue to ship with
JBoss 3.2 which is, and will remain for some time, the
production version. Therefore, making
from getting a first iteration
in place.
Bill
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Bela
Ban
Sent: Monday, June 16, 2003 1:12 PM
To: [EMAIL PROTECTED]
Subject: Re: Antwort: RE: [JBoss-dev] JBossMQ rewrite
Hi Ulf,
(2) message redelivery
Bill Burke wrote:
Nathan's design will not be based on JavaGroups, but will rather use
JavaGroups as one type of transport mechanism.
Don't get all nervous; that's what I meant. 2 transports, one is the
traditional c/s, the other one is implemented using JavaGroups.
I would rather see JBoss
PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Bela
Ban
Sent: Monday, June 16, 2003 2:28 PM
To: [EMAIL PROTECTED]
Subject: Re: Antwort: RE: [JBoss-dev] JBossMQ rewrite
Bill Burke wrote:
Nathan's design will not be based on JavaGroups, but will rather use
JavaGroups as one type
1:12 PM
To: [EMAIL PROTECTED]
Subject: Re: Antwort: RE: [JBoss-dev] JBossMQ rewrite
Hi Ulf,
(2) message redelivery / message throttling clustering / failover
since Nathan's design is based on JavaGroups, these issues are
JavaGroups issues:
- Message retransmission
JBossMQthe current code basewill continue to ship with JBoss 3.2 which is,
and will remain for some time, the production version. Therefore, making
changes to the current code base IS NOT worthless. However, I am working on
a brand new implementation with assistance from Adrian, Bela, Bill,
that sounds right..
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of John
Fawcett
Sent: Tuesday, January 14, 2003 8:14 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] JBossMQ
Hi,
I want to make sure I understand the asynchronous delivery
: [JBoss-dev] JBossMQ
Your kinda right. the loop is there for the case where the destination
is queue based (p2p and durable subs). The polling happens when the
queue is full. Now when the queue is not full (or in the pub sub case,
there is no queue), then the thread goes into asynch mode
PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of John
Fawcett
Sent: Sunday, January 12, 2003 6:50 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] JBossMQ, multiplexor test
Thanks for the explanation of the receive loop Hiram.
I am trying to run the Multiplexor test included
: Friday, January 10, 2003 6:50 PM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] JBossMQ
Your kinda right. the loop is there for the case where the destination
is
queue based (p2p and durable subs). The polling happens when the queue
is
full. Now when the queue is not full (or in the pub sub case
Your kinda right. the loop is there for the case where the destination is
queue based (p2p and durable subs). The polling happens when the queue is
full. Now when the queue is not full (or in the pub sub case, there is no
queue), then the thread goes into asynch mode and it waits for the
Hey David.. I want to see If I can start working on this.
I know like amost zero about jca but I know quite a bit about the XA stuff
and how jbossmq txs work with the MDB.
anyways.. I guess what I need to know is how is the contianer going to
initialize
the jms stuff so that it can deliver
Hey Hiram,
Glad to see you're getting interested. Unfortunately I leave for the
weekend in a few minutes... more on monday.
The part of jca 1.5 I haven't written is the deployment of the adapter. If
you get that far, you should be able to write a simple mbean to create your
ResourceAdapter
Hi,
I am sorry I have not had the time to do anything on the jca1.5
integration. I have not even had time to read the new spec. From what
you say I would however draw the following conclusions:
1. The jca 1.5 have defined a new contract superceding chapter 8 in the
JMS spec, which means that
Many thanks, peter. I have to work on some other things for a while also,
I will try to look into this more. Your pointers will be a big help in
seeing how it works.
Thanks
david jencks
On 2002.09.03 03:25:26 -0400 Peter Antman wrote:
Hi,
I am sorry I have not had the time to do anything on
Hi David
I am still looking into the code to become an JMS expert but I would
like to help to implement this. Because I added the Common Interfaces
of JMS 1.1 it would like to use this opportunity to make the appropriate
changes here.
This week I am pretty busy.
Have fun - Andy
I started
It should be possible to define any sort of grammer with JavaCC.
Perhaps the root production does not have the proper terminators to
single the end of a selector?
--jason
Hiram Chirino wrote:
To all JavaCC Gurus,
The javacc grammar that JBossMQ is using has a problem. It can't
detect
I'm looking into it.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Hiram Chirino [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, April 29, 2002 9:50 PM
Subject: [JBoss-dev] JBossMQ JavaCC Problem
Fixed. All parser unit tests now run without errors.
Scott Stark
Chief Technology Officer
JBoss Group, LLC
- Original Message -
From: Hiram Chirino [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, April 29, 2002 9:50 PM
Subject:
Dropped, as per the JMS spec.
-Original Message-
From: Andreas Schaefer [mailto:[EMAIL PROTECTED]]
Sent: Thursday, April 18, 2002 11:59 AM
To: Hiram Chirino
Cc: [EMAIL PROTECTED]
Subject: [JBoss-dev] JBossMQ Problem with Topics
Hi Geeks
When a message is sent to a
On 7 Mar, Jason Dillon wrote:
It's there to easy transition. The old state manager is still around for
people having tons of users in their old state format, so it's mostly
there to document the format of the OldStatemanager since it do not have
a DTD. Maybe it should not get copy'd over during
On 22 Feb, Scott M Stark wrote:
[...]
The new resource adaptor security will only be implemented in 3.x. The
current 2.4 code base does not matter.
Well, a connection hold in vm may possibly be used by different threads,
but the connection should, in case it was started with userid/pwd,
On 22 Feb, David Jencks wrote:
On 2002.02.22 14:50:00 -0500 [EMAIL PROTECTED] wrote:
[...]
(Do you remember our discussions earlier about this. I did infact
implement a DirContext impelementation and a DirContext JCA adapter wich
plugged in both as a JAAS LoginModule and made it easy to
On 22 Feb, Alexander Horuzhiy wrote:
Hi,
you have plane to implementing JDBC StateManager?
No, perhaps make it more pluggable. Then I would probably make an
DirContext/Ladap one...but thats for later. First we need to get
autentication pluggable.
//Peter
//Alexander
well I'm not Scott, but I've been working on security for a client. This
probably belongs on one of the forums but here are a few answers.
Yes the password is sent clear text.
Yes you can use encryption or ssl to protect yourself.
Yes it is sent every Invocation.
For the rmi, look at the
I tried to look at the documentation for how to set up a JAAS aware
client, and then looked somewhat into the proxy, jrmp and
SecurityInterceptor code, and guess what, it looks to mee as we are
sending both the principall and the credentials on every invokation, and
also does an
This is strictly a login module configuration issue. The SRP login
module implementation comes as a client/server pair of login modules
that maintain a user based state that can be logged out immeadiately.
Read the SRP section in the JBossSX chapter of the book as
it talks in detail about this.
On 22 Feb, Scott M Stark wrote:
I tried to look at the documentation for how to set up a JAAS aware
client, and then looked somewhat into the proxy, jrmp and
SecurityInterceptor code, and guess what, it looks to mee as we are
sending both the principall and the credentials on every
This is the stateless web model.
Not if you have a standalone client. The its should be the stateless RMI
model, or what?
Yes, the RMI proxies are stateless with respect to the client.
2. JCA (perhaps) commes in if we raise the question: should current
principal or subject be
On 2002.02.22 14:50:00 -0500 [EMAIL PROTECTED] wrote:
On 22 Feb, Scott M Stark wrote:
I tried to look at the documentation for how to set up a JAAS aware
client, and then looked somewhat into the proxy, jrmp and
SecurityInterceptor code, and guess what, it looks to mee as we are
sending
I will eventually get around to fixing this and in general making the
testsuite better. I have been playing with a few ideas to make it
easier and faster to write test cases too... if only I had more time.
--jason
marc fleury wrote:
|to have testcases that send up to 100 000 messages,
On 21 Feb, Jason Dillon wrote:
I will eventually get around to fixing this and in general making the
testsuite better. I have been playing with a few ideas to make it
easier and faster to write test cases too... if only I had more time.
Oh, yes, time. I'am sitting here with this faboulous
By the way, these new tests are verry time consuming, they starts and
stops JBoss and use big iteration counts. My plan is to integrate is as
an entity ref in build.xml, to not litter that file to much, and not
make them run dring normal testing. Is that OK?
I am not sure what your changes
|to have testcases that send up to 100 000 messages, sometimes taking up
|to an hour to complete...
|
|How about that?
impractical for the 'fast' test that make sure we don't mess up stuff when
we change something.
it seems, jason, that we need to use your wonderful buildmagic to get that
Hi, one reason it is taking so long is that it is testing all IL:s (I
thingk). If you do this move please split this test and run at least a
test on the OIL and preferably also the JVM IL, since these are the
defaults used by everyone.
//Peter
On 20 Feb, marc fleury wrote:
|to have testcases
On 16 Feb, Jason Dillon wrote:
Is there anything we can do to speed it up any?
Well, actually it is not slow enough ;-) since it does not catch all
bugs as it is setup today. To chatch current buggs in threading you have
to have testcases that send up to 100 000 messages, sometimes taking up
to
Yikes... that would not bee good. Perhaps this test case should be
moved outside of tests-unit into a separate target which is depended on
by tests.
--jason
On Sun, 2002-02-17 at 07:22, [EMAIL PROTECTED] wrote:
On 16 Feb, Jason Dillon wrote:
Is there anything we can do to speed it up any?
in the right
places??? The question is: how BIG should the buffer be???
Regards,
Hiram
From: Jeff Tulley [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] jbossmq message transport times
Date: Wed, 16 Jan 2002 10:03:23 -0700
Actually it is even a little more complicated than
I made two changes which I'll describe here. I haven't yet investigated the
mechanics of submitting patches.
The changes are both in the org.jboss.mq.il.oil package. Note there are analogous
places in the other il subpackages that may also need changing-- my current test
evidently doesn't
- Original Message -
From: Loren Rosen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, January 18, 2002 1:58 PM
Subject: Re: [JBoss-dev] jbossmq message transport times
I made two changes which I'll describe here. I haven't yet investigated
the
mechanics of submitting patches.
The changes
,
Sacha
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]De la part de
Hiram Chirino
Envoyé : mercredi, 16 janvier 2002 04:17
À : [EMAIL PROTECTED]; [EMAIL PROTECTED]
Objet : Re: [JBoss-dev] jbossmq message transport times
I can't think of a reason
Den 2002-01-16 02:37:12 skrev Loren Rosen [EMAIL PROTECTED]:
I'm
testing on MacOS X, which for our purposes is just another Unix flavor
with an oddball GUI.
Hi hi hi I'm waiting for my PB TI to arrive... really longing for Unix with an
oddball GUI :)
/Lennart
hi,
On Wed, 2002-01-16 at 10:58, Sacha Labourey wrote:
I guess that if you want to modify this, you need to make it optional.
The TCPNODELAY flag is related to the Nagle's algorithm
true.
This algorithm is made to avoid sending very small paquets each time you
send data through your
of you, then it is up to you.
Cheers,
Sacha
-Message d'origine-
De : [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]De la part de
Hiram Chirino
Envoyé : mercredi, 16 janvier 2002 04:17
À : [EMAIL PROTECTED]; [EMAIL PROTECTED]
Objet : Re: [JBoss-dev
janvier 2002 04:17
À : [EMAIL PROTECTED]; [EMAIL PROTECTED]
Objet : Re: [JBoss-dev] jbossmq message transpo
rt times
I can't think of a reason that it would break anything...
___
Jboss-development mailing list
[EMAIL PROTECTED]
https
]
Subject: RE: [JBoss-dev] jbossmq message transport times
Date: Wed, 16 Jan 2002 10:03:23 -0700
Actually it is even a little more complicated than that. Nagle's
algorithm by itself would not cause such delays, but what happened is
that at the other end somebody (I forget who) came up with the idea
Probably not for the default config... some are used for the testsuite, but
I think we should probably setup a 'testsuite' config, which is used to run
the testsuite against. Downside to this is we may miss configuration errors
in the 'default' config.
Does the remote queue/topic install
I'll look through the code more closely. But recovery is testable. What
you have to do is create some corrupt data files (probably by using a
byte-level editor to munge some existing data files). Then you need
some scripts to start up the server with those files -- which doesn't
fit so well
: [JBoss-dev] jbossmq: persistence implementation questions
Date: Thu, 15 Nov 2001 15:07:23 -0800 (PST)
I'll look through the code more closely. But recovery is testable. What
you have to do is create some corrupt data files (probably by using a
byte-level editor to munge some existing data files
In jboss 3, you __should__ be able to start and stop jbossmq dynamically
while the rest of the server is running. We are not very far from being
able to run several JBossMQService mbeans at once-- this could allow you to
test one pm at a time without messing up the standard jbossmq setup.
I
Use mock objects. www.mockobjects.com To use the automated mock object creator may
require modifying the code a little (creating some more interfaces), but you can
simply use the concept. It is the only great way to test complicated failure cases,
especially when there is a complicated
I was only really suggesting that rather than test the entire JBoss server
instance with a JBoss service, to focus on the individual component which
performs this functionality.
Assuming that the component can be started up from inside JUnit, then we can
setup any given environment and given
PROTECTED]
Sent: Thursday, November 15, 2001 4:29 PM
Subject: Re: [JBoss-dev] jbossmq: persistence implementation questions
I was only really suggesting that rather than test the entire JBoss server
instance with a JBoss service, to focus on the individual component which
performs
Can mockobjects be integrated with JUnit?
--jason
On Thu, 15 Nov 2001, Jeff Tulley wrote:
Use mock objects. www.mockobjects.com To use the automated mock object creator
may require modifying the code a little (creating some more interfaces), but you can
simply use the concept. It is
Hi Loren!
From: Loren Rosen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
[EMAIL PROTECTED]
Subject: [JBoss-dev] jbossmq: persistance implementation questions
Date: Mon, 12 Nov 2001 20:22:27 -0800
I've been looking a bit at the jboss mq persistence code, and I have
some questions. I'll state some
I looked too.
On 2001.11.12 23:22:27 -0500 Loren Rosen wrote:
I've been looking a bit at the jboss mq persistance code, and I have
some questions. I'll state some of them from a user perspective, but my
motivation is as a developer; that is, to address some of the 'problems'
or 'limitations'
On 2001.11.13 00:13:54 -0500 Hiram Chirino wrote:
Hi Loren!
From: Loren Rosen [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
[EMAIL PROTECTED]
Subject: [JBoss-dev] jbossmq: persistance implementation questions
Date: Mon, 12 Nov 2001 20:22:27 -0800
I've been looking a bit at the jboss mq
-
From: David Jencks [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, November 02, 2001 8:08 PM
Subject: Re: [JBoss-dev] JBossMQ JDBC PersistenceManager
Well, don't confuse the rar and the connectionfactory.
What I have on my machine, using the mbean references, is like this:
a rar gets
: David Jencks [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, November 02, 2001 8:08 PM
Subject: Re: [JBoss-dev] JBossMQ JDBC PersistenceManager
Well, don't confuse the rar and the connectionfactory.
What I have on my machine, using the mbean references, is like this:
a rar gets
- Original Message -
From: David Jencks [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, November 03, 2001 5:49 AM
Subject: Re: [JBoss-dev] JBossMQ JDBC PersistenceManager
I guess I have no particular problem having the ability to put a
jboss-service.xml file in a rar, as long as we
Interesting situation. I have on my machine a reimplementation of the
depends mechanism that changes the RARDeployment sequence so it does not
rely on the notifications noted here. However, it eliminates the separate
init and start steps of mbean startup. The only place this is used is
setting
: Re: [JBoss-dev] JBossMQ JDBC PersistenceManager
Interesting situation. I have on my machine a reimplementation of the
depends mechanism that changes the RARDeployment sequence so it does
not
rely on the notifications noted here. However, it eliminates the
separate
init and start
Hi,
Tobias Frech wrote:
There is a interesting thread on linux threads here:
http://www.jboss.org/forums/thread.jsp?forum=52thread=2273
Yes, and it kind of exposes the confusion on this.
A few years back I did a lot of Linux kernel hacking,
so I guess I know a little about this.
It is
On 5 Okt, Ole Husgaard wrote:
Hi,
I hope it is OK that I forward your reply to the list.
David Maplesden wrote:
Sounds like a good idea. It didn't feel when writing the code that an extra
thread per connection would be a problem. If it is for you then you will
probably want to pool
Group, LLC
- Original Message -
From: Peter Antman [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, October 05, 2001 5:44 AM
Subject: Re: [JBoss-dev] JBossMQ thread model
On 5 Okt, Ole Husgaard wrote:
Hi,
I hope it is OK that I forward your reply
There is a interesting thread on linux threads here:
http://www.jboss.org/forums/thread.jsp?forum=52thread=2273
tobi
Ole Husgaard wrote:
Hi,
As most of you are probably aware, JBossMQ creates a _lot_ of
threads. This can be particularly annoying with native threads
Java VMs on Linux
What do you mean by selector parser?
I could adapt the parser that is used for EJB-QL to parse. It is a generic
non-deterministic recusive descent parser, so it is not fast for complicated
grammers. This is only an issue if you want to parse on the fly.
-dain
- Original Message -
Can you send it to me??? I'll check it in.
Regards,
Hiram
From: Juha-P Lindfors [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] jbossmq selector parser grammer source
Date: Wed, 22 Aug 2001 13:01:02 +0300 (EET DST)
I have just fixed
it in.
Regards,
Hiram
From: Juha-P Lindfors [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] jbossmq selector parser grammer source
Date: Wed, 22 Aug 2001 13:01:02 +0300 (EET DST)
I have just fixed (and verified) both of these problems. Should I
On Wed, 22 Aug 2001, Dain Sundstrom wrote:
What do you mean by selector parser?
There is a parser.java which looks to be generated from a jms.y grammer
which is used to parse JMS message selectors. The generated parser source
is checked in but not the grammer.
--jason
I could adapt the
From: Juha-P Lindfors [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] jbossmq selector parser grammer source
Date: Wed, 22 Aug 2001 13:01:02 +0300 (EET DST)
I have just fixed (and verified) both of these problems. Should I
commit
On Wed, 22 Aug 2001, Jason Dillon wrote:
Do you know what is used to generate parser.java from jms.y?
//### This file created by BYACC 1.8(/Java extension 0.92)
//### Java capabilities added 7 Jan 97, Bob Jamison
//### Updated : 27 Nov 97 -- Bob Jamison, Joe Nieten
//### 01 Jan
I think Byacc. Can I get a win32 ver of that???
Regards,
Hiram
From: Jason Dillon [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] jbossmq selector parser grammer source
Date: Wed, 22 Aug 2001 12:41:33 -0700 (PDT)
Unless s has been toUpperCase
: Jason Dillon [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] jbossmq selector parser grammer source
Date: Wed, 22 Aug 2001 12:41:33 -0700 (PDT)
Unless s has been toUpperCase() (which I did not explictly check), then
this
is not spec compliant
Subject: Re: [JBoss-dev] jbossmq selector parser grammer source
Try http://troi.lincom-asg.com/~rjamison/byacc/
(at the bottom of the page)
it contains a win exe, with byaccj 1.1 (so slightly newer)
yacc -Jclass=parser jms.y
-- Juha
On Wed, 22 Aug 2001, Hiram Chirino wrote:
I think
Where do I get this from? I would like to integrate it into the build
system.
--jason
On Wed, 22 Aug 2001, Juha-P Lindfors wrote:
On Wed, 22 Aug 2001, Jason Dillon wrote:
Do you know what is used to generate parser.java from jms.y?
//### This file created by BYACC 1.8(/Java
: Re: [JBoss-dev] jbossmq selector parser grammer source
Date: Wed, 22 Aug 2001 12:41:33 -0700 (PDT)
Unless s has been toUpperCase() (which I did not explictly check), then
this
is not spec compliant. It needs to check for true and false too.
Do you know what is used to generate parser.java
I'm all for it.. Who knows yacc and javacc??
Regards,
Hiram
From: Jason Dillon [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] jbossmq selector parser grammer source
Date: Wed, 22 Aug 2001 14:43:12 -0700 (PDT)
Lets convert the grammer/parser
Hi Jason,
The way we implemented the message delivery this behaviour could happen, but
only when messages are arriving more slowly than they are being requested.
This is because the set of receivers waiting for messages is a HashSet so
that if a receiver sends a request for a message more
I am not an expert Is this sharing of a message queue receiving end
really spec compliant? How does it relate to order-of-messages guarantees?
It seems to me this may be the conceptual difference between message queues
and javaspaces..??
david jencks
On 2001.08.21 19:06:08 -0400 Jason
It does not say... this is one of the grey-areas of the spec. Most
providers will round-robin over multipule recievers. It is really too bad
that this is not more concreate, as JMS would provide a nice mech. for
distributing over a large group of machines, and allow for ordering and
such.
I
-
From: David Jencks [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 22, 2001 12:48 PM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] jbossmq load balancing across vms
I am not an expert Is this sharing of a message queue
receiving end
really spec compliant? How does it relate
What this means is that if you have multiple receivers waiting for a message
from a queue and a message arrives then it will be immediately delivered to
receiver A. Receiver A is now removed from the HashSet, however if receiver
A finishes its processing and requests another message before
of the requests.
The code I am talking about is the org.jboss.mq.server.BasicQueue class.
Cheers,
David.
-Original Message-
From: Jason Dillon [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 22, 2001 1:50 PM
To: '[EMAIL PROTECTED]'
Subject: RE: [JBoss-dev] jbossmq load balancing across
a byte array on every get) but has additional overhead for
dealing with RMI specific problems.
Cheers,
David
-Original Message-
From: Hiram Chirino [mailto:[EMAIL PROTECTED]]
Sent: Saturday, August 18, 2001 9:58 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JBossMQ
MarshalledObject always serializes an object using the same semantics
as marshaling and unmarshaling parameters and return values of RMI calls
- Original Message -
From: Hiram Chirino [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Friday, August 17, 2001 2:57 PM
Subject: Re: [JBoss-dev
a performance cost for convenience.
Cheers,
David.
-Original Message-
From: Matt Cleveland [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 21, 2001 3:09 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] JBossMQ ObjectMessage performance
I'm a little suprised that our XML
:[EMAIL PROTECTED]]
Sent: Tuesday, August 21, 2001 3:09 AM
To: [EMAIL PROTECTED]
Subject: RE: [JBoss-dev] JBossMQ ObjectMessage performance
I'm a little suprised that our XML serialization and parsing
code beats the performance of Java
serialization. Any thoughts on that?
What
, 2001 9:58 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] JBossMQ ObjectMessage performance
I think I can fix this... But I may have to use a
MarshalledObject to wrap
the object to support moving the message to the consumer
thread that may
have a different Classloader
I think I can fix this... But I may have to use a MarshalledObject to wrap
the object to support moving the message to the consumer thread that may
have a different Classloader that the publisher thread.
Am I wrong here??? If the the publisher is in the same vm as the receiver,
but the
Use the release-zip or release-tgz targets to build an archive.
--jason
On Fri, 17 Aug 2001, Hiram Chirino wrote:
Hi guys..
Finnaly! The jboss-mq has been tagged: RelMQ_1_0_0_1
This is the first public 1.0 beta release. Hopefully we can make this 1.0.0
final soon!
Could somebody make
You might also want to comment the build.id line in local.properties, so
that it uses a real build id.
--jason
On Fri, 17 Aug 2001, Jason Dillon wrote:
Use the release-zip or release-tgz targets to build an archive.
--jason
On Fri, 17 Aug 2001, Hiram Chirino wrote:
Hi guys..
On Thu, 16 Aug 2001, Scott M Stark wrote:
Due to the changes to the CVSROOT/modules file one can't checkout the 2.4 branch
of the jbossmq source using the previous syntax. The 2.4 branch needs to be checked
out using:
cvs co -r Branch_2_4 -P _jboss_messaging
which creates a messaging
problem.
Regards,
Hiram
From: Jason Dillon [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] jbossmq module alias breaks access to previous
branches
Date: Thu, 16 Aug 2001 15:36:08 -0700 (PDT)
On Thu, 16 Aug 2001, Scott M Stark wrote:
Due
hi hiram,
On 12 Aug 2001 18:19:39 -0400, Hiram Chirino wrote:
Well, seems like Paul Kendal's las set of changes made away with the pooled
executor.. I've heard some positive feed back on the change (the MQ is alot
faster now). I wish I could get a hold of a good test case that locks up
hi,
On 10 Aug 2001 12:56:42 -0700, Jason Dillon wrote:
Are you running off of jars built from jbossmq or are you using the version
that is integrated into jboss?
i'm running off the .jar files built from the jbossmq CVS module. the integrated
version (2.5 and 2.4) still locks up under load
1 - 100 of 117 matches
Mail list logo
