Java Mailing List Archive

http://www.junlu.com/

Home » Home (12/2007) » JBoss User »

[JBoss-user] Re: Problem after problem... (Re: http session clustering)

Camron Levanger

2003-07-03

Replies:

Not to fuel your fire, but it really sounds like poorly written ejb's
and jsp's. When you get into that situation there is no "magic" cluster
to save it.
Also I don't know the history or details of this story, but...

What commit option are you using? Try option A with cache invalidation.
Make sure any beans doing "selects" are deployed read-only.
If you are using tomcat, make sure the max proccessors and acceptcount
are high enough.
Make sure the JVM is getting enough RAM.
Try a different JDK.

So many things, and I don't know your story, I'm sure you tried all of
these, but I hope I maybe helped.

Cam

Joao Clemente wrote:
> sorry for replying so late, but here goes:
> No, my problems are still not solved... And I almost gave up on this...
> This is my university thesis, and I'm already almost a year late (it should
> take a year and I've started my research almost two years ago). If this is
> not finished in the 2 year-time, the thesis will be cancelled by the
> university.
>
> I'm suposed to use JBoss to provide a "scalable, fault-tolerant and
> high-available middleware" infra-structure for a j2ee app that is being
> developed by another person.. another thesis that is being developed at the
> same time, a kind of a webmail on steroids..
> This j2ee application is build on top of a already developed open source
> webapplication (servlet+jsp). It was "redesigned" to use EJB's aswell. Then
> it was expanded with the help of a couple of more external libraries of
> other independent open-source projects..
> So we're talking about a webapp that was redisegned to be a j2ee app, and
> then glued to some other libs and projects and with some extra code
> developed here... Put a Ldap connection here, a jabber server there, a
> mailserver somewhere else and with a bit of luck you get something like
> this...
>
> About 10 months ago, I should had delivered tested results on how the jboss
> cluster can improve the scalability and fault-tolerance of this application.
> I'm failing miserably every test I make... day after day I crash into
> another problem, and I'm unable to get those test results...
>
> I'm not saying this is JBoss's fault... No. I've found a couple of bugs that
> were JBoss and Javagroups related, as you (sacha) can certainly remember.
> But those were not the reasons I'm failing every time I try...
>
> This app sucks. Thats the truth I'm already seeing for a long time ago and
> it's exactly that that my thesis advisor (togheter with the other theses
> developer and advisor) is refusing to see..
> Sure.. "but the app works fine", they say.
> "It's a problem on your side", they say...
> "It's your work to get that thing usable under load, it's what your research
> is suposed to do", they say..
>
> And, actually, if we use 1 (ONE!!!) client (wich, btw, must be
> InterntExplorer) , with 1 (A SINGLE ONE!!!) jboss server, and you test it
> manually... it works..
>
> But, for instance,
> - The app uses non-serializable objects all over the http session. This
> ceartainly gives us a hard time getting fault-tolerance (or failover) to
> work, besides the problems with the load-balancing...
> - The owner of the original project (the one that was redesigned here to
> have ejb's besides servlets and jsp's) admitted that it never tought of it
> to be clustered, and had no ideia of what was to be done for it to be
> runnable in a cluster...
>
> About three or four months ago I started writing java test programs using
> httpunit to load the app.. I've designed a simple client model that would
> just do four or five steps in the web app... Simple, right? Then added a
> threading model so I could have n similar clients accessing the webapp...
> Again, simple...
> I decided to test WITHOUT a cluster. So, there as been at least 3 months
> that I do NOT have a load balancer, i DO NOT have a clustered jboss setup,
> there is just 1 jboss server and my client application...
>
> Results? I'm almost willing to wait 'till the 2 years of my thesis end, my
> university cancels it, so that I can start something new from the scratch...
> With NO cluster involved:
>
> - with 1 client ,if I run my test case (get hompage, login, check mail,
> logout) for 6 times, I would get locked. End of story.
> - with 2 clients, would get about the same results..
> - with 4 clients, I would get little more than exceptions...
>
> oh, btw, in most of these cenarios, I' would not even be able to use the
> application manually, as it would enter a cicle redirecting me for the start
> page (it's a "feature" of this app: if something goes wrong then redirect to
> start page)... until I shutted down jboss and started it over (trying to
> undeploy the app would lock jboss)
>
>  and no, it does not stop here...
>  after some time, we found out that a singleton object of that j2ee app was
> unable to be runned concurrently and would cause the exception...
>  gimme some more headaches, and we find out that the locking was due to one
> of the external libs that were being used that, by some reason, locks under
> yet to be understood circuntances.. oh, and that lib was now deprecated..
>
>  ok, now what?
>  sending mail would work fine if used with InternetExplorer, but would give
> my java test client a error 500 page... Now what? Is it my client's code
> fault? Whose fault is it? Once again, one more week goes by and we find that
> there is another lib that was badly written..
>
>  At what point am I now? This app finally runs with 4 (FOUR!?!) concurrent
> clients... More than that and I get exceptions all over again... Gimme a
> break... I know JBoss is useable with hundrends of clients. I know it! I see
> it with my own short j2ee apps that I wrote for testing with my clustered
> setup!
>  This app, with a "no-cluster" environment breaks with 5 clients! It's
> impossible to but this in a cluster and make it work better... it sucks,
> period!
>
>
> But time keeps running and my thesis, my "scalable and fault-tolerant
> middleware for a j2e appp" is going down the drain... no way this app is
> going to be useable under load... and I keep banging my head on the wall
> each time I run my tests, see the exceptions, and think to my self... "ok...
> where is it now? is it my test code? is it the app? is is the xyz lib that
> the app uses? maybe it's the foo lib... maybe the mail server fault? maybe
> jboss this time? maybe this java vm implementation has a bug... maybe
> the..."
>
>
> sometimes I'm over a week or two without doing progress... I wake up in the
> morning, I just feel like crying and I think "why tha hell didn't I went for
> medicine school? what 'tha heck... maybe I can still be a plumber or
> something... maybe I should just be in bed..."
>
>
> ----- Original Message -----
> From: "Sacha Labourey" <sacha.labourey@(protected)>
> To: <jboss-user@(protected)>
> Sent: Sunday, June 08, 2003 5:22 AM
> Subject: RE: [JBoss-user] http session clustering
>
>
>
>>You're problem is still not resolved Joao?!?
>>
>>
>>>-----Original Message-----
>>>From: jboss-user-admin@(protected)
>>>[mailto:jboss-user-admin@(protected)
>>>Joao Clemente
>>>Sent: vendredi, 6. juin 2003 14:48
>>>To: jboss-user@(protected)
>>>Subject: Re: [JBoss-user] http session clustering
>>>
>>>
>>>
>>>----- Original Message -----
>>>From: "Stefano Maestri" <stefano.maestri@(protected)>
>>>To: <jboss-user@(protected)>
>>>Sent: Friday, June 06, 2003 10:44 AM
>>>Subject: Re: [JBoss-user] http session clustering
>>>
>>>
>>>
>>>>Thanks, it works.
>>>>just a suggestion add this on your very good "JBoss
>>>
>>>Clustering" docs.
>>>
>>>>And another thing: I read in jbossbook3.2.1 draft docs in
>>>
>>>chapter "Using
>>>
>>>>Clustering with Tomcat" this phrase:
>>>>"If you are using a load balancer, make sure that your
>>>
>>>setup uses sticky
>>>
>>>>session".
>>>>I'm agree that's better to use it to reduce the overload on
>>>
>>>JBoss, but it
>>>is
>>>
>>>>not necessary. Isn't it?
>>>>BTW we are using since 2 year LVS (LinuxVirtualServer) as
>>>
>>>load balancer
>>>with
>>>
>>>>JBoss, are you interested in my experience to integrate
>>>
>>>something about
>>>LVS
>>>
>>>>in your docs exactly as you did for apache?
>>>
>>>
>>>At least I am! I am trying to get that setup working correctly for an
>>>entreprise app for over a year now..
>>>This is my unversisty final work, and it has been delayed
>>>forever as I'm
>>>being unable to locate all the changes I need to do to get my app with
>>>fault-tolerance features...
>>>Every time I need to recover sessions (in particular http
>>>session) I have a
>>>really hard time 'till I find out where all those exceptions
>>>come from...
>>>I think the problem lies deep inside the app I'm using: It
>>>uses some objects
>>>kept inside the http session that are not serializable and
>>>therefore there
>>>is a need to recover them in a application level..
>>>In particular, I also setup a LVS with LVS-DR (I once had it
>>>with LVS-NAT)
>>>and in the end I had to enable persistence so that each user
>>>session sticks
>>>with a single server...
>>>So, if you had some approach for the problems found during the cluster
>>>setup, I would love to hear it...
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01




-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01
_______________________________________________
JBoss-user mailing list
JBoss-user@(protected)
https://lists.sourceforge.net/lists/listinfo/jboss-user


©2008 junlu.com - Jax Systems, LLC, U.S.A.