One thing that I would find really useful is the ability to get each
thread size and process time which is somehow attributed to either a
realm or other accounting mechanism in order to give feedback to
different groups sharing a cluster. It would also help to monitor abuse
- ie if a clown decides
Jamie,
Could you try following patch for XAResourceTest.java. It is supposed to
fix empty branch id problem.
Jamie Burns wrote:
> By way of reminder, the exception is:
>
> javax.transaction.xa.XAException
> at com.microsoft.jdbcx.base.BaseXAResource.checkXid(Unknown Source)
> at com.microsof
Number of tests run: 946
Successful tests: 916
Errors:21
Failures: 9
[time of test: 22 September 2002 2:28 GMT]
[java.version: 1.3.1_03]
[java.vendor: Sun Microsystems
I only have two requests... 1) make the interface/page/whatever easily
queried (via Perl preferably) and 2)make it part of the standard jboss
distribution.
For monitoring I'm going to want to write a plugin for whatever
monitoring tool I use in order to collect statistical information as
well
Dain Sundstrom wrote:
> Michael Bartmann wrote:
>
>> Everybody heathy?
>>
>> If you operate a 24*7 production plant with a server like JBoss,
>> you shurely care about the "health" of your server. Now in theory
>> this is nearly trivial: we have JMX and friends.
>> Any kind of monitoring can be d
David Jencks wrote:
>
>
>>>2) Thread usage
>>>If you are not an expert on every single part of JBoss, it might be
>>>a detectives work to find out where all those nice threads in the
>>>threaddump come from.
>>>This is even more criticall, as we migrate to centrally managed thread
>>>pools, whe
> > 2) Thread usage
> > If you are not an expert on every single part of JBoss, it might be
> > a detectives work to find out where all those nice threads in the
> > threaddump come from.
> > This is even more criticall, as we migrate to centrally managed thread
> > pools, where its more easy to
Michael Bartmann wrote:
> Everybody heathy?
>
> If you operate a 24*7 production plant with a server like JBoss,
> you shurely care about the "health" of your server. Now in theory
> this is nearly trivial: we have JMX and friends.
> Any kind of monitoring can be done with it, but do we do? Of co
Neale Swinnerton wrote:
> The problem was (is?) that BCEL uses arrays rather than collections in
> it's API to generate the byte code so you end up doing lots of
> Collection -> array -> Collection manipulation.
>
> At the time there was no easy way to map java.lang.ref.Method et al to
> the BCEL
Gaaa! I swore up, down, and sideways I'd have an MBean written for that, and I've
just had a really bad run in my personal time that's kept me from it. I'm trying to
get that packaged up this weekend.
-Original Message-
From: Michael Bartmann [mailto:[EMAIL PROTECT
Change Notes item #612531, was opened at 2002-09-21 15:37
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=381174&aid=612531&group_id=22866
Category: JBossMX
Group: v4.0
Status: Open
Priority: 5
Submitted By: Adrian Brock (ejort)
Assigned to: Nobody/Anonymous (nobod
Everybody heathy?
If you operate a 24*7 production plant with a server like JBoss,
you shurely care about the "health" of your server. Now in theory
this is nearly trivial: we have JMX and friends.
Any kind of monitoring can be done with it, but do we do? Of course
a lot of aspects are applicatio
On Fri, 2002-09-20 at 16:38, Dain Sundstrom wrote:
> Thanks Scott.
>
> I think the proxy code needs a good rewrite. It seems to use a lot
> complicated code and array tricks because the writer decided not to use
> the collections APIs.
>
> If we can simplify this code, I think we should chan
Phil,
It has been suggested that Jetties approach of testing each certificate
in turn until one passes is incorrect. As the array of certificates
indicates the chain of trust and they all need to be checked to
verify authentication.
As we are already passing an object as a credential to the re
14 matches
Mail list logo
