DO NOT REPLY [Bug 40668] - MailSessionFactory is missing in Tomcat 5.5.20

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40668


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |




--- Additional Comments From [EMAIL PROTECTED]  2007-03-10 00:42 ---
This issue has not been resolved in Tomcat 5.5.23: 

Could not create resource factory instance [Root exception is
java.lang.ClassNotFoundException: org.apache.naming.factory.MailSessionFactory]
at
org.apache.naming.factory.ResourceFactory.getObjectInstance(ResourceFactory.java:132)

The class is not present in

common/lib/naming-factory.jar

where I believe it belongs to.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 41806] New: - if i activate invoker services in web.xml i get an SecurityException Version (6.0.10)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41806

   Summary: if i activate invoker services in web.xml i get an
SecurityException Version (6.0.10)
   Product: Tomcat 6
   Version: unspecified
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


if i uncomment the following lines in the web.xml:


invoker

  org.apache.catalina.servlets.InvokerServlet


debug
0

2

and: 

invoker
/servlet/*

it occur an exception on startup:

Mar 10, 2007 9:42:01 AM org.apache.catalina.startup.HostConfig deployDirectory
SEVERE: Error deploying web application directory templates
java.lang.SecurityException: Servlet of class
org.apache.catalina.servlets.InvokerServlet is privileged and cannot be loaded
by this web application
at 
org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1134)
at 
org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:981)
at
org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4044)
at 
org.apache.catalina.core.StandardContext.start(StandardContext.java:4350)
at 
org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:761)
at 
org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:741)
at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:525)
at 
org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:920)
at 
org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:883)
at 
org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:492)
at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1138)
at 
org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:311)
at
org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:120)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1023)
at org.apache.catalina.core.StandardHost.start(StandardHost.java:719)
at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1015)
at 
org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443)
at 
org.apache.catalina.core.StandardService.start(StandardService.java:448)
at 
org.apache.catalina.core.StandardServer.start(StandardServer.java:710)
at org.apache.catalina.startup.Catalina.start(Catalina.java:552)
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:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:288)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)
Mar 10, 2007 9:42:02 AM org.apache.jk.common.ChannelSocket init
INFO: JK: ajp13 listening on /0.0.0.0:8009
Mar 10, 2007 9:42:02 AM org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/259  config=null
Mar 10, 2007 9:42:02 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 8583 ms

the Exception occur for every directory in /webapps
In Version 5.5.x there is no failure if i activate the section above

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat 6 Scales

[Henri Gomez]

Great article !

I wonder now what could be done when AJP is used instead of Coyote
HTTP connector ?

How does it fit ?

Regards



2007/3/9, Filip Hanik - Dev Lists <[EMAIL PROTECTED]>:

I wrote a blog entry on how one of our connectors was developed the
challenges you face doing that.
Its not super technical as I'm saving the juicy details for ApacheCon

And since no one reads my blog, I'll let you guys get it from here :)

http://blog.covalent.net/roller/covalent/entry/20070308

Filip

-
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]

DO NOT REPLY [Bug 41806] - if i activate invoker services in web.xml i get an SecurityException Version (6.0.10)

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41806


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||WONTFIX




--- Additional Comments From [EMAIL PROTECTED]  2007-03-10 03:11 ---
As it says, you need a webapp marked as privileged to run a number of servlets
which are provided with Tomcat. I don't recommend using the invoker servlet,
except for casual testing or development.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat 6 Scales

[Mladen Turk]

Henri Gomez wrote:

Great article !



I agree. But like Filip said, the entire NIO
(as well as APR) is sort of a hack.
It is obvious that the current JSE spec doesn't
fit for hybrid logic (both blocking and non-blocking)
because the cost of switching between them is simply
to high for any practical reason.

Since we have enough expertize in the subject, perhaps
we can propose some additions to the JSE NIO specs
that would satisfy the operations needed instead
constantly hacking the NIO and trying to achieve the
possible maximum out of it, or creating a new layer
powered by APR for example.

IMHO the initial designers of NIO overlooked couple
of important aspects, and that is confirmed by the
simple fact that the number of web related designs
that are using NIO is negligible to the years the NIO
is present as a part of JSE spec.

Regards,
Mladen.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 40668] - MailSessionFactory is missing in Tomcat 5.5.23

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=40668


[EMAIL PROTECTED] changed:

   What|Removed |Added

Summary|MailSessionFactory is   |MailSessionFactory is
   |missing in Tomcat 5.5.20|missing in Tomcat 5.5.23




-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat 6 Scales

[Filip Hanik - Dev Lists]

Mladen Turk wrote:

Filip Hanik - Dev Lists wrote:


The processSocketWithOptions is a blocking call, hence you wont be 
able to acccept new connections as long as your worker threads are 
all busy. 


Not entirely true.

What we need to do, is set the socket options, then simply add the 
socket to the poller waiting for a read event, the poller will assign 
it a worker thread when one is available and the socket has data to 
be read.


This was one of the major improvements I just did in the NIO 
connector. otherwise you can't accept connections fast enough and 
they will get dropped.




Basically you simulate the OS socket implementation pending connections
queue (backlog) on the OSI layer 7 instead depending on the layer 5
provided by the OS.
Well, you'd be nuts to not run your webserver without a kernel filter, 
either 1-st byte accept on linux or the httpfilter on freebsd. My point 
goes beyond just accepting connections.
So if we use those filters, we are not simulating the backlog, the 
backlog is not needed if the OS through a kernel filter already takes 
care of accepting the connection to the client.
By using relying on the backlog, you'll simply running the risk of not 
serving those connections. The backlog should only be used if your 
acceptor can't accept connections fast enough.


The only beneficiary for that would be lab test environment where you
have a lots of burst connections, then a void, then a connection burst
again (not an real-life situation thought). The point is that no matter
how large your queue is (and how it's done) if the connection rate is
higher then a processing rate, your connections will be rejected at some
point. So, it's all about tuning.
You're missing the point. I believe I mentioned it in the article, that 
the challenge during this extreme concurrency conditions, (burst or no 
burst), will become fairness. I'm in the process of implementing the 
connection fairness in the NIO connector. Relying on 
synchronized/wait/notify from multiple threads (acceptor and poller) 
does not guarantee you anything, and you completely lose control of what 
connection gets handled vs what should should get handled.


So I'm simplifying it, since its easier to implement proper fairness on 
a single thread than on multiple threads. Hence, when an accept occurs, 
set the socket options and register it with the poller.


Then let the poller become the "scheduler" if you may say so, ie, the 
poller gets to decide what connections get handled. And to properly 
achieve this, the poller nor the acceptor can get stuck on a 
synchronized/wait state.


Remember, my goal is not simply to be able to accept as many connections 
as possible, that would be pointless if I can't serve requests on them 
anyway.


The ultimate goal is to have 20k connections and still handle them evenly.

Hope that makes sense, the article itself was just to demonstrate how 
these implementations handled different situations. Although, I wouldn't 
claim that a 500 connection burst is purely lab environment. Post an 
article on digg.com and you'll running the risk of getting a burst just 
like that  :)


Filip


Regards,
Mladen.


-
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: Tomcat 6 Scales

[Mladen Turk]

Filip Hanik - Dev Lists wrote:

Mladen Turk wrote:

The ultimate goal is to have 20k connections and still handle them evenly.



The question is what will you do with those 20K connections.
The current servlet implementation as well as http protocol
is transactional (request/response), and presumes that there
is no thread context switches during that transaction.
So, you are limited by design to handle the keep-alive only
on the opened connection.
If there is no keep-alive you are just filling the queue
with incoming connections, that needs to be served by limited
number of worker threads. The worker thread can be reused only
when the transaction ends (request/response).

True async behavior would need a true async servlet specification,
with all the thread local data persisted to a socket key, but then again
the memory consumption would be as large as traditional one.
Of course one can always try to propose something like Restlet
and hope people will start programming concurrently :)

Regards,
Mladen


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat 6 Scales

[Remy Maucherat]

Mladen Turk wrote:

(backlog)


For some reason, I have yet to see that backlog behave like it is 
supposed to in Tomcat.


As my proposed long[] array is (supposedly) the same thing as the OS 
backlog, maybe Filip can experiment with the "backlog" attribute (by 
default, it's only 100, but could be set to a large value, like 2, 
to see what it does in his test).


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat 6 Scales

[Filip Hanik - Dev Lists]

Mladen Turk wrote:

Filip Hanik - Dev Lists wrote:

Mladen Turk wrote:

The ultimate goal is to have 20k connections and still handle them 
evenly.




The question is what will you do with those 20K connections.
The goal is that they will eventually get serviced, and that is the key. 
in my test, with around 4k requests/second, each connection should get a 
request in every 5 seconds. However, if fairness is not implemented, 
some connections are very likely to never get serviced. If the 
acceptor(new connections) is competing with the poller(keep alive 
connections) there is a risk for new connections not getting a say in 
the game.

The current servlet implementation as well as http protocol
is transactional (request/response), and presumes that there
is no thread context switches during that transaction.
So, you are limited by design to handle the keep-alive only
on the opened connection.
If there is no keep-alive you are just filling the queue
with incoming connections, that needs to be served by limited
number of worker threads. The worker thread can be reused only
when the transaction ends (request/response).

A very valid point, there should be a "limit" attribute for the max
number of keep alive connections, or connections period.
Otherwise, if you are on Linux for example, if you get too many 
connections, and start taking up
too much memory (socket buffers take up a lot), Linux kills the java 
process instead of letting it take up even more RAM. The linux kernel 
has a harsh but effective way of dealing with outside Java heap OOM 
errors. :)



True async behavior would need a true async servlet specification,
We're doing pretty well with Comet, the only thing comet is missing is a 
non blocking write.
Ie, if I have 1 thread servicing 1000 comet connections, I cant afford 
to get stuck on one.
If the Comet API will let me query the response to see if I can write 
without block, I can achieve that pretty well.

with all the thread local data persisted to a socket key, but then again
the memory consumption would be as large as traditional one.
Of course one can always try to propose something like Restlet
and hope people will start programming concurrently :)
yeah, when folks like us barely program concurrently, it would be 
wishful thinking :)


I'm planning

Filip

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat 6 Scales

[Filip Hanik - Dev Lists]

Remy Maucherat wrote:

Mladen Turk wrote:

(backlog)


For some reason, I have yet to see that backlog behave like it is 
supposed to in Tomcat.


As my proposed long[] array is (supposedly) the same thing as the OS 
backlog, maybe Filip can experiment with the "backlog" attribute (by 
default, it's only 100, but could be set to a large value, like 2, 
to see what it does in his test).
yes, I'll do that indeed, it will be an interesting test. One it will 
test if they actually do get backlogged, the second one if the backlog 
will get serviced before it times out.


Thanks everyone for the feedback, I'll let you know how everything 
progresses.

Filip

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat 6 Scales

[Costin Manolache]

Great work - but I'm curious, wouldn't be better to explore the alternative
direction - i.e. detect when the server is too loaded and send a quick 502 ?

Maybe with some extra logic - like serve existing sessions first,
provide some notifications that can be used by a load balancer ( or pager
:-)
to up more servers, or some notification to be used to disable some
expensive
functionality ?

In a real world situation - I would rather have the server not accept 20.000
connection and do all of them badly. It's in the same line with 'fairness'
and handling slashdot-ing, but in a different way.

Costin


On 3/10/07, Filip Hanik - Dev Lists <[EMAIL PROTECTED]> wrote:


Remy Maucherat wrote:
> Mladen Turk wrote:
>> (backlog)
>
> For some reason, I have yet to see that backlog behave like it is
> supposed to in Tomcat.
>
> As my proposed long[] array is (supposedly) the same thing as the OS
> backlog, maybe Filip can experiment with the "backlog" attribute (by
> default, it's only 100, but could be set to a large value, like 2,
> to see what it does in his test).
yes, I'll do that indeed, it will be an interesting test. One it will
test if they actually do get backlogged, the second one if the backlog
will get serviced before it times out.

Thanks everyone for the feedback, I'll let you know how everything
progresses.
Filip

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat 6 Scales

[Filip Hanik - Dev Lists]

Costin Manolache wrote:
Great work - but I'm curious, wouldn't be better to explore the 
alternative
direction - i.e. detect when the server is too loaded and send a quick 
502 ?
I totally agree, and the way its designed, this is totally doable. so 
whenever the existing connection count is more than the configured 
"limit" send a 502 through the acceptor thread and close the connection.


Maybe with some extra logic - like serve existing sessions first,
provide some notifications that can be used by a load balancer ( or pager
:-)
to up more servers, or some notification to be used to disable some
expensive
functionality ?
Yes, that would be a tougher one, trying to correlate a new connection 
to an existing session.
If you wanna do that, you have to let the connection in on a worker 
thread, and then its pointless.


In a real world situation - I would rather have the server not accept 
20.000
connection and do all of them badly. It's in the same line with 
'fairness'

and handling slashdot-ing, but in a different way.
I'm thinking of implementing the limit, so that keep alives get turned 
off if there are too many connections. That way we should still be able 
still keep everything rolling.
In a world where we would get 20k connections, I doubt they would hammer 
the server like ab does :) so it should still be possible to keep this 
many connections alive.


Filip

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat 6 Scales

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:

Remy Maucherat wrote:

Mladen Turk wrote:

(backlog)


For some reason, I have yet to see that backlog behave like it is 
supposed to in Tomcat.


As my proposed long[] array is (supposedly) the same thing as the OS 
backlog, maybe Filip can experiment with the "backlog" attribute (by 
default, it's only 100, but could be set to a large value, like 2, 
to see what it does in his test).
yes, I'll do that indeed, it will be an interesting test. One it will 
test if they actually do get backlogged, the second one if the backlog 
will get serviced before it times out.


Thanks everyone for the feedback, I'll let you know how everything 
progresses.


Ok, so I'm waiting for some more results before trying to change the 
implementation.


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat 6 Scales

[Remy Maucherat]

Filip Hanik - Dev Lists wrote:
We're doing pretty well with Comet, the only thing comet is missing is a 
non blocking write.


It is possible to do that without changing the API, in case it is 
needed. It has a possibly significant cost however (buffering all data 
which cannot be sent right away), so I am not sure it is a very good idea.


Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

DO NOT REPLY [Bug 41809] New: - some jsp-examples are broken

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=41809

   Summary: some jsp-examples are broken
   Product: Tomcat 6
   Version: unspecified
  Platform: All
OS/Version: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Jasper
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: [EMAIL PROTECTED]


I'm using a vanilla tomcat 6.0.10.

If i open http://localhost:8080/examples/jsp/forward/forward.jsp, then i get:
  HTTP Status 404 - /examples/forward/one.jsp

If i open http://localhost:8080/examples/jsp/jsptoserv/jsptoservlet.jsp, then i 
get:
  HTTP Status 404 - /examples/jsptoserv/hello.jsp


It's nothing serious. The paths have to be adjusted.
For example in forward.jsp it says:
  
but it should be:
  

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat 6 Scales

[Mladen Turk]

Filip Hanik - Dev Lists wrote:

Remy Maucherat wrote:

Mladen Turk wrote:


Thanks everyone for the feedback, I'll let you know how everything 
progresses.


Be sure to read the
http://www.faqs.org/rfcs/rfc1925.html :)

Regards,
Mladen.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]