dev@glassfish.java.net

Re: reader-selectors and selectorThreadImpl

From: Justin Lee <Justin.Lee_at_Sun.COM>
Date: Thu, 02 Jul 2009 14:47:33 -0400

Jeanfrancois or Jan Luehe can better answer that one.

June.Parks_at_Sun.COM wrote:
> So what do they DO? The selectorThreadImpl property appears to take a
> class name as its value, but what is this class supposed to
> implement? What is a selector thread? What are reader selectors, and
> why would a user want to specify them?
>
> June
>
> On 07/02/09 11:21, Justin Lee wrote:
>> There are no defaults, per se. Not in the sense of the attributes
>> having default values at least. If they're not present then the
>> underlying engines do their normal thing.
>>
>> June.Parks_at_Sun.COM wrote:
>>> What do they do? What are their defaults?
>>>
>>> June
>>>
>>> On 07/02/09 11:04, Justin Lee wrote:
>>>> Those were the http-listener forms of those properties. Sadly,
>>>> they're still on http-service. I'd like to remove them all but
>>>> that has a rather wide impact.
>>>>
>>>> June.Parks_at_Sun.COM wrote:
>>>>> The authPassthroughEnabled, traceEnabled, and tcpNoDelay
>>>>> properties have been converted to attributes in the new network
>>>>> configuration, so it seems I can ignore those.
>>>>>
>>>>> I would like verification that the remaining properties, listed
>>>>> below, are for virtual servers. If they are for listeners, they
>>>>> don't belong under http-service anymore.
>>>> These all eventually get applied to the connector essentially
>>>> overriding settings on the listeners. Personally, I'd prefer to
>>>> remove PropertyBag support from all the network related interfaces
>>>> at least and promote the properties we're actually using to
>>>> attributes. It makes it so much easier to document what's
>>>> supported and with what values. And it makes breaks easier to
>>>> track since the compiler will let us know when we screw up in many
>>>> cases. But anyway. This is what we have now.
>>>>>
>>>>> connectionTimeout
>>>>> proxyHandler
>>>>> ssl-cache-entries
>>>>> ssl-session-timeout
>>>>> ssl3-session-timeout
>>>>> reader-selectors
>>>>> selectorThreadImpl
>>>>>
>>>>> I've never heard of reader-selectors or selectorThreadImpl. What
>>>>> do they do? What are their defaults?
>>>>>
>>>>> June
>>>>>
>>>>> On 07/02/09 08:16, Justin Lee wrote:
>>>>>> These are the http-service properties I'm finding that are still
>>>>>> referenced in v3:
>>>>>>
>>>>>> authPassthroughEnabled
>>>>>> connectionTimeout
>>>>>> proxyHandler
>>>>>> reader-selectors
>>>>>> selectorThreadImpl
>>>>>> ssl-cache-entries
>>>>>> ssl-session-timeout
>>>>>> ssl3-session-timeout
>>>>>> tcpNoDelay
>>>>>> traceEnabled
>>>>>>
>>>>>>
>>>>>>
>>>>>> June.Parks_at_Sun.COM wrote:
>>>>>>> On 07/01/09 14:17, Justin Lee wrote:
>>>>>>>> Is this related?
>>>>>>>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=6935
>>>>>>>>
>>>>>>>> For the record, properties on http-service are still supported
>>>>>>>> but not on any of the interfaces in grizzly-config because
>>>>>>>> depending on any glassfish related to bring in PropertyBag
>>>>>>>> would break the build.
>>>>>>> Okay, then I need to know SPECIFICALLY which properties of
>>>>>>> http-service are still supported. A whole bunch of them have
>>>>>>> been converted to attributes in the new Grizzly configuration.
>>>>>>> The following have not been converted. Which of these still
>>>>>>> work, given that they can only apply to virtual servers and not
>>>>>>> to listeners?
>>>>>>>
>>>>>>> use-nio-direct-bytebuffer
>>>>>>> rcmSupport
>>>>>>> proxyHandler
>>>>>>> proxiedProtocols
>>>>>>> recycle-objects
>>>>>>> reader-threads
>>>>>>> acceptor-queue-length
>>>>>>> reader-queue-length
>>>>>>> connectionTimeout
>>>>>>> monitoring-cache-enabled
>>>>>>> monitoring-cache-refresh-in-millis
>>>>>>> ssl-cache-entries
>>>>>>> ssl-session-timeout
>>>>>>> ssl3-session-timeout
>>>>>>>
>>>>>>> June
>>>>>>>>
>>>>>>>> Jan Luehe wrote:
>>>>>>>>> On 07/ 1/09 12:03 PM, June.Parks_at_Sun.COM wrote:
>>>>>>>>>> The Grizzly team told me that the proxy-related properties of
>>>>>>>>>> http-listener/http-service to which you refer are not
>>>>>>>>>> supported in the v3 network-service.
>>>>>>>>>
>>>>>>>>> I think that decision needs to be revisited.
>>>>>>>>>
>>>>>>>>> Jan
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> June
>>>>>>>>>>
>>>>>>>>>> On 07/01/09 11:52, Jan Luehe wrote:
>>>>>>>>>>> I'm trying to fix a package regression of an exposed interface.
>>>>>>>>>>>
>>>>>>>>>>> Earlier versions of GlassFish started exposing the
>>>>>>>>>>> com.sun.appserv.ProxyHandler interface, which is useful for
>>>>>>>>>>> when
>>>>>>>>>>> GlassFish is front-ended by an SSL-offloading load-balancer.
>>>>>>>>>>> Its
>>>>>>>>>>> default implementation (which works with Sun's load-balancer
>>>>>>>>>>> plug-in) is
>>>>>>>>>>> given by com.sun.enterprise.web.ProxyHandlerImpl, and
>>>>>>>>>>> alternative
>>>>>>>>>>> implementations may be specified (as http-listener/http-service
>>>>>>>>>>> properties, using their FQCN) in domain.xml.
>>>>>>>>>>>
>>>>>>>>>>> Since this has been an exposed interface, it must be
>>>>>>>>>>> preserved for
>>>>>>>>>>> backward compatibility reasons.
>>>>>>>>>>>
>>>>>>>>>>> In GlassFish v3, the ProxyHandler interface was moved from
>>>>>>>>>>> "com.sun.appserv" to "com.sun.appserv.security.provider".
>>>>>>>>>>>
>>>>>>>>>>> It needs to be moved back to its original package. In order
>>>>>>>>>>> to avoid any
>>>>>>>>>>> split-packages, that would mean moving ProxyHandler.java to
>>>>>>>>>>>
>>>>>>>>>>> common/common-util/src/main/java/com/sun/appserv
>>>>>>>>>>>
>>>>>>>>>>> which already contains BytecodePreprocessor.java and
>>>>>>>>>>> ClassLoaderUtil.java
>>>>>>>>>>> and therefore "owns" the com.sun.appserv package.
>>>>>>>>>>>
>>>>>>>>>>> ProxyHandler.java imports
>>>>>>>>>>> javax.servlet.http.HttpServletRequest, so if we
>>>>>>>>>>> moved it to "common/common-util", then we would also have to
>>>>>>>>>>> move
>>>>>>>>>>> "web/javax.servlet" to "javaee-api/javax.servlet", since
>>>>>>>>>>> "common" builds after
>>>>>>>>>>> "javaee-api", and to avoid any circular dependencies between
>>>>>>>>>>> "common" and "web".
>>>>>>>>>>>
>>>>>>>>>>> Does anybody see any issues with moving "web/javax.servlet" to
>>>>>>>>>>> "javaee-api/javax.servlet"?
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Jan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>> dev-help_at_glassfish.dev.java.net
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>
>>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>