Re: [Resin-interest] small question about entity ejb
AFAIK, using merge should not be necessary unless the entity has been
updated outside a persistent context and then needs to be synchronised
back with the DB contents. persist() is just for new entities so reading
the docs, updating an entity inside a persistent context should require
no action. Unless an exception is thrown, of course ;).
I'm going to do some tests...
S!
D.
Matt Johnston escribió:
I think you will need to use either the persist() or merge() methods of
the EntityManager in order to save your data to the database. In your
case since you are updating an existing record, you will need to use:
m_manager.merge(homeobj)
Matt
Riccardo Cohen wrote:
Hi
I used to play with entity ejb with resin 3.0 with no problem. Now in
3.1.5 I have this code :
@PersistenceContext(name=public) private EntityManager m_manager;
public boolean set_homeinfo(int id_user,String title)
{
boolean success=false;
Query hqr=m_manager.createQuery(select h from homeinfo h where
h.id_user=+id_user);
Listhomeinfo hitems = (Listhomeinfo)hqr.getResultList();
if (hitems.size()==1)
{
homeinfo homeobj=hitems.get(0);
System.out.println(title was +homeobj.getTitle());
homeobj.setTitle(title);
success=true;
}
return(success);
}
The select works all right, but the title field is never modified. I
added finer info on sql to see database requests in log, and there is no
update. Did I miss something ?
I looked at the resin amber tutorials, but there are only select
samples, I did not see insert and update samples... I remember
problems like this with 3.0 when the entity bean was reused, it was not
saved, but here it is not the case.
Thanks for any help.
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] small question about entity ejb
Hi again,
Some quick tests show that no persist() or merge() should be necessary
to update an entity inside a persistent context. I tested with Hibernate
and Amber as persistence providers and in both cases, nothing was
necessary. That was using Resin 3.1.5 and RESOURCE_LOCAL as transaction
type, which means that the problem might be with the container managed
transactions.
S!
D.
Daniel López escribió:
AFAIK, using merge should not be necessary unless the entity has been
updated outside a persistent context and then needs to be synchronised
back with the DB contents. persist() is just for new entities so reading
the docs, updating an entity inside a persistent context should require
no action. Unless an exception is thrown, of course ;).
I'm going to do some tests...
S!
D.
Matt Johnston escribió:
I think you will need to use either the persist() or merge() methods of
the EntityManager in order to save your data to the database. In your
case since you are updating an existing record, you will need to use:
m_manager.merge(homeobj)
Matt
Riccardo Cohen wrote:
Hi
I used to play with entity ejb with resin 3.0 with no problem. Now in
3.1.5 I have this code :
@PersistenceContext(name=public) private EntityManager m_manager;
public boolean set_homeinfo(int id_user,String title)
{
boolean success=false;
Query hqr=m_manager.createQuery(select h from homeinfo h where
h.id_user=+id_user);
Listhomeinfo hitems = (Listhomeinfo)hqr.getResultList();
if (hitems.size()==1)
{
homeinfo homeobj=hitems.get(0);
System.out.println(title was +homeobj.getTitle());
homeobj.setTitle(title);
success=true;
}
return(success);
}
The select works all right, but the title field is never modified. I
added finer info on sql to see database requests in log, and there is no
update. Did I miss something ?
I looked at the resin amber tutorials, but there are only select
samples, I did not see insert and update samples... I remember
problems like this with 3.0 when the entity bean was reused, it was not
saved, but here it is not the case.
Thanks for any help.
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] small question about entity ejb
Thanks a lot, I understand that I need a transaction now, while before
it could work without this... I have no idea of how to do that.
I noticed that in the doc of amber
(http://caucho.com/resin/doc/amber.xtp) there was a
@TransactionAnnotation but this makes a syntax error !
Thanks to eclipse I found a @TransactionAnn, I added it at the beginning
of my function definition, but this does not change (no update generated)
Is there any doc about this ?
Thanks
Daniel López wrote:
Hi again,
Some quick tests show that no persist() or merge() should be necessary
to update an entity inside a persistent context. I tested with Hibernate
and Amber as persistence providers and in both cases, nothing was
necessary. That was using Resin 3.1.5 and RESOURCE_LOCAL as transaction
type, which means that the problem might be with the container managed
transactions.
S!
D.
Daniel López escribió:
AFAIK, using merge should not be necessary unless the entity has been
updated outside a persistent context and then needs to be synchronised
back with the DB contents. persist() is just for new entities so reading
the docs, updating an entity inside a persistent context should require
no action. Unless an exception is thrown, of course ;).
I'm going to do some tests...
S!
D.
Matt Johnston escribió:
I think you will need to use either the persist() or merge() methods of
the EntityManager in order to save your data to the database. In your
case since you are updating an existing record, you will need to use:
m_manager.merge(homeobj)
Matt
Riccardo Cohen wrote:
Hi
I used to play with entity ejb with resin 3.0 with no problem. Now in
3.1.5 I have this code :
@PersistenceContext(name=public) private EntityManager m_manager;
public boolean set_homeinfo(int id_user,String title)
{
boolean success=false;
Query hqr=m_manager.createQuery(select h from homeinfo h where
h.id_user=+id_user);
Listhomeinfo hitems = (Listhomeinfo)hqr.getResultList();
if (hitems.size()==1)
{
homeinfo homeobj=hitems.get(0);
System.out.println(title was +homeobj.getTitle());
homeobj.setTitle(title);
success=true;
}
return(success);
}
The select works all right, but the title field is never modified. I
added finer info on sql to see database requests in log, and there is no
update. Did I miss something ?
I looked at the resin amber tutorials, but there are only select
samples, I did not see insert and update samples... I remember
problems like this with 3.0 when the entity bean was reused, it was not
saved, but here it is not the case.
Thanks for any help.
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
--
Très cordialement,
Riccardo Cohen
---
Articque
http://www.articque.com
149 av Général de Gaulle
37230 Fondettes - France
tel : 02-47-49-90-49
fax : 02-47-49-91-49
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] small question about entity ejb
On Mar 10, 2008, at 1:29 AM, Riccardo Cohen wrote:
Thanks a lot, I understand that I need a transaction now, while before
it could work without this... I have no idea of how to do that.
I noticed that in the doc of amber
(http://caucho.com/resin/doc/amber.xtp) there was a
@TransactionAnnotation but this makes a syntax error !
Thanks to eclipse I found a @TransactionAnn, I added it at the
beginning
of my function definition, but this does not change (no update
generated)
It should be @TransactionAttribute. I'm fixing the docs.
The @TransactionAttribute is the easiest method. You need to put it
on a Resin-IoC-aware object, e.g. a bean or an EJB stateless bean or
a servlet. If you put it on an arbitrary class, it won't do anything.
You can also use UserTransaction to do essentially the same thing:
class MyFoo {
@In UserTransaction _ut;
void myStuff()
{
_ut.begin();
try {
...
} finally {
ut.commit();
}
}
That's essentially identical to
@TransactionAttribute void myStuff()
{
...
}
If you turn logging level=fine, you'll see the transaction begin()/
commit(). So you can use the log to make sure the transactions are
working properly.
-- Scott
Is there any doc about this ?
Thanks
Daniel López wrote:
Hi again,
Some quick tests show that no persist() or merge() should be
necessary
to update an entity inside a persistent context. I tested with
Hibernate
and Amber as persistence providers and in both cases, nothing was
necessary. That was using Resin 3.1.5 and RESOURCE_LOCAL as
transaction
type, which means that the problem might be with the container
managed
transactions.
S!
D.
Daniel López escribió:
AFAIK, using merge should not be necessary unless the entity has
been
updated outside a persistent context and then needs to be
synchronised
back with the DB contents. persist() is just for new entities so
reading
the docs, updating an entity inside a persistent context should
require
no action. Unless an exception is thrown, of course ;).
I'm going to do some tests...
S!
D.
Matt Johnston escribió:
I think you will need to use either the persist() or merge()
methods of
the EntityManager in order to save your data to the database. In
your
case since you are updating an existing record, you will need to
use:
m_manager.merge(homeobj)
Matt
Riccardo Cohen wrote:
Hi
I used to play with entity ejb with resin 3.0 with no problem.
Now in
3.1.5 I have this code :
@PersistenceContext(name=public) private EntityManager
m_manager;
public boolean set_homeinfo(int id_user,String title)
{
boolean success=false;
Query hqr=m_manager.createQuery(select h from homeinfo h
where
h.id_user=+id_user);
Listhomeinfo hitems = (Listhomeinfo)hqr.getResultList();
if (hitems.size()==1)
{
homeinfo homeobj=hitems.get(0);
System.out.println(title was +homeobj.getTitle());
homeobj.setTitle(title);
success=true;
}
return(success);
}
The select works all right, but the title field is never
modified. I
added finer info on sql to see database requests in log, and
there is no
update. Did I miss something ?
I looked at the resin amber tutorials, but there are only select
samples, I did not see insert and update samples... I remember
problems like this with 3.0 when the entity bean was reused, it
was not
saved, but here it is not the case.
Thanks for any help.
___
resin-interest mailing list
resin-interest@caucho.com
http://maillist.caucho.com/mailman/listinfo/resin-interest
--
Très cordialement,
Riccardo Cohen
---
Articque
http://www.articque.com
149 av Général de Gaulle
37230 Fondettes - France
tel : 02-47-49-90-49
fax : 02-47-49-91-49
___
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] Quercus: Online docs incomplete in crucial area
On Mar 9, 2008, at 4:12 PM, Stargazer wrote: Crucial for me right now anyway ;-) http://quercus.caucho.com/quercus-3.1/doc/quercus.xtp#php.ini The section under JNDI DataSource ... WEB-INF/resin-web.xml has malformed xml for the database tag. Any chance of a fuller example please? I've just updated it. Basically, the underlying database support in Quercus is JDBC. So the only question is where the JDBC DataSource comes from. Setting the database tag will force a specific, configured JDBC value to be used for all PHP calls, no matter what the parameters to the mysql_connect are. - Scott The problem is I'm trying to associate a MySQL Pligg db on a different server to the one resin 3.1.5 is running on. All my attempts to patch things by updating the relevant *.php files stil result in localhost:3306 references in the error messages, when I really want to use (and see) foo.com:3306 there. Nothing I am doing seems to prevent it from looking at localhost. The comment above the paragraph I mentioned seems strange too - it suggests a db config there will override anything in the php scripts, which is pretty much what I want. Does this really mean the params defined in the php scripts are irrelevant? ___ 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] java:comp/env/caucho/auth
On Mar 9, 2008, at 4:05 AM, Ron Pitts wrote:
Getting some werid problem using resin 3.1.5, I was using 3.1.4
without any problems but looks like my form login is now broken.
Hmm. You need to add a jndi-name to the authenticator jndi-
name=caucho/auth, or even better, rewrite the FormLogin to look like:
CFormLogin extends ... {
@javax.webbeans.In ServletAuthenticator _auth;
...
}
When I updated the authenticator to use WebBeans, I'd thought the
caucho/auth name was only used internally to Resin, so removed the
default.
-- Scott
Its returning an error javax.naming.NameNotFoundException: java:comp/
env/caucho/auth
Abtract of the class is as follows :
public class CFormLogin extends com.caucho.server.security.FormLogin
public ServletAuthenticator getAuthenticator()
{
log.debug(get servletauthenticator);
if (_auth == null) {
log.debug(auth = null);
try {
javax.naming.Context ic = new javax.naming.InitialContext();
_auth = (ServletAuthenticator) ic.lookup(java:comp/env/
caucho/auth);
log.debug(_auth.toString());
} catch (Exception e) {
log.debug(e.toString());
}
Abtract of Web.xml
authenticator type='jw.jaas.CServletAuthenticator'
init
data-sourcejdbc/mysql/data-source
/init
/authenticator
!-- Default login configuration uses form-based authentication --
login-config type=jw.jaas.CFormLogin
auth-methodformc/auth-method
realm-nameAnonymous Form-Based Authentication Area/realm-
name
init
form-login-page/index.jsp/form-login-page
form-error-page/error.jsp/form-error-page
internal-forward/protected/menu.jsp/internal-forward
/init
form-login-config
form-login-page/protected/login.jsp/form-login-page
form-error-page/error.jsp/form-error-page
internal-forward/protected/menu.jsp/internal-forward
/form-login-config
/login-config
Any ideas
thanks
___
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] java com.caucho.server.resin.Resin and java-jar resin.jar behaves different
Hi Scott, Did you prove that execution of resin.jar or httpd.exe would cause the unexpected resource url? Regards, - Wesley - Original Message - From: wesley [EMAIL PROTECTED] To: General Discussion for the Resin application server resin-interest@caucho.com Sent: Friday, March 07, 2008 12:28 PM Subject: [Resin-interest] java com.caucho.server.resin.Resin and java-jar resin.jar behaves different Hi Scott, It seems the Thread.currentThread().getContextClassLoader().getResources() will produce the two urls, one of which is /C:/JDK1.6.0/jre/lib/ext/meta-index/ I've written a simple test and comfired it. Should it be a bug of Resin.jar of httpd? Regards, - Wesley ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Managing separate watchdog processes in 3.1.5
Is there a way to specify what IP the watchdog-port will bind to? I want to be able to have a number of sites/instances of resin running on a machine I want all of them to run independent of each other so to keep them independent, I need to specify a watchdog-port... but if I do... it binds to the main ip of the machine... so in my scenario, I would need to assign each resin instance a unique port number. Is there a better way for me to handle this? Thanks Eric Kreiser ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
[Resin-interest] Resin cluster failure with a single node running out of heap space
Scott and others- My client has a five-node Resin Pro cluster, each running version 3.1.2. Today one of the nodes experienced an OutOfMemoryException which did not bring Resin down but seemed to have put it in a completely unresponsive state. With 10 minutes or so of that happening, the other four servers stop responding as well. Looking at their logs shows that they are continuously getting socket timeouts while trying to communicate with the first server for session clustering. (Stack trace below). To be fair, this is not the only exception being thrown. We also see our distributed EhCache system unsuccessfully trying to replicate itself. And we *also* see the occasional Hessian exception happening (also below). Ultimately the server just gets so bogged down, it seems, that it needs to be restarted. So my question is this: Assuming a Resin node runs out of memory, is there a way for other Resin nodes to detect that and take the same action as if the node was actually down? I'm not sure this is really a bug, but it is probably a good super-edge-case scenario worth thinking about. We are currently looking at our watchdog process config to see why it did not auto-restart Resin. I think we didn't give enough memory buffer for the watchdog to detect a needed restart, and our app lost responsiveness before the watchdog could restart it. But that's just a theory. I am interested in feedback from Scott and other Caucho developers about this issue, as well as other Resin users who may have experienced issues like this before and have any thoughts or suggestions on the matter. Thanks. ..mike.. --- Socket Timeout stack trace (partial) --- [14:47:10.389] java.net.SocketTimeoutException: Read timed out [14:47:10.389] at java.net.SocketInputStream.socketRead0(Native Method) [14:47:10.389] at java.net.SocketInputStream.read(SocketInputStream.java:129) [14:47:10.389] at com.caucho.vfs.TcpStream.read(TcpStream.java:163) [14:47:10.389] at com.caucho.vfs.ReadStream.readBuffer(ReadStream.java:1001) [14:47:10.389] at com.caucho.vfs.ReadStream.read(ReadStream.java:306) [14:47:10.389] at com.caucho.server.cluster.ClusterStore.updateAccess(ClusterStore.java:85 6) [14:47:10.389] at com.caucho.server.cluster.ClusterStore.accessServer(ClusterStore.java:82 3) [14:47:10.389] at com.caucho.server.cluster.ClusterStore.accessImpl(ClusterStore.java:804) [14:47:10.389] at com.caucho.server.cluster.ClusterObject.access(ClusterObject.java:337) [14:47:10.389] at com.caucho.server.session.SessionImpl.setAccess(SessionImpl.java:839) [14:47:10.389] at com.caucho.server.session.SessionManager.load(SessionManager.java:1477) [14:47:10.389] at com.caucho.server.session.SessionManager.getSession(SessionManager.java: 1335) [14:47:10.389] at com.caucho.server.connection.AbstractHttpRequest.createSession(AbstractH ttpRequest.java:1455) [14:47:10.389] at com.caucho.server.connection.AbstractHttpRequest.getSession(AbstractHttp Request.java:1270) [14:47:10.389] at net.sf.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilte r(HttpSessionContextIntegrationFilter.java:172) [14:47:10.389] at net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(F ilterChainProxy.java:303) [14:47:10.389] at net.sf.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.jav a:173) [14:47:10.389] at net.sf.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.j ava:125) [14:47:10.389] at com.caucho.server.dispatch.FilterFilterChain.doFilter(FilterFilterChain. java:73) --- Hessian failure stack trace --- [14:15:00.065] Caused by: org.springframework.web.util.NestedServletException: Hessian skeleton invocation failed; nested exception is java.io.IOException: expected 'c' in hessian input at -1 [14:15:00.065] at org.springframework.remoting.caucho.HessianServiceExporter.handleRequest (HessianServiceExporter.java:150) [14:15:00.065] at org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter.handle(Htt pRequestHandlerAdapter.java:49) [14:15:00.065] at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherS ervlet.java:857) [14:15:00.065] at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherSe rvlet.java:792) [14:15:00.065] at org.springframework.web.servlet.FrameworkServlet.processRequest(Framewor kServlet.java:475) [14:15:00.065] at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet .java:440) [14:15:00.065] at javax.servlet.http.HttpServlet.service(HttpServlet.java:153) [14:15:00.065] at javax.servlet.http.HttpServlet.service(HttpServlet.java:91) [14:15:00.065] at com.caucho.server.dispatch.ServletFilterChain.doFilter(ServletFilterChai n.java:103) [14:15:00.065] at net.sf.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(F ilterChainProxy.java:292) [14:15:00.065] at taylor.tops.security.UserTrackerFilter.doFilter(UserTrackerFilter.java:2 7)
Re: [Resin-interest] Resin cluster failure with a single node running out of heap space
On Mar 10, 2008, at 3:05 PM, Mike Wynholds wrote: Scott and others- My client has a five-node Resin Pro cluster, each running version 3.1.2. Today one of the nodes experienced an OutOfMemoryException which did not bring Resin down but seemed to have put it in a completely unresponsive state. Do you have the memory-free-min set? Resin should restart itself before it gets to OOM. The problem with OOM is that errors and behavior start becoming undefined. Basically, it's not possible to really handle OOM other than restarting the system. The memory-free-min makes sure Resin restarts before that situation occurs. -- Scott With 10 minutes or so of that happening, the other four servers stop responding as well. Looking at their logs shows that they are continuously getting socket timeouts while trying to communicate with the first server for session clustering. (Stack trace below). To be fair, this is not the only exception being thrown. We also see our distributed EhCache system unsuccessfully trying to replicate itself. And we *also* see the occasional Hessian exception happening (also below). Ultimately the server just gets so bogged down, it seems, that it needs to be restarted. So my question is this: Assuming a Resin node runs out of memory, is there a way for other Resin nodes to detect that and take the same action as if the node was actually down? I’m not sure this is really a bug, but it is probably a good super-edge-case scenario worth thinking about. We are currently looking at our watchdog process config to see why it did not auto-restart Resin. I think we didn’t give enough memory buffer for the watchdog to detect a needed restart, and our app lost responsiveness before the watchdog could restart it. But that’s just a theory. I am interested in feedback from Scott and other Caucho developers about this issue, as well as other Resin users who may have experienced issues like this before and have any thoughts or suggestions on the matter. Thanks. ..mike.. --- Socket Timeout stack trace (partial) --- [14:47:10.389] java.net.SocketTimeoutException: Read timed out [14:47:10.389] at java.net.SocketInputStream.socketRead0(Native Method) [14:47:10.389] at java.net.SocketInputStream.read(SocketInputStream.java:129) [14:47:10.389] at com.caucho.vfs.TcpStream.read(TcpStream.java:163) [14:47:10.389] at com.caucho.vfs.ReadStream.readBuffer(ReadStream.java:1001) [14:47:10.389] at com.caucho.vfs.ReadStream.read(ReadStream.java:306) [14:47:10.389] at com .caucho.server.cluster.ClusterStore.updateAccess(ClusterStore.java: 856) [14:47:10.389] at com .caucho.server.cluster.ClusterStore.accessServer(ClusterStore.java: 823) [14:47:10.389] at com.caucho.server.cluster.ClusterStore.accessImpl(ClusterStore.java: 804) [14:47:10.389] at com.caucho.server.cluster.ClusterObject.access(ClusterObject.java:337) [14:47:10.389] at com.caucho.server.session.SessionImpl.setAccess(SessionImpl.java:839) [14:47:10.389] at com.caucho.server.session.SessionManager.load(SessionManager.java: 1477) [14:47:10.389] at com .caucho.server.session.SessionManager.getSession(SessionManager.java: 1335) [14:47:10.389] at com .caucho .server .connection .AbstractHttpRequest.createSession(AbstractHttpRequest.java:1455) [14:47:10.389] at com .caucho .server .connection.AbstractHttpRequest.getSession(AbstractHttpRequest.java: 1270) [14:47:10.389] at net .sf .acegisecurity .context .HttpSessionContextIntegrationFilter .doFilter(HttpSessionContextIntegrationFilter.java:172) [14:47:10.389] at net.sf.acegisecurity.util.FilterChainProxy $VirtualFilterChain.doFilter(FilterChainProxy.java:303) [14:47:10.389] at net .sf .acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java: 173) [14:47:10.389] at net .sf .acegisecurity .util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:125) [14:47:10.389] at com .caucho .server.dispatch.FilterFilterChain.doFilter(FilterFilterChain.java:73) --- Hessian failure stack trace --- [14:15:00.065] Caused by: org.springframework.web.util.NestedServletException : Hessian skeleton invocation failed; nested exception is java.io.IOException: expected 'c' in hessian input at -1 [14:15:00.065] at org .springframework .remoting .caucho .HessianServiceExporter.handleRequest(HessianServiceExporter.java:150) [14:15:00.065] at org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter.handle (HttpRequestHandlerAdapter.java:49) [14:15:00.065] at org.springframework.web.servlet.DispatcherServlet.doDispatch (DispatcherServlet.java:857) [14:15:00.065] at org.springframework.web.servlet.DispatcherServlet.doService (DispatcherServlet.java:792) [14:15:00.065] at org.springframework.web.servlet.FrameworkServlet.processRequest (FrameworkServlet.java:475) [14:15:00.065] at org.springframework.web.servlet.FrameworkServlet.doPost
Re: [Resin-interest] Resin cluster failure with a single node running out of heap space
We are currently looking at our watchdog process config to see why it did not auto-restart Resin. I think we didn't give enough memory buffer for the watchdog to detect a needed restart, and our app lost responsiveness before the watchdog could restart it. But that's just a theory. The memory low detection happens within the server itself. If the server itself detects that the memory is about to be exhausted, it exits. The watchdog then notices that the server did not exit cleanly, and starts a new server to replace it. -- Sam ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin cluster failure with a single noderunning out of heap space
On Mar 10, 2008, at 3:57 PM, Mike Wynholds wrote: Hmmm... we do have a memory-free-min setting of 1MB (Scott asked about that just before this email). So then how would Resin still get an OOM error? Is there a thread in the server that watches the heap space? Because we do a lot of in-JVM image manipulation, which takes up a LOT of memory and quite quickly. So if it is a timing issue, it's possible that the heap-watcher doesn't have a chance to act quickly enough. It's the main thread and checked every 10 seconds. So it's possible that using a lot of memory could run by it. Still, that thread should detect the problem after 10 seconds and force a restart. Although, memory checking isn't exact. It's even possible the original failure freed up memory between checks, but that's not likely. Did you happen to get a thread dump or was the JVM itself frozen? JVM freezes are hard to deal with. -- Scott ..mike.. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sam Sent: Monday, March 10, 2008 3:38 PM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Resin cluster failure with a single noderunning out of heap space We are currently looking at our watchdog process config to see why it did not auto-restart Resin. I think we didn't give enough memory buffer for the watchdog to detect a needed restart, and our app lost responsiveness before the watchdog could restart it. But that's just a theory. The memory low detection happens within the server itself. If the server itself detects that the memory is about to be exhausted, it exits. The watchdog then notices that the server did not exit cleanly, and starts a new server to replace it. -- Sam ___ 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 ___ resin-interest mailing list resin-interest@caucho.com http://maillist.caucho.com/mailman/listinfo/resin-interest
Re: [Resin-interest] Resin cluster failure with a singlenoderunning out of heap space
nope, no thread dump unfortunately. the whole cluster had been restarted by the IT department of my client before I came in to help figure out what had happened. I will tell them to get a thread dump if it happens again. I don't think the JVM itself was frozen. but I am not sure. in the meantime, I think we will try increasing the heap size and the memory-free-min value. ..mike.. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Ferguson Sent: Monday, March 10, 2008 4:42 PM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Resin cluster failure with a singlenoderunning out of heap space On Mar 10, 2008, at 3:57 PM, Mike Wynholds wrote: Hmmm... we do have a memory-free-min setting of 1MB (Scott asked about that just before this email). So then how would Resin still get an OOM error? Is there a thread in the server that watches the heap space? Because we do a lot of in-JVM image manipulation, which takes up a LOT of memory and quite quickly. So if it is a timing issue, it's possible that the heap-watcher doesn't have a chance to act quickly enough. It's the main thread and checked every 10 seconds. So it's possible that using a lot of memory could run by it. Still, that thread should detect the problem after 10 seconds and force a restart. Although, memory checking isn't exact. It's even possible the original failure freed up memory between checks, but that's not likely. Did you happen to get a thread dump or was the JVM itself frozen? JVM freezes are hard to deal with. -- Scott ..mike.. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sam Sent: Monday, March 10, 2008 3:38 PM To: General Discussion for the Resin application server Subject: Re: [Resin-interest] Resin cluster failure with a single noderunning out of heap space We are currently looking at our watchdog process config to see why it did not auto-restart Resin. I think we didn't give enough memory buffer for the watchdog to detect a needed restart, and our app lost responsiveness before the watchdog could restart it. But that's just a theory. The memory low detection happens within the server itself. If the server itself detects that the memory is about to be exhausted, it exits. The watchdog then notices that the server did not exit cleanly, and starts a new server to replace it. -- Sam ___ 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 ___ 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
