Hi Jeanfrancois,
> Harsha Godugu wrote:
>> Hi Jeanfrancois,
>>
>> I see some api changes related to worker thread impl in Grizzly
>> v1.7.3 Basically I think they are incompatible with applications that
>> were built on v1.7.2. Are we going to adhere to v1.7.2 for Glassfish
>> for now? (For example, please take a look at attach and detach api
>> calls which are public in both 1.7.2 and 1.7.3. They have change in
>> signature :-( ..)
>
> Yes, we discussed those at the Wednesday meeting after
>
> https://grizzly.dev.java.net/issues/show_bug.cgi?id=109
>
> Alexey talked about it and we decided to have them in 1.7.3.
I might have missed it. So, which version of Grizzly are we targeting
for GF v3 anyway?
I might want to make changes appropriately for corba/grizzly w/s.
>
>>
>> Also, on a different topic, did you / anyone noticed a spurious wake
>> up from Grizzly worker threads wait for task??
>
> No.
>
> Quite often I see 2
>> Grizzly worker threads entering almost near the same time into the
>> ProtocolFitler to read data and thereby causing a race for reading
>> data while in the ReadFilter. So, it leads to partial data read b/w 2
>> threads and hence, causes parsing errors.
>
> Hum...This is expected if your protocol chain is stateless. Is your
> protocol filter stateless or statefull?
My filter is stateless... except in one case: where it falls into the
thread attachment while expecting more bytes. I've a solution for this
problem. Just was curious if anyone else noted this here.
>
>
>>
>> Another request is, to strictly give Grizzly based names
>> (conventions) to threads that are getting started from within
>> Grizzly. This approach helps in identifying Grizzly generated
>> threads to user generated threads.
>
> File an RFE. I was under the impression the names were already easy to
> discover? Any recommendations?
You are right in some cases. For example, the worker threads get a name
like "GrizzlyWorkerThread-8080-4" which is crystal clear to know this
is worker thread on port 8080 with seq. id 4. There is no problem there.
It's about the SelectorRunner threads.. for example.. a quick grep in
grizzly workspace gives the following:
Controller.java: new Thread(readController).start();
Controller.java: Thread t = new Thread(selectorRunner);
ReadController.java: new Thread(selectorRunner).start();
SSLConnectorHandler.java: new Thread(controller).start();
TCPConnectorHandler.java: new Thread(controller).start();
UDPConnectorHandler.java: new Thread(controller).start();
Thanks,
Harsha
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: dev-help_at_grizzly.dev.java.net
>