RE: How to set orion to perform a timely task..

2001-03-05 Thread Jaco van Rooijen
Title: SV: How to set orion to perform a timely task..



We use 
a client application that runs in the orion vm that uses a scheduledTIMER 
- they've been added in JDK1.3
 Timer t = new 
Timer(true); t.schedule(new Job(), 0, 
20);

Jaco

  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]]On Behalf Of Magnus 
  RydinSent: 05 March 2001 10:08To: 
  Orion-InterestSubject: SV: How to set orion to perform a timely 
  task..
  how about an client-application that does some operation on 
  scheudled hours? WR 
   -Ursprungligt meddelande-  Fran: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]  Skickat: den 3 mars 2001 09:44  Till: 
  Orion-Interest  Amne: How to set orion to perform 
  a timely task..   
   Hello,  I need to 
  have my EJB perform some DB operation at midnight everyday.  How do I do that?  In PC, I could 
  create a timer object to do that with VC++, but in Java  it does not seem to have such a functionality. And I think it's 
  ideal  to handle it in the server side rather than 
  play with Java.  In other words, orion may have 
  such a cron function built in to do  something in 
  a timely manner.  If anyone has any experience 
  with this, please tell me how.  Thank you very 
  much in advance.   
   Simon  
   


RE: How to set orion to perform a timely task..

2001-03-05 Thread Jaco van Rooijen
Title: SV: How to set orion to perform a timely task..




We use 
a client application that runs in the orion vm that uses a scheduledTIMER 
- they've been added in JDK1.3
 Timer t = new 
Timer(true); t.schedule(new Job(), 0, 
20);

Jaco

  -Original Message-From: 
  [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED]]On Behalf Of Magnus 
  RydinSent: 05 March 2001 10:08To: 
  Orion-InterestSubject: SV: How to set orion to perform a timely 
  task..
  how about an client-application that does some operation on 
  scheudled hours? WR 
   -Ursprungligt meddelande-  Fran: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]  Skickat: den 3 mars 2001 09:44  Till: 
  Orion-Interest  Amne: How to set orion to perform 
  a timely task..   
   Hello,  I need to 
  have my EJB perform some DB operation at midnight everyday.  How do I do that?  In PC, I could 
  create a timer object to do that with VC++, but in Java  it does not seem to have such a functionality. And I think it's 
  ideal  to handle it in the server side rather than 
  play with Java.  In other words, orion may have 
  such a cron function built in to do  something in 
  a timely manner.  If anyone has any experience 
  with this, please tell me how.  Thank you very 
  much in advance.   
   Simon  
   


RE: Orion Server running out of memory fast!

2001-02-16 Thread Jaco van Rooijen

Correction:

We ran a profiler on the Orion VM  it showed that the server hold the beans
in a List object so the GC cannot have it.  Further, the server aint
passivating.  We wrote to Orion  they admitted it as a bug.

Jaco

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Victor A.
Salaman
Sent: 16 February 2001 06:22
To: Orion-Interest
Subject: RE: Orion Server running out of memory fast!


Well, not to rant here, but your first mistake is using mysql... it's not
designed for ejb/transaction work even though it's been recently kludged to
apparently do that. The second might be a leaky mysql jdbc driver (yes, this
is a known fact). The third might be in your code, and lastly it could be
Orion. Although the last is very unlikely. If you look at the list, a lot of
people have had this problem before... While investigating the problem, the
following common factors arose:

1. Using of mysql
2. Using MS-SQL or MS-Access with JDBC-ODBC driver.
3. Bad JVM

None of the reported cases have traced back to Orion. So before reporting it
as a bug, please track your memory usage using something like OptimizeIt. If
it turns out to be an Orion bug, log it in Bugzilla and the Orion Team will
look at it and provide more assistance.

-- Victor

-Original Message-
From: Peter Kua [mailto:[EMAIL PROTECTED]]
Sent: Thursday, February 15, 2001 11:21 PM
To: Orion-Interest
Subject: Orion Server running out of memory fast!


hello,

we've been running into "out of memory" problems recently.

we are deploying about 10-12 BMP EJBs and after a few minutes of intensive
querying the database, we run out of memory. seems like the EJB does not
passivate or the GC is not doing it's job, although i've tried to null all
the objects i don't need anymore. basically i have a jsp page calling a bean
that is calling the home and remote interface of the EJB.

we are using jdk1.3, orion 1.4.5 and MySQL. has any user reported similar
out of memory problems? the documentation doesn't say anything.

any help is greatly appreciated, so that i'll be able to convince my client
that orion server is THE server of choice.

thanks! peter kua







Re: RE: Garbage collection, out of memory

2001-02-15 Thread Jaco van Rooijen

The problem is not that simple.  There's a bug.

We then ran a test program that creates a simple entity bean in an infinite
loop and then releases the reference of this entity bean. We ran a profiler
on the VM and counted the memory instances. The server keeps the beans in a
list, so the GC cant have them, and it turns out that even though memory
seems to be running out, orion does not passivate.

We told them, and [EMAIL PROTECTED] said thanx and they'd fix it, but
they cannot give an estimate of when - we've been waiting for 3 months now.
Up to 1.4.5 you could not limit the pool size, so there aint no way to force
it to start passivating.

Regards
Jaco

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Tim Endres
Sent: 13 February 2001 23:32
To: Orion-Interest
Subject: Re: Garbage collection, out of memory


Your GC times are huge because you have provided so much memory. If you
reduce the 500MB to 128MB, you will see more GC's, but they will be much
shorter. This is a well known optimization issue. Too little memory causes
to many GC runs, while too much memory causes GC runs to be too long. You
need to experiment to find the best amount of memory to allocate.

tim.

 Hello

 We are experiencing a garbage collection problem.  We are running Orion
 1.4.7 on a Linux 2.4 box.  We have been trying the Sun 1.2.2, the Sun 1.3
 and the IBM JVM 1.3.  On the Sun 1.3 JVM we have tried normal garbage
 collection and also -Xincgc incremental garbage collection.  We run with
 500 megabytes of heap space available to Java.

 The system uses lots of EJBs (mainly stateless session but also quite a
 few entities and a handful of stateful session beans), and we have JSP
 pages which run in the same JVM.

 The system runs very responsively and well, with up to 90 users
 simultaneously using it, for up to an hour.  Then enormous GCs start
 happening which block all activity for up to 180 seconds at a time!  The
 length and frequency of the freezes vary with the different JVMs but all
 are unusable after say an hour of up time.

 The Sun 1.3 in incremental GC mode is the best, and in fact remains stable
 and usable until it starts doing a few 9 second GCs from time to time
 (comparatively bearable) until we get a "HotSpot internal error" which
 stops all processing.

 We are trying all sorts of different things to stop our users getting
 upset, like reducing the JSP session timeout to a minimum, and are
 currently trying to analyse the code with JProbe to find out how to
 minimise unnecessary object creation or memory leaks (stale references to
 no longer used objects etc).

 As several list members have already said, it also seems that some beans
 are never passivated.

 What can we do to make Orion stop using more and more memory, and not to
 cause such outrageous garbage collection cycles?

 Any comments or suggestions would be very much appreciated.

 --
 Thomas Munro [EMAIL PROTECTED]
  http://www.fullsix.com/
  Fullsix Technology (Paris)









RE: Orion Server running out of memory fast!

2001-02-15 Thread Jaco van Rooijen

Indeed

We then ran a test program that creates a simple entity bean in an infinite
loop and then releases the reference of this entity bean. We ran a profiler
on the VM and counted the memory instances. It turns out that
even though memory seems to be running out, orion does not passivate the
beans that are not being used anymore.  Only halve of our projects have this
bug, we cannot see the pattern yet.  Of course the bigger project with the
tighter deadline has it too.

[EMAIL PROTECTED] said thanx and they'd fix it, but they cannot give
an estimate of when - we've been waiting for 3 months now.  Up to 1.4.5 you
could not limit the pool size, so there aint no way to force it to start
passivating.

Regards
Jaco

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Peter Kua
Sent: 16 February 2001 05:21
To: Orion-Interest
Subject: Orion Server running out of memory fast!


hello,

we've been running into "out of memory" problems recently.

we are deploying about 10-12 BMP EJBs and after a few minutes of intensive
querying the database, we run out of memory. seems like the EJB does not
passivate or the GC is not doing it's job, although i've tried to null all
the objects i don't need anymore. basically i have a jsp page calling a bean
that is calling the home and remote interface of the EJB.

we are using jdk1.3, orion 1.4.5 and MySQL. has any user reported similar
out of memory problems? the documentation doesn't say anything.

any help is greatly appreciated, so that i'll be able to convince my client
that orion server is THE server of choice.

thanks! peter kua







RE: Garbage collection, out of memory

2001-02-15 Thread Jaco van Rooijen

Sounds good, but WHERE does these parameters go?  I include a snippit of my
orion-ejb-jar.xml file...


entity-deployment name="ejb/ActualBankControl"
location="ejb/ActualBankControl"
wrapper="ActualBankControlHome_EntityHomeWrapper78"
table="ejb/ActualBankControl"
ejb-ref-mapping name="ejb/EventLogDB" /
resource-ref-mapping name="jdbc/ActualBankControlDataSource" /
/entity-deployment

Thanx
Jaco

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Michael
Doernberg
Sent: 14 February 2001 01:45
To: Orion-Interest
Subject: Re: Garbage collection, out of memory


When you deploy your application. Orion will generate an XML file called
orion-ejb-jar.xml, if one does not exist. The file is derived from your
EJBs.  The file can be found buried in the application-deployments
directory.

You can set some parameters on each EJB you deem appropriate. These
parameters are not set in the auto generated file.

The first is a "validity-timeout" set to milliseconds. This will passivate
the the EJB if not active.

The second is a parameter called "max-instances" . This is set to the max
number of EJBs of a particular type you want. I am not sure if this is
supported yet, but I believe it was supposed to be implemented in the 1.4.7.

Hope this help. Let me know what you figure out.

-Mike




- Original Message -
From: "Thomas Munro" [EMAIL PROTECTED]
To: "Orion-Interest" [EMAIL PROTECTED]
Sent: Tuesday, February 13, 2001 1:29 PM
Subject: Garbage collection, out of memory


 Hello

 We are experiencing a garbage collection problem.  We are running Orion
 1.4.7 on a Linux 2.4 box.  We have been trying the Sun 1.2.2, the Sun 1.3
 and the IBM JVM 1.3.  On the Sun 1.3 JVM we have tried normal garbage
 collection and also -Xincgc incremental garbage collection.  We run with
 500 megabytes of heap space available to Java.

 The system uses lots of EJBs (mainly stateless session but also quite a
 few entities and a handful of stateful session beans), and we have JSP
 pages which run in the same JVM.

 The system runs very responsively and well, with up to 90 users
 simultaneously using it, for up to an hour.  Then enormous GCs start
 happening which block all activity for up to 180 seconds at a time!  The
 length and frequency of the freezes vary with the different JVMs but all
 are unusable after say an hour of up time.

 The Sun 1.3 in incremental GC mode is the best, and in fact remains stable
 and usable until it starts doing a few 9 second GCs from time to time
 (comparatively bearable) until we get a "HotSpot internal error" which
 stops all processing.

 We are trying all sorts of different things to stop our users getting
 upset, like reducing the JSP session timeout to a minimum, and are
 currently trying to analyse the code with JProbe to find out how to
 minimise unnecessary object creation or memory leaks (stale references to
 no longer used objects etc).

 As several list members have already said, it also seems that some beans
 are never passivated.

 What can we do to make Orion stop using more and more memory, and not to
 cause such outrageous garbage collection cycles?

 Any comments or suggestions would be very much appreciated.

 --
 Thomas Munro [EMAIL PROTECTED]
  http://www.fullsix.com/
  Fullsix Technology (Paris)










Out Of Memory Problem / Passivation Error

2001-02-01 Thread Jaco van Rooijen

Hi

We urgently need a solution to the following problem:

We get java.lang.OutOfMemoryErrors with our application. We increased the
amount of allocated memory to the heap, with the result that the application
just took a bit longer to run out of memory.

We then ran a test program that creates a simple entity bean in an infinite
loop and then releases the reference of this entity bean. It turns out that
even though memory seems to be running out, orion does not passivate the
beans that are not being used anymore. Is this correct behavior? Shouldn't
unused active beans be passivated at some point?

Is it possible to limit the pool size of an entity bean?

We are using JDK 1.3 and OrionServer 1.4.5.

Thanks
Jaco





Re: RE: LogicalDriverManagerXAConnection not closed

2000-10-10 Thread Jaco van Rooijen

I think not.  This is the first time I GET the connection, and it complains that I did 
not close it.  Also, according to my understanding, I do not have to explicitly close 
pooled connections.  At least, when we were using 1.0.3 the documentation said 
something to that effect.

Thanx for responding, I thought I wasn't getting my message through.
Jaco

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Will Glozer
Sent: 09 October 2000 19:09
To: Orion-Interest
Subject: RE: LogicalDriverManagerXAConnection not closed


It means that you forgot to close the connection when you
were finished using it.

-Original Message-
From: Jaco van Rooijen [mailto:[EMAIL PROTECTED]]
Sent: Monday, October 09, 2000 12:08 AM
To: Orion-Interest
Subject: RE: LogicalDriverManagerXAConnection not closed


Anybody have any ideas?

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jaco van
Rooijen
Sent: 06 October 2000 13:40
To: Orion-Interest
Subject: LogicalDriverManagerXAConnection not closed


I am developing against the stable 1.3.8

I get an output stating:
LogicalDriverManagerXAConnection not closed, check your code!
Created at:
java.lang.Throwable: OrionCMTConnection created
at com.evermind.sql.ai.init(JAX)
at com.evermind.sql.OrionCMTDataSource.getConnection(JAX)
at
com.agri24.data.LegalEntityBean.getConnection(LegalEntityBean.java:843)
at
com.agri24.data.LegalEntityBean.ejbFindByAgri24ID(LegalEntityBean.java:463)
at
LegalEntityHome_EntityHomeWrapper55.findByAgri24ID(LegalEntityHome_EntityHom
eWrapper55.java:1122)
at java.lang.reflect.Method.invoke(Native Method)
at com.evermind.server.rmi.bd.run(JAX)
at com.evermind.server.rmi.bb.hy(JAX)
at com.evermind.server.rmi.bb.run(JAX)
at com.evermind.util.f.run(JAX)

LegalEntityBean.java:843 says - 
  Connection newConn =
((javax.sql.DataSource)ctx.lookup("java:comp/env/jdbc/LegalEntityDataSource"
)).getConnection();  
The call goes through, but the console has this exception on it.  What does
that mean?

Regards
Jaco









RE: LogicalDriverManagerXAConnection not closed

2000-10-09 Thread Jaco van Rooijen

Anybody have any ideas?

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jaco van
Rooijen
Sent: 06 October 2000 13:40
To: Orion-Interest
Subject: LogicalDriverManagerXAConnection not closed


I am developing against the stable 1.3.8

I get an output stating:
LogicalDriverManagerXAConnection not closed, check your code!
Created at:
java.lang.Throwable: OrionCMTConnection created
at com.evermind.sql.ai.init(JAX)
at com.evermind.sql.OrionCMTDataSource.getConnection(JAX)
at com.agri24.data.LegalEntityBean.getConnection(LegalEntityBean.java:843)
at com.agri24.data.LegalEntityBean.ejbFindByAgri24ID(LegalEntityBean.java:463)
at 
LegalEntityHome_EntityHomeWrapper55.findByAgri24ID(LegalEntityHome_EntityHomeWrapper55.java:1122)
at java.lang.reflect.Method.invoke(Native Method)
at com.evermind.server.rmi.bd.run(JAX)
at com.evermind.server.rmi.bb.hy(JAX)
at com.evermind.server.rmi.bb.run(JAX)
at com.evermind.util.f.run(JAX)

LegalEntityBean.java:843 says - 
  Connection newConn = 
((javax.sql.DataSource)ctx.lookup("java:comp/env/jdbc/LegalEntityDataSource")).getConnection();
  
The call goes through, but the console has this exception on it.  What does that mean?

Regards
Jaco







LogicalDriverManagerXAConnection not closed

2000-10-06 Thread Jaco van Rooijen

I am developing against the stable 1.3.8

I get an output stating:
LogicalDriverManagerXAConnection not closed, check your code!
Created at:
java.lang.Throwable: OrionCMTConnection created
at com.evermind.sql.ai.init(JAX)
at com.evermind.sql.OrionCMTDataSource.getConnection(JAX)
at com.agri24.data.LegalEntityBean.getConnection(LegalEntityBean.java:843)
at com.agri24.data.LegalEntityBean.ejbFindByAgri24ID(LegalEntityBean.java:463)
at 
LegalEntityHome_EntityHomeWrapper55.findByAgri24ID(LegalEntityHome_EntityHomeWrapper55.java:1122)
at java.lang.reflect.Method.invoke(Native Method)
at com.evermind.server.rmi.bd.run(JAX)
at com.evermind.server.rmi.bb.hy(JAX)
at com.evermind.server.rmi.bb.run(JAX)
at com.evermind.util.f.run(JAX)

LegalEntityBean.java:843 says - 
  Connection newConn = 
((javax.sql.DataSource)ctx.lookup("java:comp/env/jdbc/LegalEntityDataSource")).getConnection();
  
The call goes through, but the console has this exception on it.  What does that mean?

Regards
Jaco