[bug] websocket generics?

[Romain Manni-Bucau]

Hi,

I know websocket 1.0 methods without providing the handler type are kind of
deprecated (not recommended would be more correct) so not sure this bug
would get a fix or not.
Long story
short, 
org.apache.tomcat.websocket.WsSession#addMessageHandler(jakarta.websocket.MessageHandler)
will call Util.getMessageType which goes into the reflection code and the
interesting part is org.apache.tomcat.websocket.Util#getGenericType and
more precisely TypeResult superClassTypeResult = getGenericType(type,
superClazz); which can return null (end of recursion) but next line being int
dimension = superClassTypeResult.getDimension(); we can get a NPE.

The fix is trivial but I'mnot sure it is worth it or just redirecting to
the right API would be better.

Side note: for the context i'm using records instead of pojo, not very
important since I guess interfaces would lead to the same issues but makes
it more concrete.

Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | Book

Re: Supposed to provide performance at daemon thread in tomcat

[koteswara Rao Gundapaneni]

hi all,

On high level view if i look at up with reflection we use in tomcat code
for the existing class in Bootstrap and core jvm methods internally works
excellent

On Sat, Jan 20, 2024 at 11:57 PM koteswara Rao Gundapaneni <
koti.gundapan...@gmail.com> wrote:

> I am going to provide unit tests through which I identifies the
> performance issue at core JVM method
>
> Let me provide this
>
> On Tue, 16 Jan 2024, 21:15 Christopher Schultz, <
> ch...@christopherschultz.net> wrote:
>
>> Hello,
>>
>> On 1/15/24 03:45, koteswara Rao Gundapaneni wrote:
>> > On Sun, 14 Jan 2024, 18:13 koteswara Rao Gundapaneni, <
>> > koti.gundapan...@gmail.com> wrote:
>> >
>> >> hi
>> >>
>> >> Daemon threads have identified the performance issue inorder to
>> complete .
>> >>
>> >
>> >
>> > Thread which is set as daemon by default has performance bottleneck
>> >
>> > I explain that as below
>> >
>> > myeg.setDaemon(true);
>> > myeg.start();
>> >
>> >
>> > the above start() method is taking long time to complete which is by
>> > default performance bottleneck
>>
>> The Thread.start() method is not something under the control of the
>> Apache Tomcat team. That is a core JVM method.
>>
>> >> so bootstrap has its performance issue as this loader thread is using
>> >> daemon thread.
>> >>
>> >
>> >
>> > In our code base we have lot of places where we have the code as below
>> as
>> > mentioned above.
>> >
>> > myeg.setDaemon(true);
>> > myeg.start();
>>
>> Whose code is "our code"?
>>
>> >> inorder to resolve the issue we will yield the corresponding thread
>> >>
>> >
>> >
>> > Inorder to limit the time taking for above line of code we have the
>> > solution like below
>> >
>> > myeg.setDaemon(true);
>> > myeg.start();
>> > myeg.yield();
>>
>> How can a call to Thread.yield() which is made *after* a call to
>> Thread.start() make the call to Thread.start() execute more quickly?
>>
>> Here is the documentation for Thread.yield (with emphasis added by me):
>>
>> "
>> A hint to the scheduler that the current thread is willing to yield its
>> current use of a processor. **The scheduler is free to ignore this hint.**
>>
>> Yield is a heuristic attempt to improve relative progression between
>> threads that would otherwise over-utilise a CPU. Its use should be
>> combined with detailed profiling and benchmarking to ensure that it
>> actually has the desired effect.
>>
>> **It is rarely appropriate to use this method.** It may be useful for
>> debugging or testing purposes, where it may help to reproduce bugs due
>> to race conditions. It may also be useful when designing concurrency
>> control constructs such as the ones in the java.util.concurrent.locks
>> package.
>> "
>>
>> Note that calling someOtherThread.yield() actually causes the current
>> thread (e.g. Main in your likely example) to yield, rather than
>> instructing someOtherThread to yield.
>>
>> If this is intentional, it looks like what you are trying to do is
>> instruct the current thread to cause Thread called "myeg" (aka
>> someOtherThread) to start and then to immediate yield the current
>> thread's time back to the scheduler.
>>
>> This should not be necessary.
>>
>> > the yield method declared as above will reduce the time taking for start
>> > method
>> >
>> >
>> >
>> > Hope this will make sense if not I will write it in my own language
>> telugu.
>>
>> I get the idea you are trying to convey, but it does not make much
>> technical sense to me.
>>
>> Your code for Bootstrap.start() is using reflection to invoke
>> Catalina.start from your main thread. But you are not running any of
>> your own code in any non-main thread, so of course the call to
>> Catalina.start is taking "a long time": there is a lot of work to be
>> done to bring a server online.
>>
>> If you want your main thread to continue while Catalina is starting,
>> then you should run that in a separate thread. For example:
>>
>> new Thread(r -> catalina.start()).start();
>>
>> If you think there is a performance problem in Apache Tomcat, the best
>> way to demonstrate it is with a Unit Test which reproduces the problem.
>>
>> What you are presenting appears to be either a misunderstanding of
>> threading in Java or a misuse of Tomcat's Catalina class.
>>
>> If you are concerned with performance, you might want to use less
>> reflection in your code, since it's very slow compared to direct method
>> invocations.
>>
>> -chris
>>
>> >> On Sun, Jan 14, 2024 at 4:13 AM Mark Thomas  wrote:
>> >>
>> >>> You have yet to provide an explanation of the problem you are trying
>> to
>> >>> solve.
>> >>>
>> >>> Unless and until you provide the information requested, further
>> messages
>> >>> from you on this topic will be ignored.
>> >>>
>> >>> Mark
>> >>>
>> >>>
>> >>> On 14/01/2024 12:05, koteswara Rao Gundapaneni wrote:
>>  hi team
>> 
>>  before clicking the link or check new private window in mozilla
>> 
>>  image.png
>> 
>> 
>> 
>>  when we browse the following link
>> 
>