You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Jay Burgess <li...@vtgroup.com> on 2006/02/21 21:54:17 UTC
RE: never say never...
The following comments are not intended to be a personal attack on anyone.
However, I can't stand by and watch George speak my mind for me, word for word,
and not chime in and say "I agree!". Plus, I think if you took a poll, you'd
find he speaks for a large number of list subcribers.
Whether you want to admit it or not, there has been a history of downright
rudeness by certain people on this list when it comes to certain issues. The
constant "RESOLVED/INVALID" and "If you open it again, I will close it."
comments need to stop. Besides the fact that they alienate potential useful
members of the community, I think less time would probably be spent by all
parties involved if the first answer to one of these issues was educational,
instead of being rude and lacking useful feedback.
Maybe George's raising this issue will make everyone think twice the next time
they're about to dismiss one of these issues so quickly.
Fortunately/unfortunately, there are are always going to be newbies and people
that don't know enough about list protocol, etc. The "professional" response,
though, is to treat every one of them with respect.
Jay
| Jay Burgess [Vertical Technology Group]
| http://www.vtgroup.com/
-----Original Message-----
From: George Sexton [mailto:gsexton@mhsoftware.com]
Sent: Tuesday, February 21, 2006 1:12 PM
To: 'Tomcat Developers List'
Subject: RE: never say never...
> -----Original Message-----
> From: Martin van den Bemt [mailto:mllist@mvdb.net]
> Sent: Tuesday, February 21, 2006 11:24 AM
> To: Tomcat Developers List
> Subject: Re: never say never...
>
> You are pretty bad in taking examples.
The example I took was specifically chosen because his comments are
incorrect. I suppose I could have put his opening comments where he was
baiting me but I chose to ignore those.
> Bill nicely described
> the why nicely in nice words
Bill started out his comments by baiting me. Whether it was done nicely or
not depends upon which side of the stick you're on.
> (don't
> know who is right or wrong, I don't care about that)
If you don't know what is wrong or right how do you know Bill gave a great
answer? It may have been a pleasant answer, but how can an answer be great
if its not right?
>> ) and your answer to that is quite unapropiate.
>> Especially the shouting. Just say you think he is
>> wrong, because of xxx and everyone is happy..
Mladen's comments were pretty intemperate as well. They were accusatory and
belittling (joining the "Elite" trash). I think most people would be moved
to shout at this point.
> In short : I think Bill gave a great answer and you didn't
> return that favour.
No. Bill gave a wrong answer. He ignored in the fact that java.io.tmpdir and
javax.servlet.context.tempdir are equivalent in implementation in Tomcat,
and that to be compliant, Tomcat has to make java.io.tmpdir writable.
>
> And another thing : I (and others do to I guess) read
> bugzilla mails, so no need to copy & paste
> that thing to a thread that has nothing to do with the thread
> (despite to what you seem to think).
>
Mladen specifically referenced the issue. I felt it appropriate in my reply
to reference the whole context. I re-posted the relevant portions to
bugzilla after drafting the message.
George Sexton
MH Software, Inc.
http://www.mhsoftware.com/
Voice: 303 438 9585
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: never say never...
Posted by Leon Rosenberg <ro...@googlemail.com>.
On 2/25/06, Wade Chandler <hw...@yahoo.com> wrote:
> I thought about not even writing this. Then I thought
> about not even submitting it. Don't take it
> personally how ever it hits anyone. I think it's
> fair.
>
> I think it runs both ways. I think most of the Tomcat
> developers are really great. I think an unnamed
> developer could learn how to be a little nicer. I
> think a good number of users could as well. There is
> no good excuse for simply being mean and nasty for
> users nor developers.
>
+1
...
> Anyways, many thanks to the Tomcat developers. I
> think almost every one of them are really great guys (and/or girls)
+1 and another +1
>
> Wade
>
Leon
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: DTrace analysis of TC-Cluster Multicast
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
correctness can be achieved in many different ways, synchronization
just happens to be the easiest one.
The build is working, including session replication (modules
groupcom,ha,storeconfig-ha), just uncomment one line in
container/modules/build.properties and tomcat builds the new modules
instead of the old.
I have a lot of refactoring and optimization left to do.
Filip
Rainer Jung wrote:
> I agree, heartbeat is not that important w.r.t. performance. I used it
> as a simple test for how DTrace will be able to help. And at least in
> that nearly trivial test case the results are already interesting.
>
> Another thing that DTrace can check is lock contention. So there's
> more to come :)
>
> Do you have a working build of groupcom? I could trace some of the
> group communication.
>
> I hope you will not sacrifice synchronization correctness for
> performance ...
>
> Rainer
>
> Filip Hanik - Dev Lists wrote:
>> Cool Rainer, interesting numbers. Can you run the same numbers on the
>> new module groupcom.
>> I have done some optimizations there, for example, the name isn't
>> broadcasted. And I am about to remove the domain, instead of having a
>> default one. also, I agree, lets not translate the 4byte IP and the
>> 4byte port when receiving it. instead, member comparisons can be done
>> on the byte array level, excellent suggestion.
>>
>> After that I won't be spending to much focus on this issue, as a
>> heartbeat do not really have to be optimized. The heartbeat runs
>> *very* infrequently and it not a critical piece.
>>
>> Instead I am gonna start reworking the data senders, there are way
>> too many synchronized calls locking down the sockets, the code is
>> somewhat cluttered then I am gonna move on to serialization. In the
>> current cluster module, too much gets serialized, in the new module
>> "ha" I have already removed a lot of serialization and will continue
>> stripping it out.
>>
>> Filip
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: DTrace analysis of TC-Cluster Multicast
Posted by Rainer Jung <to...@kippdata.de>.
I agree, heartbeat is not that important w.r.t. performance. I used it
as a simple test for how DTrace will be able to help. And at least in
that nearly trivial test case the results are already interesting.
Another thing that DTrace can check is lock contention. So there's more
to come :)
Do you have a working build of groupcom? I could trace some of the group
communication.
I hope you will not sacrifice synchronization correctness for
performance ...
Rainer
Filip Hanik - Dev Lists wrote:
> Cool Rainer, interesting numbers. Can you run the same numbers on the
> new module groupcom.
> I have done some optimizations there, for example, the name isn't
> broadcasted. And I am about to remove the domain, instead of having a
> default one. also, I agree, lets not translate the 4byte IP and the
> 4byte port when receiving it. instead, member comparisons can be done on
> the byte array level, excellent suggestion.
>
> After that I won't be spending to much focus on this issue, as a
> heartbeat do not really have to be optimized. The heartbeat runs *very*
> infrequently and it not a critical piece.
>
> Instead I am gonna start reworking the data senders, there are way too
> many synchronized calls locking down the sockets, the code is somewhat
> cluttered then I am gonna move on to serialization. In the current
> cluster module, too much gets serialized, in the new module "ha" I have
> already removed a lot of serialization and will continue stripping it out.
>
> Filip
>
> Rainer Jung wrote:
>> Hi,
>>
>> I started to trace TC cluster with DTrace. I did a first simple exam for
>> the mcast subcomplex. CPU usage and especially elapsed times might be
>> slightly larger than expected, because I used the more intrusive
>> extended DTrace probes.
>>
>> All tests were done with JDK 1.6.0 build 72 on Solaris 10 SPARC, using a
>> T2000 system (8 cores with 4 Threads each).
>>
>> Method allocation elapsed cpu
>> mcast/McastServiceImpl.send() 1328B 40ms 6.7ms
>> mcast/McastServiceImpl.receive() 744-760B 23-510ms 3.5ms
>>
>> So this does not look very bad, but I inspected, where cpu time is used
>> and objects get allocated:
>>
>> 1) send cpu time, elapsed time and allocation, per send
>>
>> cpu elapsed alloc
>> 6.7ms 40.3ms 1328B McastServiceImpl.send()
>>
>> 6.3ms 37.6ms 1296B McastMember.getData()
>>
>> 1.3ms 7.6ms 136B ... getName().getBytes();
>> 0.9ms 5.3ms 120B ... getDomain().getBytes();
>> 3.6ms 21.2ms 880B ... java.net.InetAddress.getByName(host)...
>>
>> It's interesting, that the last three statements are responsible for 85%
>> of the allocation and 90% of the cpu usage. This seems unnecessary,
>> because for sending multicast heartbeat, name, domain and host do not
>> change, so they could be buffered easily.
>>
>> 2) receive cpu time, elapsed time and allocation, per receive
>>
>> cpu elapsed alloc
>> 3.5ms 23-510ms 744-760B McastServiceImpl.receive()
>>
>> 0.1ms 3-485ms 0B socket.receive()
>> 2.8ms 17.9ms 640B McastMember.getMember()
>>
>> 1.4ms 8.1ms 160B new String(named),
>> 1.0ms 5.6ms 128B new String(domaind),
>> 0.1ms 0.6ms 112B addressToString(addr),
>>
>> 0.3ms 2.7ms 16B ... membership.memberAlive(m) [Only 50%]
>> 0.2ms 2.3ms 32B ... membership.expire(timeToExpiration);
>> ...
>>
>> The calls to memberAlive are much faster in ~50% of the calls.
>>
>> Here most interesting is the fact, that the string construction takes
>> 70% of total cpu time. I inspected, why this is so. For the next trace I
>> had to increase the depth I traced, so elapsed times go a little up. The
>> columns are:
>>
>> - ">" or "<": ">" means start of method, "<" end of method
>> - stack depth relative to the receive method
>> - cpu time
>> - elapsed time
>> - allocated bytes
>> - class and method
>>
>>> 3 - - - java/lang/String.<init>
>>> 4 - - - java/lang/String.<init>
>>> 5 - - - java/lang/StringCoding.decode
>>> 6 - - - java/lang/StringCoding.decode
>>> 7 - - - java/lang/StringCoding.deref
>> < 7 0.1ms 0.7ms 0 java/lang/StringCoding.deref
>>> 7 - - - java/lang/StringCoding$StringDecoder.decode
>>> 8 - - - java/nio/ByteBuffer.wrap
>> < 8 0.1ms 0.5ms 48 java/nio/ByteBuffer.wrap
>>> 8 - - - java/nio/CharBuffer.wrap
>> < 8 0.1ms 0.5ms 48 java/nio/CharBuffer.wrap
>>> 8 - - - java/nio/charset/CharsetDecoder.decode
>> < 8 0.7ms 4.4ms 0 java/nio/charset/CharsetDecoder.decode
>> < 7 1.1ms 7.8ms 160 java/lang/StringCoding$StringDecoder.decode
>> < 6 1.2ms 9.1ms 160 java/lang/StringCoding.decode
>> < 5 1.2ms 9.5ms 160 java/lang/StringCoding.decode
>> < 4 1.3ms 10.1ms 160 java/lang/String.<init>
>> < 3 1.3ms 10.2ms 160 java/lang/String.<init>
>>
>> So we can see, that most of the cpu time is needed inside
>>
>> - java/nio/charset/CharsetDecoder.decode: 0.7ms
>> - java/lang/StringCoding.deref: 0.1ms
>> - java/nio/ByteBuffer.wrap: 0.1ms
>> - java/nio/CharBuffer.wrap: 0.1ms
>>
>> Maybe it would help to use a more byte-oriented format in the heartbeat
>> messages and to not convert from it. String conversions might be
>> restrictable to the case when logging in debug mode.
>>
>> Cheers,
>>
>> Rainer
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: DTrace analysis of TC-Cluster Multicast
Posted by Filip Hanik - Dev Lists <de...@hanik.com>.
Cool Rainer, interesting numbers. Can you run the same numbers on the
new module groupcom.
I have done some optimizations there, for example, the name isn't
broadcasted. And I am about to remove the domain, instead of having a
default one. also, I agree, lets not translate the 4byte IP and the
4byte port when receiving it. instead, member comparisons can be done on
the byte array level, excellent suggestion.
After that I won't be spending to much focus on this issue, as a
heartbeat do not really have to be optimized. The heartbeat runs *very*
infrequently and it not a critical piece.
Instead I am gonna start reworking the data senders, there are way too
many synchronized calls locking down the sockets, the code is somewhat
cluttered then I am gonna move on to serialization. In the current
cluster module, too much gets serialized, in the new module "ha" I have
already removed a lot of serialization and will continue stripping it out.
Filip
Rainer Jung wrote:
> Hi,
>
> I started to trace TC cluster with DTrace. I did a first simple exam for
> the mcast subcomplex. CPU usage and especially elapsed times might be
> slightly larger than expected, because I used the more intrusive
> extended DTrace probes.
>
> All tests were done with JDK 1.6.0 build 72 on Solaris 10 SPARC, using a
> T2000 system (8 cores with 4 Threads each).
>
> Method allocation elapsed cpu
> mcast/McastServiceImpl.send() 1328B 40ms 6.7ms
> mcast/McastServiceImpl.receive() 744-760B 23-510ms 3.5ms
>
> So this does not look very bad, but I inspected, where cpu time is used
> and objects get allocated:
>
> 1) send cpu time, elapsed time and allocation, per send
>
> cpu elapsed alloc
> 6.7ms 40.3ms 1328B McastServiceImpl.send()
>
> 6.3ms 37.6ms 1296B McastMember.getData()
>
> 1.3ms 7.6ms 136B ... getName().getBytes();
> 0.9ms 5.3ms 120B ... getDomain().getBytes();
> 3.6ms 21.2ms 880B ... java.net.InetAddress.getByName(host)...
>
> It's interesting, that the last three statements are responsible for 85%
> of the allocation and 90% of the cpu usage. This seems unnecessary,
> because for sending multicast heartbeat, name, domain and host do not
> change, so they could be buffered easily.
>
> 2) receive cpu time, elapsed time and allocation, per receive
>
> cpu elapsed alloc
> 3.5ms 23-510ms 744-760B McastServiceImpl.receive()
>
> 0.1ms 3-485ms 0B socket.receive()
> 2.8ms 17.9ms 640B McastMember.getMember()
>
> 1.4ms 8.1ms 160B new String(named),
> 1.0ms 5.6ms 128B new String(domaind),
> 0.1ms 0.6ms 112B addressToString(addr),
>
> 0.3ms 2.7ms 16B ... membership.memberAlive(m) [Only 50%]
> 0.2ms 2.3ms 32B ... membership.expire(timeToExpiration);
> ...
>
> The calls to memberAlive are much faster in ~50% of the calls.
>
> Here most interesting is the fact, that the string construction takes
> 70% of total cpu time. I inspected, why this is so. For the next trace I
> had to increase the depth I traced, so elapsed times go a little up. The
> columns are:
>
> - ">" or "<": ">" means start of method, "<" end of method
> - stack depth relative to the receive method
> - cpu time
> - elapsed time
> - allocated bytes
> - class and method
>
>> 3 - - - java/lang/String.<init>
>> 4 - - - java/lang/String.<init>
>> 5 - - - java/lang/StringCoding.decode
>> 6 - - - java/lang/StringCoding.decode
>> 7 - - - java/lang/StringCoding.deref
> < 7 0.1ms 0.7ms 0 java/lang/StringCoding.deref
>> 7 - - - java/lang/StringCoding$StringDecoder.decode
>> 8 - - - java/nio/ByteBuffer.wrap
> < 8 0.1ms 0.5ms 48 java/nio/ByteBuffer.wrap
>> 8 - - - java/nio/CharBuffer.wrap
> < 8 0.1ms 0.5ms 48 java/nio/CharBuffer.wrap
>> 8 - - - java/nio/charset/CharsetDecoder.decode
> < 8 0.7ms 4.4ms 0 java/nio/charset/CharsetDecoder.decode
> < 7 1.1ms 7.8ms 160 java/lang/StringCoding$StringDecoder.decode
> < 6 1.2ms 9.1ms 160 java/lang/StringCoding.decode
> < 5 1.2ms 9.5ms 160 java/lang/StringCoding.decode
> < 4 1.3ms 10.1ms 160 java/lang/String.<init>
> < 3 1.3ms 10.2ms 160 java/lang/String.<init>
>
> So we can see, that most of the cpu time is needed inside
>
> - java/nio/charset/CharsetDecoder.decode: 0.7ms
> - java/lang/StringCoding.deref: 0.1ms
> - java/nio/ByteBuffer.wrap: 0.1ms
> - java/nio/CharBuffer.wrap: 0.1ms
>
> Maybe it would help to use a more byte-oriented format in the heartbeat
> messages and to not convert from it. String conversions might be
> restrictable to the case when logging in debug mode.
>
> Cheers,
>
> Rainer
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
DTrace analysis of TC-Cluster Multicast
Posted by Rainer Jung <to...@kippdata.de>.
Hi,
I started to trace TC cluster with DTrace. I did a first simple exam for
the mcast subcomplex. CPU usage and especially elapsed times might be
slightly larger than expected, because I used the more intrusive
extended DTrace probes.
All tests were done with JDK 1.6.0 build 72 on Solaris 10 SPARC, using a
T2000 system (8 cores with 4 Threads each).
Method allocation elapsed cpu
mcast/McastServiceImpl.send() 1328B 40ms 6.7ms
mcast/McastServiceImpl.receive() 744-760B 23-510ms 3.5ms
So this does not look very bad, but I inspected, where cpu time is used
and objects get allocated:
1) send cpu time, elapsed time and allocation, per send
cpu elapsed alloc
6.7ms 40.3ms 1328B McastServiceImpl.send()
6.3ms 37.6ms 1296B McastMember.getData()
1.3ms 7.6ms 136B ... getName().getBytes();
0.9ms 5.3ms 120B ... getDomain().getBytes();
3.6ms 21.2ms 880B ... java.net.InetAddress.getByName(host)...
It's interesting, that the last three statements are responsible for 85%
of the allocation and 90% of the cpu usage. This seems unnecessary,
because for sending multicast heartbeat, name, domain and host do not
change, so they could be buffered easily.
2) receive cpu time, elapsed time and allocation, per receive
cpu elapsed alloc
3.5ms 23-510ms 744-760B McastServiceImpl.receive()
0.1ms 3-485ms 0B socket.receive()
2.8ms 17.9ms 640B McastMember.getMember()
1.4ms 8.1ms 160B new String(named),
1.0ms 5.6ms 128B new String(domaind),
0.1ms 0.6ms 112B addressToString(addr),
0.3ms 2.7ms 16B ... membership.memberAlive(m) [Only 50%]
0.2ms 2.3ms 32B ... membership.expire(timeToExpiration);
...
The calls to memberAlive are much faster in ~50% of the calls.
Here most interesting is the fact, that the string construction takes
70% of total cpu time. I inspected, why this is so. For the next trace I
had to increase the depth I traced, so elapsed times go a little up. The
columns are:
- ">" or "<": ">" means start of method, "<" end of method
- stack depth relative to the receive method
- cpu time
- elapsed time
- allocated bytes
- class and method
> 3 - - - java/lang/String.<init>
> 4 - - - java/lang/String.<init>
> 5 - - - java/lang/StringCoding.decode
> 6 - - - java/lang/StringCoding.decode
> 7 - - - java/lang/StringCoding.deref
< 7 0.1ms 0.7ms 0 java/lang/StringCoding.deref
> 7 - - - java/lang/StringCoding$StringDecoder.decode
> 8 - - - java/nio/ByteBuffer.wrap
< 8 0.1ms 0.5ms 48 java/nio/ByteBuffer.wrap
> 8 - - - java/nio/CharBuffer.wrap
< 8 0.1ms 0.5ms 48 java/nio/CharBuffer.wrap
> 8 - - - java/nio/charset/CharsetDecoder.decode
< 8 0.7ms 4.4ms 0 java/nio/charset/CharsetDecoder.decode
< 7 1.1ms 7.8ms 160 java/lang/StringCoding$StringDecoder.decode
< 6 1.2ms 9.1ms 160 java/lang/StringCoding.decode
< 5 1.2ms 9.5ms 160 java/lang/StringCoding.decode
< 4 1.3ms 10.1ms 160 java/lang/String.<init>
< 3 1.3ms 10.2ms 160 java/lang/String.<init>
So we can see, that most of the cpu time is needed inside
- java/nio/charset/CharsetDecoder.decode: 0.7ms
- java/lang/StringCoding.deref: 0.1ms
- java/nio/ByteBuffer.wrap: 0.1ms
- java/nio/CharBuffer.wrap: 0.1ms
Maybe it would help to use a more byte-oriented format in the heartbeat
messages and to not convert from it. String conversions might be
restrictable to the case when logging in debug mode.
Cheers,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: never say never...
Posted by Wade Chandler <hw...@yahoo.com>.
--- Bill Barker <wb...@wilshire.com> wrote:
>
>
> > -----Original Message-----
> > From: Wade Chandler
> [mailto:hwadechandler-apache@yahoo.com]
> > Sent: Friday, February 24, 2006 4:57 PM
> > To: Tomcat Developers List
> > Subject: Re: never say never...
> >
> > --- "William A. Rowe, Jr." <wr...@rowe-clan.net>
> > wrote:
>
> >
> > Anyways, many thanks to the Tomcat developers. I
> > think almost every one of them are really great
> guys.
>
> I'm not certain how Amy is going to take that ;-).
>
> >
> > Wade
> >
Yes to be politically correct. :-D They are really
great people.
Wade
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: never say never...
Posted by Bill Barker <wb...@wilshire.com>.
> -----Original Message-----
> From: Wade Chandler [mailto:hwadechandler-apache@yahoo.com]
> Sent: Friday, February 24, 2006 4:57 PM
> To: Tomcat Developers List
> Subject: Re: never say never...
>
> --- "William A. Rowe, Jr." <wr...@rowe-clan.net>
> wrote:
>
> Anyways, many thanks to the Tomcat developers. I
> think almost every one of them are really great guys.
I'm not certain how Amy is going to take that ;-).
>
> Wade
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
This message is intended only for the use of the person(s) listed above as the intended recipient(s), and may contain information that is PRIVILEGED and CONFIDENTIAL. If you are not an intended recipient, you may not read, copy, or distribute this message or any attachment. If you received this communication in error, please notify us immediately by e-mail and then delete all copies of this message and any attachments.
In addition you should be aware that ordinary (unencrypted) e-mail sent through the Internet is not secure. Do not send confidential or sensitive information, such as social security numbers, account numbers, personal identification numbers and passwords, to us via ordinary (unencrypted) e-mail.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: never say never...
Posted by Wade Chandler <hw...@yahoo.com>.
--- "William A. Rowe, Jr." <wr...@rowe-clan.net>
wrote:
> Glen Mazza wrote:
> > Haroon Rafique wrote:
> >
> >> On Tuesday at 12:54pm, JB=>Jay Burgess
> <li...@vtgroup.com> wrote:
> >>
> >> JB> The following comments are not intended to be
> a personal attack on
> >> JB> anyone. However, I can't stand by and watch
> George speak my mind
> >> for JB> me, word for word, and not chime in and
> say "I agree!". Plus,
> >> I think JB> if you took a poll, you'd find he
> speaks for a large
> >> number of list JB> subcribers.
> >>
> >> Yes Jay, other members have that feeling too. If
> we take a look at the
> >> recent past, there are various examples of
> rudeness, impropriety and
> >> lack of respect.
> >
> > Well, my sympathies are more with the Tomcat
> developer team, given the
> > abuse they incur from certain unfortunate
> individuals in the user
> > community.
>
> You mean by the same unfortunate individuals who
> like to abuse their
> checkout clerk, bank teller and doctor's
> receptionist? Odd, they tend
> to excuse themselves that they are paying for that
> privilage; Funny
> I don't recall seeing a donation check from them to
> the ASF.
>
> Bill
I thought about not even writing this. Then I thought
about not even submitting it. Don't take it
personally how ever it hits anyone. I think it's
fair.
I think it runs both ways. I think most of the Tomcat
developers are really great. I think an unnamed
developer could learn how to be a little nicer. I
think a good number of users could as well. There is
no good excuse for simply being mean and nasty for
users nor developers.
Without mentioning any names: If one could see a list
of what contracts and monetary connections are made
through the Apache project for certain members they
would see some things a little differently, and I do
not mean that any of the developers deserve to be
yelled at or belittled. For instance, I'm sure a few
JBoss customers might find a couple of bugs and
comments associated with them a little disturbing. I
would imagine a few other commercial customers of
other companies using projects based on Tomcat would
as well. This based on my own experiences with aiding
in explaining a couple of issues found in Tomcat.
Some things do not require arguing about. They simply
need to be looked at and egos need not get in the way.
So, not to kick up the flames, just being real; I
don't think it is as black and white as some people
would like to believe in relation to volunteering
hours to the project vs being compensated. The same
can be said about Eclipse, Netbeans, etc. Many
projects today have incorporated corporate interests
into their ranks (whether it's admitted or not).
Companies employ people to work on these projects, so
they aren't doing it for free. Others are
contributing their time to also utilize others time
and selling products based on these open source
projects and making a good amount of money doing so.
Then some 3rd party softwares based on these solutions
are bought by users. The company they purchased their
software from spends money in donations or contributes
developers to the projects. Money = Time and Time =
Money. Lets face it, if these companies were not
making money from from these open source projects they
would not be contributing. They like the collective
free time and work, which is also why many contribute
to projects. Others contribute in their free time one
way or another mostly just for fun.
Anyways, many thanks to the Tomcat developers. I
think almost every one of them are really great guys.
Wade
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: never say never...
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
Glen Mazza wrote:
> Haroon Rafique wrote:
>
>> On Tuesday at 12:54pm, JB=>Jay Burgess <li...@vtgroup.com> wrote:
>>
>> JB> The following comments are not intended to be a personal attack on
>> JB> anyone. However, I can't stand by and watch George speak my mind
>> for JB> me, word for word, and not chime in and say "I agree!". Plus,
>> I think JB> if you took a poll, you'd find he speaks for a large
>> number of list JB> subcribers.
>>
>> Yes Jay, other members have that feeling too. If we take a look at the
>> recent past, there are various examples of rudeness, impropriety and
>> lack of respect.
>
> Well, my sympathies are more with the Tomcat developer team, given the
> abuse they incur from certain unfortunate individuals in the user
> community.
You mean by the same unfortunate individuals who like to abuse their
checkout clerk, bank teller and doctor's receptionist? Odd, they tend
to excuse themselves that they are paying for that privilage; Funny
I don't recall seeing a donation check from them to the ASF.
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: never say never...
Posted by Glen Mazza <gr...@verizon.net>.
Haroon Rafique wrote:
> On Tuesday at 12:54pm, JB=>Jay Burgess <li...@vtgroup.com> wrote:
>
> JB> The following comments are not intended to be a personal attack on
> JB> anyone. However, I can't stand by and watch George speak my mind for
> JB> me, word for word, and not chime in and say "I agree!". Plus, I think
> JB> if you took a poll, you'd find he speaks for a large number of list
> JB> subcribers.
> JB>
>
> Yes Jay, other members have that feeling too. If we take a look at the
> recent past, there are various examples of rudeness, impropriety and lack
> of respect.
>
Well, my sympathies are more with the Tomcat developer team, given the
abuse they incur from certain unfortunate individuals in the user
community.
> There's the thread:
> http://marc.theaimsgroup.com/?t=113107961000002&r=1&w=2
> Subject: Sloppy, Lazy Tomcat Developers (Was: Persistent) which speaks
> volumes about how the tomcat dev community is turning people away.
>
I checked the thread and didn't see anything wrong with what was stated
by the Tomcat developers. They're only properly defending themselves
against abuse from a disrespectful user. How would you expect any team
to respond to an email with a subject of "Sloppy, Lazy Tomcat Developers"?
Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: never say never...
Posted by Haroon Rafique <ha...@utoronto.ca>.
On Tuesday at 12:54pm, JB=>Jay Burgess <li...@vtgroup.com> wrote:
JB> The following comments are not intended to be a personal attack on
JB> anyone. However, I can't stand by and watch George speak my mind for
JB> me, word for word, and not chime in and say "I agree!". Plus, I think
JB> if you took a poll, you'd find he speaks for a large number of list
JB> subcribers.
JB>
Yes Jay, other members have that feeling too. If we take a look at the
recent past, there are various examples of rudeness, impropriety and lack
of respect.
There's the thread:
http://marc.theaimsgroup.com/?t=113107961000002&r=1&w=2
Subject: Sloppy, Lazy Tomcat Developers (Was: Persistent) which speaks
volumes about how the tomcat dev community is turning people away.
Constant threats of banning people don't help:
http://marc.theaimsgroup.com/?l=tomcat-dev&m=113109876214068&w=2
and
http://marc.theaimsgroup.com/?l=tomcat-dev&m=113803462800300&w=2
and
http://marc.theaimsgroup.com/?l=tomcat-dev&m=113654919116826&w=2
In addition, what does a guy need to do get his bug fixed!!!!???
I don't claim to be an expert by any means and the quality of the patch is
not that great either, but come on:
http://marc.theaimsgroup.com/?l=tomcat-dev&m=113024930913866&w=2
Subject: solicit some interest in fixing bug 36847 (PatchAvailable)
and
http://marc.theaimsgroup.com/?l=tomcat-dev&m=113742608431361&w=2
Subject: squeaky wheel gets the oil (so please fix bug 36847)
So, yes, the persistent among us will keep trying but, for sure, a few of
use will be turned away for good.
Cheers,
--
Haroon Rafique
<ha...@utoronto.ca>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org