You are viewing a plain text version of this content. The canonical link for it is here.
Posted to phoenix-dev@avalon.apache.org by Ulrich Mayring <ul...@denic.de> on 2002/09/27 15:05:42 UTC
Jo! integration questions
Hello folks,
I have a couple of questions concerning Jo! running as a
.sar-application under Phoenix:
1) There is this passage in the config.xml:
<policy>
<grant code-base="file:${app.home}${/}SAR-INF${/}lib${/}*">
<permission class="java.security.AllPermission" />
</grant>
</policy>
However, when starting Phoenix with avalon-jo.sar I get this message:
java.security.AccessControlException: access denied
(java.io.FilePermission
/usr/local/avalon/apps/avalon-jo/etc/server.properties read))
The file is globally readable in the filesystem. What's wrong here? Is a
security directive missing? But shouldn't Jo! be able to read/write its
own files? Jo! does write to its logfiles, for example.
2) Suppose I get Jo! up and running. Then I want to write a servlet that
basically just deals with incoming requests and loads off the real work
to a custom .sar application that also runs under Phoenix. How could the
servlet communicate with this other .sar-application? Or would I have to
write this other application as a bunch of blocks and integrate it
within the avalon-jo.sar?
Kind regards,
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jo! integration questions
Posted by Paul Hammant <Pa...@yahoo.com>.
Peter, Ulrich
To round up a series of messages here (late to the conv)....
1. The speeds are relative.... and out of date. Run the unit tests for
AltRMI after changing the speedtest.iterations property in
Ant.properties to something like 10000 from 1. The figures are not
perfect as Junit and Threads really distort the tests, but at least it
allows you to collate some sort of benchmarking information. The test
results show the time taken for the TestSpeed method ofr each trasport
(that is the point).
2. Same VM optimisations. Well if a WAR file app wanted to open a
AltRMI socket transport to some server in the same VM, then it would
still open a socket connection. Vinay and I have talked about the
perfect way to shortcut that to a pipe instead (irrespective of the
client's chosen transport) and we know we can do it, but the perfect
multi-classloader solution is still being thought over. There are some
complexities that we need to smooth out, or else we will do something
that will work in 70% of the situations perfectly, and the remainder
not. The remainder being for the advanced user.
Regards,
- Paul
> On Friday, September 27, 2002, at 11:27 AM, Ulrich Mayring wrote:
>
>> If Java RMI does 4329 calls per 10 seconds, that equals 432.9 per
>> second, which means a single request takes a little more than 2 ms to
>> complete. How could you possibly have saved a couple hundred ms that
>> way? :)
>
>
> Because I changed a bunch of things at once, and didn't do any
> super-formal benchmarking :) There are also multiple rmi invocations
> per request (sometimes), so I may have saved up to 10ms in the calls I
> removed.
>
>> I'd be willing to invest 0.48 ms per request :)
>>
>> Anyway, it's probably got to do with the null method invocation, if
>> we start to push some real data, we will see much different numbers.
>> Your application would be a good example, you probably push some
>> XML-file sized data around, have you made any measurements?
>
>
> I'm pushing mainly hashmaps (aside from Strings and primitives), but
> its a nested structure (a container object with a hashmap and then an
> array of hashmaps, think parent object and collection of children, but
> just a data-extract).
>
> I did some simple, informal speed tests of the system as a whole a few
> months back, but the recent push has been on completing functionality,
> as it is "fast enough". The average request is still over 1sec tho
> (not good enough for me yet), but the main bottleneck is the xslt
> transforms.
>
> I have on my list to push everything into the same JVM and do proper
> benchmarks on that, as we have a customer that will be coming online
> in the next few months that has speed requirements in their contract.
> I'll be sure to update the list with some numbers once that happens.
> -pete
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jo! integration questions
Posted by Peter Royal <pr...@apache.org>.
On Friday, September 27, 2002, at 11:27 AM, Ulrich Mayring wrote:
> If Java RMI does 4329 calls per 10 seconds, that equals 432.9 per
> second, which means a single request takes a little more than 2 ms to
> complete. How could you possibly have saved a couple hundred ms that
> way? :)
Because I changed a bunch of things at once, and didn't do any
super-formal benchmarking :) There are also multiple rmi invocations
per request (sometimes), so I may have saved up to 10ms in the calls I
removed.
> I'd be willing to invest 0.48 ms per request :)
>
> Anyway, it's probably got to do with the null method invocation, if we
> start to push some real data, we will see much different numbers. Your
> application would be a good example, you probably push some XML-file
> sized data around, have you made any measurements?
I'm pushing mainly hashmaps (aside from Strings and primitives), but
its a nested structure (a container object with a hashmap and then an
array of hashmaps, think parent object and collection of children, but
just a data-extract).
I did some simple, informal speed tests of the system as a whole a few
months back, but the recent push has been on completing functionality,
as it is "fast enough". The average request is still over 1sec tho (not
good enough for me yet), but the main bottleneck is the xslt transforms.
I have on my list to push everything into the same JVM and do proper
benchmarks on that, as we have a customer that will be coming online in
the next few months that has speed requirements in their contract. I'll
be sure to update the list with some numbers once that happens.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jo! integration questions
Posted by Ulrich Mayring <ul...@denic.de>.
Peter Royal wrote:
> On Friday, September 27, 2002, at 10:26 AM, Ulrich Mayring wrote:
>
> That's what we do over here, except we do have that costly TCP
> connection. A Cocoon2-based webapp is running inside of Catalina and
> communicates via AltRMI to a .sar-app in phoenix on the same host. The
> Java RMI -> AltRMI switch saved a couple hundred ms per request (mainly
> due to dropping one of the RMI calls, as it was trivial to embed
> user-auth information into the AltRMI request).
>
> Thats k. The numbers represent how many null method invocations could be
> completed in 10 seconds on paul's machine...
>
> java RMI (b) performed 4329 calls..
If Java RMI does 4329 calls per 10 seconds, that equals 432.9 per
second, which means a single request takes a little more than 2 ms to
complete. How could you possibly have saved a couple hundred ms that way? :)
> the intra-JVM bits were all 3x as fast, at least, with the slowest being
> 12095 calls (an object stream over a pipe). The one you may want to look
> at is the 'Direct Marshalled' variant which did 20759 calls (5x as fast
> as RMI), which works with the classloader separation.
I'd be willing to invest 0.48 ms per request :)
Anyway, it's probably got to do with the null method invocation, if we
start to push some real data, we will see much different numbers. Your
application would be a good example, you probably push some XML-file
sized data around, have you made any measurements?
cheers,
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jo! integration questions
Posted by Peter Royal <pr...@apache.org>.
On Friday, September 27, 2002, at 10:26 AM, Ulrich Mayring wrote:
> Hmm... I want to use Jo! as a webserver for publishing dynamic
> content. The actual content generation is in a .sar-application. I
> want to take advantage of the fact that by using Jo! I don't need to
> invoke a plug-in on the webserver, possibly over a costly TCP
> connection and re-parse the request on the servlet engine side.
That's what we do over here, except we do have that costly TCP
connection. A Cocoon2-based webapp is running inside of Catalina and
communicates via AltRMI to a .sar-app in phoenix on the same host. The
Java RMI -> AltRMI switch saved a couple hundred ms per request (mainly
due to dropping one of the RMI calls, as it was trivial to embed
user-auth information into the AltRMI request).
> I'm not sure what the numbers on the site mean, maybe there should be
> a number for "direct method call" for comparison.
Thats k. The numbers represent how many null method invocations could
be completed in 10 seconds on paul's machine...
java RMI (b) performed 4329 calls..
the intra-JVM bits were all 3x as fast, at least, with the slowest
being 12095 calls (an object stream over a pipe). The one you may want
to look at is the 'Direct Marshalled' variant which did 20759 calls (5x
as fast as RMI), which works with the classloader separation.
If you had the client and server in the same classloader, you get
2,391,498 calls, similar in speed to a dynamic proxy. A vanilla method
call can be run 42,384,804 times, by far the fastest.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jo! integration questions
Posted by Ulrich Mayring <ul...@denic.de>.
Peter Royal wrote:
> On Friday, September 27, 2002, at 09:58 AM, Ulrich Mayring wrote:
>
>> Is AltRMI fast enough for high performance requirements?
>
>
> What are your performance requirements? See
> http://jakarta.apache.org/avalon/excalibur/altrmi/transports.html for
> some number from altrmi.
Hmm... I want to use Jo! as a webserver for publishing dynamic content.
The actual content generation is in a .sar-application. I want to take
advantage of the fact that by using Jo! I don't need to invoke a plug-in
on the webserver, possibly over a costly TCP connection and re-parse the
request on the servlet engine side.
I'm not sure what the numbers on the site mean, maybe there should be a
number for "direct method call" for comparison.
> no, I agree with you, it doesn't seem as ideal as it should. it would be
> very nice to have a componentized servlet container that integrated
> nicely with the rest of the avalon frameworks.
Yep, that's what I meant.
>> BTW, what route has been taken with Sevak in this regard?
>
> I believe Sevak runs as a block, so as long as you will only have a
> single webapp inside of it you can embed it within your SAR.
Hm, well, Tomcat is not exactly a speed-freak either :)
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jo! integration questions
Posted by Peter Royal <pr...@apache.org>.
On Friday, September 27, 2002, at 09:58 AM, Ulrich Mayring wrote:
> Is AltRMI fast enough for high performance requirements?
What are your performance requirements? See
http://jakarta.apache.org/avalon/excalibur/altrmi/transports.html for
some number from altrmi.
> Anyway, this problem has got me thinking. What is the benefit of
> running Jo! under Phoenix as compared to a stand-alone solution?
Good question :) The only one I can think of would be having a single
JVM instance on the machine.
> Ok, if there is a high-performance communication channel with AltRMI,
> then that would be a good reason. But somehow this doesn't seem to me
> to follow the Avalon philosophy of componentization and IoC. I can't
> really explain it well at this moment, so just take it as some random
> thoughts.
no, I agree with you, it doesn't seem as ideal as it should. it would
be very nice to have a componentized servlet container that integrated
nicely with the rest of the avalon frameworks.
> BTW, what route has been taken with Sevak in this regard?
I believe Sevak runs as a block, so as long as you will only have a
single webapp inside of it you can embed it within your SAR.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jo! integration questions
Posted by Ulrich Mayring <ul...@denic.de>.
Peter Royal wrote:
> On Friday, September 27, 2002, at 09:05 AM, Ulrich Mayring wrote:
>
> I'd recommend AltRMI as it has transports optimized for intra-jvm
> communication, including instances where the client and server are
> located in separate classloaders.
Is AltRMI fast enough for high performance requirements?
Anyway, this problem has got me thinking. What is the benefit of running
Jo! under Phoenix as compared to a stand-alone solution?
Ok, if there is a high-performance communication channel with AltRMI,
then that would be a good reason. But somehow this doesn't seem to me to
follow the Avalon philosophy of componentization and IoC. I can't really
explain it well at this moment, so just take it as some random thoughts.
BTW, what route has been taken with Sevak in this regard?
cheers,
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Jo! integration questions
Posted by Peter Royal <pr...@apache.org>.
On Friday, September 27, 2002, at 09:05 AM, Ulrich Mayring wrote:
> 2) Suppose I get Jo! up and running. Then I want to write a servlet
> that basically just deals with incoming requests and loads off the
> real work to a custom .sar application that also runs under Phoenix.
> How could the servlet communicate with this other .sar-application? Or
> would I have to write this other application as a bunch of blocks and
> integrate it within the avalon-jo.sar?
You could use Java RMI, or AltRMI.
I'd recommend AltRMI as it has transports optimized for intra-jvm
communication, including instances where the client and server are
located in separate classloaders.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>