You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by the666pack <ma...@gmail.com> on 2008/02/24 13:24:45 UTC
Geronimo 2.0.2 - OpenEJB "Passivation Failed"
hello,
i try to stress-test the geronimo application server version 2.0.2.
so i try to call a jsp repeatedly, which validates against a stateless
session bean and then creates a stateful session bean.. for the first few
calls it starts fine but then after about 100 calls the server starts to
throw the following error every now and then (means that inbetween there are
calls which create the session beans successful):
[exec] 13:04:31,854 INFO [OpenEJB] finished invoking method create
[exec] 13:04:31,855 INFO [OpenEJB] finished invoking method create
[exec] 13:04:31,857 INFO [OpenEJB] Passivating to file
/usr/local/geronimo/5-2.0.2/var/temp/11d1def534ea1be0=-8cc2910=1184b52f0a4=-7e38
[exec] 13:04:31,865 INFO [OpenEJB] Passivation failed
[exec] java.io.NotSerializableException: vt.bean.stateful.WriteDataBean
[exec] at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156)
[exec] at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
[exec] at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
[exec] at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
[exec] at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
[exec] at
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
[exec] at
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
[exec] at
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
[exec] at
java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
[exec] at
java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
[exec] at
org.apache.openejb.core.stateful.SimplePassivater.passivate(SimplePassivater.java:73)
[exec] at
org.apache.openejb.core.stateful.SimplePassivater.passivate(SimplePassivater.java:93)
[exec] at
org.apache.openejb.core.stateful.StatefulInstanceManager.passivate(StatefulInstanceManager.java:487)
[exec] at
org.apache.openejb.core.stateful.StatefulInstanceManager$BeanEntryQueue.add(StatefulInstanceManager.java:579)
[exec] at
org.apache.openejb.core.stateful.StatefulInstanceManager.poolInstance(StatefulInstanceManager.java:413)
[exec] at
org.apache.openejb.core.stateful.StatefulContainer.createEJBObject(StatefulContainer.java:291)
[exec] at
org.apache.openejb.core.stateful.StatefulContainer.invoke(StatefulContainer.java:241)
[exec] at
org.apache.openejb.core.ivm.EjbHomeProxyHandler.create(EjbHomeProxyHandler.java:267)
[exec] at
org.apache.openejb.core.ivm.EjbHomeProxyHandler._invoke(EjbHomeProxyHandler.java:158)
[exec] at
org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:245)
[exec] at
org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(Jdk13InvocationHandler.java:49)
[exec] at $Proxy22.create(Unknown Source)
[exec] at
org.apache.openejb.core.ivm.naming.BusinessRemoteReference.getObject(BusinessRemoteReference.java:33)
[exec] at
org.apache.openejb.core.ivm.naming.IvmContext.lookup(IvmContext.java:150)
[exec] at
org.apache.openejb.core.ivm.naming.IntraVmJndiReference.getObject(IntraVmJndiReference.java:38)
[exec] at
org.apache.openejb.core.ivm.naming.Reference.getContent(Reference.java:40)
[exec] at
org.apache.xbean.naming.context.ContextUtil.resolve(ContextUtil.java:61)
[exec] at
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:118)
[exec] at
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:617)
[exec] at
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:158)
[exec] at
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:617)
[exec] at
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:158)
[exec] at
org.apache.xbean.naming.context.AbstractContext.lookup(AbstractContext.java:603)
[exec] at
javax.naming.InitialContext.lookup(InitialContext.java:392)
[exec] at vt.servlet.LoginServlet.doGet(LoginServlet.java:68)
[exec] at
javax.servlet.http.HttpServlet.service(HttpServlet.java:693)
[exec] at
javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
[exec] at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
[exec] at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
[exec] at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:230)
[exec] at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
[exec] at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
[exec] at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:353)
[exec] at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
[exec] at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
[exec] at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:104)
[exec] at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
[exec] at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:563)
[exec] at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:261)
[exec] at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
[exec] at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:581)
[exec] at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
[exec] at java.lang.Thread.run(Thread.java:619)
does this error concern me? i mean does it affect the result? the server
seems to keep running and as it is just an "[INFO]" message i am not sure
what to think about it.
thanks a lot for helping,
mario
--
View this message in context: http://www.nabble.com/Geronimo-2.0.2---OpenEJB-%22Passivation-Failed%22-tp15663519s134p15663519.html
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
VTD-XML 2.3 released
Posted by jimmy Zhang <cr...@comcast.net>.
VTD-XML 2.3 is now released. To download the latest version please visit
http://sourceforge.net/project/showfiles.php?group_id=110612&package_id=120172.
Below is a list of new features and enhancements in this version.
a.. VTDException is now introduced as the root class for all other
VTD-XML's exception classes (per suggestion of Max Rahder).
b.. Transcoding capability is now added for inter-document cut and paste.
You can cut a chuck of bytes in a UTF-8 encoded document and paste it into a
UTF-16 encoded document and the output document is still well-formed.
c.. ISO-8859-10, ISO-8859-11, ISO-8859-12, ISO-8859-13, ISO-8859-14 and
ISO-8859-15 support has now been added
d.. Zero length Text node is now possible.
e.. Ability to dump in-memory copy of text is added.
f.. Various code cleanup, enhancement and bug fixes.
Below are some new articles related to VTD-XML
a.. Index XML documents with VTD-XML
http://xml.sys-con.com/read/453082.htm
b.. Manipulate XML content the Ximple Way
http://www.devx.com/xml/Article/36379
c.. VTD-XML: A new vision of XML
http://www.developer.com/xml/article.php/3714051
d.. VTD-XML: XML Processing for the future
http://www.codeproject.com/KB/cs/vtd-xml_examples.aspx
If you (or someone you know) like the concept of VTD-XML, think that it can
help solve enterprises' XML processing related issues (particularly those
related to SOA), and would like to directly influence and contribute to the
development of the future of Internet, please email me
crackeur@comcast.net). We are looking for open source software developers
and project management people to take VTD-XML to the next level.
Re: Geronimo 2.0.2 - OpenEJB "Passivation Failed"
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On Mon, Feb 25, 2008 at 1:07 PM, Mario Kofler <ma...@gmail.com> wrote:
> <persistence xmlns="http://java.sun.com/xml/ns/persistence"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>
> xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
> version="1.0">
> <persistence-unit name="valhalla" transaction-type="JTA">
Hi,
I'm pretty sure I've seen the persistence.xml before ;-)
Let's see how we can make it "better". Remote transaction-type - it's
unnecessary as the default value in the managed env like Geronimo is
JTA.
> <description>videothek</description>
Unnecessary, but could be helpful.
> <provider>org.apache.openjpa.persistence.PersistenceProviderImpl</provider>
Unnecessary. It's the default JPA provider in Geronimo and OpenEJB
> <class>vt.bean.entity.Person</class>
> <class>vt.bean.entity.Actor</class>
> <class>vt.bean.entity.Director</class>
> <class>vt.bean.entity.Movie</class>
> <class>vt.bean.entity.Dvd</class>
I'm pretty sure you don't have to specify it either (you should do it
in the outside-the-container mode, outside javaee managed env).
> <properties>
>
> <property name="openjpa.jdbc.DBDictionary" value="postgres"/>
>
> </properties>
> <jta-data-source>jdbc/postgres</jta-data-source>
> <non-jta-data-source>jdbc/postgres</non-jta-data-source>
I don't know if Geronimo provides a notion of a default jdbc data
source for JPA. It's available in some other java ee app servers and
it could be very handy for prototyping. In your case, it should
definitely be specified as you're using PostgreSQL (which I doubt will
ever be a default database).
> </persistence-unit>
> </persistence>
>
> it took me some configuration time to get it working this way and i think it
> is already as short as it can get ;)
Nope. It could be shorter/more compact ;-) That's the beauty of Java
EE 5 - most of the configuration settings are defaults and there's no
need to repeat them if you don't have to.
> so another thing is when i keep calling the bean repeatedly to insert 1
> director per transaction as in a performance test after about 100 inserts it
> is the first time i get an exception. the server continues inserting to the
> db but the exception is coming every now and then.. i wonder what it means..
> i don't want to just throw exceptions here, but maybe you see it with one
> eye, taking a short look.. thanks in anyway, here is the stacktrace:
Add "implements Serializable" to your session bean(s) and the issue
should vanish in a puff of smoke. It's a bug in OpenEJB. It's reported
and it should be taken care of before OpenEJB 3.0. Dunno when it
appears in Geronimo. It could be 2.2 but it could take longer. I'm
sure you could help us fixing it. You're well skilled to squash it.
https://issues.apache.org/jira/browse/OPENEJB-215 (it looks Dave's
working on it so it should be available in a day or so ;-))
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: Geronimo 2.0.2 - OpenEJB "Passivation Failed"
Posted by Mario Kofler <ma...@gmail.com>.
2008/2/25, Jacek Laskowski <ja...@laskowski.net.pl>:
>
> On Mon, Feb 25, 2008 at 12:20 PM, Mario Kofler <ma...@gmail.com>
> wrote:
>
> > so there is a simple reason why i decided to close the entity manager
> > explicitely: because i thought it is a good idea ;)
>
>
> And you didn't get any exception?! It's disallowed to play with server
> managed resources and close them just like you tried to do. The reason
> people are still using EJB3 and all the Java EE 5 stack is their
> simplicity (or attempt to be simple) as far as resources are
> concerned. You just use them and don't have to worry about managing
> them - that's the role of Geronimo or other less-feature-rich
> application servers ;-) Use it and when you're done forget about them.
> Geronimo takes care of them for you.
>
> > em.flush();
>
> Don't do that. Forget about managing resources by yourself and let
> Geronimo do that for you. Besides, it's also not recommended unless
> you're using RESOURCE_LOCAL PU which is not recommended in the managed
> environment like Geronimo either.
i think there was some reason why i called em.flush() but i commented it out
now and it seems to work fine too. if i run into some problem i will tell ;)
Show us the persistence.xml. Let's make it better/simpler/shorter
> (cross out or add any word you'd like to hear about your app ;-)). The
> less you write it's better for your app. That's why Geronimo (or other
> Java EE 5 app servers) are for.
ok thanks here is my persistence.xml:
<persistence xmlns="http://java.sun.com/xml/ns/persistence"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="
http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"
version="1.0">
<persistence-unit name="valhalla" transaction-type="JTA">
<description>videothek</description>
<provider>org.apache.openjpa.persistence.PersistenceProviderImpl
</provider>
<class>vt.bean.entity.Person</class>
<class>vt.bean.entity.Actor</class>
<class>vt.bean.entity.Director</class>
<class>vt.bean.entity.Movie</class>
<class>vt.bean.entity.Dvd</class>
<properties>
<property name="openjpa.jdbc.DBDictionary" value="postgres"/>
</properties>
<jta-data-source>jdbc/postgres</jta-data-source>
<non-jta-data-source>jdbc/postgres</non-jta-data-source>
</persistence-unit>
</persistence>
it took me some configuration time to get it working this way and i think it
is already as short as it can get ;)
so another thing is when i keep calling the bean repeatedly to insert 1
director per transaction as in a performance test after about 100 inserts it
is the first time i get an exception. the server continues inserting to the
db but the exception is coming every now and then.. i wonder what it means..
i don't want to just throw exceptions here, but maybe you see it with one
eye, taking a short look.. thanks in anyway, here is the stacktrace:
[exec] EM created!
[exec] Write of 1 Directors successful!
[exec] EM created!
[exec] Write of 1 Directors successful!
[exec] EM created!
[exec] Write of 1 Directors successful!
[exec] javax.naming.NamingException: Could not look up :
ejb/WriteDataBean [Root exception is
java.lang.reflect.UndeclaredThrowableException]
[exec] at org.apache.xbean.naming.context.ContextUtil.resolve(
ContextUtil.java:65)
[exec] at org.apache.xbean.naming.context.AbstractContext.lookup(
AbstractContext.java:118)
[exec] at org.apache.xbean.naming.context.AbstractContext.lookup(
AbstractContext.java:617)
[exec] at org.apache.xbean.naming.context.AbstractContext.lookup(
AbstractContext.java:158)
[exec] at org.apache.xbean.naming.context.AbstractContext.lookup(
AbstractContext.java:617)
[exec] at org.apache.xbean.naming.context.AbstractContext.lookup(
AbstractContext.java:158)
[exec] at org.apache.xbean.naming.context.AbstractContext.lookup(
AbstractContext.java:603)
[exec] at javax.naming.InitialContext.lookup(InitialContext.java
:392)
[exec] at vt.servlet.AddServlet.doGet(AddServlet.java:46)
[exec] at javax.servlet.http.HttpServlet.service(HttpServlet.java
:693)
[exec] at javax.servlet.http.HttpServlet.service(HttpServlet.java
:806)
[exec] at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
ApplicationFilterChain.java:290)
[exec] at org.apache.catalina.core.ApplicationFilterChain.doFilter(
ApplicationFilterChain.java:206)
[exec] at org.apache.catalina.core.StandardWrapperValve.invoke(
StandardWrapperValve.java:230)
[exec] at org.apache.catalina.core.StandardContextValve.invoke(
StandardContextValve.java:175)
[exec] at
org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(
DefaultSubjectValve.java:56)
[exec] at
org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(
GeronimoStandardContext.java:353)
[exec] at
org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(
GeronimoBeforeAfterValve.java:47)
[exec] at org.apache.catalina.core.StandardHostValve.invoke(
StandardHostValve.java:128)
[exec] at org.apache.catalina.valves.ErrorReportValve.invoke(
ErrorReportValve.java:104)
[exec] at org.apache.catalina.core.StandardEngineValve.invoke(
StandardEngineValve.java:109)
[exec] at org.apache.catalina.valves.AccessLogValve.invoke(
AccessLogValve.java:563)
[exec] at org.apache.catalina.connector.CoyoteAdapter.service(
CoyoteAdapter.java:261)
[exec] at org.apache.coyote.http11.Http11Processor.process(
Http11Processor.java:844)
[exec] at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(
Http11Protocol.java:581)
[exec] at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(
JIoEndpoint.java:447)
[exec] at java.lang.Thread.run(Thread.java:619)
[exec] Caused by: java.lang.reflect.UndeclaredThrowableException
[exec] at $Proxy22.create(Unknown Source)
[exec] at
org.apache.openejb.core.ivm.naming.BusinessRemoteReference.getObject(
BusinessRemoteReference.java:33)
[exec] at org.apache.openejb.core.ivm.naming.IvmContext.lookup(
IvmContext.java:150)
[exec] at
org.apache.openejb.core.ivm.naming.IntraVmJndiReference.getObject(
IntraVmJndiReference.java:38)
[exec] at org.apache.openejb.core.ivm.naming.Reference.getContent(
Reference.java:40)
[exec] at org.apache.xbean.naming.context.ContextUtil.resolve(
ContextUtil.java:61)
[exec] ... 26 more
[exec] Caused by: java.rmi.RemoteException: Container has suffered a
SystemException; nested exception is:
[exec] java.io.NotSerializableException:
org.apache.openjpa.persistence.EntityManagerImpl
[exec] at org.apache.openejb.core.ivm.EjbHomeProxyHandler._invoke(
EjbHomeProxyHandler.java:243)
[exec] at org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(
BaseEjbProxyHandler.java:245)
[exec] at
org.apache.openejb.util.proxy.Jdk13InvocationHandler.invoke(
Jdk13InvocationHandler.java:49)
[exec] ... 32 more
[exec] Caused by: java.io.NotSerializableException:
org.apache.openjpa.persistence.EntityManagerImpl
[exec] at java.io.ObjectOutputStream.writeObject0(
ObjectOutputStream.java:1156)
[exec] at java.io.ObjectOutputStream.defaultWriteFields(
ObjectOutputStream.java:1509)
[exec] at java.io.ObjectOutputStream.writeSerialData(
ObjectOutputStream.java:1474)
[exec] at java.io.ObjectOutputStream.writeOrdinaryObject(
ObjectOutputStream.java:1392)
[exec] at java.io.ObjectOutputStream.writeObject0(
ObjectOutputStream.java:1150)
[exec] at java.io.ObjectOutputStream.defaultWriteFields(
ObjectOutputStream.java:1509)
[exec] at java.io.ObjectOutputStream.writeSerialData(
ObjectOutputStream.java:1474)
[exec] at java.io.ObjectOutputStream.writeOrdinaryObject(
ObjectOutputStream.java:1392)
[exec] at java.io.ObjectOutputStream.writeObject0(
ObjectOutputStream.java:1150)
[exec] at java.io.ObjectOutputStream.defaultWriteFields(
ObjectOutputStream.java:1509)
[exec] at java.io.ObjectOutputStream.writeSerialData(
ObjectOutputStream.java:1474)
[exec] at java.io.ObjectOutputStream.writeOrdinaryObject(
ObjectOutputStream.java:1392)
[exec] at java.io.ObjectOutputStream.writeObject0(
ObjectOutputStream.java:1150)
[exec] at java.io.ObjectOutputStream.writeObject(
ObjectOutputStream.java:326)
[exec] at
org.apache.openejb.core.stateful.SimplePassivater.passivate(
SimplePassivater.java:73)
[exec] at
org.apache.openejb.core.stateful.SimplePassivater.passivate(
SimplePassivater.java:93)
[exec] at
org.apache.openejb.core.stateful.StatefulInstanceManager.passivate(
StatefulInstanceManager.java:487)
[exec] at
org.apache.openejb.core.stateful.StatefulInstanceManager$BeanEntryQueue.add(
StatefulInstanceManager.java:579)
[exec] at
org.apache.openejb.core.stateful.StatefulInstanceManager.poolInstance(
StatefulInstanceManager.java:413)
[exec] at
org.apache.openejb.core.stateful.StatefulContainer.createEJBObject(
StatefulContainer.java:291)
[exec] at org.apache.openejb.core.stateful.StatefulContainer.invoke
(StatefulContainer.java:241)
[exec] at org.apache.openejb.core.ivm.EjbHomeProxyHandler.create(
EjbHomeProxyHandler.java:267)
[exec] at org.apache.openejb.core.ivm.EjbHomeProxyHandler._invoke(
EjbHomeProxyHandler.java:158)
[exec] ... 34 more
[exec] EM created!
[exec] Write of 1 Directors successful!
[exec] EM created!
[exec] Write of 1 Directors successful!
greetings,
mario
Re: Geronimo 2.0.2 - OpenEJB "Passivation Failed"
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On Mon, Feb 25, 2008 at 12:20 PM, Mario Kofler <ma...@gmail.com> wrote:
> so there is a simple reason why i decided to close the entity manager
> explicitely: because i thought it is a good idea ;)
And you didn't get any exception?! It's disallowed to play with server
managed resources and close them just like you tried to do. The reason
people are still using EJB3 and all the Java EE 5 stack is their
simplicity (or attempt to be simple) as far as resources are
concerned. You just use them and don't have to worry about managing
them - that's the role of Geronimo or other less-feature-rich
application servers ;-) Use it and when you're done forget about them.
Geronimo takes care of them for you.
> em.flush();
Don't do that. Forget about managing resources by yourself and let
Geronimo do that for you. Besides, it's also not recommended unless
you're using RESOURCE_LOCAL PU which is not recommended in the managed
environment like Geronimo either.
> so my thought why to put the em.close() in the @PreDestroy was, because i
> leave the handle to the em open in this method after em.flush(). then to
> close it rightfully i thought i'd put it into the @PreDestroy method. i
> cannot close the em right after em.flush because the SFSB lives longer than
> just one call to this particular write method, so if there is a call to
> another method, like "writeMovie" the em would be closed already and i get
> an exception.
Show us the persistence.xml. Let's make it better/simpler/shorter
(cross out or add any word you'd like to hear about your app ;-)). The
less you write it's better for your app. That's why Geronimo (or other
Java EE 5 app servers) are for.
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: Geronimo 2.0.2 - OpenEJB "Passivation Failed"
Posted by Mario Kofler <ma...@gmail.com>.
2008/2/25, Jacek Laskowski <ja...@laskowski.net.pl>:
>
> On Sun, Feb 24, 2008 at 12:31 PM, the666pack <ma...@gmail.com>
> wrote:
>
> > the only thing i do in the @PreDestroy method is to explicitly close
> the
> > entity manager via em.close() and then print a line to stdout that the
> > entitymanager was closed. am i not supposed to close the em?
>
>
> Dave explained why it blew up. What worried me a lot was when you
> wrote that you closed em explicitly? Why are you doing it? Show the
> code so it's simpler to talk about it.
hello.
so there is a simple reason why i decided to close the entity manager
explicitely: because i thought it is a good idea ;)
so in my "WriteDataBean" class i have more different methods which are all
writing data to the database. One time it is Directors, one time Movies..
and so on. one of these methods, the "writeDirectors" is in the following
code listing:
private String writeDirectors()
{
try
{
for(int i=0;i<newDirectors;i++)
{
Director d = new Director();
Calendar c = Calendar.getInstance();
c.set(1900+i,00,02);
d.setName("Terry"+i);
d.setBirthdate(c);
d.setOrigin("GB");
em.persist(d);
em.flush();
}
}
catch(Exception e)
{
e.printStackTrace();
return e.getMessage();
}
return "Write to DB success!";
}
very stupid method which just adds an amount of directors with fixed values
to the database.
so my thought why to put the em.close() in the @PreDestroy was, because i
leave the handle to the em open in this method after em.flush(). then to
close it rightfully i thought i'd put it into the @PreDestroy method. i
cannot close the em right after em.flush because the SFSB lives longer than
just one call to this particular write method, so if there is a call to
another method, like "writeMovie" the em would be closed already and i get
an exception.
that were my thoughts on this.
thanks,
mario.
Re: Geronimo 2.0.2 - OpenEJB "Passivation Failed"
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On Sun, Feb 24, 2008 at 12:31 PM, the666pack <ma...@gmail.com> wrote:
> the only thing i do in the @PreDestroy method is to explicitly close the
> entity manager via em.close() and then print a line to stdout that the
> entitymanager was closed. am i not supposed to close the em?
Dave explained why it blew up. What worried me a lot was when you
wrote that you closed em explicitly? Why are you doing it? Show the
code so it's simpler to talk about it.
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: Geronimo 2.0.2 - OpenEJB "Passivation Failed"
Posted by the666pack <ma...@gmail.com>.
Jacek Laskowski wrote:
>
>
> Hi,
>
> You should be concerned although the message level is too low I guess.
> It happens when openejb attempts to passivate an instance so that
> particular instance is in fact destroyed (the @PreDestroy method may
> have been called). I think you may not have seen any troubles yet as
> you didn't reuse the sfsbs and hence you didn't notice these
> passivated instances were no longer active. Let's find out why the
> bean is not capable of being passivated. How does it look like? I
> guess it uses a logger instance or such with no transient keyword
> specified, doesn't it?
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.JacekLaskowski.pl
>
>
hello jacek,
the only thing i do in the @PreDestroy method is to explicitly close the
entity manager via em.close() and then print a line to stdout that the
entitymanager was closed. am i not supposed to close the em?
thanks,
mario
--
View this message in context: http://www.nabble.com/Geronimo-2.0.2---OpenEJB-%22Passivation-Failed%22-tp15663519s134p15668868.html
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Geronimo 2.0.2 - OpenEJB "Passivation Failed"
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On Sun, Feb 24, 2008 at 4:24 AM, the666pack <ma...@gmail.com> wrote:
> [exec] 13:04:31,854 INFO [OpenEJB] finished invoking method create
> [exec] 13:04:31,855 INFO [OpenEJB] finished invoking method create
> [exec] 13:04:31,857 INFO [OpenEJB] Passivating to file
> /usr/local/geronimo/5-2.0.2/var/temp/11d1def534ea1be0=-8cc2910=1184b52f0a4=-7e38
> [exec] 13:04:31,865 INFO [OpenEJB] Passivation failed
> [exec] java.io.NotSerializableException: vt.bean.stateful.WriteDataBean
> [exec] at
> java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156)
> [exec] at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
> [exec] at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
> [exec] at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
> [exec] at
> java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
> [exec] at
> java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509)
> [exec] at
> java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474)
> [exec] at
> java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392)
> [exec] at
> java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150)
> [exec] at
> java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326)
> [exec] at
> org.apache.openejb.core.stateful.SimplePassivater.passivate(SimplePassivater.java:73)
...
> does this error concern me? i mean does it affect the result? the server
> seems to keep running and as it is just an "[INFO]" message i am not sure
> what to think about it.
Hi,
You should be concerned although the message level is too low I guess.
It happens when openejb attempts to passivate an instance so that
particular instance is in fact destroyed (the @PreDestroy method may
have been called). I think you may not have seen any troubles yet as
you didn't reuse the sfsbs and hence you didn't notice these
passivated instances were no longer active. Let's find out why the
bean is not capable of being passivated. How does it look like? I
guess it uses a logger instance or such with no transient keyword
specified, doesn't it?
Jacek
--
Jacek Laskowski
http://www.JacekLaskowski.pl
Re: Geronimo 2.0.2 - OpenEJB "Passivation Failed"
Posted by the666pack <ma...@gmail.com>.
David Blevins wrote:
>
>
> Nothing like that. Best you can do is bump your poolSize up much
> higher. The settings we supply are very conservative and you could
> likely have a much higher limit depending on the memory limits of your
> vm.
>
> -David
>
>
>
ok, i overcame the issue now with editing /var/config/config.xml and setting
BulkPassivate to 0:
<gbean name="DefaultStatefulContainer">
<attribute name="properties">TimeOut=30
PoolSize=100
BulkPassivate=0</attribute>
</gbean>
now the error is gone. i want to thank you for your help
greetings,
mario
--
View this message in context: http://www.nabble.com/Re%3A-Geronimo-2.0.2---OpenEJB-%22Passivation-Failed%22-tp15880469s134p16024338.html
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Geronimo 2.0.2 - OpenEJB "Passivation Failed"
Posted by David Blevins <da...@visi.com>.
On Mar 10, 2008, at 4:38 AM, the666pack wrote:
>
>
>
> David Blevins wrote:
>>
>>
>> You could implement serializable on your Entity beans, but it's ill
>> advised in almost any situation to have the data passivated with your
>> bean as you wind up with a private, detached, copy of the data that
>> may be outdated. The rare case may be that you're collecting data
>> that has yet to be persisted (never been attached) and therefore
>> doesn't live in the EntityManager's cache or database yet, but even
>> then you should really be using a transaction which would prevent
>> your
>> bean from getting passivated at all so the issue should never arise.
>>
> so this means i have to manually "turn off" the passivation of my
> SFSB via
> bean managed transactions. but i suppose this means a performance
> loss :(.
A container or bean managed transaction will work, though a bean
managed may be easier for long running transactions.
> is this problem another issue of the bug mentioned above and so the
> only
> solution is turning off the passivation mechanism?
No, this is just a warning to be careful of *potential* complications
serializing (which is storing) database data somewhere that is not the
database for future use. It is fine to do in the right
circumstances. Just wanted you to be aware there is an actively
maintained cache of entities in the EntityManager itself which never
leaves memory. In terms of temporary storage, it's usually the far
better place than a serialized stateful bean.
Also know that it is possible to implement serialization api methods
in your stateful bean such as writeObject and readObject which gives
you more control of what and how your bean is serialized/
deserialized. It is possible to do things like write the primary key
data of the entities you're holding during serialization, then in
deserialization use the EntityManager and primary keys to grab the
live entities again.
> further, til now whenever i tried to make some kind of manual
> transaction in
> my beans i always got the error that the container is taking care of
> the
> transactions and bean managed control (transactions) is not allowed.
> maybe
> you can tell me what i have to change to be able to add transactions
> to my
> bean.
You just have to add this to your bean:
@TransactionManagement(TransactionManagementType.BEAN)
The default is TransactionManagementType.CONTAINER as you've noticed.
Just another FYI on a good reference, here's a full list javax.ejb and
javax.annotation annotations and their defaults when unspecified: http://openejb.apache.org/3.0/annotations-xml-and-defaults.html
> and even further, is there the possibility to turn off the
> passivation for
> SFSB at all in geronimo? like some entry in a deployment descriptor
> "passivation=false" ?
Nothing like that. Best you can do is bump your poolSize up much
higher. The settings we supply are very conservative and you could
likely have a much higher limit depending on the memory limits of your
vm.
-David
Re: Geronimo 2.0.2 - OpenEJB "Passivation Failed"
Posted by the666pack <ma...@gmail.com>.
David Blevins wrote:
>
>
> You could implement serializable on your Entity beans, but it's ill
> advised in almost any situation to have the data passivated with your
> bean as you wind up with a private, detached, copy of the data that
> may be outdated. The rare case may be that you're collecting data
> that has yet to be persisted (never been attached) and therefore
> doesn't live in the EntityManager's cache or database yet, but even
> then you should really be using a transaction which would prevent your
> bean from getting passivated at all so the issue should never arise.
>
> -David
>
>
>
>
so this means i have to manually "turn off" the passivation of my SFSB via
bean managed transactions. but i suppose this means a performance loss :(.
is this problem another issue of the bug mentioned above and so the only
solution is turning off the passivation mechanism?
further, til now whenever i tried to make some kind of manual transaction in
my beans i always got the error that the container is taking care of the
transactions and bean managed control (transactions) is not allowed. maybe
you can tell me what i have to change to be able to add transactions to my
bean.
and even further, is there the possibility to turn off the passivation for
SFSB at all in geronimo? like some entry in a deployment descriptor
"passivation=false" ?
thanks a lot for helping,
mario.
--
View this message in context: http://www.nabble.com/Re%3A-Geronimo-2.0.2---OpenEJB-%22Passivation-Failed%22-tp15880469s134p15950694.html
Sent from the Apache Geronimo - Users mailing list archive at Nabble.com.
Re: Geronimo 2.0.2 - OpenEJB "Passivation Failed"
Posted by Mario Kofler <ma...@gmail.com>.
2008/3/10, Mario Kofler <ma...@gmail.com>:
>
>
>
> 2008/3/10, David Blevins david.blevins@visi.com:
> >
> >
> >
> > You could implement serializable on your Entity beans, but it's ill
> > advised in almost any situation to have the data passivated with your
> > bean as you wind up with a private, detached, copy of the data that
> > may be outdated. The rare case may be that you're collecting data
> > that has yet to be persisted (never been attached) and therefore
> > doesn't live in the EntityManager's cache or database yet, but even
> > then you should really be using a transaction which would prevent your
> > bean from getting passivated at all so the issue should never arise.
> >
> > -David
>
>
> so this means i have to manually "turn off" the passivation of my SFSB via
> bean managed transactions. but i suppose this means a performance loss :(.
> is this problem another issue of the bug mentioned above and so the only
> solution is turning off the passivation mechanism?
>
> further, til now whenever i tried to make some kind of manual transaction
> in my beans i always got the error that the container is taking care of the
> transactions and bean managed control (transactions) is not allowed. maybe
> you can tell me what i have to change to be able to add transactions to
> my bean.
>
> thanks, mario
>
>
>
>
and even further, is there the possibility to turn off the passivation for
SFSB at all in geronimo? like some entry in a deployment descriptor
"passivation=false" ?
thanks for helping,
mario.
Re: Geronimo 2.0.2 - OpenEJB "Passivation Failed"
Posted by Mario Kofler <ma...@gmail.com>.
2008/3/10, David Blevins david.blevins@visi.com:
>
>
>
> You could implement serializable on your Entity beans, but it's ill
> advised in almost any situation to have the data passivated with your
> bean as you wind up with a private, detached, copy of the data that
> may be outdated. The rare case may be that you're collecting data
> that has yet to be persisted (never been attached) and therefore
> doesn't live in the EntityManager's cache or database yet, but even
> then you should really be using a transaction which would prevent your
> bean from getting passivated at all so the issue should never arise.
>
> -David
so this means i have to manually "turn off" the passivation of my SFSB via
bean managed transactions. but i suppose this means a performance loss :(.
is this problem another issue of the bug mentioned above and so the only
solution is turning off the passivation mechanism?
further, til now whenever i tried to make some kind of manual transaction in
my beans i always got the error that the container is taking care of the
transactions and bean managed control (transactions) is not allowed. maybe
you can tell me what i have to change to be able to add transactions to
my bean.
thanks, mario
Re: Geronimo 2.0.2 - OpenEJB "Passivation Failed"
Posted by David Blevins <da...@visi.com>.
On Mar 9, 2008, at 11:41 AM, Mario Kofler wrote:
> thanks!
>
> unfortunately i cannot wait til it is coming in a release. the
> problem i have got now is that my SFSB implements Serializable but i
> still keep getting the error!!! very unfortunate.
>
> i realized that the error is not coming after accessing the SFSB but
> just after accessing the method that writes the beans to the database.
>
> Do also the Entity beans have to implement Serializable? or do i
> have to do something for the entity manager which is created in this
> function?
>
Holding the EntityManager itself is fine, it essentially stays in
memory and only a reference to it is serialized. With the Entities
themselves an actual copy of the object is serialzied to disk.
Optimally, you assume the EntityManager has good caching so you don't
need to keep N copies in X numbers of stateful beans in serialized
form on disk. Just keep track of the minimal amount of information
you need to grab your Entities again from the EntityManager (and it's
live cache) when you activate.
You could implement serializable on your Entity beans, but it's ill
advised in almost any situation to have the data passivated with your
bean as you wind up with a private, detached, copy of the data that
may be outdated. The rare case may be that you're collecting data
that has yet to be persisted (never been attached) and therefore
doesn't live in the EntityManager's cache or database yet, but even
then you should really be using a transaction which would prevent your
bean from getting passivated at all so the issue should never arise.
-David
Re: Geronimo 2.0.2 - OpenEJB "Passivation Failed"
Posted by Mario Kofler <ma...@gmail.com>.
thanks!
unfortunately i cannot wait til it is coming in a release. the problem i
have got now is that my SFSB implements Serializable but i still keep
getting the error!!! very unfortunate.
i realized that the error is not coming after accessing the SFSB but just
after accessing the method that writes the beans to the database.
Do also the Entity beans have to implement Serializable? or do i have to do
something for the entity manager which is created in this function?
thanks for the help,
mario.
2008/3/6, David Blevins <da...@visi.com>:
>
>
> On Feb 24, 2008, at 1:27 PM, David Blevins wrote:
>
> >
> > On Feb 24, 2008, at 4:24 AM, the666pack wrote:
> >
> >> [exec] 13:04:31,865 INFO [OpenEJB] Passivation failed
> >> [exec] java.io.NotSerializableException:
> >> vt.bean.stateful.WriteDataBean
> >> [exec] at
> >> java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156)
> >
> > This is an unimplemented feature:
> http://issues.apache.org/jira/browse/OPENEJB-215
> >
> > The workaround is to add java.io.Serializable to your stateful bean
> > class.
>
>
> FYI, this feature is now implemented and should show up in a release
> Real Soon Now.
>
>
> -David
>
>
Re: Geronimo 2.0.2 - OpenEJB "Passivation Failed"
Posted by David Blevins <da...@visi.com>.
On Feb 24, 2008, at 1:27 PM, David Blevins wrote:
>
> On Feb 24, 2008, at 4:24 AM, the666pack wrote:
>
>> [exec] 13:04:31,865 INFO [OpenEJB] Passivation failed
>> [exec] java.io.NotSerializableException:
>> vt.bean.stateful.WriteDataBean
>> [exec] at
>> java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156)
>
> This is an unimplemented feature: http://issues.apache.org/jira/browse/OPENEJB-215
>
> The workaround is to add java.io.Serializable to your stateful bean
> class.
FYI, this feature is now implemented and should show up in a release
Real Soon Now.
-David
Re: Geronimo 2.0.2 - OpenEJB "Passivation Failed"
Posted by David Blevins <da...@visi.com>.
On Feb 24, 2008, at 4:24 AM, the666pack wrote:
> [exec] 13:04:31,865 INFO [OpenEJB] Passivation failed
> [exec] java.io.NotSerializableException:
> vt.bean.stateful.WriteDataBean
> [exec] at
> java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1156)
This is an unimplemented feature: http://issues.apache.org/jira/browse/OPENEJB-215
The workaround is to add java.io.Serializable to your stateful bean
class.
-David