It is complicated.
I have a client, which communicates with a servlet running on one JBoss
server. That servlet then proxies one or more requests from the client to a
stateless session bean running inside of another JBoss server. That bean
creates 2 entities and the enqueues a messsage via the JMS RA to a queue
that resides on yet another JBoss server.
There is then a MDB running on the same machine as the first session bean,
which reads the message, uses JMX to lookup an MBean to finish the
processing. That MBean creates a stateful session bean and starts up a new
thread. Inside that thread the session bean is called in a loop. Each call
to the session bean causes some disk io, the creation of 2 more entity
beans, updates to one of the first beans created (in the first paragraph)
and finally another message gets queued via the JMS RA.
There is another MDB running on another JBoss server which reads this
message. It then creates or uses a pooled object to do some relavant
processing. That object uses vanilla JMS to enqueue a response to the
message when completed (or failed). In some cases where the invokation of
this object failes, then the MDB will send the response (through the same
mechanism).
That response is read by yet another MDB running on the same machine as the
first MDB, which creates or looks up a created statefull session bean to
handle the response. That bean will then update the beans created for the
request and a controlling bean (all entities).
So, that is 5 virtual machines:
o client
o jms router
o web server
o request creation/response handler
o worker
Everything but the client is running in a JBoss server built from CVS.
All JMS is done via the RMI IL, since I ran into too many problems with OIL
and UIL.
Durring all of this, the client will continue to poll, which will cause one
of the first created entities to be reloaded to check the state of things.
Now I understand that I could have all of this running in the same vm, but
the nature of the application is to scale by adding hardware, so I need to
test each logical component close to it's production usage.
As a side note, all of the beans are marked with TIO = Required, which could
be causing some problems, but should work regardless.
The "dispatcher" has a connection to an Oracle 8 database via the JBossPool
drivers (because I had too much problems with the Oracle versions a while
ago).
* * *
So I updated my JBoss after you checked in the EEI change, but still ran
into server hangs:
Customer [Thread-13] WARN - Transaction XidImpl [FormatId=257,
GlobalId=reason//160, BranchQual=] timed out. status=STATUS_COMMITING
Customer [Thread-14] WARN - Transaction XidImpl [FormatId=257,
GlobalId=reason//165, BranchQual=] timed out. status=STATUS_ACTIVE
So I tired narrowing things down by not running the vm with the last MDB and
things looked alot better. I also tried starting that VM but not having it
respond, which worked... though to actually test all of this takes some time
(to load up the required params and such).
Any ways... it is complicated. All of this worked with 2.3 (though I was
not using the JMS RA). As a side note, it only seems to break when I try to
put it under a high message volume (by high I mean 50 or so... from the
first first statfull session bean to the second MDB).
*sigh*
--jason
On Wed, 11 Jul 2001, Scott M Stark wrote:
> Generate a thread dump using SIGHUP or Ctrl-\ on unix/linux or Ctrl-Break on
> win32.
> This should be the first step to any deadlock/starvation investigation. The
> sun vm
> tends to produce garbage dumps with HotSpot so turn it off using
> the -classic
> switch.
>
> MDBs are involed in the lock unit test so what are you running?
>
> ----- Original Message -----
> From: "Jason Dillon" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, July 11, 2001 8:57 PM
> Subject: [JBoss-dev] EntityInstanceInterceptor change
>
>
> > What was the problem... the diff is more or less the entire file. I am
> > curious, because I am still running into a hang, though it seems like it
> > might be MDB or SB related (not sure at the moment).
> >
> > --jason
> >
>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
>
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
