[Resin-interest] Did resin support epoll?
Hi Sun JRE nio has supported epoll from JDK5.0_up9,JDK6.0 at bottom, I wanna know whether it meaned resin support epoll now? thanks. -- Best Regards! ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Did resin support epoll?
Steve Z wrote: Hi Sun JRE nio has supported epoll from JDK5.0_up9,JDK6.0 at bottom, I wanna know whether it meaned resin support epoll now? thanks. Resin does not use nio, so how the Sun JVM implements NIO is not significant. This is an interesting read on the matter from when epoll was a new feature: http://www.theserverside.com/discussions/thread.tss?thread_id=26700 -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Did resin support epoll?
On Dec 26, 2006, at 9:59 AM, Serge Knystautas wrote: Steve Z wrote: Hi Sun JRE nio has supported epoll from JDK5.0_up9,JDK6.0 at bottom, I wanna know whether it meaned resin support epoll now? thanks. Resin does not use nio, so how the Sun JVM implements NIO is not significant. This is an interesting read on the matter from when epoll was a new feature: http://www.theserverside.com/discussions/thread.tss? thread_id=26700 Yep. Threads aren't all that bad, especially on recent operating systems. Remember, that any epoll/nio solution has extra overhead associated with detaching/attaching the thread. A poll/epoll is essentially the same as an operating system block, but handled at the user level (and so requires several extra system calls). OS blocks essentially do the exact same thing, but are handled by the kernel, which is far more efficient. The problem at the moment is really 32-bit memory limitations. Since threads take up virtual memory, lots of threads take up lots of memory. In a 64-bit system, that's not an issue. But we're running up to the limits of 32-bit virtual memory with lots of threads. That issue will go away in the next 3-5 years as we transition to 64- bits. At that point, it would make sense to just stick with lots of threads and avoid the epoll issue entirely. -- Scott -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin 3.1.0 release
Scott, many thanks for the official release of 3.1
I've installed it on a RHEL4 system with the BEA Jrockit JVM.
Got all my ususal stuff working but sadly not Gallery2 or media wiki.
I've switched debug logging on and have what might be some useful
logging. Should I send it to the list or [EMAIL PROTECTED]
All the best for the new year
Alex
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Scott Ferguson
Sent: 26 December 2006 17:56
To: General Discussion for the Resin application server;
[EMAIL PROTECTED]
Subject: [Resin-interest] Resin 3.1.0 release
Resin 3.1.0 is now available. Keep in mind that 3.1.x is a
development branch. 3.1.1 will have new features as well as bug
fixes, so it is possible that 3.1.1 may introduce new bugs.
Main changes in 3.1.0:
Requires JDK 1.5
Servlet for JavaEE 1.5
JSP for JavaEE 1.5
Amber progress (almost, but not quite passing JPA)
resin.conf refactoring for improved cluster configuration
watchdog/startup changes
web services configuration (as servlet)
Quercus updates for PHP 6 (i18n), Java reflection
I) Watchdog/startup changes:
The most visible change is the Resin startup, particularly on Unix.
The wrapper.pl is now gone, replaced by a Java watchdog process. The
unix command-line startup is:
unix java -jar resin-3.1.0/lib/resin.jar start
Or, for foreground, development work, just
unix java -jar resin-3.1.0/lib/resin.jar
For different configuration files and servers, use
unix java -jar lib/resin.jar -conf conf/myconfig.conf -server app-
a start
Windows users can also use the new startup, but can still use the old
httpd.exe.
Because the watchdog process is in Java, JDK command-line arguments
now belong in the resin.conf. This will be nice, since all the
relevant configuration will now be in resin.conf.
II) resin.conf clustering changes.
We've reorganized the resin.conf to better handle multiple clusters.
The most important use is for web-tier and app-tier load-balancing.
Now, both the web-tier and the app-tier fit into the same resin.conf.
The old 3.1.0 syntax is still available as backward compatibility,
but we encourage people to upgrade.
The basic structure is:
resin xmlns=http://caucho.com/ns/resin;
cluster id=app-tier
server-default
!-- common configuration for all servers in a cluster,
like thread-max --
http address=* port=8080/
/server-default
!-- server replaces srun --
server id=app-a address=192.168.2.10 port=6800/
host id=www.caucho.com
!-- usual virtual host configuration --
/host
/cluster
/resin
III) web services
Web services can now be configured as servlets (this is part of the
Servlet 2.5 spec). If the servlet-class implements @WebService, it
will be treated as a web-service. The class does not need to
implement Servlet. The lifecycle is the same as for a servlet, i.e.
only a single, multithreaded instance (no pooling).
Resin allows a choice of protocols, including Hessian, Burlap, and
REST. So the configuration might look like:
servlet-mapping url-pattern=/hello/*
servlet-class=example.HelloServiceImpl
protocol type=hessian
api-classexample.Hello/api-class
/protocol
/servlet-mapping
IV) JSP and Servlet for JavaEE 5
See the specs. :)
The main new capabilities are @Resource injection and capabilities
for the new JSF (i.e. %{foo}).
The @Resource injection is very nice. It removes the requirement for
most JNDI lookup, e.g.
public class MyServlet ... {
@Resource(name=jdbc/db)
private DataSource _dataSource;
...
}
Resin will inject the DataSource into the servlet before it calls the
init() method.
V) @Resource for java.util.concurrent.Executor
In Resin you can use the @Resource to get access to Resin's thread
pool for Executor-launched threads. This means you can launch short-
lived threads using Resin's thread pool.
However, you still need to be careful about lifecycle issues. We
haven't yet implemented an ExecutorService which would let Resin stop
the thread on web-app restart automatically. So you still need to
have the destroy() method stop the thread.
class MyServlet {
@Resource
private Executor _executor;
private void foo()
{
_executor.execute(new MyRunnableTask());
}
}
VI) Resin 3.1.1 roadmap
The roadmap always changes, so take this as a rough guideline of
intent. We think the following will be ready for 3.1.1 (in about 12
weeks or so)
Amber/JPA
SOAP/JAX-WS
JSF
more of EJB 3.0 (I'm not sure we'll get it done by 3.1.1)
Quercus integration as scripting language for packages like
Spring, Grails, etc.
We're aiming on JavaEE 5 by May. I think that's probably optimistic,
but it's our current target.
Share and Enjoy!
___
resin-interest mailing list
resin-interest@caucho.com
Re: [Resin-interest] Resin 3.1.0 release
On Dec 26, 2006, at 1:22 PM, Alex Sharaz wrote:
Scott, many thanks for the official release of 3.1
I've installed it on a RHEL4 system with the BEA Jrockit JVM.
Got all my ususal stuff working but sadly not Gallery2 or media wiki.
I've switched debug logging on and have what might be some useful
logging. Should I send it to the list or [EMAIL PROTECTED]
bugs.caucho.com would be best (if the logs are small).
We also refactored Quercus in a major way for 3.1.0, so that's almost
certainly what you're running into. We should be able to split out
the interpreted half of Quercus as a standalone web-app (i.e. non-
Resin), so we can have non-Resin users working on Quercus too.
-- Scott
All the best for the new year
Alex
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Scott Ferguson
Sent: 26 December 2006 17:56
To: General Discussion for the Resin application server;
[EMAIL PROTECTED]
Subject: [Resin-interest] Resin 3.1.0 release
Resin 3.1.0 is now available. Keep in mind that 3.1.x is a
development branch. 3.1.1 will have new features as well as bug
fixes, so it is possible that 3.1.1 may introduce new bugs.
Main changes in 3.1.0:
Requires JDK 1.5
Servlet for JavaEE 1.5
JSP for JavaEE 1.5
Amber progress (almost, but not quite passing JPA)
resin.conf refactoring for improved cluster configuration
watchdog/startup changes
web services configuration (as servlet)
Quercus updates for PHP 6 (i18n), Java reflection
I) Watchdog/startup changes:
The most visible change is the Resin startup, particularly on Unix.
The wrapper.pl is now gone, replaced by a Java watchdog process. The
unix command-line startup is:
unix java -jar resin-3.1.0/lib/resin.jar start
Or, for foreground, development work, just
unix java -jar resin-3.1.0/lib/resin.jar
For different configuration files and servers, use
unix java -jar lib/resin.jar -conf conf/myconfig.conf -server app-
a start
Windows users can also use the new startup, but can still use the old
httpd.exe.
Because the watchdog process is in Java, JDK command-line arguments
now belong in the resin.conf. This will be nice, since all the
relevant configuration will now be in resin.conf.
II) resin.conf clustering changes.
We've reorganized the resin.conf to better handle multiple clusters.
The most important use is for web-tier and app-tier load-balancing.
Now, both the web-tier and the app-tier fit into the same resin.conf.
The old 3.1.0 syntax is still available as backward compatibility,
but we encourage people to upgrade.
The basic structure is:
resin xmlns=http://caucho.com/ns/resin;
cluster id=app-tier
server-default
!-- common configuration for all servers in a cluster,
like thread-max --
http address=* port=8080/
/server-default
!-- server replaces srun --
server id=app-a address=192.168.2.10 port=6800/
host id=www.caucho.com
!-- usual virtual host configuration --
/host
/cluster
/resin
III) web services
Web services can now be configured as servlets (this is part of the
Servlet 2.5 spec). If the servlet-class implements @WebService, it
will be treated as a web-service. The class does not need to
implement Servlet. The lifecycle is the same as for a servlet, i.e.
only a single, multithreaded instance (no pooling).
Resin allows a choice of protocols, including Hessian, Burlap, and
REST. So the configuration might look like:
servlet-mapping url-pattern=/hello/*
servlet-class=example.HelloServiceImpl
protocol type=hessian
api-classexample.Hello/api-class
/protocol
/servlet-mapping
IV) JSP and Servlet for JavaEE 5
See the specs. :)
The main new capabilities are @Resource injection and capabilities
for the new JSF (i.e. %{foo}).
The @Resource injection is very nice. It removes the requirement for
most JNDI lookup, e.g.
public class MyServlet ... {
@Resource(name=jdbc/db)
private DataSource _dataSource;
...
}
Resin will inject the DataSource into the servlet before it calls the
init() method.
V) @Resource for java.util.concurrent.Executor
In Resin you can use the @Resource to get access to Resin's thread
pool for Executor-launched threads. This means you can launch short-
lived threads using Resin's thread pool.
However, you still need to be careful about lifecycle issues. We
haven't yet implemented an ExecutorService which would let Resin stop
the thread on web-app restart automatically. So you still need to
have the destroy() method stop the thread.
class MyServlet {
@Resource
private Executor _executor;
private void foo()
{
_executor.execute(new MyRunnableTask());
}
}
VI) Resin 3.1.1 roadmap
The roadmap always changes, so take this as a rough guideline of
intent. We think the following will be ready for 3.1.1 (in
Re: [Resin-interest] Did resin support epoll?
thank all very much :) Do you mean if we're using 64-bit os, poll equal epoll? On 12/27/06, Scott Ferguson [EMAIL PROTECTED] wrote: On Dec 26, 2006, at 9:59 AM, Serge Knystautas wrote: Steve Z wrote: Hi Sun JRE nio has supported epoll from JDK5.0_up9,JDK6.0 at bottom, I wanna know whether it meaned resin support epoll now? thanks. Resin does not use nio, so how the Sun JVM implements NIO is not significant. This is an interesting read on the matter from when epoll was a new feature: http://www.theserverside.com/discussions/thread.tss? thread_id=26700 Yep. Threads aren't all that bad, especially on recent operating systems. Remember, that any epoll/nio solution has extra overhead associated with detaching/attaching the thread. A poll/epoll is essentially the same as an operating system block, but handled at the user level (and so requires several extra system calls). OS blocks essentially do the exact same thing, but are handled by the kernel, which is far more efficient. The problem at the moment is really 32-bit memory limitations. Since threads take up virtual memory, lots of threads take up lots of memory. In a 64-bit system, that's not an issue. But we're running up to the limits of 32-bit virtual memory with lots of threads. That issue will go away in the next 3-5 years as we transition to 64- bits. At that point, it would make sense to just stick with lots of threads and avoid the epoll issue entirely. -- Scott -- Serge Knystautas Lokitech software . strategy . design http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED] ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest -- Best Regards! ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Isapi_dll 3.0.18 vs 3.0.22
On about 50% of our machines using IE 6.0 is not reloading JavaScript/Image files. We are running HTTPS/SSL over IIS 6.0 SP2. (IE loads the file the first time but when IE Checks to see if the files in its cache are up to date I believe the reload fails) When we switched to the 3.0.18 version of the ISAPI DLL, and used either 3.0.21 or 3.0.22 PRO core the application works like a champ ! In protocol.cpp I noticed the return value for write_client_buffer Is NOT being checked. This differs from 3.0.18 when that block of code was inline. I believe on Line 479 of protocol.cpp write_client_buffer(r, s-read_buf + s-read_offset, sublen); should be if (write_client_buffer(r, s-read_buf + s-read_offset, sublen) 0) return -1; Otherwise the condition of !r-WriteClient(r-ConnID, buffer, sentlen, HSE_IO_SYNC) is not detected as it was in 3.0.18. Also 3.0.18 would cse_close(s, response) in cse_write_response 3.0.21 uses cse_close(s, write) after send_data completes. These are the differences I see. I should also mention that there are 14 other production servers from other projects here that are using the 3.0.14 ISAPI DLL. When I heard about that 6 months ago I thought they were asking for trouble, And I deployed with the FULL PRO 3.0.18 w/o trouble except the OOM problem. Trying to go to 3.0.21/3.0.22 has been very frustrating, any feedback would be helpful. _ Robert Leland INTEGRITYOne (Formerly PRIZUM) P: (703) 581-6522 1900 Campus Commons Drive F: (703) 476-7405Reston, VA 20191 [EMAIL PROTECTED] BUSINESS CONSULTING | TECHNOLOGY SOLUTIONS | INNOVATION RD ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Isapi_dll 3.0.18 vs 3.0.22
Robert, Try out the latest snapshot, if you have an environment in which you can test this. It should turn into a 3.0.23 release very soon, and has a fix for chunked encoding with cached responses. (i.e. it shouldn't be setting the header for chunked encoding.) 3.0.22 also contained some plugin and chunked encoding fixes, but the static file behavior you're seeing is because of the header issue that's fixed in the snaphot. Please report anything else you do see with the current snapshot so that any fix that might arise from it can be include in .23. Hope that helps, Matt Pangaro Lokitech software . strategy . design http://www.lokitech.com m. 1.301.728.6906 f. 1.815.364.0656 e. [EMAIL PROTECTED] Leland, Robert wrote: On about 50% of our machines using IE 6.0 is not reloading JavaScript/Image files. We are running HTTPS/SSL over IIS 6.0 SP2. (IE loads the file the first time but when IE Checks to see if the files in its cache are up to date I believe the reload fails) When we switched to the 3.0.18 version of the ISAPI DLL, and used either 3.0.21 or 3.0.22 PRO core the application works like a champ ! ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
