Re: Mod_Jk2 - Default Worker
Costin Manolache wrote: Henri Gomez wrote: Well, if we didn't get the POST somewhere on the WebServer, and if the tomcat failed to respond, we couldn't resent the whole POST to the second one. If we get the first bytes ( but not the entire POST ), we can still save them, and if the first tomcat fails - resend it. When a tomcat responds - it can ask for more bytes. If a tomcat is failing in the middle of the processing - it's better to report the error and not try to recover. The strategy will be to keep, say up to 32kb on Apache pools, and if the POST is larger save it to filesystem. I'm not sure I understand the problem with saving only the first part of the POST data. The request that is sent to tomcat only includes those bytes anyway - tomcat has to ask for more. The problem is that getting the entier body changes the processing model for POST fundamentally - the entire streaming is gone, servlets that may reject the POST ( because the size is too big for example ) will still have the entier body downloaded, etc. Are you sure this is absolutely needed ? Not sure, I'm only an human. BTW, I'll commit the POST recovery scheme used in jk to jk2, so it will be available for 2.0.4 (together with ping/pong and others goodies from latest jk). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_Jk2 - Default Worker
Bill Barker wrote: - Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 12, 2004 11:03 AM Subject: Re: Mod_Jk2 - Default Worker Henri Gomez wrote: Well, if we didn't get the POST somewhere on the WebServer, and if the tomcat failed to respond, we couldn't resent the whole POST to the second one. If we get the first bytes ( but not the entire POST ), we can still save them, and if the first tomcat fails - resend it. When a tomcat responds - it can ask for more bytes. If a tomcat is failing in the middle of the processing - it's better to report the error and not try to recover. +1. If tomcat has already gotten the body, and then dies, if you attempt to recover you will have charged the user's credit card twice :). Such problem should be handled at the application side, not by the connector. BTW, I hardcoded my boss credit card for the second request :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_Jk2 - Default Worker
Costin Manolache wrote: NormW wrote: Good morning Costin. Apologies for the silence. I had hoped there might have been a little more input from others on this topic. Same here :-) We're working, Jean-Frederic, Kurt and I in arranging 2.0.4 build so new features should wait for 2.0.5. BTW, I add some fix in jk 1.2.x to make POST recovery in LB mode and I agree that the LB shouldn't be seen as a worker. What I like to see to make easier the LoadBalancing/Failover in jk2 : - in service, grab request HEADERS and POST datas and store BOTH in the service land. - forward the HEADERS/POST datas to the first worker, and if transmission failed or no replies came after XXX seconds, forward the HEADERS/POST to another worker and so on. When I see how ajp13 works in jk (don't look at jk2 for now), the mix of buffers is a nightmare, since ajp13 mix send part of datas from webserver to tomcat, and reception of datas from tomcat to webserver. What I'd like to see is a more simpler communication system, where webserver will send ONE packet containing HEADERS and another with POST datas (if needed). However the most common case is to have at least one tomcat, and there is no real benefit in supporting an arbitrary name for the worker ( lb:lb ) or in mapping the request directly to the protocol. I think the goal should be to have the protocol ( ajp worker ) register itself automatically with the lb:lb. That mapping only exists now because it is implemented by the worker. The worker is the logical recipient if the functionality offered by the lb worker was not required. (There is enough for a worker to manage, even without the protocol, to justify its existence as an object.). All that is missing from the scenario is the protocol to be a part of the channel or perhaps an intermediate layer. Not sure what you mean - the worker name is very overloaded, there are many ways to interpret. My point was that the mapping is done between a URI and a tomcat ( either a standalone instance or a group ). This is represented by lb - which should be the only target for the mapping. The lb will then use a channel ( ajp object ) to connect to the tomcat. The role of lb is to implement the forwarding of the request via the ajp object, with load balancing or failover ( if multiple channel/ajp objects exist ). The fact that both the channel ( ajp ) and the lb are implementing the worker interface is IMO confusing. I think it's better to have an lb that can dynamically be configured with more channels, does retry, balancing and failover - as a separate entity- separated from the channel ( that just forwards a request ). IMO getting to this point requires removing some of the (arbitrary ) flexibility in naming workers or bypassing the lb. From an 'objects' perspective, it is inconsistent with current practice to 'parse' object names (CN in ldap parlence) for properties of the object, when those properties have unique identifiers such as port and host. Hence I support arbitrary naming ;-( CN ( and distinguished names in JNDI as well as jmx object names ) is the source for the object names in jk2. I know it's a religious issue if the name should mean something or not - and probably that's a reason we'll have to keep supporting the arbitrary names. IMO we should deprecate the arbitrary names and only support JMX-like object names, with using the properties to extract information like host, etc. In any case - it's Henri and the other people actively involved in this release you need to convince :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_Jk2 - Default Worker
Henri Gomez wrote: Costin Manolache wrote: NormW wrote: Good morning Costin. Apologies for the silence. I had hoped there might have been a little more input from others on this topic. Same here :-) We're working, Jean-Frederic, Kurt and I in arranging 2.0.4 build so new features should wait for 2.0.5. BTW, I add some fix in jk 1.2.x to make POST recovery in LB mode and I agree that the LB shouldn't be seen as a worker. What I like to see to make easier the LoadBalancing/Failover in jk2 : - in service, grab request HEADERS and POST datas and store BOTH in the service land. POST data could be very big. - forward the HEADERS/POST datas to the first worker, and if transmission failed or no replies came after XXX seconds, forward the HEADERS/POST to another worker and so on. When I see how ajp13 works in jk (don't look at jk2 for now), the mix of buffers is a nightmare, since ajp13 mix send part of datas from webserver to tomcat, and reception of datas from tomcat to webserver. What I'd like to see is a more simpler communication system, where webserver will send ONE packet containing HEADERS and another with POST datas (if needed). May be better to send an empty POST data packet. However the most common case is to have at least one tomcat, and there is no real benefit in supporting an arbitrary name for the worker ( lb:lb ) or in mapping the request directly to the protocol. I think the goal should be to have the protocol ( ajp worker ) register itself automatically with the lb:lb. That mapping only exists now because it is implemented by the worker. The worker is the logical recipient if the functionality offered by the lb worker was not required. (There is enough for a worker to manage, even without the protocol, to justify its existence as an object.). All that is missing from the scenario is the protocol to be a part of the channel or perhaps an intermediate layer. Not sure what you mean - the worker name is very overloaded, there are many ways to interpret. My point was that the mapping is done between a URI and a tomcat ( either a standalone instance or a group ). This is represented by lb - which should be the only target for the mapping. The lb will then use a channel ( ajp object ) to connect to the tomcat. The role of lb is to implement the forwarding of the request via the ajp object, with load balancing or failover ( if multiple channel/ajp objects exist ). The fact that both the channel ( ajp ) and the lb are implementing the worker interface is IMO confusing. I think it's better to have an lb that can dynamically be configured with more channels, does retry, balancing and failover - as a separate entity- separated from the channel ( that just forwards a request ). IMO getting to this point requires removing some of the (arbitrary ) flexibility in naming workers or bypassing the lb. From an 'objects' perspective, it is inconsistent with current practice to 'parse' object names (CN in ldap parlence) for properties of the object, when those properties have unique identifiers such as port and host. Hence I support arbitrary naming ;-( CN ( and distinguished names in JNDI as well as jmx object names ) is the source for the object names in jk2. I know it's a religious issue if the name should mean something or not - and probably that's a reason we'll have to keep supporting the arbitrary names. IMO we should deprecate the arbitrary names and only support JMX-like object names, with using the properties to extract information like host, etc. In any case - it's Henri and the other people actively involved in this release you need to convince :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_Jk2 - Default Worker
jean-frederic clere wrote: Henri Gomez wrote: Costin Manolache wrote: NormW wrote: Good morning Costin. Apologies for the silence. I had hoped there might have been a little more input from others on this topic. Same here :-) We're working, Jean-Frederic, Kurt and I in arranging 2.0.4 build so new features should wait for 2.0.5. BTW, I add some fix in jk 1.2.x to make POST recovery in LB mode and I agree that the LB shouldn't be seen as a worker. What I like to see to make easier the LoadBalancing/Failover in jk2 : - in service, grab request HEADERS and POST datas and store BOTH in the service land. POST data could be very big. I agree but we could still detect VERY BIG POST (not the usual case), and save them on disk. The goal is to have in fine a bullet proof LB connector. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_Jk2 - Default Worker
Hi Costin, Good morning Costin. Apologies for the silence. I had hoped there might have been a little more input from others on this topic. I think it is also necessary to discuss a bit the proper configuration of mod_jk2. The docu is all other but clear, mixed up with the docu for mod_jk, and I see that the jkstatus output differs heavily with only slight other configs; also I think we should add a minimal config to the binary distributions; I want to have a config which is easy to change, and works without change in 98% of installations; and is just enough to connect to TC, access the docu, and execute the samples. here's a sample which works without a workers2.properties file: http://www.gknw.com/development/apache/docs/win32/mod_jk2/mod_jk2x.conf and here a nearly mininal workers2.properties file: http://www.gknw.com/development/apache/docs/win32/mod_jk2/min_w2.properties common with both configs is that there's only one place where you have to change the host and port if necessary; and that's what I call user-friendly. also would be nice to have some hints in the docu about where to put uri stuff, benefit of having them in mod_jk2.conf, and samples for lb mode. if you have a few minutes please test both configs and check how the jkstatus differs... Guenter. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_Jk2 - Default Worker
Henri Gomez wrote: jean-frederic clere wrote: Henri Gomez wrote: Costin Manolache wrote: NormW wrote: Good morning Costin. Apologies for the silence. I had hoped there might have been a little more input from others on this topic. Same here :-) We're working, Jean-Frederic, Kurt and I in arranging 2.0.4 build so new features should wait for 2.0.5. BTW, I add some ftix in jk 1.2.x to make POST recovery in LB mode and I agree that the LB shouldn't be seen as a worker. What I like to see to make easier the LoadBalancing/Failover in jk2 : - in service, grab request HEADERS and POST datas and store BOTH in the service land. POST data could be very big. I agree but we could still detect VERY BIG POST (not the usual case), and save them on disk. The goal is to have in fine a bullet proof LB connector. We could save only some initial chunk - for example what is needed to fill the first Ajp packet. My understanding is that this is the current behavior - just obfuscated. I think the protocl would work even if you don't send any byte of the POST data in the first packet, the only reason we send post data is to avoid round-trips for very small posts. Keeping the entire POST can be dangerous ( out of memory on apache side, etc ). It is very possible the servlet will just reject the request and never read the IS. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_Jk2 - Default Worker
Costin Manolache wrote: Henri Gomez wrote: jean-frederic clere wrote: Henri Gomez wrote: Costin Manolache wrote: NormW wrote: Good morning Costin. Apologies for the silence. I had hoped there might have been a little more input from others on this topic. Same here :-) We're working, Jean-Frederic, Kurt and I in arranging 2.0.4 build so new features should wait for 2.0.5. BTW, I add some ftix in jk 1.2.x to make POST recovery in LB mode and I agree that the LB shouldn't be seen as a worker. What I like to see to make easier the LoadBalancing/Failover in jk2 : - in service, grab request HEADERS and POST datas and store BOTH in the service land. POST data could be very big. I agree but we could still detect VERY BIG POST (not the usual case), and save them on disk. The goal is to have in fine a bullet proof LB connector. We could save only some initial chunk - for example what is needed to fill the first Ajp packet. My understanding is that this is the current behavior - just obfuscated. I think the protocl would work even if you don't send any byte of the POST data in the first packet, the only reason we send post data is to avoid round-trips for very small posts. Keeping the entire POST can be dangerous ( out of memory on apache side, etc ). It is very possible the servlet will just reject the request and never read the IS. Well, if we didn't get the POST somewhere on the WebServer, and if the tomcat failed to respond, we couldn't resent the whole POST to the second one. The strategy will be to keep, say up to 32kb on Apache pools, and if the POST is larger save it to filesystem. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_Jk2 - Default Worker
Henri Gomez wrote: Well, if we didn't get the POST somewhere on the WebServer, and if the tomcat failed to respond, we couldn't resent the whole POST to the second one. If we get the first bytes ( but not the entire POST ), we can still save them, and if the first tomcat fails - resend it. When a tomcat responds - it can ask for more bytes. If a tomcat is failing in the middle of the processing - it's better to report the error and not try to recover. The strategy will be to keep, say up to 32kb on Apache pools, and if the POST is larger save it to filesystem. I'm not sure I understand the problem with saving only the first part of the POST data. The request that is sent to tomcat only includes those bytes anyway - tomcat has to ask for more. The problem is that getting the entier body changes the processing model for POST fundamentally - the entire streaming is gone, servlets that may reject the POST ( because the size is too big for example ) will still have the entier body downloaded, etc. Are you sure this is absolutely needed ? Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_Jk2 - Default Worker
Good morning Costin. NormW wrote: Good morning Costin. Apologies for the silence. I had hoped there might have been a little more input from others on this topic. Same here :-) However the most common case is to have at least one tomcat, and there is no real benefit in supporting an arbitrary name for the worker ( lb:lb ) or in mapping the request directly to the protocol. I think the goal should be to have the protocol ( ajp worker ) register itself automatically with the lb:lb. That mapping only exists now because it is implemented by the worker. The worker is the logical recipient if the functionality offered by the lb worker was not required. (There is enough for a worker to manage, even without the protocol, to justify its existence as an object.). All that is missing from the scenario is the protocol to be a part of the channel or perhaps an intermediate layer. Not sure what you mean - the worker name is very overloaded, there are many ways to interpret. * Apologies for the mixup I knew what I meant. I meant 'worker' in a functional sense as an object/entity that accepts a URI request from Apache and who's sole job is to do all the management processes required to deliver that URI to a Tomcat and back to the client, except actually getting it there. If this object is functionally tweaked for this role it more than adequately meets a large number of user requirements. It is only when features like fail-over, clustering and load-balancing are added to the overall requirement, is an entity with the current 'skills' of an lb-type 'worker' required to decide which 'worker/object' gets the task of processing the request. One doesn't have to stand back very far to discover that is almost what exists now. My point was that the mapping is done between a URI and a tomcat ( either a standalone instance or a group ). This is represented by lb - which should be the only target for the mapping. The lb will then use a channel ( ajp object ) to connect to the tomcat. The role of lb is to implement the forwarding of the request via the ajp object, with load balancing or failover ( if multiple channel/ajp objects exist ). The fact that both the channel ( ajp ) and the lb are implementing the worker interface is IMO confusing. I think it's better to have an lb that can dynamically be configured with more channels, does retry, balancing and failover - as a separate entity- separated from the channel ( that just forwards a request ). * This dual interface to a single logical task is 'normal' in a lot of things, for example, a one man business and an enterprise employing a number of similarly skilled workers but fronted by a manager who decides which worker gets the job. One should be able to scale the enterprise for the overall task at hand rather than have a manager in front of a single person. (Sounds like a government department.) IMO getting to this point requires removing some of the (arbitrary ) flexibility in naming workers or bypassing the lb. From an 'objects' perspective, it is inconsistent with current practice to 'parse' object names (CN in ldap parlence) for properties of the object, when those properties have unique identifiers such as port and host. Hence I support arbitrary naming ;-( CN ( and distinguished names in JNDI as well as jmx object names ) is the source for the object names in jk2. I know it's a religious issue if the name should mean something or not - and probably that's a reason we'll have to keep supporting the arbitrary names. IMO we should deprecate the arbitrary names and only support JMX-like object names, with using the properties to extract information like host, etc. Acknowledge being unfamiliar with the JMX standard, but if it means not parsing object names for properties then I'm a supporter. In any case - it's Henri and the other people actively involved in this release you need to convince :-) * I don't have 'barrow' to push much beyond wanting to make mod_jk2 function in what I perceive is a logical way and have it's modular design become visible enough to remove a lot of the questions I see on user groups about configuring it. If I convince anyone to re-evaluate past decisions it is a by-product. Costin Norm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_Jk2 - Default Worker
- Original Message - From: Costin Manolache [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, February 12, 2004 11:03 AM Subject: Re: Mod_Jk2 - Default Worker Henri Gomez wrote: Well, if we didn't get the POST somewhere on the WebServer, and if the tomcat failed to respond, we couldn't resent the whole POST to the second one. If we get the first bytes ( but not the entire POST ), we can still save them, and if the first tomcat fails - resend it. When a tomcat responds - it can ask for more bytes. If a tomcat is failing in the middle of the processing - it's better to report the error and not try to recover. +1. If tomcat has already gotten the body, and then dies, if you attempt to recover you will have charged the user's credit card twice :). The strategy will be to keep, say up to 32kb on Apache pools, and if the POST is larger save it to filesystem. I'm not sure I understand the problem with saving only the first part of the POST data. The request that is sent to tomcat only includes those bytes anyway - tomcat has to ask for more. The problem is that getting the entier body changes the processing model for POST fundamentally - the entire streaming is gone, servlets that may reject the POST ( because the size is too big for example ) will still have the entier body downloaded, etc. Are you sure this is absolutely needed ? Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_Jk2 - Default Worker
Good morning Costin. Apologies for the silence. I had hoped there might have been a little more input from others on this topic. NormW wrote: Good morning Costin. Thanks for the time given to replying. I agree with the ideas you have given, of decoupling URI's from workers explicitly tied to a communications protocol, but in reality this connectivity is supported and actually gives the minimum workable configuration. But given that a default architecture is but a 'guess', I see the programming to be 'cleaner' without such defaults and rather provide a 'default' configuration file that would achieve the same end. The present situation hides the basic building blocks of Mod_Jk2 and leads to the majority of questions in regard to how to reconfigure the module. Remove the ability of 'workers' to directly accept requests and force all URI's through an lb type, and the current default approach would be entirely appropriate. Yes, it would be nice to make a clean cut and use a different interface for protocol workers ( channels ) and lb and similar request processors. Lb is not only load balancing - it also implements fail over and can be used to accept registration for tomcat instances - i.e. a sort of zero config, with tomcat instance(s) announcing themself to lb. nameurigroup context * null null null *// lb:lb / Given the present arrangement, I can understand (if not support) the lb:lb uri entry above but the one assigned to a 'null' group with a uri of 'null' seems to be a bug. It is a bug. Even the second can be considered a bug - if no tomcat instance is present there is no need for an lb:lb. * With a release of mod_jk2 imminent, someone might look at this perhaps? However the most common case is to have at least one tomcat, and there is no real benefit in supporting an arbitrary name for the worker ( lb:lb ) or in mapping the request directly to the protocol. I think the goal should be to have the protocol ( ajp worker ) register itself automatically with the lb:lb. That mapping only exists now because it is implemented by the worker. The worker is the logical recipient if the functionality offered by the lb worker was not required. (There is enough for a worker to manage, even without the protocol, to justify its existence as an object.). All that is missing from the scenario is the protocol to be a part of the channel or perhaps an intermediate layer. In the advanced case, of multiple pools or instances handling different webapps - there is no harm in having a default ( lb:lb ) and explicitely mapping the webapps that don't fall into the default with lb:GROUP names. This case can be zero-configured by having each tomcat instance self-register with ajp URI and GROUP ( plus the webapps ) Given the diversity of structures that mod_jk2 can implement, having a default configuration only caters for a portion of them. Catering for none forces 'exposure' of the few building blocks that mod_jk2 actually has available, and would help to remove a lot of the mod_jk/jk2 mystique. IMO getting to this point requires removing some of the (arbitrary ) flexibility in naming workers or bypassing the lb. From an 'objects' perspective, it is inconsistent with current practice to 'parse' object names (CN in ldap parlence) for properties of the object, when those properties have unique identifiers such as port and host. Hence I support arbitrary naming ;-( As noted, the proposed patch subtracts nothing from the present position, while allowing access to the parameter if required. That's a very common problem - having additional configuration flexibility, but without any immediate benefit. It doesn't substract anything, but it may prevent future simplifications. Point taken. Equally, it's absence today shouldn't automatically mitigated against its existence tomorrow. If 'mod_jk3' should evolve perhaps I'm ok with any renaming or clarification or defaults - as long as we keep or increase the current separation between protocols ( i.e. ajp-like workers ) and clusters/instances - or however you want to call the lb-like workers. That tie-up exists because the worker name was derived from the protocol. Ideally the protocol should have been in the channel, leaving the 'worker' to handle _a_ request, and lb to decide which worker to get it... assuming there is more than one Tomcat to receive it. However, it still doesn't make much sense to have a balancer capability in front of a single worker. I think we discussed this a lot in the past - and my proposal was to stop using the term worker :-) The request is mapped by a mapper that decides if it's a servlet and to which group it should go ( with lb:lb as a clear default ), then the lb decides on a particular channel. mod_jk1 does this using a single concept - worker, in jk2 I think a lot have changed to split things into
Re: Mod_Jk2 - Default Worker
NormW wrote: Good morning Costin. Apologies for the silence. I had hoped there might have been a little more input from others on this topic. Same here :-) However the most common case is to have at least one tomcat, and there is no real benefit in supporting an arbitrary name for the worker ( lb:lb ) or in mapping the request directly to the protocol. I think the goal should be to have the protocol ( ajp worker ) register itself automatically with the lb:lb. That mapping only exists now because it is implemented by the worker. The worker is the logical recipient if the functionality offered by the lb worker was not required. (There is enough for a worker to manage, even without the protocol, to justify its existence as an object.). All that is missing from the scenario is the protocol to be a part of the channel or perhaps an intermediate layer. Not sure what you mean - the worker name is very overloaded, there are many ways to interpret. My point was that the mapping is done between a URI and a tomcat ( either a standalone instance or a group ). This is represented by lb - which should be the only target for the mapping. The lb will then use a channel ( ajp object ) to connect to the tomcat. The role of lb is to implement the forwarding of the request via the ajp object, with load balancing or failover ( if multiple channel/ajp objects exist ). The fact that both the channel ( ajp ) and the lb are implementing the worker interface is IMO confusing. I think it's better to have an lb that can dynamically be configured with more channels, does retry, balancing and failover - as a separate entity- separated from the channel ( that just forwards a request ). IMO getting to this point requires removing some of the (arbitrary ) flexibility in naming workers or bypassing the lb. From an 'objects' perspective, it is inconsistent with current practice to 'parse' object names (CN in ldap parlence) for properties of the object, when those properties have unique identifiers such as port and host. Hence I support arbitrary naming ;-( CN ( and distinguished names in JNDI as well as jmx object names ) is the source for the object names in jk2. I know it's a religious issue if the name should mean something or not - and probably that's a reason we'll have to keep supporting the arbitrary names. IMO we should deprecate the arbitrary names and only support JMX-like object names, with using the properties to extract information like host, etc. In any case - it's Henri and the other people actively involved in this release you need to convince :-) Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mod_Jk2 - Default Worker
NormW wrote: Good morning Costin. Thanks for the time given to replying. I agree with the ideas you have given, of decoupling URI's from workers explicitly tied to a communications protocol, but in reality this connectivity is supported and actually gives the minimum workable configuration. But given that a default architecture is but a 'guess', I see the programming to be 'cleaner' without such defaults and rather provide a 'default' configuration file that would achieve the same end. The present situation hides the basic building blocks of Mod_Jk2 and leads to the majority of questions in regard to how to reconfigure the module. Remove the ability of 'workers' to directly accept requests and force all URI's through an lb type, and the current default approach would be entirely appropriate. Yes, it would be nice to make a clean cut and use a different interface for protocol workers ( channels ) and lb and similar request processors. Lb is not only load balancing - it also implements fail over and can be used to accept registration for tomcat instances - i.e. a sort of zero config, with tomcat instance(s) announcing themself to lb. nameurigroup context * null null null *// lb:lb / Given the present arrangement, I can understand (if not support) the lb:lb uri entry above but the one assigned to a 'null' group with a uri of 'null' seems to be a bug. It is a bug. Even the second can be considered a bug - if no tomcat instance is present there is no need for an lb:lb. However the most common case is to have at least one tomcat, and there is no real benefit in supporting an arbitrary name for the worker ( lb:lb ) or in mapping the request directly to the protocol. I think the goal should be to have the protocol ( ajp worker ) register itself automatically with the lb:lb. In the advanced case, of multiple pools or instances handling different webapps - there is no harm in having a default ( lb:lb ) and explicitely mapping the webapps that don't fall into the default with lb:GROUP names. This case can be zero-configured by having each tomcat instance self-register with ajp URI and GROUP ( plus the webapps ) IMO getting to this point requires removing some of the (arbitrary ) flexibility in naming workers or bypassing the lb. As noted, the proposed patch subtracts nothing from the present position, while allowing access to the parameter if required. That's a very common problem - having additional configuration flexibility, but without any immediate benefit. It doesn't substract anything, but it may prevent future simplifications. I'm ok with any renaming or clarification or defaults - as long as we keep or increase the current separation between protocols ( i.e. ajp-like workers ) and clusters/instances - or however you want to call the lb-like workers. That tie-up exists because the worker name was derived from the protocol. Ideally the protocol should have been in the channel, leaving the 'worker' to handle _a_ request, and lb to decide which worker to get it... assuming there is more than one Tomcat to receive it. However, it still doesn't make much sense to have a balancer capability in front of a single worker. I think we discussed this a lot in the past - and my proposal was to stop using the term worker :-) The request is mapped by a mapper that decides if it's a servlet and to which group it should go ( with lb:lb as a clear default ), then the lb decides on a particular channel. mod_jk1 does this using a single concept - worker, in jk2 I think a lot have changed to split things into mapper, group and channel, with some attempts to provide defaults for the common case. Costin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Autoreply: Re: Mod_Jk2 - Default Worker
Hello, Due to the increased volume of SPAM this mailbox has been closed. Please contact us via http://www.directxtras.com/ContactUS.asp We apology for the inconvenience. Best Regards, -- The DirectXtras Team - DirectXtras - Xtra Power for Director and Authorware - http://www.directxtras.com Sites with something to say - http://www.SpeaksForItself.com - Your message reads: Received: from mail.apache.org (unverified [208.185.179.12]) by mail2.intermedia.net (Rockliffe SMTPRA 4.5.6) with SMTP id [EMAIL PROTECTED] for [EMAIL PROTECTED]; Sun, 8 Feb 2004 18:06:25 -0800 Received: (qmail 73079 invoked by uid 500); 9 Feb 2004 02:06:07 - Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk List-Unsubscribe: mailto:[EMAIL PROTECTED] List-Subscribe: mailto:[EMAIL PROTECTED] List-Help: mailto:[EMAIL PROTECTED] List-Post: mailto:[EMAIL PROTECTED] List-Id: Tomcat Developers List tomcat-dev.jakarta.apache.org Reply-To: Tomcat Developers List [EMAIL PROTECTED] Delivered-To: mailing list [EMAIL PROTECTED] Received: (qmail 73040 invoked from network); 9 Feb 2004 02:06:06 - Received: from unknown (HELO main.gmane.org) (80.91.224.249) by daedalus.apache.org with SMTP; 9 Feb 2004 02:06:06 - Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 1Aq0oQ-Su-00 for [EMAIL PROTECTED]; Mon, 09 Feb 2004 03:06:14 +0100 Received: from adsl-63-202-82-219.dsl.snfc21.pacbell.net ([63.202.82.219]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for [EMAIL PROTECTED]; Mon Feb 9 02:06:14 2004 Received: from cmanolache by adsl-63-202-82-219.dsl.snfc21.pacbell.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for [EMAIL PROTECTED]; Mon Feb 9 02:06:14 2004 X-Injected-Via-Gmane: http://gmane.org/ To: [EMAIL PROTECTED] From: Costin Manolache [EMAIL PROTECTED] Subject: Re: Mod_Jk2 - Default Worker Date: Sun, 08 Feb 2004 18:06:10 -0800 Lines: 81 Message-ID: [EMAIL PROTECTED] References: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: [EMAIL PROTECTED] X-Gmane-NNTP-Posting-Host: adsl-63-202-82-219.dsl.snfc21.pacbell.net User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en In-Reply-To: [EMAIL PROTECTED] Sender: news [EMAIL PROTECTED] X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N NormW wrote: Good morning Costin. Thanks for the time given to replying. I agree with the ideas you have given, of decoupling URI's from workers explicitly tied to a communications protocol, but in reality this connectivity is supported and actually gives the minimum workable configuration. But given that a default architecture is but a 'guess', I see the programming to be 'cleaner' without such defaults and rather provide a 'default' configuration file that would achieve the same end. The present situation hides the basic building blocks of Mod_Jk2 and leads to the majority of questions in regard to how to reconfigure the module. Remove the ability of 'workers' to directly accept requests and force all URI's through an lb type, and the current default approach would be entirely appropriate. Yes, it would be nice to make a clean cut and use a different interface for protocol workers ( channels ) and lb and similar request processors. Lb is not only load balancing - it also implements fail over and can be used to accept registration for tomcat instances - i.e. a sort of zero config, with tomcat instance(s) announcing themself to lb. nameurigroup context * null null null *// lb:lb / Given the present arrangement, I can understand (if not support) the lb:lb uri entry above but the one assigned to a 'null' group with a uri of 'null' seems to be a bug. It is a bug. Even the second can be considered a bug - if no tomcat instance is present there is no need for an lb:lb. However the most common case is to have at least one tomcat, and there is no real benefit in supporting an arbitrary name for the worker ( lb:lb ) or in mapping the request directly to the protocol. I think the goal should be to have the protocol ( ajp worker ) register itself automatically with the lb:lb. In the advanced case, of multiple pools or instances handling different webapps - there is no harm in having a default ( lb:lb ) and explicitely mapping the webapps that don't fall into the default with lb:GROUP names. This case can be zero-configured by having each tomcat instance self-register with ajp URI and GROUP ( plus the webapps ) IMO getting to this point requires removing some of the (arbitrary ) flexibility in naming
Re: Mod_Jk2 - Default Worker
Good morning Costin. Thanks for the time given to replying. I agree with the ideas you have given, of decoupling URI's from workers explicitly tied to a communications protocol, but in reality this connectivity is supported and actually gives the minimum workable configuration. But given that a default architecture is but a 'guess', I see the programming to be 'cleaner' without such defaults and rather provide a 'default' configuration file that would achieve the same end. The present situation hides the basic building blocks of Mod_Jk2 and leads to the majority of questions in regard to how to reconfigure the module. Remove the ability of 'workers' to directly accept requests and force all URI's through an lb type, and the current default approach would be entirely appropriate. NormW wrote: Good morning All. The default 'worker', which is hard-wired into Mod_Jk2, is 'lb:lb', and is, for most users I believe, a wrong guess at best, since the majority of users are probably not using mod_jk2 in load-balancing mode. The 'guess' means that mod_jk2 creates uri objects assigned to either a load-balancer that doesn't exist , a load-balancer that is not hooked into anything or a load-balancer that is not even wanted. For example, the following uri's are created automatically: :-) I agree that lb is a missleading name, as is the whole worker concept. The real intent is for lb to represent one tomcat cluster ( of one or many servers ), and for routing to be directed to different clusters instead of individual machines. Even if you have a single tomcat - I think it is still better to make the mapping based on the tomcat instance, and not on the various protocols used to connect. The overhead of having lb is very small, and IMO it's well worth it given the simplification in code and the extra features. I also think the right direction is to decouple the worker ( as a particular protcol to connect to a tomcat instance ) from the notion of routing requests to a particular instance or cluster, which may use multipe protocols and workers. nameurigroup context * null null null *// lb:lb / Given the present arrangement, I can understand (if not support) the lb:lb uri entry above but the one assigned to a 'null' group with a uri of 'null' seems to be a bug. There is no means to determine the existence of the 'lb:lb' worker, but suffice to say, my setup doesn't want or need it anyway. (As an aside, perhaps this might be an extension to /jkstatus/ ?) I think the code created the lb:lb automatically unless one is defined exeplicitely. The goal was to have each tomcat instance ( or cluster ) associated with an lb, with a reasonable default to minimize trivial configuration. Then each lb would have one or multiple protocols pointing at different tomcat instances. A more valid approach would be to identify, via the workers2.properties file, which worker of those configured is to be considered the 'default'. It would also become the 'default' worker/group for [uri] sections not having a worker/group entry when created, and a variation of the JkUriSet parameter could also allow use of the 'default' worker, for example: JkUriSet worker default The existing code makes allowance for a defaultWorker property in the [workerEnv] section of memory, and I would like to submit the attached [patch as a step in such an arrangement. If this option isn't used within the workers2.properties file, then the module reverts to current operation. The parameter proposed would look as follows and retain the current default for wEnv-defaultWorker: I'm not very comfortable with this ( I'm close to -1, but if other people think it's a good idea I can change it to -0). As noted, the proposed patch subtracts nothing from the present position, while allowing access to the parameter if required. It kinds of moves us backwards, to the mess of protocols and load balancers. Architecturally, Mod_Jk2 isn't a 'mess' by any description, it has mostly been rendered incomprehensible by hiding it's few building blocks. I'm ok with any renaming or clarification or defaults - as long as we keep or increase the current separation between protocols ( i.e. ajp-like workers ) and clusters/instances - or however you want to call the lb-like workers. That tie-up exists because the worker name was derived from the protocol. Ideally the protocol should have been in the channel, leaving the 'worker' to handle _a_ request, and lb to decide which worker to get it... assuming there is more than one Tomcat to receive it. However, it still doesn't make much sense to have a balancer capability in front of a single worker. All mapping should be made between URIs and lb ( clusters/instances ), and each lb can have multiple protocols ( ajp ) associated. It would be great if we just create a separate interface to make it clear
Re: Mod_Jk2 - Default Worker
NormW wrote:
Good morning All.
The default 'worker', which is hard-wired into Mod_Jk2, is 'lb:lb', and
is, for most users I believe, a wrong guess at best, since the majority of
users are probably not using mod_jk2 in load-balancing mode. The 'guess'
means that mod_jk2 creates uri objects assigned to either a load-balancer
that doesn't exist , a load-balancer that is not hooked into anything or a
load-balancer that is not even wanted. For example, the following uri's
are created automatically:
:-)
I agree that lb is a missleading name, as is the whole worker concept.
The real intent is for lb to represent one tomcat cluster ( of one or
many servers ), and for routing to be directed to different clusters
instead of individual machines.
Even if you have a single tomcat - I think it is still better to make the
mapping based on the tomcat instance, and not on the various protocols used
to connect.
The overhead of having lb is very small, and IMO it's well worth it given
the simplification in code and the extra features.
I also think the right direction is to decouple the worker ( as a
particular protcol to connect to a tomcat instance ) from the notion of
routing requests to a particular instance or cluster, which may use multipe
protocols and workers.
nameurigroup context
* null null null
*// lb:lb /
There is no means to determine the existence of the 'lb:lb' worker, but
suffice to say, my setup doesn't want or need it anyway. (As an aside,
perhaps this might be an extension to /jkstatus/ ?)
I think the code created the lb:lb automatically unless one is defined
exeplicitely. The goal was to have each tomcat instance ( or cluster )
associated with an lb, with a reasonable default to minimize trivial
configuration.
Then each lb would have one or multiple protocols pointing at different
tomcat instances.
A more valid approach would be to identify, via the workers2.properties
file, which worker of those configured is to be considered the 'default'.
It would also become the 'default' worker/group for [uri] sections not
having a worker/group entry when created, and a variation of the JkUriSet
parameter could also allow use of the 'default' worker, for example:
JkUriSet worker default
The existing code makes allowance for a defaultWorker property in the
[workerEnv] section of memory, and I would like to submit the attached
[patch
as a step in such an arrangement. If this option isn't used within the
workers2.properties file, then the module reverts to current operation.
The parameter proposed would look as follows and retain the current
default for wEnv-defaultWorker:
I'm not very comfortable with this ( I'm close to -1, but if other people
think it's a good idea I can change it to -0).
It kinds of moves us backwards, to the mess of protocols and load balancers.
I'm ok with any renaming or clarification or defaults - as long as we keep
or increase the current separation between protocols ( i.e. ajp-like
workers ) and clusters/instances - or however you want to call the
lb-like workers.
All mapping should be made between URIs and lb ( clusters/instances ), and
each lb can have multiple protocols ( ajp ) associated. It would be great
if we just create a separate interface to make it clear that those are
distinct.
Costin
[workerEnv]
defaultWorker=workerName
For your consideration and comment,
Norm
--- jk_workerEnv.c.orig Fri Sep 26 07:00:51 2003
+++ jk_workerEnv.c Thu Feb 5 18:36:39 2004
@@ -93,6 +93,8 @@
wEnv-ssl_enable = JK_TRUE;
} else if( strcmp( name, timing )==0 ) {
wEnv-timing= atoi( value );
+} else if( strcmp( name, defaultWorker )==0 ) {
+wEnv-defaultWorker = value ;
} else if( strcmp( name, httpsIndicator )==0 ) {
wEnv-https_indicator = value;
} else if( strcmp( name, certsIndicator )==0 ) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Mod_Jk2 - Default Worker
Good morning All.
The default 'worker', which is hard-wired into Mod_Jk2, is 'lb:lb', and is,
for most users I believe, a wrong guess at best, since the majority of users
are probably not using mod_jk2 in load-balancing mode. The 'guess' means
that mod_jk2 creates uri objects assigned to either a load-balancer that
doesn't exist , a load-balancer that is not hooked into anything or a
load-balancer that is not even wanted. For example, the following uri's are
created automatically:
nameurigroup context
* null null null
*// lb:lb /
There is no means to determine the existence of the 'lb:lb' worker, but
suffice to say, my setup doesn't want or need it anyway. (As an aside,
perhaps this might be an extension to /jkstatus/ ?)
A more valid approach would be to identify, via the workers2.properties
file, which worker of those configured is to be considered the 'default'. It
would also become the 'default' worker/group for [uri] sections not having a
worker/group entry when created, and a variation of the JkUriSet parameter
could also allow use of the 'default' worker, for example:
JkUriSet worker default
The existing code makes allowance for a defaultWorker property in the
[workerEnv] section of memory, and I would like to submit the attached patch
as a step in such an arrangement. If this option isn't used within the
workers2.properties file, then the module reverts to current operation. The
parameter proposed would look as follows and retain the current default for
wEnv-defaultWorker:
[workerEnv]
defaultWorker=workerName
For your consideration and comment,
Norm
--- jk_workerEnv.c.orig Fri Sep 26 07:00:51 2003
+++ jk_workerEnv.c Thu Feb 5 18:36:39 2004
@@ -93,6 +93,8 @@
wEnv-ssl_enable = JK_TRUE;
} else if( strcmp( name, timing )==0 ) {
wEnv-timing= atoi( value );
+} else if( strcmp( name, defaultWorker )==0 ) {
+wEnv-defaultWorker = value ;
} else if( strcmp( name, httpsIndicator )==0 ) {
wEnv-https_indicator = value;
} else if( strcmp( name, certsIndicator )==0 ) {
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
