You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Jeff Tulley <JT...@novell.com> on 2002/10/15 18:19:38 UTC

Re: MBeanException w/AJP13Connector and (hopefully) itssolution

So I find that works on NetWare with our mod_jk, as you said.  The only thing that worries me is that the port value set in server.xml is not honored, on Windows or on NetWare.  Is there somewhere else it is pulling its configuration from?  I cannot have shifting ajp ports, since I might have two catalina instances running simultaneously, and I need to control what port Apache sends requests to, so that I can route them right.

What I saw was that I set the port to 9010, but Catalina still comes up with "ajp13 listening on tcp port 8009".  When I fire up the second instance of Catalina, it comes up listening on 8010, after unsuccessfully trying to get port 8009.  I cannot just use 8009 and 8010, due to both port conflicts on NetWare(with 8009), and because I do not want to rely on startup order of the two Catalina instances.

Is this a bug, or is there some part of the design that I'm missing?

Jeff Tulley  (jtulley@novell.com)
(801)861-5322
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com

>>> JTULLEY@novell.com 10/15/02 9:44:57 AM >>>
So I'm barking up the wrong tree?  I thought somebody had told me that the Coyote JK 2 connector only worked with mod_jk2.  I'll go play around with the Coyote / mod_jk combo on NetWare, and see how it works.

Thanks.

Jeff Tulley  (jtulley@novell.com)
(801)861-5322
Novell, Inc., the leading provider of Net business solutions
http://www.novell.com 

>>> remm@apache.org 10/15/02 1:08:06 AM >>>
Jeff Tulley wrote:
> When I uncomment the AJP13 Connector, I get the following exception on startup:
> ServerLifecycleListener: createMBeans: MBeanException                           
> java.lang.Exception: ManagedBean is not found with Ajp13Connector               
>         at org.apache.catalina.mbeans.MBeanUtils.createMBean(MBeanUtils.java:225)                                                                               
>         at org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:369)                                                    
>         at org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:777)                                                    
>         at org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:751)                                                    
>         at org.apache.catalina.mbeans.ServerLifecycleListener.createMBeans(ServerLifecycleListener.java:339)                                                    
>         at org.apache.catalina.mbeans.ServerLifecycleListener.lifecycleEvent(ServerLifecycleListener.java:206)                                                  
>         at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:166)                                                              
>         at org.apache.catalina.core.StandardServer.start(StandardServer.java:2182)                                                                              
>         at org.apache.catalina.startup.Catalina.start(Catalina.java:510)        
>         at org.apache.catalina.startup.Catalina.execute(Catalina.java:400)      
>         at org.apache.catalina.startup.Catalina.process(Catalina.java:180)      
>         at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)          
>         at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)                                                                        
>         at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)                                                                
>         at java.lang.reflect.Method.invoke(Method.java:324)                     
>         at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) 
> 
> I'm wondering if the fix is simply to add a section into catalina/src/share/o/a/c/mbeans/mbeans-descriptors.xml, describing the AJP 13 connector?
> 
> I've attached my naive fix to this, which is to copy the Coyote connector section, removing only the protocolHandler attribute, since that is unique to Coyote(if I'm not mistaken, I very well could be).
> 
> Could I get one of the committers to review this please and submit the change?  We need this for NetWare, which does not have a port of mod_jk2 yet.

Either Coyote JK 2 or the old AJP 1.3 connector can be used with mod_jk 
(that's why the AJP 1.3 connector is deprecated).

Remy


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: MBeanException w/AJP13Connector and (hopefully) itssolution

Posted by Costin Manolache <cm...@yahoo.com>.
Jeff Tulley wrote:

> So I find that works on NetWare with our mod_jk, as you said.  The only
> thing that worries me is that the port value set in server.xml is not
> honored, on Windows or on NetWare.  Is there somewhere else it is pulling
> its configuration from?  I cannot have shifting ajp ports, since I might
> have two catalina instances running simultaneously, and I need to control
> what port Apache sends requests to, so that I can route them right.
> 
> What I saw was that I set the port to 9010, but Catalina still comes up
> with "ajp13 listening on tcp port 8009".  When I fire up the second
> instance of Catalina, it comes up listening on 8010, after unsuccessfully
> trying to get port 8009.  I cannot just use 8009 and 8010, due to both
> port conflicts on NetWare(with 8009), and because I do not want to rely on
> startup order of the two Catalina instances.
> 
> Is this a bug, or is there some part of the design that I'm missing?

Most likely a bug.

The problem is that we're using 2 configs - one is jk2.properties,
and the other is server.xml.

The original intention was that both mod_jk and the java side use the
same config file/format. Xml in C was considered too complex and too
big change. Unfortunately that wasn't implemented, but there is still
hope for 5.0, if the new config mechanism happens.

Regarding 8009, 8010, etc - that can be disabled ( set maxPort==port ),
it is intended to simplify load-balanced setup ( no need for multiple
configs - at least if you disable the shutdown and http ports which may
create conflicts ).

I'm pretty sure that if you set the port in jk2.properties it'll work,
I'll try to find out why the information is not passed from server.xml.
( if you can send a patch - it would be great ).

Regarding jk1/jk2 - the protocol is identical. The java side ( coyote-based) 
is stable for jk2, and it seems much better than the original connector,
so that's the default. The old one can be considered as deprecated. On the
C side, jk2 is getting there - but most people consider jk1 as more stable
and it's the only one to support netscape or aol - we only implemented the 
apache and iis adapters so far for jk2. Hopefully mod_jk2 will be released 
at the same time with 5.0.

We certainly need a mechanism to extend the mbeans.xml for thrid party
and other modules, again - a patch would be great :-)


Costin





--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>