from:"Howard W. Smith, Jr."

Forgot the following footnote:

[1] http://openejb.apache.org/examples-trunk/schedule-methods/README.html


On Sat, Dec 29, 2012 at 5:28 PM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:

 Recently, I added multiple @Schedule methods to ONE @Singleton bean, and i
 ran into LOCK errors/exceptions, so I resolved that by moving the @Schedule
 methods to their own @Singleton bean. Today/yesterday, I just recognized
 the TomEE Schedule Methods example [1], so I'm planning to use the sample
 code provided in that example and move the @Schedule methods back to one
 @Singleton bean and monitor how it performs...in production. :)

Re: Using TomEE 1.5.2 SNAPSHOT, and NO errors in log files!!!

You're welcome. My pleasure! I tend to be a communicator, and I become very
much the loyal type when I am treated well, and I like to spread/share the
news and/or my experience! :)

FYI, my endusers are loving the web app, too!


On Sat, Dec 29, 2012 at 5:32 PM, Jean-Louis MONTEIRO jeano...@gmail.comwrote:

 Hi Howard,

 Thanks for the feedback and let us know about those new tests and the
 results.
 With such a feedback and the whole amount of questions you can raise, you
 are making TomEE even better each time.

 So thanks again for that.

 Jean-Louis

Re: Using TomEE 1.5.2 SNAPSHOT, and NO errors in log files!!!

You're welcome. Well, please note/remember, I am only one person.

FYI, I 'only' downloaded apache-tomee-1.5.2-20121225.041258-14-plus.zip,
installed it on test/dev and production server, let her rip, and there has
been absolutely 'no issues at all' with this JAR/version that I'm currently
running.

I like to 'validate' SNAPSHOT JARs, because I know/feel that they are
legitimate and reliable. I like to watch the user mailing list and the
issue list as well to determine, if I should download. I didn't see any
issues that would seem to impact my web app, so I downloaded and used it
immediately with very little testing on the test/dev server.

That shows my trust in/for TomEE (committers/etc)!


On Sat, Dec 29, 2012 at 5:41 PM, Jean-Louis MONTEIRO jeano...@gmail.comwrote:

 Great!
 Thanks you so much.

 Then, if 1.5.2-SNAPSHOT is working fine for everybody, maybe we can start
 planning a release.
 Maybe by February.

 Gonna raise a topic.

Re: Using TomEE 1.5.2 SNAPSHOT, and NO errors in log files!!!

Mine is a WAR deployed to TomEE, and I am using MyFaces CODI 1.0.6, too,
deployed in WAR's WEB-INF (classes) folder.

Sorry, I didn't read that email, but I'm sure David Blevins and all of the
TomEE committers would appreciate it if you create a new issue/JIRA for
this. [1]

[1] https://issues.apache.org/jira/browse/TOMEE


On Sat, Dec 29, 2012 at 9:42 PM, José Luis Cetina maxtorz...@gmail.comwrote:

 Hey i have issues with the 1.5.2 Snapshot.  I sent an email yesterday about
 using apache codi with tomee in an ear application. I dont have any
 response yet.
 IMO i think this is important because CODI is the same apache stuff.

 Somebody read the email?

Re: Shutdown TomEE hangs at @PreDestroy of CDI @ApplicationScoped bean

2012-12-20 Thread Howard W. Smith, Jr.

AndyG,

On Thu, Dec 20, 2012 at 7:09 AM, AndyG andy.gumbre...@orprovision.com
 wrote:

 Wrap your preDestroy method body in a thread and 'join' it for a period
 before giving up on it. If anything 'hangs' in preDestroy then it will
 prevent a shutdown.


As I stated earlier, I would shutdown the server later on today, and
confirm if the commented out code would allow TomEE to shutdown. I let
TomEE run all day and finally shutdown TomEE, and TomEE shutdown
normally/successfully without the need to use Windows Task Manager. :)

I need to research imap close folder and store, and find out if this is a
good practice, on shutdown of the container/webapp.


On Thu, Dec 20, 2012 at 7:09 AM, AndyG andy.gumbre...@orprovision.com
 wrote:


 Also noted from that log output, you should replace the JVM flag
 CMSPermGenSweepingEnabled with CMSClassUnloadingEnabled (which also
 requires
 UseConcMarkSweepGC). Google is your friend.


I used my friend, Google, to find out how to prevent the warning/msg above.
I tried to change my settings as recommended on the following URL:

http://docs.oracle.com/cd/E13209_01/wlcp/wlss30/configwlss/jvmgc.html

When trying to alter my JVM options, TomEE would not start. Below is what
showed up in stderr log every time i altered JVM options and attempted to
start TomEE. So, I reverted to the JVM options that I've been using, and I
was able to start TomEE. :)


2012-12-20 22:43:54 Commons Daemon procrun stderr initialized

2012-12-20 22:49:05 Commons Daemon procrun stderr initialized

2012-12-20 22:49:54 Commons Daemon procrun stderr initialized

2012-12-20 22:50:28 Commons Daemon procrun stderr initialized

2012-12-20 22:52:31 Commons Daemon procrun stderr initialized

2012-12-20 22:53:21 Commons Daemon procrun stderr initialized

2012-12-20 22:55:16 Commons Daemon procrun stderr initialized

Shutdown TomEE hangs at @PreDestroy of CDI @ApplicationScoped bean

2012-12-19 Thread Howard W. Smith, Jr.

Is this a known issue of TomEE 1.5.1 on Win32 (Windows Server 2003 32-bit)?
I am experiencing this issue, and I usually have use Windows Task Manager
to end the process. I have SLF4J 'info' lines in the @PreDestroy method. I
usually see those lines outputted to server log when TomEE was started
minutes ago. I usually see this behavior when running TomEE all day without
a shutdown or restart. Windows Task Manager seems to reveal a memory leak;
the server/catalina log usually mentions possible threadlocal memory leaks,
especially related to the use of Google Calendar API.

I am currently running the following:

apache-tomee-1.5.1-20121207.152523-plus.zip

tomee-catalina-1.5.1-20121212.041530-107.jar (issue is duplicated with
'and' without this JAR)

I think this all started to occur, when I added javamail imap close folder
and close store. My server/catalina log also reveals that my current
implementation, @Schedule every 10 minutes to check imap store/folder, does
result in imap exceptions (unknown host, etc...).

If this issue is possibly resolved in a later release of TomEE, then please
let me know.

Thanks,
Howard

Re: Why are Tomcat's threads more costly than background threads?

2012-12-17 Thread Howard W. Smith, Jr.

Well, I had that when my app was running via GlassFish. I still have that
code ready to use but websockets and tomee getting it all done for me,
quite nicely. :-)
 On Dec 17, 2012 2:59 AM, Romain Manni-Bucau rmannibu...@gmail.com
wrote:

 Yes and no, it makes the connection being from the client why is better for
 it and it works - when websockets can have issues with proxies and so on.
 Websocket are nice when you have a real protocol...just create one and ask
 the client to ask for an update with a timer, that's already better and you
 keep the full connected advantages
 Le 17 déc. 2012 08:54, Howard W. Smith, Jr. smithh032...@gmail.com a
 écrit :

  Polling is too much network traffic in my opinion. Websocket is instant
  messaging. No need to add polling code and xhtml here there for different
  type of messages coming from server and no need of an ajax request to
  server throughout entire session just to get an update from the server.
   On Dec 17, 2012 2:47 AM, Romain Manni-Bucau rmannibu...@gmail.com
  wrote:
 
   Side note: if your need is pushing regularly to the client just having
  some
   client polling can make it far easier to manage on both sides...
   Le 17 déc. 2012 08:33, Howard W. Smith, Jr. smithh032...@gmail.com
 a
   écrit :
  
Almost forgot...PrimeFaces peer/friend of mine informed me that JMS
 is
   good
for running two instances of an app, similar to load balancer.
   
Prior to using TomEE, I really wanted to use PrimeFaces Push (powered
  by
Atmosphere/websocket), and at that time, I was thinking that I could
possibly run Tomcat or TomEE just to push messages to the clients of
 my
   app
running on Glassfish, since Glassfish had issues with PrimeFaces Push
(Atmosphere). I think he said that tomEE and Glassfish could do that,
  but
they would have to communicate via JMS or the two servlets would have
  to
serve requests/responses, appropriately, via JMS.
   
I am probably not stating the above correctly as he said, but that's
  how
   I
understood what he told me.
   
Now that I'm only using tomEE, there is no need to do such a thing.
   Loving
TomEE!!!
   
   
   
On Mon, Dec 17, 2012 at 2:26 AM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:
   
 Very interesting discussion and responses here! Anthony motivates
 me
  to
 jump on the bandwagon of using JMS/message-driven-beans, and at the
   same
 time, Romain tells me, not much need (for local) in a Java EE 6
 application. :)

 Either way, i have not ruled out JMS. I have done some strategic
  coding
on
 my part to avoid @Schedule or use of timer service...using Date
 class
   to
 postpone pushing data to google calendar, and only pushing when
 there
   is
a
 new date to update...application-wide. At first, i was pushing data
  to
 google calendar after 'every' update request... sending over 1,000
requests
 to google calendar sometimes or daily (adding and deleting events
 on
google
 calendar to keep google calendar in sync with the database), but I
  cut
that
 back (or decreased the # of requests) with the new code I developed
  2+
 months ago. just makes for a faster user experience since they
   requested
to
 have data updated via ajax on change/selection of this field, and
  that
 field.

 Right now, JMS would be similar to a nice science project for me...
   just
 to see if I can do it and the success of it.


 On Mon, Dec 17, 2012 at 1:57 AM, Romain Manni-Bucau 
rmannibu...@gmail.com
  wrote:

 I used it a lot in javaee 5 (openejb 3) but i'm happy to leave it
 on
   the
 road qince javaee 6, no more.

 It works but i dont find it effective when it stays local

Re: Why are Tomcat's threads more costly than background threads?

Anthony, thanks for the recommendation. I will have to give that a try.
On Dec 16, 2012 8:33 AM, Anthony Fryer apfr...@hotmail.com wrote:

 Another change you could make to improve the performance of the method
 invoked by the timer, is instead of performing the actual database insert
 for each email in that method, instead write a message to a JMS queue.
  Then
 create a message driven bean that processes the JMS messages and performs
 the actual database insert.



 --
 View this message in context:
 http://openejb.979440.n4.nabble.com/Re-Why-are-Tomcat-s-threads-more-costly-than-background-threads-tp4659429p4659697.html
 Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: Why are Tomcat's threads more costly than background threads?

I have never used JMS/message-driven-beans as of yet, but considering it...

On Sun, Dec 16, 2012 at 8:35 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 i'm quite again using JMS for local asynchronism generally

 not the goal of JMS IMO

 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau



 2012/12/16 Anthony Fryer apfr...@hotmail.com:
  Another change you could make to improve the performance of the method
  invoked by the timer, is instead of performing the actual database insert
  for each email in that method, instead write a message to a JMS queue.
  Then
  create a message driven bean that processes the JMS messages and performs
  the actual database insert.
 
 
 
  --
  View this message in context:
 http://openejb.979440.n4.nabble.com/Re-Why-are-Tomcat-s-threads-more-costly-than-background-threads-tp4659429p4659697.html
  Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: Why are Tomcat's threads more costly than background threads?

Good points Anthony and thanks for sharing all that. Stephen, right now, I
assume the same as what you stated. My experience with entirely @stateless
solution, IMHO, got me nowhere because @stateless seems to be application
scope and the database got locked application scope/wide, so that is why I
reverted to user session being responsible for the update. JMS seems a bit
@stateless in its nature to me. I honestly believe that entirely @stateless
can perform narrower scope transactions. Maybe one day I can achieve such a
thing. :-)
On Dec 16, 2012 7:07 PM, Anthony Fryer apfr...@hotmail.com wrote:

Romain, you're opinion means alot so i'm wondering why you are against JMS
in
this case. This kind of pattern happens alot in my experience. In this
case a timer job executes that finds a list of jobs to execute, in this
case
read a list of emails and for each email insert a row into a database.

In my experience, the timer job that executes wants to finish as quickly as
possible so you don't get overlapping timer executions and also to minimize
resource utilization. Putting a jms message on a queue is generally alot
quicker than performing an actual database insert. In addition JMS gives
you guaranteed message delivery, so you know that the message is going to
get processed and not get lost. It is part of the JMS spec that i believe
is very applicable in this case.

As for the transactional semantics that apply to the Message Driven Bean
that performs the actual work of inserting the record into the database,
again i think it works well in this case. If the MDB is executing within a
container managed transaction, then only if the database insert succeeds
and
the transaction commits will the message be taken off the queue. This
means
if the database insert fails, you haven't lost the message and can either
retry or configure the JMS to place the message on an error queue that can
be processed in a different way.

How would you handle a database insert failure in the current solution?

Also I don't think it matters if the MDB that performs the message
processing is local or not. Its irrelevant really. I wouldn't be using
the
JMS just for asynchronous calls. I'd be using it for the guarenteed
message
delivery and processing, performance AND asynchronous processing.

--
View this message in context:
http://openejb.979440.n4.nabble.com/Re-Why-are-Tomcat-s-threads-more-costly-than-background-threads-tp4659429p4659710.html
Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: TomEE 1.5.1: bean encountered a non-application exception; nested exception???

okay, thanks Romain for the response. :)

On Mon, Dec 17, 2012 at 2:09 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 Because that's not an app exception (see ejb spec and/or
 @ApplicationException)
 Le 17 déc. 2012 04:43, Howard W. Smith, Jr. smithh032...@gmail.com a
 écrit :

  First of all, I already fixed the cause of this exception in my app, I
 just
  wanted to ask a question about the exception.
 
  The exception occurred when the following line of code was executed:
 
  ejbFacadeDetails.create(argOrder.getDetailsId());
 
 
  argOrder.getDetailsId() returned/was 'null', because of the following
 code.
 
 
  // these lines below occur at beginning of the method
  OrderDetails orderDetails = new OrderDetails(1);
  orderDetails.setDetailsTx();
  details.append(request.getMessage());
 
  // these lines below occur later on in the code
  if (details.length()  0) {
  orderDetails.setDetailsTx(details.toString());
  order.setDetailsId(orderDetails);
  }
 
 
  I fixed the above code already and the exception is no longer raised, but
  my question is, why is this considered a 'non-application exception' and
 a
  'nested exception' as stated in the stacktrace below?
 
  javax.ejb.EJBException: The bean encountered a non-application exception;
  nested exception is:
  java.lang.IllegalArgumentException: Object: null is not a known entity
  type.
  at
 
 
 org.apache.openejb.core.ivm.BaseEjbProxyHandler.convertException(BaseEjbProxyHandler.java:363)
  at
 
 
 org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:283)
  at
 
 
 jpa.session.OrderDetailsFacade$LocalBeanProxy.create(jpa/session/OrderDetailsFacade.java)
  at
 
 
 jsf.orders.pf_OrdersController.createFromAirportShuttleRequest(pf_OrdersController.java:14194)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
  at java.lang.reflect.Method.invoke(Unknown Source)
  at
 
 
 org.apache.webbeans.intercept.InterceptorHandler.invoke(InterceptorHandler.java:322)
  at
 
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:117)
  at
 
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:108)
  at
 
 
 jsf.orders.pf_OrdersController_$$_javassist_6.createFromAirportShuttleRequest(pf_OrdersController_$$_javassist_6.java)
  at
 
 
 utils.mail.AddAirportShuttleRequest.createOrderForAirportShuttle(AddAirportShuttleRequest.java:322)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
  at java.lang.reflect.Method.invoke(Unknown Source)
  at
 
 
 org.apache.webbeans.intercept.InterceptorHandler.invoke(InterceptorHandler.java:322)
  at
 
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:117)
  at
 
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:108)
  at
 
 
 utils.mail.AddAirportShuttleRequest_$$_javassist_53.createOrderForAirportShuttle(AddAirportShuttleRequest_$$_javassist_53.java)
  at
 
 
 utils.mail.EmailRequestBean.processAirportShuttleRequest(EmailRequestBean.java:212)
  at
 
 
 utils.mail.EmailRequestBean.addAirportShuttleRequests(EmailRequestBean.java:152)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
  at java.lang.reflect.Method.invoke(Unknown Source)
  at
 
 
 org.apache.webbeans.intercept.InterceptorHandler.invoke(InterceptorHandler.java:322)
  at
 
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:117)
  at
 
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:108)
  at
 
 
 utils.mail.EmailRequestBean_$$_javassist_52.addAirportShuttleRequests(EmailRequestBean_$$_javassist_52.java)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
  at java.lang.reflect.Method.invoke(Unknown Source)
  at javax.el.BeanELResolver.invokeMethod(BeanELResolver.java:737)
  at javax.el.BeanELResolver.invoke(BeanELResolver.java:467)
  at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:246)
  at de.odysseus.el.tree.impl.ast.AstMethod.eval(AstMethod.java:91)
  at de.odysseus.el.tree.impl.ast.AstMethod.invoke(AstMethod.java:104)
  at de.odysseus.el.tree.impl.ast.AstEval.invoke(AstEval.java:71

Re: Why are Tomcat's threads more costly than background threads?

Very interesting discussion and responses here! Anthony motivates me to
jump on the bandwagon of using JMS/message-driven-beans, and at the same
time, Romain tells me, not much need (for local) in a Java EE 6
application. :)

Either way, i have not ruled out JMS. I have done some strategic coding on
my part to avoid @Schedule or use of timer service...using Date class to
postpone pushing data to google calendar, and only pushing when there is a
new date to update...application-wide. At first, i was pushing data to
google calendar after 'every' update request... sending over 1,000 requests
to google calendar sometimes or daily (adding and deleting events on google
calendar to keep google calendar in sync with the database), but I cut that
back (or decreased the # of requests) with the new code I developed 2+
months ago. just makes for a faster user experience since they requested to
have data updated via ajax on change/selection of this field, and that
field.

Right now, JMS would be similar to a nice science project for me... just to
see if I can do it and the success of it.


On Mon, Dec 17, 2012 at 1:57 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 I used it a lot in javaee 5 (openejb 3) but i'm happy to leave it on the
 road qince javaee 6, no more.

 It works but i dont find it effective when it stays local

Re: Why are Tomcat's threads more costly than background threads?

Almost forgot...PrimeFaces peer/friend of mine informed me that JMS is good
for running two instances of an app, similar to load balancer.

Prior to using TomEE, I really wanted to use PrimeFaces Push (powered by
Atmosphere/websocket), and at that time, I was thinking that I could
possibly run Tomcat or TomEE just to push messages to the clients of my app
running on Glassfish, since Glassfish had issues with PrimeFaces Push
(Atmosphere). I think he said that tomEE and Glassfish could do that, but
they would have to communicate via JMS or the two servlets would have to
serve requests/responses, appropriately, via JMS.

I am probably not stating the above correctly as he said, but that's how I
understood what he told me.

Now that I'm only using tomEE, there is no need to do such a thing. Loving
TomEE!!!



On Mon, Dec 17, 2012 at 2:26 AM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:

 Very interesting discussion and responses here! Anthony motivates me to
 jump on the bandwagon of using JMS/message-driven-beans, and at the same
 time, Romain tells me, not much need (for local) in a Java EE 6
 application. :)

 Either way, i have not ruled out JMS. I have done some strategic coding on
 my part to avoid @Schedule or use of timer service...using Date class to
 postpone pushing data to google calendar, and only pushing when there is a
 new date to update...application-wide. At first, i was pushing data to
 google calendar after 'every' update request... sending over 1,000 requests
 to google calendar sometimes or daily (adding and deleting events on google
 calendar to keep google calendar in sync with the database), but I cut that
 back (or decreased the # of requests) with the new code I developed 2+
 months ago. just makes for a faster user experience since they requested to
 have data updated via ajax on change/selection of this field, and that
 field.

 Right now, JMS would be similar to a nice science project for me... just
 to see if I can do it and the success of it.


 On Mon, Dec 17, 2012 at 1:57 AM, Romain Manni-Bucau rmannibu...@gmail.com
  wrote:

 I used it a lot in javaee 5 (openejb 3) but i'm happy to leave it on the
 road qince javaee 6, no more.

 It works but i dont find it effective when it stays local

Re: Why are Tomcat's threads more costly than background threads?

Polling is too much network traffic in my opinion. Websocket is instant
messaging. No need to add polling code and xhtml here there for different
type of messages coming from server and no need of an ajax request to
server throughout entire session just to get an update from the server.
 On Dec 17, 2012 2:47 AM, Romain Manni-Bucau rmannibu...@gmail.com
wrote:

 Side note: if your need is pushing regularly to the client just having some
 client polling can make it far easier to manage on both sides...
 Le 17 déc. 2012 08:33, Howard W. Smith, Jr. smithh032...@gmail.com a
 écrit :

  Almost forgot...PrimeFaces peer/friend of mine informed me that JMS is
 good
  for running two instances of an app, similar to load balancer.
 
  Prior to using TomEE, I really wanted to use PrimeFaces Push (powered by
  Atmosphere/websocket), and at that time, I was thinking that I could
  possibly run Tomcat or TomEE just to push messages to the clients of my
 app
  running on Glassfish, since Glassfish had issues with PrimeFaces Push
  (Atmosphere). I think he said that tomEE and Glassfish could do that, but
  they would have to communicate via JMS or the two servlets would have to
  serve requests/responses, appropriately, via JMS.
 
  I am probably not stating the above correctly as he said, but that's how
 I
  understood what he told me.
 
  Now that I'm only using tomEE, there is no need to do such a thing.
 Loving
  TomEE!!!
 
 
 
  On Mon, Dec 17, 2012 at 2:26 AM, Howard W. Smith, Jr. 
  smithh032...@gmail.com wrote:
 
   Very interesting discussion and responses here! Anthony motivates me to
   jump on the bandwagon of using JMS/message-driven-beans, and at the
 same
   time, Romain tells me, not much need (for local) in a Java EE 6
   application. :)
  
   Either way, i have not ruled out JMS. I have done some strategic coding
  on
   my part to avoid @Schedule or use of timer service...using Date class
 to
   postpone pushing data to google calendar, and only pushing when there
 is
  a
   new date to update...application-wide. At first, i was pushing data to
   google calendar after 'every' update request... sending over 1,000
  requests
   to google calendar sometimes or daily (adding and deleting events on
  google
   calendar to keep google calendar in sync with the database), but I cut
  that
   back (or decreased the # of requests) with the new code I developed 2+
   months ago. just makes for a faster user experience since they
 requested
  to
   have data updated via ajax on change/selection of this field, and that
   field.
  
   Right now, JMS would be similar to a nice science project for me...
 just
   to see if I can do it and the success of it.
  
  
   On Mon, Dec 17, 2012 at 1:57 AM, Romain Manni-Bucau 
  rmannibu...@gmail.com
wrote:
  
   I used it a lot in javaee 5 (openejb 3) but i'm happy to leave it on
 the
   road qince javaee 6, no more.
  
   It works but i dont find it effective when it stays local

Re: Why are Tomcat's threads more costly than background threads?

2012-12-15 Thread Howard W. Smith, Jr.

David,

just wanted to let you know that I did what you recommended below, and it's
working great (no errors; will continue to monitor server log). I had to
make a few other code changes to this piece of software, and did some
testing as well.

Feel free to see my latest test results... once I have the data from each
email in memory/POJO, then it is updating data at an average of 4 to 6
seconds (2 airport shuttles per email).

https://issues.apache.org/jira/browse/OPENEJB-1968#comment-13532966

Thanks,
Howard

On Fri, Dec 14, 2012 at 3:47 PM, David Blevins david.blev...@gmail.comwrote:

 Now that things are working, I suggest converting your @Schedule bean from
 @Stateless to @Singleton for the reasons mentioned before.  If you someday
 (knock on wood) get totally nailed with a ton of emails/orders, the
 @Singleton with @Lock(WRITE) will prevent any situations where your timers
 start to overlap due to backlog and you accidentally process emails twice
 or more.

Re: tomee would not start with tomee-catalina-1.5.1-20121212.041530-107.jar

2012-12-15 Thread Howard W. Smith, Jr.

Romain informed me that that jar would address a session expire exception
related to http session listener, I think, but I removed the http session
listener from my project since I have CDI managed beans, and I am now using
@predestroy on my user bean. :-)
 On Dec 15, 2012 6:21 AM, Jean-Louis MONTEIRO jeano...@gmail.com wrote:

 And what was the reason of such a replacement?
 Le 15 déc. 2012 06:02, Howard W. Smith, Jr. smithh032...@gmail.com a
 écrit :

  I just replaced catalina.jar
  with tomee-catalina-1.5.1-20121212.041530-107.jar, and TomEE would not
  start; I only saw the following in the stderr log; nothing in catalina
 log.
  Please advise. Thanks.
 
  2012-12-14 23:57:31 Commons Daemon procrun stderr initialized
  Please use CMSClassUnloadingEnabled in place of CMSPermGenSweepingEnabled
  in the future
  ClassLoader$1.run(Unknown Source)
  at java.net.URLClassLoader$1.run(Unknown Source)
  at java.security.AccessController.doPrivileged(Native Method)
  at java.net.URLClassLoader.findClass(Unknown Source)
  at java.lang.ClassLoader.loadClass(Unknown Source)
  at java.lang.ClassLoader.loadClass(Unknown Source)
  at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:236)
  at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:426)

Re: tomee would not start with tomee-catalina-1.5.1-20121212.041530-107.jar

2012-12-15 Thread Howard W. Smith, Jr.

Now I know, thanks.
 On Dec 15, 2012 7:08 AM, Romain Manni-Bucau rmannibu...@gmail.com
wrote:

 Tomee-catalina is the tomcat integration of tomee, catalina is a tomcat
 jar...you cant replace one by another one
 Le 15 déc. 2012 12:21, Jean-Louis MONTEIRO jeano...@gmail.com a écrit
 :

  And what was the reason of such a replacement?
  Le 15 déc. 2012 06:02, Howard W. Smith, Jr. smithh032...@gmail.com a
  écrit :
 
   I just replaced catalina.jar
   with tomee-catalina-1.5.1-20121212.041530-107.jar, and TomEE would not
   start; I only saw the following in the stderr log; nothing in catalina
  log.
   Please advise. Thanks.
  
   2012-12-14 23:57:31 Commons Daemon procrun stderr initialized
   Please use CMSClassUnloadingEnabled in place of
 CMSPermGenSweepingEnabled
   in the future
   ClassLoader$1.run(Unknown Source)
   at java.net.URLClassLoader$1.run(Unknown Source)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.net.URLClassLoader.findClass(Unknown Source)
   at java.lang.ClassLoader.loadClass(Unknown Source)
   at java.lang.ClassLoader.loadClass(Unknown Source)
   at org.apache.catalina.startup.Bootstrap.init(Bootstrap.java:236)
   at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:426)

Re: Why are Tomcat's threads more costly than background threads?

2012-12-14 Thread Howard W. Smith, Jr.

David (and any/all interested),

Please click URL below to see my latest test results (along with code
changes).  It took about 12 seconds to perform the update on the Windows
Server 2003 32bit 4GB RAM.

https://issues.apache.org/jira/browse/OPENEJB-1968#comment-13532480


I know, I know, I need to consider moving away from Apache Derby database
to a 'real database', but I hope to do that, ASAP.

Thanks for all the responses/recommendations/etc...

Howard


On Thu, Dec 13, 2012 at 11:09 PM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:

 David, I corrected that as you stated, and I made sure the code was as you
 recommended, and I've updated the JIRA with test results. Windows Server
 2008 64bit is still fast, Windows SErver 2003 32bit is 'still' slow and
 locking the database.

Re: Why are Tomcat's threads more costly than background threads?

2012-12-14 Thread Howard W. Smith, Jr.

Thanks David.

Before you introduced me to the @Lock(WRITE), I already came up with a
Boolean variable that is updated on @ApplicationScoped bean, every time
@schedule is triggered 'and' whenever a user clicks the commandLink to
check/get emails. The Boolean variable is checked whenever @schedule or
enduser is checking emails...if @schedule or enduser is 'already' checking
emails, then 'return' from the method.

The @Schedule is 'not' responsible for retrieving/downloading the data from
the email server. The enduser is 100% responsible for downloading the data
from the email server...via the commandLink.

The @schedule is only used for providing a notification to endusers...that
airport shuttle requests are available to download.

I will let you know, if I use Singleton and @Lock(WRITE). On the current
database (Apache Derby), the @Lock(WRITE) always results in a 'locked'
exception which tells me that @Lock(WRITE) does not work well with the
Apache Derby database.

It would be nice to know why all you recommended to me...does not work with
Apache Derby; I did read that row-level or table-level locking is (or can
be) enabled/disabled throughout the database. All I know...i have 'no'
issues updating the database when enduser initiates database updates via
managed-bean-to-stateless-ejb approach.

since I've spent too much time on this and since I have something
working-as-designed, I'm going to leave this alone for now and move on to
the next task...which is very similar to this task...another set of emails
to retrieve from the email server, but a different set of data. A lot of my
code can be reused, but still need to write separate software for those
emails. Looking forward to it...i'm loving me some Java!!!

It will be interesting, when i have time/bandwidth to migrate to another
database...as others, here, have suggested to me. :)


On Fri, Dec 14, 2012 at 3:47 PM, David Blevins david.blev...@gmail.comwrote:

 Now that things are working, I suggest converting your @Schedule bean from
 @Stateless to @Singleton for the reasons mentioned before.  If you someday
 (knock on wood) get totally nailed with a ton of emails/orders, the
 @Singleton with @Lock(WRITE) will prevent any situations where your timers
 start to overlap due to backlog and you accidentally process emails twice
 or more.

Re: TomEE: StandardSession expire

2012-12-14 Thread Howard W. Smith, Jr.

Okay, I'm still getting this exception (a lot) in TomEE localhost log and I
still have 1.5.1 release JARs and no added/patched catalina JAR.

Also, I just/finally looked at the exception, carefully, and recognized
that TomEE 1.5.1 is calling my UserHttpSessionListener.sessionDestroy(),
since UserHttpSessionListener implements HttpSessionListener, but guess
what...  I commented '@WebListener' out on that code. Is this according to
J2EE spec or is this TomEE?

Below is the class definition. Since I added @PreDestroy to
pf_UsersController, this UserHttpSessionListener is now obsolete; I'm sure
if I delete this class from my library/app, then I will not get the
exception (in previous email), anymore. Still looking for an answer to my
question in the previous paragraph, above. Thanks.


/*
 * To change this template, choose Tools | Templates
 * and open the template in the editor.
 */
package pf;

import java.util.Date;

import javax.inject.Inject;

import javax.servlet.annotation.WebListener;
import javax.servlet.http.HttpSessionEvent;
import javax.servlet.http.HttpSessionListener;

import jsf.users.pf_UsersController;

/**
 *
 * @author Administrator
 *
 * DOES NOT WORK in CDI-managed-bean web app, so commenting out the
following:
 *
@WebListener
 */
public class UserHttpSessionListener implements HttpSessionListener {

@Inject
private pf_UsersController userBean;

@Override
public void sessionCreated(HttpSessionEvent event) {
// Do here the job.
}

@Override
public void sessionDestroyed(HttpSessionEvent event) {
/*
 * JSF Managed Beans
 *
pf_UsersController userBean = (pf_UsersController)
event.getSession().
  getAttribute(pf_usersController);
 */
if (userBean != null  userBean.getUser() != null) {
String userName = userBean.getUser().getUserName();
System.out.println(UserHttpSessionListener.sessionDestroyed():
 +
   userName +  session destroyed);
userBean.sessionTimeout();
}
}

}





On Tue, Dec 11, 2012 at 12:02 AM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:

 This exception occurs a different times throughout the day on production
 as well as test/development server. Is there anything I can do to prevent
 the exception (and I'm not asking to 'swallow' the exception).  Please
 advise. Thanks.

 Dec 10, 2012 9:03:14 PM org.apache.catalina.session.StandardSession expire
 SEVERE: Session event listener threw exception
 javax.enterprise.context.ContextNotActiveException: WebBeans context with
 scope type annotation @SessionScoped does not exist within current thread
 at
 org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:351)
  at
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:143)
  at
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:114)
  at
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:108)
  at
 jsf.users.pf_UsersController_$$_javassist_2.getUser(pf_UsersController_$$_javassist_2.java)
  at
 pf.UserHttpSessionListener.sessionDestroyed(UserHttpSessionListener.java:40)
 at
 org.apache.catalina.session.StandardSession.expire(StandardSession.java:806)
  at
 org.apache.catalina.session.StandardSession.isValid(StandardSession.java:658)
 at
 org.apache.catalina.session.ManagerBase.processExpires(ManagerBase.java:534)
  at
 org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase.java:519)
 at
 org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1352)
  at
 org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1530)
  at
 org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540)
  at
 org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540)
  at
 org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1519)
  at java.lang.Thread.run(Unknown Source)

Re: TomEE EjbTimerServiceImpl ejbTimeout exception while completing container transaction

the following has the same test results too. i'm changing my implementation
a bit. will share more based on (or after) test results.

On Thu, Dec 13, 2012 at 2:38 AM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:

 Okay, I tried the following,

 @TransactionAttribute(value = TransactionAttributeType.REQUIRES_NEW)

Re: TomEE EjbTimerServiceImpl ejbTimeout exception while completing container transaction

Below is what I'm entering on the JIRA. very very interesting...and
baffling! Just as I did not like the behavior of @Schedule in Glassfish,
i'm not liking the behavior of @Schedule in TomEE.  I have been developing
my own timers without Timer service...just use joda DateTime or
java.util.Date. I may need to do that in this case.


@TransactionAttribute(value = TransactionAttributeType.REQUIRES_NEW)

had same test results...too.

My next attempt/implementation involves the following:

1. Move all the logic of @Stateless EJB @Schedule getEmails() to
@Asynchronous getEmails() on CDI @ApplicationScoped bean

2. Add a new method on CDI @ApplicationScoped bean called
makeAsyncCallToGetEmails(), which will be called by @Stateless EJB
@Schedule getEmails()

3. makeAsyncCallToGetEmails() will invoke @Asynchronous getEmails()


So far, the test results are below. It's interesting/strange that TomEE
(the container) invokes the @Asynchronous getEmails() 'immediately' after
TomEE/container completed 'start'. See log below and look at the time; I
set the @Schedule to be 15 minutes. All the prior tests (without
@Asynchronous), @Schedule getEmails() was invoked every 15
minutes...working as designed. Is this a bug or feature of TomEE to invoke
@Asynchronous on CDI @ApplicationScoped bean immediately after
TomEE/container starts???

Well, the end result is same exception as before with a few more debug
lines. See below.


Dec 13, 2012 3:12:07 AM org.apache.catalina.startup.Catalina start
INFO: Server startup in 38783 ms
Dec 13, 2012 3:16:32 AM org.apache.myfaces.el.unified.ResolverBuilderBase
sortELResolvers
INFO: Chain of EL resolvers for Faces sorted with:
org.apache.myfaces.el.unified.OpenWebBeansELResolverComparator@32735 and
the result order is
[org.apache.myfaces.el.unified.resolver.implicitobject.ImplicitObjectResolver@1032447,
org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver@142b5f0,
org.apache.myfaces.el.FlashELResolver@b6b6c6,
org.apache.myfaces.el.unified.resolver.ManagedBeanResolver@199be0d,
org.apache.myfaces.el.unified.resolver.ResourceResolver@8c7362,
javax.el.ResourceBundleELResolver@eb5873,
org.apache.myfaces.el.unified.resolver.ResourceBundleResolver@fbf8f4,
javax.el.MapELResolver@9587c9, javax.el.ListELResolver@105ba24,
javax.el.ArrayELResolver@ffc33f, javax.el.BeanELResolver@16b7d69,
org.apache.webbeans.el.WebBeansELResolver@1f67d53]
Dec 13, 2012 3:21:35 AM pf.ApplicationScopeBean log
INFO: ApplicationScopeBean.processAirportShuttleRequest(): ADD Airport
Shuttle - Flight # 1 SUCCESSFULLY for 01/06/2013
Dec 13, 2012 3:29:10 AM pf.ApplicationScopeBean log
INFO: ApplicationScopeBean.processAirportShuttleRequest(): ADD Airport
Shuttle - Flight # 2 SUCCESSFULLY for 01/18/2012
Dec 13, 2012 3:29:11 AM pf.ApplicationScopeBean log
INFO: ApplicationScopeBean.makeAsyncCallToGetEmails(): getEmails() returned
javax.ejb.AsyncResult@1baecd3
Dec 13, 2012 3:29:19 AM org.apache.openejb.core.timer.EjbTimerServiceImpl
ejbTimeout
WARNING: Exception occured while completing container transaction
javax.transaction.RollbackException: Unable to commit: transaction marked
for rollback
at
org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:272)
at
org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:252)
at
org.apache.openejb.core.timer.EjbTimerServiceImpl.ejbTimeout(EjbTimerServiceImpl.java:598)
at
org.apache.openejb.core.timer.EjbTimeoutJob.execute(EjbTimeoutJob.java:39)
at org.quartz.core.JobRunShell.run(JobRunShell.java:213)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.Exception: Transaction has timed out
at
org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:266)
... 7 more

Dec 13, 2012 3:29:20 AM pf.ApplicationScopeBean log
INFO: ApplicationScopeBean.makeAsyncCallToGetEmails(): getEmails() returned
javax.ejb.AsyncResult@e72662
Dec 13, 2012 3:30:01 AM pf.ApplicationScopeBean log
INFO: ApplicationScopeBean.makeAsyncCallToGetEmails(): getEmails() returned
javax.ejb.AsyncResult@bafb73





On Thu, Dec 13, 2012 at 3:12 AM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:

 the following has the same test results too. i'm changing my
 implementation a bit. will share more based on (or after) test results.

Re: TomEE EjbTimerServiceImpl ejbTimeout exception while completing container transaction

agreed on all accounts. I may be open to increasing timeout to 30minutes.

i really don't know why this takes so long... I have one page where user
can enter a bunch of stuff, and that page saves more data then this
operation does... and it takes 1 or 2 seconds when user click Save button
on that ADD (data) page.

gotta get to bed. :)


On Thu, Dec 13, 2012 at 4:45 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 great to hear you go further with TomEE ;) (lol)

 well think next step is to identify why you are so slow since i guess
 you last more than 10mn

 you can configure the timeout to be 30mn but think it is a very bad idea ;)

 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau



 2012/12/13 Howard W. Smith, Jr. smithh032...@gmail.com:
  I didn't get that far with glassfish; i think i remember errors on
 startup,
  trying to get the timerservice as resource. i left it alone. this is
 first
  time i really used @schedule.
 
  On Thu, Dec 13, 2012 at 4:11 AM, Romain Manni-Bucau
  rmannibu...@gmail.comwrote:
 
  once again the issue is probably not directly in tomee since we use it
  for quite a long time
 
  you should just try to identify why
 
  a timeout is quite explicit as error, what was the one of glassfish
  for transactions? think it is 10mn in tomee by default
 
  Romain Manni-Bucau
  Twitter: @rmannibucau
  Blog: http://rmannibucau.wordpress.com/
  LinkedIn: http://fr.linkedin.com/in/rmannibucau
  Github: https://github.com/rmannibucau
 
 
 
  2012/12/13 Howard W. Smith, Jr. smithh032...@gmail.com:
   Below is what I'm entering on the JIRA. very very interesting...and
   baffling! Just as I did not like the behavior of @Schedule in
 Glassfish,
   i'm not liking the behavior of @Schedule in TomEE.  I have been
  developing
   my own timers without Timer service...just use joda DateTime or
   java.util.Date. I may need to do that in this case.
  
  
   @TransactionAttribute(value = TransactionAttributeType.REQUIRES_NEW)
  
   had same test results...too.
  
   My next attempt/implementation involves the following:
  
   1. Move all the logic of @Stateless EJB @Schedule getEmails() to
   @Asynchronous getEmails() on CDI @ApplicationScoped bean
  
   2. Add a new method on CDI @ApplicationScoped bean called
   makeAsyncCallToGetEmails(), which will be called by @Stateless EJB
   @Schedule getEmails()
  
   3. makeAsyncCallToGetEmails() will invoke @Asynchronous getEmails()
  
  
   So far, the test results are below. It's interesting/strange that
 TomEE
   (the container) invokes the @Asynchronous getEmails() 'immediately'
 after
   TomEE/container completed 'start'. See log below and look at the
 time; I
   set the @Schedule to be 15 minutes. All the prior tests (without
   @Asynchronous), @Schedule getEmails() was invoked every 15
   minutes...working as designed. Is this a bug or feature of TomEE to
  invoke
   @Asynchronous on CDI @ApplicationScoped bean immediately after
   TomEE/container starts???
  
   Well, the end result is same exception as before with a few more debug
   lines. See below.
  
  
   Dec 13, 2012 3:12:07 AM org.apache.catalina.startup.Catalina start
   INFO: Server startup in 38783 ms
   Dec 13, 2012 3:16:32 AM
 org.apache.myfaces.el.unified.ResolverBuilderBase
   sortELResolvers
   INFO: Chain of EL resolvers for Faces sorted with:
   org.apache.myfaces.el.unified.OpenWebBeansELResolverComparator@32735and
   the result order is
  
 
 [org.apache.myfaces.el.unified.resolver.implicitobject.ImplicitObjectResolver@1032447
  ,
  
 
 org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver@142b5f0
  ,
   org.apache.myfaces.el.FlashELResolver@b6b6c6,
   org.apache.myfaces.el.unified.resolver.ManagedBeanResolver@199be0d,
   org.apache.myfaces.el.unified.resolver.ResourceResolver@8c7362,
   javax.el.ResourceBundleELResolver@eb5873,
   org.apache.myfaces.el.unified.resolver.ResourceBundleResolver@fbf8f4,
   javax.el.MapELResolver@9587c9, javax.el.ListELResolver@105ba24,
   javax.el.ArrayELResolver@ffc33f, javax.el.BeanELResolver@16b7d69,
   org.apache.webbeans.el.WebBeansELResolver@1f67d53]
   Dec 13, 2012 3:21:35 AM pf.ApplicationScopeBean log
   INFO: ApplicationScopeBean.processAirportShuttleRequest(): ADD Airport
   Shuttle - Flight # 1 SUCCESSFULLY for 01/06/2013
   Dec 13, 2012 3:29:10 AM pf.ApplicationScopeBean log
   INFO: ApplicationScopeBean.processAirportShuttleRequest(): ADD Airport
   Shuttle - Flight # 2 SUCCESSFULLY for 01/18/2012
   Dec 13, 2012 3:29:11 AM pf.ApplicationScopeBean log
   INFO: ApplicationScopeBean.makeAsyncCallToGetEmails(): getEmails()
  returned
   javax.ejb.AsyncResult@1baecd3
   Dec 13, 2012 3:29:19 AM
 org.apache.openejb.core.timer.EjbTimerServiceImpl
   ejbTimeout
   WARNING: Exception occured while completing container transaction
   javax.transaction.RollbackException: Unable to commit: transaction

Re: TomEE EjbTimerServiceImpl ejbTimeout exception while completing container transaction

I know what I must do. Stateless ejb to stateless ejb is not how I normally
do things. I usually do updates by injecting the CDI managed beans and that
bean does update. Managed bean call other managed bean, and then that
managed bean updates database via stateless ejb.
On Dec 13, 2012 5:01 AM, Howard W. Smith, Jr. smithh032...@gmail.com
wrote:

 agreed on all accounts. I may be open to increasing timeout to 30minutes.

 i really don't know why this takes so long... I have one page where user
 can enter a bunch of stuff, and that page saves more data then this
 operation does... and it takes 1 or 2 seconds when user click Save button
 on that ADD (data) page.

 gotta get to bed. :)


 On Thu, Dec 13, 2012 at 4:45 AM, Romain Manni-Bucau rmannibu...@gmail.com
  wrote:

 great to hear you go further with TomEE ;) (lol)

 well think next step is to identify why you are so slow since i guess
 you last more than 10mn

 you can configure the timeout to be 30mn but think it is a very bad idea
 ;)

 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau



 2012/12/13 Howard W. Smith, Jr. smithh032...@gmail.com:
  I didn't get that far with glassfish; i think i remember errors on
 startup,
  trying to get the timerservice as resource. i left it alone. this is
 first
  time i really used @schedule.
 
  On Thu, Dec 13, 2012 at 4:11 AM, Romain Manni-Bucau
  rmannibu...@gmail.comwrote:
 
  once again the issue is probably not directly in tomee since we use it
  for quite a long time
 
  you should just try to identify why
 
  a timeout is quite explicit as error, what was the one of glassfish
  for transactions? think it is 10mn in tomee by default
 
  Romain Manni-Bucau
  Twitter: @rmannibucau
  Blog: http://rmannibucau.wordpress.com/
  LinkedIn: http://fr.linkedin.com/in/rmannibucau
  Github: https://github.com/rmannibucau
 
 
 
  2012/12/13 Howard W. Smith, Jr. smithh032...@gmail.com:
   Below is what I'm entering on the JIRA. very very interesting...and
   baffling! Just as I did not like the behavior of @Schedule in
 Glassfish,
   i'm not liking the behavior of @Schedule in TomEE.  I have been
  developing
   my own timers without Timer service...just use joda DateTime or
   java.util.Date. I may need to do that in this case.
  
  
   @TransactionAttribute(value = TransactionAttributeType.REQUIRES_NEW)
  
   had same test results...too.
  
   My next attempt/implementation involves the following:
  
   1. Move all the logic of @Stateless EJB @Schedule getEmails() to
   @Asynchronous getEmails() on CDI @ApplicationScoped bean
  
   2. Add a new method on CDI @ApplicationScoped bean called
   makeAsyncCallToGetEmails(), which will be called by @Stateless EJB
   @Schedule getEmails()
  
   3. makeAsyncCallToGetEmails() will invoke @Asynchronous getEmails()
  
  
   So far, the test results are below. It's interesting/strange that
 TomEE
   (the container) invokes the @Asynchronous getEmails() 'immediately'
 after
   TomEE/container completed 'start'. See log below and look at the
 time; I
   set the @Schedule to be 15 minutes. All the prior tests (without
   @Asynchronous), @Schedule getEmails() was invoked every 15
   minutes...working as designed. Is this a bug or feature of TomEE to
  invoke
   @Asynchronous on CDI @ApplicationScoped bean immediately after
   TomEE/container starts???
  
   Well, the end result is same exception as before with a few more
 debug
   lines. See below.
  
  
   Dec 13, 2012 3:12:07 AM org.apache.catalina.startup.Catalina start
   INFO: Server startup in 38783 ms
   Dec 13, 2012 3:16:32 AM
 org.apache.myfaces.el.unified.ResolverBuilderBase
   sortELResolvers
   INFO: Chain of EL resolvers for Faces sorted with:
   org.apache.myfaces.el.unified.OpenWebBeansELResolverComparator@32735and
   the result order is
  
 
 [org.apache.myfaces.el.unified.resolver.implicitobject.ImplicitObjectResolver@1032447
  ,
  
 
 org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver@142b5f0
  ,
   org.apache.myfaces.el.FlashELResolver@b6b6c6,
   org.apache.myfaces.el.unified.resolver.ManagedBeanResolver@199be0d,
   org.apache.myfaces.el.unified.resolver.ResourceResolver@8c7362,
   javax.el.ResourceBundleELResolver@eb5873,
   org.apache.myfaces.el.unified.resolver.ResourceBundleResolver@fbf8f4
 ,
   javax.el.MapELResolver@9587c9, javax.el.ListELResolver@105ba24,
   javax.el.ArrayELResolver@ffc33f, javax.el.BeanELResolver@16b7d69,
   org.apache.webbeans.el.WebBeansELResolver@1f67d53]
   Dec 13, 2012 3:21:35 AM pf.ApplicationScopeBean log
   INFO: ApplicationScopeBean.processAirportShuttleRequest(): ADD
 Airport
   Shuttle - Flight # 1 SUCCESSFULLY for 01/06/2013
   Dec 13, 2012 3:29:10 AM pf.ApplicationScopeBean log
   INFO: ApplicationScopeBean.processAirportShuttleRequest(): ADD
 Airport
   Shuttle - Flight # 2 SUCCESSFULLY for 01/18/2012
   Dec 13, 2012 3:29:11 AM

Re: DB access is very slow

I had research my emails for this...

Dual Core Xeon Processor 5050 2x2MB Cache, 3.00GHz, 667MHz FSB, PE 2900
Dual Core Xeon 2nd Processor 5050, 2x2MB Cache, 3.00GHz 667MHz FSB, PE 2900
2GB 533MHz (4x512MB), Single Ranked DIMMs (replaced by 4GB RAM)
80GB, SATA, 3.5-inch 7.2K RPM Hard Drive
1TB, SATA, 3.5-inch 7.2K RPM Hard Drive (installed later; database and web
app software is here)
SAS 5/i Integrated, No RAID
Windows Server 2003 R2 Standard Edition, Includes 5 CALs
Embedded Broadcom NetXtreme II5708 GigabitEthernet NIC
PowerVault 100T, DAT72 Tape Backup, 36/72GB, w/Controller Internal for
PowerEdge 2900



On Thu, Dec 13, 2012 at 1:26 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 Do you have the machine usage (cpu+mem+io)?

 Glassfish is not faster, eclipselink is not faster in general (depend what
 you do). Maybe you need to configure openjpa sequence to set bigger
 allocation size (openjpa.Sequence=class-tacle(Increment=1000) IIRC)

Re: DB access is very slow

same machine

On Thu, Dec 13, 2012 at 8:05 AM, José Luis Cetina maxtorz...@gmail.comwrote:

 Where is your database, localhost?

Re: DB access is very slow

haha okay... it is  primarily a file server, also has some other software
running on it, another database engine (Microsoft SQL, I think, but that's
not my software), that database engine is accessed by client software on
laptops connected to the LAN as well as remote connection (windows remote
desktop connection)...

outside of that...i really don't understand why @Stateless EJB referencing
other @Stateless EJB to perform database operations (insert into multiple
tables...'long' transaction)...does 'not' perform well at all, introduces
database locks when users are logged in the web app

CDI/JSF 'managed bean' referencing @Stateless EJB to perform database
operations has been the 'norm' in my web app, and this never introduce
database locks, deadlock situation, or people seeing exceptions with
eclipselink SQL in their Facesmessage after a long long wait... :)

i'm going with the managed bean -- @Stateless EJB approach, just need to
change around my code to do so.

will keep you posted.


On Thu, Dec 13, 2012 at 9:31 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 that's not the usage of the machine :p

 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau



 2012/12/13 Howard W. Smith, Jr. smithh032...@gmail.com:
  same machine
 
  On Thu, Dec 13, 2012 at 8:05 AM, José Luis Cetina maxtorz...@gmail.com
 wrote:
 
  Where is your database, localhost?

Re: DB access is very slow

only queries i do is to small lookup tables... address/phone/email address
type to get the database entity. at most, those tables have 3 to 5 rows of
really really small data... Business, home, mobile (phone)...

file database? 'Apache' Derby

locks on windows... when i first developed this (few days ago), it was show
Apache Derby 'lock' exceptions... hahaha


On Thu, Dec 13, 2012 at 9:43 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 maybe you just do too much queries and the schedul is called too
 often...and you are on a file database right? so it locks on
 windows...

 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau



 2012/12/13 Howard W. Smith, Jr. smithh032...@gmail.com:
  haha okay... it is  primarily a file server, also has some other software
  running on it, another database engine (Microsoft SQL, I think, but
 that's
  not my software), that database engine is accessed by client software on
  laptops connected to the LAN as well as remote connection (windows remote
  desktop connection)...
 
  outside of that...i really don't understand why @Stateless EJB
 referencing
  other @Stateless EJB to perform database operations (insert into multiple
  tables...'long' transaction)...does 'not' perform well at all, introduces
  database locks when users are logged in the web app
 
  CDI/JSF 'managed bean' referencing @Stateless EJB to perform database
  operations has been the 'norm' in my web app, and this never introduce
  database locks, deadlock situation, or people seeing exceptions with
  eclipselink SQL in their Facesmessage after a long long wait... :)
 
  i'm going with the managed bean -- @Stateless EJB approach, just need to
  change around my code to do so.
 
  will keep you posted.
 
 
  On Thu, Dec 13, 2012 at 9:31 AM, Romain Manni-Bucau
  rmannibu...@gmail.comwrote:
 
  that's not the usage of the machine :p
 
  Romain Manni-Bucau
  Twitter: @rmannibucau
  Blog: http://rmannibucau.wordpress.com/
  LinkedIn: http://fr.linkedin.com/in/rmannibucau
  Github: https://github.com/rmannibucau
 
 
 
  2012/12/13 Howard W. Smith, Jr. smithh032...@gmail.com:
   same machine
  
   On Thu, Dec 13, 2012 at 8:05 AM, José Luis Cetina 
 maxtorz...@gmail.com
  wrote:
  
   Where is your database, localhost?

Re: DB access is very slow

Neale,

Yes, real server that I maintain, myself, definitely 4GB RAM and Windows
Server 2003 = 32bit. :)

Howard

On Thu, Dec 13, 2012 at 10:07 AM, Neale ne...@metawerx.net wrote:

 Hi Howard,

 Is this a real server (ie: real hardware), or a VPS that says it has 4gb
 RAM, 32bit?

 Neale

 - Original Message - From: Howard W. Smith, Jr. 
 smithh032...@gmail.com
 To: users@openejb.apache.org
 Sent: Friday, December 14, 2012 1:49 AM
 Subject: Re: DB access is very slow



 only queries i do is to small lookup tables... address/phone/email address
 type to get the database entity. at most, those tables have 3 to 5 rows of
 really really small data... Business, home, mobile (phone)...

 file database? 'Apache' Derby

 locks on windows... when i first developed this (few days ago), it was show
 Apache Derby 'lock' exceptions... hahaha


 On Thu, Dec 13, 2012 at 9:43 AM, Romain Manni-Bucau
 rmannibu...@gmail.comwrote:

  maybe you just do too much queries and the schedul is called too
 often...and you are on a file database right? so it locks on
 windows...

 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.**com/http://rmannibucau.wordpress.com/
 LinkedIn: 
 http://fr.linkedin.com/in/**rmannibucauhttp://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau



 2012/12/13 Howard W. Smith, Jr. smithh032...@gmail.com:
  haha okay... it is  primarily a file server, also has some other 
 software
  running on it, another database engine (Microsoft SQL, I think, but
 that's
  not my software), that database engine is accessed by client software on
  laptops connected to the LAN as well as remote connection (windows 
 remote
  desktop connection)...
 
  outside of that...i really don't understand why @Stateless EJB
 referencing
  other @Stateless EJB to perform database operations (insert into 
 multiple
  tables...'long' transaction)...does 'not' perform well at all, 
 introduces
  database locks when users are logged in the web app
 
  CDI/JSF 'managed bean' referencing @Stateless EJB to perform database
  operations has been the 'norm' in my web app, and this never introduce
  database locks, deadlock situation, or people seeing exceptions with
  eclipselink SQL in their Facesmessage after a long long wait... :)
 
  i'm going with the managed bean -- @Stateless EJB approach, just need
  to
  change around my code to do so.
 
  will keep you posted.
 
 
  On Thu, Dec 13, 2012 at 9:31 AM, Romain Manni-Bucau
  rmannibu...@gmail.comwrote:
 
  that's not the usage of the machine :p
 
  Romain Manni-Bucau
  Twitter: @rmannibucau
  Blog: 
  http://rmannibucau.wordpress.**com/http://rmannibucau.wordpress.com/
  LinkedIn: 
  http://fr.linkedin.com/in/**rmannibucauhttp://fr.linkedin.com/in/rmannibucau
  Github: https://github.com/rmannibucau
 
 
 
  2012/12/13 Howard W. Smith, Jr. smithh032...@gmail.com:
   same machine
  
   On Thu, Dec 13, 2012 at 8:05 AM, Jos￩ Luis Cetina 

 maxtorz...@gmail.com
  wrote:
  
   Where is your database, localhost?

Re: DB access is very slow

hahaha, it is funny. :)

i will definitely consider another database, thanks.

On Thu, Dec 13, 2012 at 12:08 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 funny what you call fast sounds slow for me :p


 that's said maybe try antoher database (mysql?)

Re: DB access is very slow

Neale,

Thanks for the responses and suggestions; much appreciated.

I will definitely consider another database. I need to take some time and
dump all of the 'real' data (and the schema), and make sure the SQL and
schema will work well with a 'real' database. For the most part, it is all
SQL-92, except for Derby SQL for the identity fields for primary key
columns on 99% of the tables in the database.

Please feel free to send me a URL to a blog or two for migrating from derby
to one of the 'real' databases. Also, send me a URL to recommended 'real'
databases. MySQL and HyperSQL DB is within my radar right now.

Thanks,
Howard


On Thu, Dec 13, 2012 at 12:50 PM, Neale ne...@metawerx.net wrote:

 Hi Howard,

 Derby is an in-memory java-based DB, so with a 100mb database it performs
 great.

 Once you start putting real data into it, it fails horribly.  It's
 designed for testing, and never for production (read the docs).

 Please never use it as a production database.  We had a customer here
 using it, and after their database grew to 2gb in size it started consuming
 100% CPU on multiple CPUs and displaying huge disk I/O and GC.  They
 converted to MySQL and their usage has dropped to less than 1% of what
 derby was using.

 But it's a great DB for testing small apps, and with very small apps it
 may even perform faster than a real DB ;-)

 Anyway, with your specific problem, for now I would recommend separating
 the database and JPA so you can measure them both separately.

 It's always easier to solve a problem by breaking it into smaller pieces.

 Best Regards,
 Neale Rudd
 Metawerx Pty Ltd
 www.metawerx.net

Re: DB access is very slow

That's the benchmark website that I've been referring to, and that is what
I've been using to justify apache derby. I don't know how reliable this
website is though. :)

On Thu, Dec 13, 2012 at 1:13 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:


 yep, more or less same note can apply to windows i guess :p

 that's said, i'm not sure of the data but here some figures:
 http://www.jpab.org/EclipseLink/Derby/server/OpenJPA/Derby/server.html

 don't know why OpenJPA is so slow

 @Mark: any idea?

 FYI the same with MySQL:
 http://www.jpab.org/EclipseLink/MySQL/server/OpenJPA/MySQL/server.html

Re: DB access is very slow

Great, thanks Romain. Is MySQL still Open Source? I thought they are under
Oracle umbrella now...and I would assume there is a license or fee
involved. right?

On Thu, Dec 13, 2012 at 1:20 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 MySQL, don't even try hsqldb if your app has users

 then http://dbcopyplugin.sourceforge.net/ should help ;)

Re: DB access is very slow

okay, thanks!

On Thu, Dec 13, 2012 at 1:26 PM, José Luis Cetina maxtorz...@gmail.comwrote:

 I recommend to you Mysql too.  I always used with jpa openjpa or
 eclipselink for now without problems.

Re: DB access is very slow

Agreed about Romain, he is very amazing. Noted about HyperSQL, will avoid
that, and understood about 17mb = playing. This is a new app that I've
developed and it's being used every day for 'business', so definitely not
playing, but I do want to move to prime-time and a faster database, so I
will do that, ASAP. Thanks Neale.

TomEE committers already admit that TomEE is not 'perfect'...yet, so I
would assume these discussions are welcome. Honestly, I do my best to make
sure I am on topic. I'm sure TomEE and OpenEJB is responsible for the
@Stateless EJB transaction, triggered by @Schedule, and why is TomEE
performing well with Derby when user click button, and managed beans call
@Stateless EJB (DAO) to perform database operations... but why is TomEE not
allowing my @Stateless EJB with @Schedule method() to perform well...with a
large transaction.

I have heard that geronimo has many many issues and does not have a good
name/reputation, but regardless of the negative chatter I've seen on
stackoverflow about geronimo, I still continue to use TomEE and I
communicate my issues here on the list.



On Thu, Dec 13, 2012 at 1:39 PM, Neale ne...@metawerx.net wrote:

 HyperSQL is another toy.

 The specs below are great, Derby looks good in some cases, bad in others.
 But once again this is a very small test database.

 You might get 10% performance increase moving your database from derby to
 mysql, or you might get a 10% performance loss.  If you plan to use it
 commercially, use a real database because you will avoid all the issues
 when the database grows.  All our (non-student) databases here are
 300mb-12gb. That is a very big difference to 17mb, but it depends on what
 data they store and how long they keep it.  17mb is just playing.  So 10%
 performance difference up or down is not much fun to look at.

 Anyway - I don't think this is relevant to the TomEE list, and all the
 users/developers receiving these emails 10-20 times per day are probably
 not interested at all.  It's very important to keep the discussion relevant
 so that people don't leave the TomEE list.   The list gains more members
 from people seeing relevant information and staying subscribed, so we
 shouldn't really discuss this here as it's off-topic.

 You are saying your real problem is JPA, so please try on another
 database, and cut the problem into smaller pieces.  Then you will quickly
 find out if it's a Derby issue, a JPA issue, or a TomEE issue.

 If TomEE is performing badly compared to Tomcat or JPA on a command-line
 JVM, then I'm sure the TomEE devs will jump on the issue and fix it as soon
 as possible.  Romain is quite amazing, if he sees a problem with TomEE, he
 leaps on it!   So let's try to limit the number of emails to be real TomEE
 issues so we don't waste his time ;-)

 Best Regards,
 Neale

Re: DB access is very slow

Smiling...forgot to mention... the database would have been much larger (if
I kept all the 'historic' / obsolete data from 1998, but decided to keep
only 3 years worth of data, and archive the rest in the old dBase IV
database files) )... the first version of my app, dBase IV app, created in
1994/1995, and recently migrated from dBAse IV to Java Server Faces web
application, and the endusers (my family) are loving the new web
application, the scalability, the accessibility, the HTML5 web application
features (can be used on mobile devices... iPad, Android, phones, tablets,
etc...) and yes, the speed too. This is the first time I actually had a
speed/performance issue, and I'm glad TomEE/openejb list is trying to help
rectify the issue.

Would I have this performance issue if I stuck it out with Glassfish? Good
question and that answer remains to be seen. I've decided to stick with
TomEE and not really use Glassfish as the 'reference implementation'. Going
forward, I'll use TomEE as the reference implementation. :)



On Thu, Dec 13, 2012 at 1:50 PM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:

 Agreed about Romain, he is very amazing. Noted about HyperSQL, will avoid
 that, and understood about 17mb = playing. This is a new app that I've
 developed and it's being used every day for 'business', so definitely not
 playing, but I do want to move to prime-time and a faster database, so I
 will do that, ASAP. Thanks Neale.

 TomEE committers already admit that TomEE is not 'perfect'...yet, so I
 would assume these discussions are welcome. Honestly, I do my best to make
 sure I am on topic. I'm sure TomEE and OpenEJB is responsible for the
 @Stateless EJB transaction, triggered by @Schedule, and why is TomEE
 performing well with Derby when user click button, and managed beans call
 @Stateless EJB (DAO) to perform database operations... but why is TomEE not
 allowing my @Stateless EJB with @Schedule method() to perform well...with a
 large transaction.

 I have heard that geronimo has many many issues and does not have a good
 name/reputation, but regardless of the negative chatter I've seen on
 stackoverflow about geronimo, I still continue to use TomEE and I
 communicate my issues here on the list.



 On Thu, Dec 13, 2012 at 1:39 PM, Neale ne...@metawerx.net wrote:

 HyperSQL is another toy.

 The specs below are great, Derby looks good in some cases, bad in others.
 But once again this is a very small test database.

 You might get 10% performance increase moving your database from derby to
 mysql, or you might get a 10% performance loss.  If you plan to use it
 commercially, use a real database because you will avoid all the issues
 when the database grows.  All our (non-student) databases here are
 300mb-12gb. That is a very big difference to 17mb, but it depends on what
 data they store and how long they keep it.  17mb is just playing.  So 10%
 performance difference up or down is not much fun to look at.

 Anyway - I don't think this is relevant to the TomEE list, and all the
 users/developers receiving these emails 10-20 times per day are probably
 not interested at all.  It's very important to keep the discussion relevant
 so that people don't leave the TomEE list.   The list gains more members
 from people seeing relevant information and staying subscribed, so we
 shouldn't really discuss this here as it's off-topic.

 You are saying your real problem is JPA, so please try on another
 database, and cut the problem into smaller pieces.  Then you will quickly
 find out if it's a Derby issue, a JPA issue, or a TomEE issue.

 If TomEE is performing badly compared to Tomcat or JPA on a command-line
 JVM, then I'm sure the TomEE devs will jump on the issue and fix it as soon
 as possible.  Romain is quite amazing, if he sees a problem with TomEE, he
 leaps on it!   So let's try to limit the number of emails to be real TomEE
 issues so we don't waste his time ;-)

 Best Regards,
 Neale

Re: DB access is very slow

Thanks Will!

On Thu, Dec 13, 2012 at 1:41 PM, Will Hoover java.whoo...@gmail.com wrote:

 If you want speed/performance/flexibility/scalability I would recommend H2
 Database:

 http://www.h2database.com

 There's a really handy comparison matrix (Derby/HSQLDB/MySQL/PostgreSQL):

 http://www.h2database.com/html/features.html#comparison

 The nice thing about H2 Database is it can potentially simplify migration
 by
 using the available compatibility modes
 (DB2/Derby/HSQLDB/MSSQL/MySQL/Oracle/PostgreSQL):

 http://www.h2database.com/html/features.html#compatibility

Re: DB access is very slow

Thank you very much Neale for all your responses. I have been open to
searching around for a good java web host, but just didn't find it
necessary...yet. At some point, I may be interested in your TomEE hosting
service; when the project reaches a larger scope of endusers. Right now, I
think we are doing okay with the hardware in place (and planning to have in
place).

I'll do my best to take any/all of your suggestions...especially about high
volume. Romain is funny...he seems to welcome any/all discussion related to
'using TomEE'. :)


On Thu, Dec 13, 2012 at 2:04 PM, Neale ne...@metawerx.net wrote:

 Hi Howard,

 Your discussions are very interesting - I haven't unsubscribed from the
 TomEE list yet even though there is such high volume.  Lately I actually
 quite enjoy following your progress.  There are a lot of emails - but just
 don't get too off-topic ;-)  Try a few things on your own, then bring your
 findings to the list.  Some questions are a bit off-topic so they're better
 being discussed on other lists.

 It's really exciting seeing you using TomEE for the first time and running
 into the initial problems.  Those problems are very interesting.  When we
 get to discussing Derby vs Hyper vs MySQL however, it's better to do some
 independant research and come back to the list afterwards.  (IMHO)

 Anyway - I'd love to hear more about how your project turns out, and if
 you want some free hosting on our new TomEE cluster, drop me a private
 email and I'd be happy to give you some free space.  Any experience we have
 with commerical TomEE customers is a great experience for us that we can
 blog about or share with the TomEE devs.

 Best Regards,
 Neale



 - Original Message - From: Howard W. Smith, Jr. 
 smithh032...@gmail.com
 To: users@openejb.apache.org
 Sent: Friday, December 14, 2012 5:50 AM

 Subject: Re: DB access is very slow


  Agreed about Romain, he is very amazing. Noted about HyperSQL, will avoid
 that, and understood about 17mb = playing. This is a new app that I've
 developed and it's being used every day for 'business', so definitely not
 playing, but I do want to move to prime-time and a faster database, so I
 will do that, ASAP. Thanks Neale.

 TomEE committers already admit that TomEE is not 'perfect'...yet, so I
 would assume these discussions are welcome. Honestly, I do my best to make
 sure I am on topic. I'm sure TomEE and OpenEJB is responsible for the
 @Stateless EJB transaction, triggered by @Schedule, and why is TomEE
 performing well with Derby when user click button, and managed beans call
 @Stateless EJB (DAO) to perform database operations... but why is TomEE
 not
 allowing my @Stateless EJB with @Schedule method() to perform well...with
 a
 large transaction.

 I have heard that geronimo has many many issues and does not have a good
 name/reputation, but regardless of the negative chatter I've seen on
 stackoverflow about geronimo, I still continue to use TomEE and I
 communicate my issues here on the list.



 On Thu, Dec 13, 2012 at 1:39 PM, Neale ne...@metawerx.net wrote:

  HyperSQL is another toy.

 The specs below are great, Derby looks good in some cases, bad in others.
 But once again this is a very small test database.

 You might get 10% performance increase moving your database from derby to
 mysql, or you might get a 10% performance loss.  If you plan to use it
 commercially, use a real database because you will avoid all the issues
 when the database grows.  All our (non-student) databases here are
 300mb-12gb. That is a very big difference to 17mb, but it depends on what
 data they store and how long they keep it.  17mb is just playing.  So
 10%
 performance difference up or down is not much fun to look at.

 Anyway - I don't think this is relevant to the TomEE list, and all the
 users/developers receiving these emails 10-20 times per day are probably
 not interested at all.  It's very important to keep the discussion
 relevant
 so that people don't leave the TomEE list.   The list gains more members
 from people seeing relevant information and staying subscribed, so we
 shouldn't really discuss this here as it's off-topic.

 You are saying your real problem is JPA, so please try on another
 database, and cut the problem into smaller pieces.  Then you will quickly
 find out if it's a Derby issue, a JPA issue, or a TomEE issue.

 If TomEE is performing badly compared to Tomcat or JPA on a command-line
 JVM, then I'm sure the TomEE devs will jump on the issue and fix it as
 soon
 as possible.  Romain is quite amazing, if he sees a problem with TomEE,
 he
 leaps on it!   So let's try to limit the number of emails to be real
 TomEE
 issues so we don't waste his time ;-)

 Best Regards,
 Neale

Re: DB access is very slow

Honestly, my preference would be to use @Schedule; I don't want to bug the
users and ask/make/require them to click a button to download this data
from email server. TomEE examples has @Schedule on a Singleton bean (I
think that's what I remember, when I saw it). I saw the same in a (BalusC)
stackoverflow answer. To this day, I have never used Singleton bean. I
assumed that since I have a CDI @ApplicationScoped bean, then there should
be no 'need' to use Singleton bean. Singleton and ApplicationScoped are
both application wide, but now via CDI, it seems as though any/everything
is application-wide, available within any 'context'.

I can accept the notion that my design/implementation is wrong. I've
already learned how to 'improve' my app, specifically for TomEE as the
container, where the app ran perfectly/flawlessly/reliably in Glassfish
(and I'm not alone for saying that).

I'm rewriting code right now, trying to make sure the transaction(s) are as
short as possible. Originally, the code was written similar to a batch
process (kinda like the java application I wrote... to migrate data from
dBase IV to the newer/bigger JavaDB... I went from 6-table dbase IV
database to 88+ table JavaDB).

As far as the code sample... David Blevins shared that in another thread. I
may have to dig that up.


On Thu, Dec 13, 2012 at 2:16 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 Well Howard think you should try to share with us some sample (not the
 full app please)

 i used a lot Geronimo transaction manager and i used ( a bit less)
 @Schedule and it worked fine

 i could understand OpenJPA begin slower on derby but geronimo not
 working is a different topic

 Side note: maybe your design is wrong, you manage a history in a
 @Schedule? not sure that's the best you can do

Re: DB access is very slow

Interesting what you mentioned about JavaEE7, I remember you advising me to
use tomee.xml and even 'questioned' me... why are you not using tomee.xml
instead of context.xml... remember that?  :)

Well, I'm definitely using JTA, and if I understand you correctly, I think
you are recommending to remove non-jta from my persistence.xml as well as
tomee.xml. Right?



On Thu, Dec 13, 2012 at 2:37 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 well your @Schedule == polling no server, it sounds weird by design

 @Neale: the default datasource will be a feature of JavaEE 7.
 Context.xml stuff should be better on 1.5.1 but we clearly use
 tomee.xml by default (and not context.xml) because of jta management
 at least

 that's said the issues are often easier, often the non jt datasource
 is not defined or something like that

Re: DB access is very slow

Sorry, don't understand what you're trying to say here.

@Schedule is used to poll or check an email server for 'specific' emails,
and the emails of interest has JSON embedded, and that JSON are populated
into POJOs via Gson, and then the fun begins... saving that little bit of
data to multiple tables... so endusers don't have to perform 'data entry'
and enter that data 'manually'.

1. The design and implemenation... works as designed

2. the @Stateless EJB with @Schedule getEmails().. works as designed

3. @Stateless EJB (DAO) updating the database.. works as designed but takes
t long.

You all say it is because of the database, but I actually disagree it is
the database, because user click button, CDI-managed-bean updating database
via @Stateless EJB (DAO) is much much faster than #3 listed above.


On Thu, Dec 13, 2012 at 2:37 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 well your @Schedule == polling no server, it sounds weird by design

Re: Simple Netbeans CDI Web Application Not Working

Kay,

Welcome to TomEE, and glad to see someone that is interested in doing what
I did at least one month ago.

Please note/do the following:

1. Download TomEE Plus 1.5.1 (SNAPSHOT) instead of 1.5.0; 1.5.0 did not
work at all for me as my environment is Windows Server 2003  2008; 1.5.1
resolves a file/directory/path issue in TomEE.

2. tomEE 1.5.1 comes bundled with MyFaces 2.1.10 (few weeks ago, it was
bundled with MyFaces 2.1.9), and I never had the following 'reference' in
my web.xml; I think I heard/read that you don't need the following i/fsince
you are using servlet 3.0 in web.xml

listener
listener-classorg.apache.**myfaces.webapp.**StartupServletContextListener
**/listener-class
/listener

3. Copy any/all dependencies to your tomee/lib folder; whenever I install a
new SNAPSHOT version of TomEE 1.5.1, I copy the following to tomee /lib

asm-3.3.1.jar (added that when I was evaluating batoo jpa)
derby.jar
eclipselink.jar
el-api-2.2
el-impl-2.2
javax.mail
joda-time-2.0 (to replace joda-time-1.6.2 which already exists in tomee/lib)
juel-2.2.5 (since I'm using JUEL with MyFaces for faster/better EL
performance)

4. take a look at tomee/conf/tomee.xml; at the bottom of that file, you
will see JDBC resources defined there; put your JDBC resources there

5. your persistence.xml, make sure you set your persistence provider, or
TomEE will default it to OpenJPA; i use eclipselink (since Glassfish3.1.2.2
used eclipselink, by default, and my app performs really well with
eclipselink)

6. also, see tomee/conf/tomcat-users.xml; read all the lines below
(copy/pasted from my file), especially the last line...for Netbeans. :)


!-- Activate those lines to get access to TomEE GUI --
!-- *** DO NOT ENABLE THESE!!! SOMEONE TRIED TO HACK INTO MY SERVER!!! ***
  role rolename=tomee-admin /
  user username=tomee password=tomee roles=tomee-admin,manager-gui /
--
!-- *** DO NOT ENABLE THESE!!! SOMEONE TRIED TO HACK INTO MY SERVER!!! ***

Nov 27, 2012 5:48:08 AM org.apache.catalina.realm.LockOutRealm authenticate
WARNING: An attempt was made to authenticate the locked user tomcat
Nov 27, 2012 5:48:08 AM org.apache.catalina.realm.LockOutRealm authenticate
WARNING: An attempt was made to authenticate the locked user tomcat
Nov 27, 2012 5:48:09 AM org.apache.catalina.realm.LockOutRealm authenticate
WARNING: An attempt was made to authenticate the locked user both
Nov 27, 2012 5:48:09 AM org.apache.catalina.realm.LockOutRealm authenticate
WARNING: An attempt was made to authenticate the locked user both
Nov 27, 2012 5:48:09 AM org.apache.catalina.realm.LockOutRealm authenticate
WARNING: An attempt was made to authenticate the locked user both

localhost_access_log.txt
88.191.100.2 - - [27/Nov/2012:05:47:58 -0500] HEAD /manager/html HTTP/1.0
401 -
...
88.191.100.2 - - [27/Nov/2012:05:48:09 -0500] HEAD /manager/html HTTP/1.0
401 -
88.191.100.2 - - [27/Nov/2012:05:48:09 -0500] HEAD /manager/html HTTP/1.0
401 -
88.191.100.2 - - [27/Nov/2012:05:48:09 -0500] HEAD /manager/html HTTP/1.0
401 -

--
  user password=YourPasswordHereSameAsNetBeans
roles=manager-script,admin username=YourUserNameSameAsNetBeans/
/tomcat-users


Hope this helps,
Howard



On Thu, Dec 13, 2012 at 3:12 PM, Kay Wrobel kwro...@hawkusa.com wrote:

 Hi everybody.

 I am new to TomEE and am having problems with the very basics of getting a
 simple CDI Application to work from Netbeans 7.2. I have added TomEE Plus
 1.5.0 as a server via the Tools-Servers-Add Server... steps. The problem
 I have is as follows:

 I create a simple Web Application with Context and Dependency Injection
 enabled and server-supplied JSF 2.1 implementation activated. I proceed to
 adding a very simple WelcomeBean.java file that looks like this:

 package beans;

 import java.io.Serializable;
 import javax.enterprise.context.**SessionScoped;
 import javax.inject.Named;

 /**
  *
  * @author kuw
  */
 @Named(value = welcomeBean)
 @SessionScoped
 public class WelcomeBean implements Serializable {

 private int counter;

 /**
  * Creates a new instance of WelcomeBean
  */
 public WelcomeBean() {
 }

 public String getMessage() {
 return super.toString() + String.format( You called me %d
 times, ++counter);
 }
 }

 and then access that bean from the index.xhtml page like this:

 h:body
 h:form
 Message is: h:outputText value=#{welcomeBean.message}**/
 /h:form
 /h:body

 When I run the project, the page simply shows this: Message is: and the
 nothing. I can't see anything in the project files that is missing. I have
 the empty shell of beans.xml file to enable CDI, web.xml is fairly standard
 only that I changed the url-pattern for the Faces Servlet. Here's the
 complete web.xml:

 ?xml version=1.0 encoding=UTF-8?
 web-app version=3.0 
 xmlns=http://java.sun.com/**xml/ns/javaeehttp://java.sun.com/xml/ns/javaee
 xmlns:xsi=http://www.w3.org/**2001/XMLSchema-instancehttp://www.w3.org/2001/XMLSchema-instance

Re: Simple Netbeans CDI Web Application Not Working

I struggled getting mine to work as well, but I was advised to either add
beans.xml to WEB-INF or META-INF folder.

I learned that in NetBeans, for META-INF, you create a new folder in the
same folder that contain all your java code. Netbeans does not like
META-INF/beans.xml, you get squiggly lines etc when trying to code, so the
full path of mine is as follows:

C:\Users\Public\NetBeansProjects\mcms_tomee\web\WEB-INF\beans.xml

Empty beans.xml would be like the following:


?xml version=1.0 encoding=UTF-8?
beans xmlns=http://java.sun.com/xml/ns/javaee;
   xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
   xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/beans_1_0.xsd;
/beans




On Thu, Dec 13, 2012 at 3:56 PM, Kay Wrobel kwro...@hawkusa.com wrote:

 Now CDI is item number one in the feature list of TomEE Web Profile and
 has been since version 1.0 if I remember correctly. I just can't get it to
 work...

Re: Why are Tomcat's threads more costly than background threads?

David,

1. definitely not using @Asynchronous; that was no good at all

2. Actually, it was 2 seconds on the Windows Server 2008 64-bit 16GB RAM...
always

3. Always 5 to 10 minutes to process 1 or 2 emails on Windows Server 2003
32-bit 4GB RAM

4. As noted on the JIRA, I tried the TransactionAttribute NEVER and
REQUIRES_NEW on @Stateless EJB that was all invoked via @Schedule, and same
test results, which are The EJB timer rolls back the transaction, and
every database operation that the EmailStatelessBean completed...prior to
@Schedule rolling back the transaction.



On Thu, Dec 13, 2012 at 4:06 PM, David Blevins david.blev...@gmail.comwrote:

  David,
 
  Yes, please refer to the following (and see what I wrote at the beginning
  of that comment), thanks.
 
  https://issues.apache.org/jira/browse/OPENEJB-1968#comment-13531442
 

 So first note, the @TransactionAttribute(value =
 TransactionAttributeType.NEVER) and @TransactionAttribute(value =
 TransactionAttributeType.REQUIRES_NEW) were two aspects of the same
 suggestion.

 Second note is, were I in your shoes, the very first thing I'd do is
 revert all the @ApplicationScoped and @Asychronous stuff and go back to the
 code that only took 2 minutes -- I seem to recall that before it jumped to
 30 minutes there was a version that ran faster (2 minute range).

Re: Simple Netbeans CDI Web Application Not Working

I recommend 1.5.1 and I prefer it over Glassfish? Why, because I don't make
sticking with it...to make it work.

TomEE and CDI-managed-beans and the not-so-real Apache Derby database on my
slow/old Windows Server 2003 32bit 4GB RAM is performing just as good as
Glassfish 3.1.2.2. I'm just learning 'how' to use TomEE, correctly and
efficiently.

Please make that sale.. TomEE/CDI... defintely not .NET. :)

Glassfish/WELD for CDI? i was not able to make it work at all, too hard,
too complicated... someone else told me recently, they heard all my
buzz/chatter in many different forums, they had/have Glassfish/WELD for CDI
and it's working good in production forthem, but they tried
TomEE/CDI-managed-beans, and that person said... it 'feels' faster than
Glassfish/WELD.

I like the tomEE committers big time! go with tomEE. :)


On Thu, Dec 13, 2012 at 4:15 PM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 you'll not get issue with your management, the 1.5.1 release passed,
 we just wait Jean-Louis to push binaries on repo1 :)

 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau



 2012/12/13 Kay Wrobel kwro...@hawkusa.com:
  It does when you check the Enable Context and Dependency Injection
 check
  box.
 
 
   Kay Wrobel
 
  MIS Associate
  *Hawk Electronics, Inc.*
  800-THE-HAWK
  800-843-4295
  kwro...@hawkusa.com
 
 
  On 12/13/2012 03:08 PM, Romain Manni-Bucau wrote:
 
  Question from a none netbeans user: when creating a new JavaEE 6
  project netbeans doesn't create a beans.xml?
 
  Romain Manni-Bucau
  Twitter: @rmannibucau
  Blog: http://rmannibucau.wordpress.com/
  LinkedIn: http://fr.linkedin.com/in/rmannibucau
  Github: https://github.com/rmannibucau
 
 
 
  2012/12/13 Howard W. Smith, Jr. smithh032...@gmail.com:
 
  I struggled getting mine to work as well, but I was advised to either
 add
  beans.xml to WEB-INF or META-INF folder.
 
  I learned that in NetBeans, for META-INF, you create a new folder in
 the
  same folder that contain all your java code. Netbeans does not like
  META-INF/beans.xml, you get squiggly lines etc when trying to code, so
  the
  full path of mine is as follows:
 
  C:\Users\Public\NetBeansProjects\mcms_tomee\web\WEB-INF\beans.xml
 
  Empty beans.xml would be like the following:
 
 
  ?xml version=1.0 encoding=UTF-8?
  beans xmlns=http://java.sun.com/xml/ns/javaee;
  xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
  xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
  http://java.sun.com/xml/ns/javaee/beans_1_0.xsd;
  /beans
 
 
 
 
  On Thu, Dec 13, 2012 at 3:56 PM, Kay Wrobel kwro...@hawkusa.com
 wrote:
 
  Now CDI is item number one in the feature list of TomEE Web Profile
 and
  has been since version 1.0 if I remember correctly. I just can't get
 it
  to
  work...
 
 
 
  --
 
  --
  The information in this e-mail is confidential and is intended solely for
  the addressee(s). Access to this email by anyone else is unauthorized. If
  you are not an intended recipient, you may not print, save or otherwise
  store the e-mail or any of the contents thereof in electronic or physical
  form, nor copy, use or disseminate the information contained in the
 email.
  If you are not an intended recipient,  please notify the sender of this
  email immediately.

Re: Why are Tomcat's threads more costly than background threads?

David,

Thanks for the response. Guess what... the 2 beans along with the names and
all... is exactly what I did 'yesterday', the only thing I did 'not' do was
mark each of the beans according to what you mentioned.

I will try that, ASAP might not be able to report about it until a
little later. I want the @Schedule approach along with a user-initiated
approach. I'm coding the user initiated approach right now.

The original approach will definitely serve for background processing.

Thanks,
Howard

On Thu, Dec 13, 2012 at 4:53 PM, David Blevins david.blev...@gmail.comwrote:

 Let's try this:

   - Go back to the very original 5-10 minutes 32-bit code

   - Split EmailSessionBean into two beans

   - EmailSessionBean
  - will be marked @TransactionAttribute(NEVER)
  - will no longer have an @PersistenceContext EntityManager
 reference
   - AirportShuttleRequestProcessorBean
  - will be marked @TransactionAttribute(REQUIRES_NEW)
  - will have only one public method, `createOrderForAirportShuttle`
  - will do all persistence processing

 The EmailSessionBean will have an @EJB reference to the new
 AirportShuttleRequestProcessorBean.  Effectively, we're splitting the code
 that does the contacting the of the email server from the code that
 contacts the database and we're creating several much smaller transactions.

Re: Why are Tomcat's threads more costly than background threads?

David, I did as you recommended. I got an exception related to the ejbTimer
and JTA. please see my latest 2 post on the JIRA.

https://issues.apache.org/jira/browse/OPENEJB-1968

Need to leave my desk for little bit. Thanks.

On Thu, Dec 13, 2012 at 4:06 PM, David Blevins david.blev...@gmail.comwrote:

 If you're willing to go back to the original version of the code and do
 *only* the suggestions given, I think we can get this easily sorted out
 today.

Re: Why are Tomcat's threads more costly than background threads?

David, I corrected that as you stated, and I made sure the code was as you
recommended, and I've updated the JIRA with test results. Windows Server
2008 64bit is still fast, Windows SErver 2003 32bit is 'still' slow and
locking the database.



On Thu, Dec 13, 2012 at 7:02 PM, David Blevins david.blev...@gmail.comwrote:

 My bad, should be @TransactionAttribute(NOT_SUPPORTED)  -- even hard for
 me to remember the right names :)

 In case you're curious, reading for another day:

   http://tomee.apache.org/transaction-annotations.html

Re: Why are Tomcat's threads more costly than background threads?

Jean-Louis, please clarify 'finder methods' and/provide a short example,
thanks.


On Wed, Dec 12, 2012 at 3:08 AM, Jean-Louis MONTEIRO jeano...@gmail.comwrote:

 I tend to recommend to set any finder methods to SUPPORT which is far
 better in terms of performances and allow reusability of finder methods in
 business methods.

 JLouis


 2012/12/11 David Blevins david.blev...@gmail.com

  Setting the LockModeType is good.  Understand, though, that all the
 values
  in LockModeType are not guaranteed to be supported in all databases.
 
  It doesn't address the core problem in that the transaction scope is
  likely too broad.  As a general rule *always* ensure your transactions
 are
  as *small* as possible.  In order to be very conscious about it it can
 help
  to actually document the code and justify why two or more operations need
  to be in the same transaction.  It'll force you to think about
 transactions
  more deliberately and ask yourself other questions like where are my
  transactions starting and stopping in the first place.
 
  In this particular situation, with default settings, you'll get one
  transaction started for you when the @Schedule method fires.  So
  essentially, you're batch processing unrelated data in one transaction.
  If
  Joe and Jane both send email with data, you're processing Jane's data in
  Joe's transaction.  As as well your email fetching time is getting
 included
  in your transaction time.  If your email server hangs, your transaction
  hangs.
 
  So instead of:
 
  // TRANSACTION START
  @Schedule(...)
  public void processPendingEmail() {
 
  ListEmail emails = fetchEmail();
  for (Email email : emails) {
 // parse email and insert records
  }
  }
  // TRANSACTION END
 
  You want:
 
  @Schedule(...)
  public void processPendingEmail() {
 
  ListEmail emails = fetchEmail();
  for (Email email : emails) {
 // TRANSACTION START
 // parse email and insert records
 // TRANSACTION END
  }
  }
 
  This can be as easy as marking the `processPendingEmail` as
  `@TransactionAttribute(NEVER)` then moving the insert logic to another
 EJB
  method.  Just make sure that if you move that logic to another method of
  the same EJB that you don't invoke that method with a `this` reference or
  you won't get container-managed transactions on that method call. (see
 this
  reference for why):
 
 
 
 http://stackoverflow.com/questions/3381002/how-is-the-return-value-of-sessioncontext-getbusinessobject-different-from-th/3384128#3384128
 
  Hope this helps!
 
 
  -David
 
  On Dec 11, 2012, at 12:21 PM, Howard W. Smith, Jr. 
  smithh032...@gmail.com wrote:
 
   Prior to adding this @Stateless EJB (that's invoked via @Schedule every
  10
   minutes), my JSF web app has been running 100% okay without any
 deadlocks
   or anything else like that.
  
   So, is it okay if I just add optimistic locking, em.lock(entity,
   LockType.Optimistic) before any/all em.persist(...) that I have in the
   @Stateless EJB?
  
   JSF web app is working okay, because the JSF components call multiple
   @Stateless EJB that usually do any of the following, SELECT, UPDATE,
   DELETE,  on one table at time.
  
  
  
   On Tue, Dec 11, 2012 at 2:35 PM, Howard W. Smith, Jr. 
   smithh032...@gmail.com wrote:
  
   You're absolutely right, David. Thanks for the response.
  
   It is a transaction issue and the @Stateless EJB is holding a
  transaction
   open and writing into 6 to 10 tables in a single database, which is
 also
   the database accessed by JSF components (by endusers). The @Stateless
  EJB
   is on a timer ( @Schedule), checks email server for incoming requests
  from
   customers, and takes that data and inserts it into database, so
 endusers
   don't have to manually enter the data (that they receive from these
   formmail results).
  
   Below is the exception that I saw maybe an hour or two ago, and I
   confirmed that it's a locking/transaction issue, and from the
  stacktrace,
   it seems as though the JSF components cannot access the table, that is
   evidently locked by @Stateless EJB. The @Stateless @EJB updated all
  tables
   on my faster/dev/test server on average of 1 to 2 seconds, and/so in
 my
   opinion, the data is not that much at all, maybe a few kbytes of data
  being
   inserted into the database. Anyway, I've been reading up on
 pessismistic
   and optimistic locking, and that's where I was in my reading before I
   noticed your email. I really don't know what the database or JPA is
   defaulting to, because honestly, I have no code that specifies any
  locks.
   Recently, I only added query hint (readonly) to JPA queries.
  Personally, I
   feel as though I can use 'no locking' for these inserts, since this is
   brand new data, but the JSF components may be locking the
 entites/tables
   during simple queries (SELECT statements).  Feel free to change

Re: TomEE: @Stateless EJB holds transaction/database-locks after @Schedule method completed

smiling... okay, well, i already opened the JIRA

https://issues.apache.org/jira/browse/OPENEJB-1968

only provided log and @Stateless EJB.



On Wed, Dec 12, 2012 at 4:20 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 Hi,

 please reproduce it in a small maven project with a unit test

 this is tested and we never had such an issue so opening a jira will
 not help without any sample to reproduce it IMO

 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau



 2012/12/12 Howard W. Smith, Jr. smithh032...@gmail.com:
  After implementing 'workaround' option # 1 in my previous email (below),
  the test results were really really bad. :(
 
  for 4 emails, it took 30 minutes to insert the data into the database,
 and
  then it seemed as though the single @Stateless EJB held onto the
  transaction, even after the @Schedule method, getEmails(), was done and
  exited.
 
  Should I file a JIRA? I would assume that the @Stateless bean would 'let
  go' of the transaction, but transaction remained opened. Maybe, I should
  have issued a entityManager.flush() after completing each email, but I
 did
  flush() a lot throughout the process.
 
  Please note that this machine is Windows Server 2003 32bit 4GB RAM, and
 it
  takes 10 to 15 minutes to insert data from 2 emails (which is a very
 small
  amount of data embedded in the email). I could not select any data from
  database after login. I had to shutdown TomEE.
 
  Also, note, when I originally developed this, one @Stateless EJB with 1
  entity manager, it took 2 seconds on Windows Server 2008 64bit 16GB RAM,
  and it did not hold the transaction (or database locks). also, i could
  select data afterwards.
 
  I still need to try what David mentioned, but it's been an all-nighter
 for
  me, so i need to stop right here for now.
 
  I think I will open a JIRA for this.
 
 
  On Tue, Dec 11, 2012 at 10:10 PM, Howard W. Smith, Jr. 
  smithh032...@gmail.com wrote:
 
  Shaking my head... test results were not good at all.
 
  1. @StatelessEJB EmailStatelessBean has @Schedule getEmails()
  2. @EmailStatelessBean has multiple @EJB references to @Stateless
  (sessionfacade) classes that are the DAO classes
  3. EmailStatelessBean gets invoked when triggered by @Schedule
  4. EmailStatelessBean execution locks the tables, still, and locks up
 the
  entire app, and seems to take longer...since endusers (myself) are
 making
  requests against database (and web app).
  5. Last but not least, EmailStatelessBean failed to commit the changes;
  transaction rolled back for EmailStatelessBean as well as enduser
 requests.
 
  So, my workaround options include the following:
 
  1. EmailStatelessBean, when invoked by @Schedule method, will check the
  CDI @ApplicationScoped bean (ApplicationScopeBean), and see if any
 endusers
  are logged in; i developed a sessionInfo class that is updated everytime
  enduser does a HTTP request; if any endusers are logged in, then I can
 use
  Atmosphere (PrimeFaces Push) to push a message to the endusers,
 notifying
  them to 'please logout, as there are customer requests pending that
 need to
  be retrieved and inserted into the web app's database', and
  EmailStatelessBean will 'return' (or exit) and not perform the
 operation.
  This way, everytime @Schedule invokes the bean method, it will continue
 to
  check for an available time to perform the
  get-emails-and-insert-into-database operation. Also, I'll set when
  EmailStatelessBean begins the operation, then I'll set flag on
  @ApplicationScoped bean (insertingCustomerRequestsIntoDatabase = true);
  this flag will be checked when endusers attempt to login web app, and
  FacesMessage will be displayed, Please login a few minutes later as
 system
  is inserting customer requests into database.
 
  2. Another option would be to send a message to all clients via
 Atmosphere
  (PrimeFaces Push), and the UI will be locked immediately, and user will
 be
  required to wait.
 
  Honestly, I don't like either of these approaches, but I think the
  endusers will accept the 1st option (above). If I go with 1st approach,
  then I may revert back to single transaction, which will complete the
  entire operation much faster than multiple transactions (via multiple
 EJB
  DAO classes).
 
  As you can see, I don't have enough experience locking database for
 such a
  batch operation as this. I know the endusers want the customer requests
 to
  show up into the database 'immediately', and they want to know when it
  happens. Right now, this is my only option until I redesign the business
  website to interface directly with the web app. right now, the web app
 is
  'only' used by 'personnel' (the owners of the business...which is my
  family). hahaha :)
 
  They love the app (honestly, they liked the speed and reliability of the
  web app when it was on Glassfish), but I'm doing all i

Re: Why are Tomcat's threads more costly than background threads?

okay, thanks. I was aware of that already. ;)

On Wed, Dec 12, 2012 at 4:03 AM, Jean-Louis MONTEIRO jeano...@gmail.comwrote:

Finder methods are usually methods to retrieve an entity or a set of
entities.
Basically, it means Qurey.getSingleResult() or getResultList().

By default any method is REQUIRED in EJBs so that means a transaction will
be created whereas it's not required as per the spec.
When you just want to browse data, you actually don't need a transaction.

A special attention must be of course placed on JPA relationships and more
especially LAZY tagged ones.
As soon as the transaction finished or as soon as they are retrieved when
no transaction is used, they are in an unmanaged state which means that you
cannot navigate through lazy relationships.

So before retrieving an object graph to browse it in the front layer, you
basically need to know what you want to display in order to pre load all
relationships (using a left join fetch or so query).

Jean-Louis

2012/12/12 Howard W. Smith, Jr. smithh032...@gmail.com

Jean-Louis, please clarify 'finder methods' and/provide a short example,
thanks.

On Wed, Dec 12, 2012 at 3:08 AM, Jean-Louis MONTEIRO jeano...@gmail.com
wrote:

I tend to recommend to set any finder methods to SUPPORT which is far
better in terms of performances and allow reusability of finder methods
in
business methods.

JLouis

2012/12/11 David Blevins david.blev...@gmail.com

Setting the LockModeType is good. Understand, though, that all the
values
in LockModeType are not guaranteed to be supported in all databases.

It doesn't address the core problem in that the transaction scope is
likely too broad. As a general rule *always* ensure your
transactions
are
as *small* as possible. In order to be very conscious about it it
can
help
to actually document the code and justify why two or more operations
need
to be in the same transaction. It'll force you to think about
transactions
more deliberately and ask yourself other questions like where are my
transactions starting and stopping in the first place.

In this particular situation, with default settings, you'll get one
transaction started for you when the @Schedule method fires. So
essentially, you're batch processing unrelated data in one
transaction.
If
Joe and Jane both send email with data, you're processing Jane's data
in
Joe's transaction. As as well your email fetching time is getting
included
in your transaction time. If your email server hangs, your
transaction
hangs.

So instead of:

// TRANSACTION START
@Schedule(...)
public void processPendingEmail() {

ListEmail emails = fetchEmail();
for (Email email : emails) {
// parse email and insert records
}
}
// TRANSACTION END

You want:

@Schedule(...)
public void processPendingEmail() {

ListEmail emails = fetchEmail();
for (Email email : emails) {
// TRANSACTION START
// parse email and insert records
// TRANSACTION END
}
}

This can be as easy as marking the `processPendingEmail` as
`@TransactionAttribute(NEVER)` then moving the insert logic to
another
EJB
method. Just make sure that if you move that logic to another method
of
the same EJB that you don't invoke that method with a `this`
reference
or
you won't get container-managed transactions on that method call.
(see
this
reference for why):

http://stackoverflow.com/questions/3381002/how-is-the-return-value-of-sessioncontext-getbusinessobject-different-from-th/3384128#3384128

Hope this helps!

-David

On Dec 11, 2012, at 12:21 PM, Howard W. Smith, Jr.
smithh032...@gmail.com wrote:

Prior to adding this @Stateless EJB (that's invoked via @Schedule
every
10
minutes), my JSF web app has been running 100% okay without any
deadlocks
or anything else like that.

So, is it okay if I just add optimistic locking, em.lock(entity,
LockType.Optimistic) before any/all em.persist(...) that I have in
the
@Stateless EJB?

JSF web app is working okay, because the JSF components call
multiple
@Stateless EJB that usually do any of the following, SELECT,
UPDATE,
DELETE, on one table at time.

On Tue, Dec 11, 2012 at 2:35 PM, Howard W. Smith, Jr.
smithh032...@gmail.com wrote:

You're absolutely right, David. Thanks for the response.

It is a transaction issue and the @Stateless EJB is holding a
transaction
open and writing into 6 to 10 tables in a single database, which
is
also
the database accessed by JSF components (by endusers). The
@Stateless

Re: TomEE: @Stateless EJB holds transaction/database-locks after @Schedule method completed

I really think this is hardware related issue. Why would 64bit 16GB RAM
development server (2 seconds for 2 emails) out perform 32bit 4GB RAM
production server (10 minutes for same 2 emails). ? :-)

I am requesting newer better hardware now.
On Dec 12, 2012 4:21 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote:

 Hi,

 please reproduce it in a small maven project with a unit test

 this is tested and we never had such an issue so opening a jira will
 not help without any sample to reproduce it IMO

 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau



 2012/12/12 Howard W. Smith, Jr. smithh032...@gmail.com:
  After implementing 'workaround' option # 1 in my previous email (below),
  the test results were really really bad. :(
 
  for 4 emails, it took 30 minutes to insert the data into the database,
 and
  then it seemed as though the single @Stateless EJB held onto the
  transaction, even after the @Schedule method, getEmails(), was done and
  exited.
 
  Should I file a JIRA? I would assume that the @Stateless bean would 'let
  go' of the transaction, but transaction remained opened. Maybe, I should
  have issued a entityManager.flush() after completing each email, but I
 did
  flush() a lot throughout the process.
 
  Please note that this machine is Windows Server 2003 32bit 4GB RAM, and
 it
  takes 10 to 15 minutes to insert data from 2 emails (which is a very
 small
  amount of data embedded in the email). I could not select any data from
  database after login. I had to shutdown TomEE.
 
  Also, note, when I originally developed this, one @Stateless EJB with 1
  entity manager, it took 2 seconds on Windows Server 2008 64bit 16GB RAM,
  and it did not hold the transaction (or database locks). also, i could
  select data afterwards.
 
  I still need to try what David mentioned, but it's been an all-nighter
 for
  me, so i need to stop right here for now.
 
  I think I will open a JIRA for this.
 
 
  On Tue, Dec 11, 2012 at 10:10 PM, Howard W. Smith, Jr. 
  smithh032...@gmail.com wrote:
 
  Shaking my head... test results were not good at all.
 
  1. @StatelessEJB EmailStatelessBean has @Schedule getEmails()
  2. @EmailStatelessBean has multiple @EJB references to @Stateless
  (sessionfacade) classes that are the DAO classes
  3. EmailStatelessBean gets invoked when triggered by @Schedule
  4. EmailStatelessBean execution locks the tables, still, and locks up
 the
  entire app, and seems to take longer...since endusers (myself) are
 making
  requests against database (and web app).
  5. Last but not least, EmailStatelessBean failed to commit the changes;
  transaction rolled back for EmailStatelessBean as well as enduser
 requests.
 
  So, my workaround options include the following:
 
  1. EmailStatelessBean, when invoked by @Schedule method, will check the
  CDI @ApplicationScoped bean (ApplicationScopeBean), and see if any
 endusers
  are logged in; i developed a sessionInfo class that is updated everytime
  enduser does a HTTP request; if any endusers are logged in, then I can
 use
  Atmosphere (PrimeFaces Push) to push a message to the endusers,
 notifying
  them to 'please logout, as there are customer requests pending that
 need to
  be retrieved and inserted into the web app's database', and
  EmailStatelessBean will 'return' (or exit) and not perform the
 operation.
  This way, everytime @Schedule invokes the bean method, it will continue
 to
  check for an available time to perform the
  get-emails-and-insert-into-database operation. Also, I'll set when
  EmailStatelessBean begins the operation, then I'll set flag on
  @ApplicationScoped bean (insertingCustomerRequestsIntoDatabase = true);
  this flag will be checked when endusers attempt to login web app, and
  FacesMessage will be displayed, Please login a few minutes later as
 system
  is inserting customer requests into database.
 
  2. Another option would be to send a message to all clients via
 Atmosphere
  (PrimeFaces Push), and the UI will be locked immediately, and user will
 be
  required to wait.
 
  Honestly, I don't like either of these approaches, but I think the
  endusers will accept the 1st option (above). If I go with 1st approach,
  then I may revert back to single transaction, which will complete the
  entire operation much faster than multiple transactions (via multiple
 EJB
  DAO classes).
 
  As you can see, I don't have enough experience locking database for
 such a
  batch operation as this. I know the endusers want the customer requests
 to
  show up into the database 'immediately', and they want to know when it
  happens. Right now, this is my only option until I redesign the business
  website to interface directly with the web app. right now, the web app
 is
  'only' used by 'personnel' (the owners of the business...which is my
  family). hahaha :)
 
  They love the app (honestly

Re: TomEE: @Stateless EJB holds transaction/database-locks after @Schedule method completed

AFAIR? Jean-Louis, that's funny. Are you telling me that you're not using
or testing on 32-bit hardware any longer? :)

On a serious note...what platforms/hardware are TomEE test cases tested on?
Do you all test on a 'similar' platform to my 'current' production platform
(Windows Server 2003 32bit 4GB RAM)?



On Wed, Dec 12, 2012 at 9:44 AM, Jean-Louis MONTEIRO jeano...@gmail.comwrote:

 32 Bits = 3,2GB max AFAIR


 2012/12/12 Howard W. Smith, Jr. smithh032...@gmail.com

  I really think this is hardware related issue. Why would 64bit 16GB RAM
  development server (2 seconds for 2 emails) out perform 32bit 4GB RAM
  production server (10 minutes for same 2 emails). ? :-)
 
  I am requesting newer better hardware now.
  On Dec 12, 2012 4:21 AM, Romain Manni-Bucau rmannibu...@gmail.com
  wrote:
 
   Hi,
  
   please reproduce it in a small maven project with a unit test
  
   this is tested and we never had such an issue so opening a jira will
   not help without any sample to reproduce it IMO
  
   Romain Manni-Bucau
   Twitter: @rmannibucau
   Blog: http://rmannibucau.wordpress.com/
   LinkedIn: http://fr.linkedin.com/in/rmannibucau
   Github: https://github.com/rmannibucau
  
  
  
   2012/12/12 Howard W. Smith, Jr. smithh032...@gmail.com:
After implementing 'workaround' option # 1 in my previous email
  (below),
the test results were really really bad. :(
   
for 4 emails, it took 30 minutes to insert the data into the
 database,
   and
then it seemed as though the single @Stateless EJB held onto the
transaction, even after the @Schedule method, getEmails(), was done
 and
exited.
   
Should I file a JIRA? I would assume that the @Stateless bean would
  'let
go' of the transaction, but transaction remained opened. Maybe, I
  should
have issued a entityManager.flush() after completing each email, but
 I
   did
flush() a lot throughout the process.
   
Please note that this machine is Windows Server 2003 32bit 4GB RAM,
 and
   it
takes 10 to 15 minutes to insert data from 2 emails (which is a very
   small
amount of data embedded in the email). I could not select any data
 from
database after login. I had to shutdown TomEE.
   
Also, note, when I originally developed this, one @Stateless EJB
 with 1
entity manager, it took 2 seconds on Windows Server 2008 64bit 16GB
  RAM,
and it did not hold the transaction (or database locks). also, i
 could
select data afterwards.
   
I still need to try what David mentioned, but it's been an
 all-nighter
   for
me, so i need to stop right here for now.
   
I think I will open a JIRA for this.
   
   
On Tue, Dec 11, 2012 at 10:10 PM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:
   
Shaking my head... test results were not good at all.
   
1. @StatelessEJB EmailStatelessBean has @Schedule getEmails()
2. @EmailStatelessBean has multiple @EJB references to @Stateless
(sessionfacade) classes that are the DAO classes
3. EmailStatelessBean gets invoked when triggered by @Schedule
4. EmailStatelessBean execution locks the tables, still, and locks
 up
   the
entire app, and seems to take longer...since endusers (myself) are
   making
requests against database (and web app).
5. Last but not least, EmailStatelessBean failed to commit the
  changes;
transaction rolled back for EmailStatelessBean as well as enduser
   requests.
   
So, my workaround options include the following:
   
1. EmailStatelessBean, when invoked by @Schedule method, will check
  the
CDI @ApplicationScoped bean (ApplicationScopeBean), and see if any
   endusers
are logged in; i developed a sessionInfo class that is updated
  everytime
enduser does a HTTP request; if any endusers are logged in, then I
 can
   use
Atmosphere (PrimeFaces Push) to push a message to the endusers,
   notifying
them to 'please logout, as there are customer requests pending that
   need to
be retrieved and inserted into the web app's database', and
EmailStatelessBean will 'return' (or exit) and not perform the
   operation.
This way, everytime @Schedule invokes the bean method, it will
  continue
   to
check for an available time to perform the
get-emails-and-insert-into-database operation. Also, I'll set when
EmailStatelessBean begins the operation, then I'll set flag on
@ApplicationScoped bean (insertingCustomerRequestsIntoDatabase =
  true);
this flag will be checked when endusers attempt to login web app,
 and
FacesMessage will be displayed, Please login a few minutes later as
   system
is inserting customer requests into database.
   
2. Another option would be to send a message to all clients via
   Atmosphere
(PrimeFaces Push), and the UI will be locked immediately, and user
  will
   be
required to wait.
   
Honestly, I don't like either of these approaches, but I think the
endusers will accept

Re: TomEE: @Stateless EJB holds transaction/database-locks after @Schedule method completed

Wow, I wanted to search google, but didn't have to, it was in my email
(oracle java developer email).  That was right on time.

http://plumbr.eu/blog/should-i-use-32-or-64-bit-jvm


On Wed, Dec 12, 2012 at 9:55 AM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:

 AFAIR? Jean-Louis, that's funny. Are you telling me that you're not using
 or testing on 32-bit hardware any longer? :)

 On a serious note...what platforms/hardware are TomEE test cases tested
 on? Do you all test on a 'similar' platform to my 'current' production
 platform (Windows Server 2003 32bit 4GB RAM)?



 On Wed, Dec 12, 2012 at 9:44 AM, Jean-Louis MONTEIRO 
 jeano...@gmail.comwrote:

 32 Bits = 3,2GB max AFAIR

Re: TomEE/OpenEJB manage @EJB's different in @Stateless EJB versus JSF/CDI managed bean

Okay, thanks for that response.

I'll go ahead with my plans (that I mentioned in my previous/original email
on this topic).

thanks.


On Wed, Dec 12, 2012 at 10:56 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 the differences are http://jcp.org/en/jsr/detail?id=318 and
 http://www.jcp.org/en/jsr/detail?id=299

 basically i think the one you'll mainly see will be related to
 transaction management (cdi doesn't have any transaction where ejb tx
 context can be configured by method)

 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau



 2012/12/12 Howard W. Smith, Jr. smithh032...@gmail.com:
  There is some type of difference between how TomEE/OpenEJB ('container')
  manages @EJB's within @Stateless EJB and CDI/JSF managed bean.
 
  What is the difference?
 
  Since my CDI managed beans update many many tables via multiple @EJB's
 just
  fine, on a single enduser (http) request, concurrently when multiple
 users
  are logged in (seamlessly and never returning any database lock
 messages),
  then I'm going to move most of the code out of this @Stateless EJB into a
  CDI @RequestScoped bean.
 
  I hope that will make a difference for some batch processing that I need
 to
  do 'while' endusers are logged in (preferably)... or maybe this is just
 not
  possible at all... on a 32-bit (4GB RAM) platform and JVM.  :(

Re: TomEE: @Stateless EJB holds transaction/database-locks after @Schedule method completed

Interesting response, thanks Jean-Louis for the response. I'll keep that in
mind when I present issues/questions.

I'm loving TomEE, especially the committers! thank you all for all your
responses...so far!



On Wed, Dec 12, 2012 at 11:04 AM, Jean-Louis MONTEIRO jeano...@gmail.comwrote:

 Interesting question :)
 I of course still use 32Bits architecture, but was not fully sure of the
 precise number.

 Anyway, interesting link, thx.

 Regarding TomEE testing.
 Most of developers use MacOS and Linux (Ubuntu or so) system.

 In the CI, we are used to focus on Ubuntu but we should have also a
 configuration on Windows. Can't remember exactly the link (jenckins maybe
 instead of buildbot), but I can't retrieve it.

 Some years ago (not sure), we also asked for a virtual machin for MacOS.
 Finally, I guess we still have a build with an IBM JDK.

 Hope it helps
 JLouis



 2012/12/12 Howard W. Smith, Jr. smithh032...@gmail.com

  Wow, I wanted to search google, but didn't have to, it was in my email
  (oracle java developer email).  That was right on time.
 
  http://plumbr.eu/blog/should-i-use-32-or-64-bit-jvm
 
 
  On Wed, Dec 12, 2012 at 9:55 AM, Howard W. Smith, Jr. 
  smithh032...@gmail.com wrote:
 
   AFAIR? Jean-Louis, that's funny. Are you telling me that you're not
 using
   or testing on 32-bit hardware any longer? :)
  
   On a serious note...what platforms/hardware are TomEE test cases tested
   on? Do you all test on a 'similar' platform to my 'current' production
   platform (Windows Server 2003 32bit 4GB RAM)?
  
  
  
   On Wed, Dec 12, 2012 at 9:44 AM, Jean-Louis MONTEIRO 
 jeano...@gmail.com
  wrote:
  
   32 Bits = 3,2GB max AFAIR
  
  
 



 --
 Jean-Louis

Re: TomEE: @Stateless EJB holds transaction/database-locks after @Schedule method completed

Well, I appreciate it...a lot. The first real open source project that I
really could see the benefit of 'open source' was PrimeFaces. I was very
very active in the forum there as I was developing my JSF web application,
and I saw the value of open source, supporting the 'community', and the
value of issue tracker, filing issues, and even referring to issue tracker
for possible fixes/workarounds...even if the issue/JIRA is not marked as
fixed yet. I have benefited big time from PrimeFaces community,
stackoverflow, and google... in the last year as a 1.5-year-old JAVA/JSF
developer.

RD (research and development) has been my job for the last 1.5 years, and
I love it!

Anyway, i'm glad that TomEE/OpenEJB committers support the (open source)
community as well. I think open source probably improves software the most,
because many 'users' will use open source version, and I 'think' that open
source users are filing or communicating most of the issues... but I could
be wrong... I'm still new at all this. :)



On Wed, Dec 12, 2012 at 11:24 AM, Jean-Louis MONTEIRO jeano...@gmail.comwrote:

 Thx you to keep interesting even if TomEE is not perfect. We know that and
 we want to make it even better thanks to users feedback.

 Regarding responses, almost all of us don't work on opensource and TomEE
 full time. It's mainly our free time and a company contribution when
 possible and when it matches to company business needs.

 So we try to share as much as possible our experience and also to get the
 most from user needs, feedback and questions (kinda 2 ways discussion ;-))

 Jean-Louis


 2012/12/12 Howard W. Smith, Jr. smithh032...@gmail.com

  Interesting response, thanks Jean-Louis for the response. I'll keep that
 in
  mind when I present issues/questions.
 
  I'm loving TomEE, especially the committers! thank you all for all your
  responses...so far!
 
 
 
  On Wed, Dec 12, 2012 at 11:04 AM, Jean-Louis MONTEIRO 
 jeano...@gmail.com
  wrote:
 
   Interesting question :)
   I of course still use 32Bits architecture, but was not fully sure of
 the
   precise number.
  
   Anyway, interesting link, thx.
  
   Regarding TomEE testing.
   Most of developers use MacOS and Linux (Ubuntu or so) system.
  
   In the CI, we are used to focus on Ubuntu but we should have also a
   configuration on Windows. Can't remember exactly the link (jenckins
 maybe
   instead of buildbot), but I can't retrieve it.
  
   Some years ago (not sure), we also asked for a virtual machin for
 MacOS.
   Finally, I guess we still have a build with an IBM JDK.
  
   Hope it helps
   JLouis
  
  
  
   2012/12/12 Howard W. Smith, Jr. smithh032...@gmail.com
  
Wow, I wanted to search google, but didn't have to, it was in my
 email
(oracle java developer email).  That was right on time.
   
http://plumbr.eu/blog/should-i-use-32-or-64-bit-jvm
   
   
On Wed, Dec 12, 2012 at 9:55 AM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:
   
 AFAIR? Jean-Louis, that's funny. Are you telling me that you're not
   using
 or testing on 32-bit hardware any longer? :)

 On a serious note...what platforms/hardware are TomEE test cases
  tested
 on? Do you all test on a 'similar' platform to my 'current'
  production
 platform (Windows Server 2003 32bit 4GB RAM)?



 On Wed, Dec 12, 2012 at 9:44 AM, Jean-Louis MONTEIRO 
   jeano...@gmail.com
wrote:

 32 Bits = 3,2GB max AFAIR


   
  
  
  
   --
   Jean-Louis
  
 



 --
 Jean-Louis

Re: TomEE: @Stateless EJB holds transaction/database-locks after @Schedule method completed

And, to add, this is probably not the first time hearing this from me, but
I've already gone on and learned and benefited by being active here in the
tomee/openejb mailing list (community) now.

So...loads of thanks to you guys!


On Wed, Dec 12, 2012 at 11:39 AM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:

 Well, I appreciate it...a lot. The first real open source project that I
 really could see the benefit of 'open source' was PrimeFaces. I was very
 very active in the forum there as I was developing my JSF web application,
 and I saw the value of open source, supporting the 'community', and the
 value of issue tracker, filing issues, and even referring to issue tracker
 for possible fixes/workarounds...even if the issue/JIRA is not marked as
 fixed yet. I have benefited big time from PrimeFaces community,
 stackoverflow, and google... in the last year as a 1.5-year-old JAVA/JSF
 developer.

 RD (research and development) has been my job for the last 1.5 years, and
 I love it!

 Anyway, i'm glad that TomEE/OpenEJB committers support the (open source)
 community as well. I think open source probably improves software the most,
 because many 'users' will use open source version, and I 'think' that open
 source users are filing or communicating most of the issues... but I could
 be wrong... I'm still new at all this. :)



 On Wed, Dec 12, 2012 at 11:24 AM, Jean-Louis MONTEIRO 
 jeano...@gmail.comwrote:

 Thx you to keep interesting even if TomEE is not perfect. We know that and
 we want to make it even better thanks to users feedback.

 Regarding responses, almost all of us don't work on opensource and TomEE
 full time. It's mainly our free time and a company contribution when
 possible and when it matches to company business needs.

 So we try to share as much as possible our experience and also to get the
 most from user needs, feedback and questions (kinda 2 ways discussion ;-))

 Jean-Louis


 2012/12/12 Howard W. Smith, Jr. smithh032...@gmail.com

  Interesting response, thanks Jean-Louis for the response. I'll keep
 that in
  mind when I present issues/questions.
 
  I'm loving TomEE, especially the committers! thank you all for all your
  responses...so far!
 
 
 
  On Wed, Dec 12, 2012 at 11:04 AM, Jean-Louis MONTEIRO 
 jeano...@gmail.com
  wrote:
 
   Interesting question :)
   I of course still use 32Bits architecture, but was not fully sure of
 the
   precise number.
  
   Anyway, interesting link, thx.
  
   Regarding TomEE testing.
   Most of developers use MacOS and Linux (Ubuntu or so) system.
  
   In the CI, we are used to focus on Ubuntu but we should have also a
   configuration on Windows. Can't remember exactly the link (jenckins
 maybe
   instead of buildbot), but I can't retrieve it.
  
   Some years ago (not sure), we also asked for a virtual machin for
 MacOS.
   Finally, I guess we still have a build with an IBM JDK.
  
   Hope it helps
   JLouis
  
  
  
   2012/12/12 Howard W. Smith, Jr. smithh032...@gmail.com
  
Wow, I wanted to search google, but didn't have to, it was in my
 email
(oracle java developer email).  That was right on time.
   
http://plumbr.eu/blog/should-i-use-32-or-64-bit-jvm
   
   
On Wed, Dec 12, 2012 at 9:55 AM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:
   
 AFAIR? Jean-Louis, that's funny. Are you telling me that you're
 not
   using
 or testing on 32-bit hardware any longer? :)

 On a serious note...what platforms/hardware are TomEE test cases
  tested
 on? Do you all test on a 'similar' platform to my 'current'
  production
 platform (Windows Server 2003 32bit 4GB RAM)?



 On Wed, Dec 12, 2012 at 9:44 AM, Jean-Louis MONTEIRO 
   jeano...@gmail.com
wrote:

 32 Bits = 3,2GB max AFAIR


   
  
  
  
   --
   Jean-Louis
  
 



 --
 Jean-Louis

Re: DB access is very slow

Glad to hear eclipselink is faster. What kind of hardware and operating
system? 32 bit or 64 bit? My windows server 2008 64bit 16GB RAM development
server performs much better than my windows 2003 32bit 4GB RAM production
server.

2008 64bit 16GB RAM server inserts data in database at 2 seconds. Inserting
same data via same software on 2003 32bit 4GB RAM server takes 10 minutes.

Trying to upgrade out of the 32bit machine asap. Using jdk7 on both
servers.
 On Dec 12, 2012 6:32 PM, knak55 naka...@xb4.so-net.ne.jp wrote:

 I'd like to make a test application I can share with you.

 Regarding my application, when I replaced the OpenJPA with the eclipselink
 by changing provider in persistent.xml and put eclipselink.jar in lib
 directory under the TomEE home directory, the performance is greatly
 improved in the last case where it took about 2000msec with the OpenJPA. It
 becomes to take nearly 0 msec for the case, though for other two cases,
 insert and update, it still takes from 300msec to 400msec.



 --
 View this message in context:
 http://openejb.979440.n4.nabble.com/DB-access-is-very-slow-tp4659326p4659470.html
 Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: DB access is very slow

Well, there you go, 32 bit. Is the Linux environment going to be 32bit or
64bit with plenty of RAM?
On Dec 12, 2012 7:34 PM, knak55 naka...@xb4.so-net.ne.jp wrote:

 Thank you for your suggestion.
 My application is now under development. So I use the Windows 7(32bit) with
 2GB memory. Once the development finishes, I am going to deploy the
 application to the Linux server environment.



 --
 View this message in context:
 http://openejb.979440.n4.nabble.com/DB-access-is-very-slow-tp4659326p4659478.html
 Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: DB access is very slow

I came across this blog this morning, since I clearly had differences in
performance running my code on 32-bit and 64-bit platforms. read it when
you can.

Should I use a 32- or a 64-bit JVM? | Plumbr blog
http://plumbr.eu/blog/should-i-use-32-or-64-bit-jvm


On Wed, Dec 12, 2012 at 9:19 PM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:

 Well, there you go, 32 bit. Is the Linux environment going to be 32bit or
 64bit with plenty of RAM?
 On Dec 12, 2012 7:34 PM, knak55 naka...@xb4.so-net.ne.jp wrote:

 Thank you for your suggestion.
 My application is now under development. So I use the Windows 7(32bit)
 with
 2GB memory. Once the development finishes, I am going to deploy the
 application to the Linux server environment.



 --
 View this message in context:
 http://openejb.979440.n4.nabble.com/DB-access-is-very-slow-tp4659326p4659478.html
 Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: TomEE: StandardSession expire

Romain, I'm revisiting this email. I did briefly take a look at the folder
,but didn't really download the update...yet. I would assume 1.5.1-SNAPSHOT
is latest and greatest...more than 1.5.1 that was released some days ago.
right?  :)


On Tue, Dec 11, 2012 at 8:43 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:


 https://repository.apache.org/content/groups/public/org/apache/openejb/tomee-catalina/1.5.1-SNAPSHOT/
 tomorrow i guess

 will try to update snapshot version tomorrow morning

 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau



 2012/12/11 Howard W. Smith, Jr. smithh032...@gmail.com:
  Smiling... new snapshot? 1.5.1 or 1.5.2 snapshot?
 
  please reply with repository URL where I can download the JAR. thanks.
 
 
  On Tue, Dec 11, 2012 at 4:17 AM, Romain Manni-Bucau
  rmannibu...@gmail.comwrote:
 
  updated trunk (tomee-catalina.jar only)
 
  if you want to give it a try tomorrow with the new snapshot.
 
  Romain Manni-Bucau
  Twitter: @rmannibucau
  Blog: http://rmannibucau.wordpress.com/
  LinkedIn: http://fr.linkedin.com/in/rmannibucau
  Github: https://github.com/rmannibucau
 
 
 
  2012/12/11 Romain Manni-Bucau rmannibu...@gmail.com:
   Think the session scoped bean (controller) is destroyed before the
  listener
   is called.
  
   So it depends why you need the controller in the listener. Replacing
 it
  by a
   not session scoped bean will work.
  
   Btw we need to have a look to it. Can you raise a jira please?
  
   Le 11 déc. 2012 06:03, Howard W. Smith, Jr. smithh032...@gmail.com
 a
   écrit :
  
   This exception occurs a different times throughout the day on
 production
   as
   well as test/development server. Is there anything I can do to
 prevent
  the
   exception (and I'm not asking to 'swallow' the exception).  Please
  advise.
   Thanks.
  
   Dec 10, 2012 9:03:14 PM org.apache.catalina.session.StandardSession
  expire
   SEVERE: Session event listener threw exception
   javax.enterprise.context.ContextNotActiveException: WebBeans context
  with
   scope type annotation @SessionScoped does not exist within current
  thread
   at
  
  
 
 org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:351)
at
  
  
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:143)
at
  
  
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:114)
at
  
  
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:108)
at
  
  
 
 jsf.users.pf_UsersController_$$_javassist_2.getUser(pf_UsersController_$$_javassist_2.java)
at
  
  
 
 pf.UserHttpSessionListener.sessionDestroyed(UserHttpSessionListener.java:40)
   at
  
  
 
 org.apache.catalina.session.StandardSession.expire(StandardSession.java:806)
at
  
  
 
 org.apache.catalina.session.StandardSession.isValid(StandardSession.java:658)
   at
  
  
 
 org.apache.catalina.session.ManagerBase.processExpires(ManagerBase.java:534)
at
  
  
 
 org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase.java:519)
   at
  
  
 
 org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1352)
at
  
  
 
 org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1530)
at
  
  
 
 org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540)
at
  
  
 
 org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540)
at
  
  
 
 org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1519)
at java.lang.Thread.run(Unknown Source)

Re: DB access is very slow

Well, my web app has performed very well with 32bit and 4GB RAM (Glassfish
and now via TomEE). I just find it strange that 'insert'
operations/transactions via @Stateless EJB triggered by @Schedule method on
the @Stateless EJB performs so very slow and locks the database (deadlock
situation) on my 32bit 4GB RAM production server, but similar
multiple-table update initiated by enduser performs 'very very fast' and
'no' deadlock...ever!!!

So, I'm thinking about redesigning my current implementation, the @Schedule
method on @Stateless to import some data (from customer-request emails),
and 'instead', present an option on the page (similar to Microsoft Outlook
and Outlook Express 'Send/Receive' option, and leave it up to the web app
enduser to take time out of his session to invoke the CDI @RequestScoped
bean to perform the multiple-table update, and then I think this way, there
will be no deadlock situation, since I never see deadlock
situation/exception while endusers are logged in completing all kinds of
database transactions 'concurrently'.

It makes me not trust @Stateless @Schedule (background) transactions, since
it completely locks up the database, and at same time, locks up the web app
real bad!  :(


On Wed, Dec 12, 2012 at 11:27 PM, knak55 naka...@xb4.so-net.ne.jp wrote:

 Thank you, smithh032772,

 The Linux machine where I plan to deploy my application does not have so
 much memory (4GB). But the DB size is very small for the present, maybe a
 few years. So I will go with 32bit JVM at first. When the DB becomes
 bigger,
 I will move the system to 64bit environment.




 --
 View this message in context:
 http://openejb.979440.n4.nabble.com/DB-access-is-very-slow-tp4659326p4659485.html
 Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: TomEE EjbTimerServiceImpl ejbTimeout exception while completing container transaction

okay, i changed the implementation and testing that now... waiting for it
to finish and see how it performs and if it completes... no exceptions.

the parent @Stateless EJB @Schedule calls @Stateless EJB now instead of CDI
@RequestScoped.

On Thu, Dec 13, 2012 at 1:28 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

Cdi has no tx so that's the ejb which manages it

If you want commit intervals either use another ejb or usertransaction
Le 13 déc. 2012 07:23, Howard W. Smith, Jr. smithh032...@gmail.com a
écrit :

I have the following implementation:

1. @Stateless EJB invoked by @Schedule getEmails() method
2. getEmails() will make a maximum of 2 calls to CDI @RequestScoped bean
to
do a multiple-table update
3. CDI @RequestScoped bean inserts data into multiple tables via multiple
@EJBs (per database table)
4. @Stateless EJB completes it's job after the 2nd call to CDI
@RequestScoped bean

Test results are as follows:

1. As you can see in the log below, the 2 calls to the CDI @RequestScoped
bean completed 'successfully', and the data 'should' have been inserted
into the database 'successfully'

2. BUT, the ejbTimer exception occurred, and the entire transaction
'rolled
by', which was initiated by @Stateless @EJB via @Schedule getEmails()

Please tell me why @Stateless EJB with @Schedule holds the entire
transaction, and why the rollback of @Stateless EJB @Schedule is causing
rollback of all transactions completed by the CDI @requestedscoped bean?
I
guess this is working as designed as per EJB spec. Right??? :(

INFO: EmailStatelessBean.processAirportShuttleRequest(): ADD Airport
Shuttle - Flight # 1 SUCCESSFULLY for 01/06/2013
Dec 12, 2012 6:33:47 PM pf.ApplicationScopeBean log
INFO: EmailStatelessBean.processAirportShuttleRequest(): ADD Airport
Shuttle - Flight # 2 SUCCESSFULLY for 01/18/2012
Dec 12, 2012 6:33:57 PM org.apache.openejb.core.timer.EjbTimerServiceImpl
ejbTimeout
WARNING: Exception occured while completing container transaction
javax.transaction.RollbackException: Unable to commit: transaction marked
for rollback
at

org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:272)
at

org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:252)
at

org.apache.openejb.core.timer.EjbTimerServiceImpl.ejbTimeout(EjbTimerServiceImpl.java:598)
at

org.apache.openejb.core.timer.EjbTimeoutJob.execute(EjbTimeoutJob.java:39)
at org.quartz.core.JobRunShell.run(JobRunShell.java:213)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.Exception: Transaction has timed out
at

org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:266)
... 7 more

Re: TomEE: StandardSession expire

smiling/laughing...i was wondering when that last # would be incremented. :)

i still saw 1.5.1 SNAPSHOT on/in that repository.

My app is running okay in production, so I guess I can wait for 1.5.2
SNAPSHOT, but I did download that catalina JAR... just not using it 'yet'.
:)



On Thu, Dec 13, 2012 at 1:29 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 1.5.2-SNAPSHOT should be here now ;)
 Le 13 déc. 2012 04:51, Howard W. Smith, Jr. smithh032...@gmail.com a
 écrit :

  Romain, I'm revisiting this email. I did briefly take a look at the
 folder
  ,but didn't really download the update...yet. I would assume
 1.5.1-SNAPSHOT
  is latest and greatest...more than 1.5.1 that was released some days ago.
  right?  :)
 
 
  On Tue, Dec 11, 2012 at 8:43 AM, Romain Manni-Bucau
  rmannibu...@gmail.comwrote:
 
  
  
 
 https://repository.apache.org/content/groups/public/org/apache/openejb/tomee-catalina/1.5.1-SNAPSHOT/
   tomorrow i guess
  
   will try to update snapshot version tomorrow morning
  
   Romain Manni-Bucau
   Twitter: @rmannibucau
   Blog: http://rmannibucau.wordpress.com/
   LinkedIn: http://fr.linkedin.com/in/rmannibucau
   Github: https://github.com/rmannibucau
  
  
  
   2012/12/11 Howard W. Smith, Jr. smithh032...@gmail.com:
Smiling... new snapshot? 1.5.1 or 1.5.2 snapshot?
   
please reply with repository URL where I can download the JAR.
 thanks.
   
   
On Tue, Dec 11, 2012 at 4:17 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
   
updated trunk (tomee-catalina.jar only)
   
if you want to give it a try tomorrow with the new snapshot.
   
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
   
   
   
2012/12/11 Romain Manni-Bucau rmannibu...@gmail.com:
 Think the session scoped bean (controller) is destroyed before the
listener
 is called.

 So it depends why you need the controller in the listener.
 Replacing
   it
by a
 not session scoped bean will work.

 Btw we need to have a look to it. Can you raise a jira please?

 Le 11 déc. 2012 06:03, Howard W. Smith, Jr. 
  smithh032...@gmail.com
   a
 écrit :

 This exception occurs a different times throughout the day on
   production
 as
 well as test/development server. Is there anything I can do to
   prevent
the
 exception (and I'm not asking to 'swallow' the exception).
  Please
advise.
 Thanks.

 Dec 10, 2012 9:03:14 PM
 org.apache.catalina.session.StandardSession
expire
 SEVERE: Session event listener threw exception
 javax.enterprise.context.ContextNotActiveException: WebBeans
  context
with
 scope type annotation @SessionScoped does not exist within
 current
thread
 at


   
  
 
 org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:351)
  at


   
  
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:143)
  at


   
  
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:114)
  at


   
  
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:108)
  at


   
  
 
 jsf.users.pf_UsersController_$$_javassist_2.getUser(pf_UsersController_$$_javassist_2.java)
  at


   
  
 
 pf.UserHttpSessionListener.sessionDestroyed(UserHttpSessionListener.java:40)
 at


   
  
 
 org.apache.catalina.session.StandardSession.expire(StandardSession.java:806)
  at


   
  
 
 org.apache.catalina.session.StandardSession.isValid(StandardSession.java:658)
 at


   
  
 
 org.apache.catalina.session.ManagerBase.processExpires(ManagerBase.java:534)
  at


   
  
 
 org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase.java:519)
 at


   
  
 
 org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1352)
  at


   
  
 
 org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1530)
  at


   
  
 
 org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540)
  at


   
  
 
 org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540)
  at


   
  
 
 org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1519)
  at java.lang.Thread.run(Unknown Source)

Re: TomEE: StandardSession expire

what's the URL?


On Thu, Dec 13, 2012 at 1:38 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 Dont think the fix is in 1.5.1-SNASHOT, use the 1.5.2 one please

Re: TomEE Plus comes bundled with APR?

Good, i'm glad to hear that. :)

On Thu, Dec 13, 2012 at 2:31 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 That's pure tomcat...but here far before tomcat 7.
 Le 13 déc. 2012 08:22, Howard W. Smith, Jr. smithh032...@gmail.com a
 écrit :

  I see the following in my log. I was reading up on this and wanted this,
  but did not want to go through the hassle of building it myself. Does the
  following come bundled with TomEE, or is it a Tomcat 7.0.32/33/44
 'feature'
  ?
 
  Dec 12, 2012 5:13:18 PM org.apache.catalina.core.AprLifecycleListener
 init
  INFO: Loaded APR based Apache Tomcat Native library 1.1.24 using APR
  version 1.4.6.
  Dec 12, 2012 5:13:18 PM org.apache.catalina.core.AprLifecycleListener
 init
  INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters
  [false], random [true].
  Dec 12, 2012 5:13:20 PM org.apache.catalina.core.AprLifecycleListener
  initializeSSL
  INFO: OpenSSL successfully initialized (OpenSSL 1.0.1c 10 May 2012)

Re: TomEE EjbTimerServiceImpl ejbTimeout exception while completing container transaction

In case you're wondering, and David Blevins, if you're tuned in on this...
these test results are being recorded on the JIRA I opened earlier.  :)


https://issues.apache.org/jira/browse/OPENEJB-1968



On Thu, Dec 13, 2012 at 2:38 AM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:

 Okay, I tried the following,

 @TransactionAttribute(value = TransactionAttributeType.NEVER)

 but that resulted in the same exception. Now, I'm testing the following:

 @TransactionAttribute(value = TransactionAttributeType.REQUIRES_NEW)

Re: DB access is very slow

knak55,

First of all I find your emails interesting.

After you saw these lines in eclipse console, did you see any improvement
in dba access? If OpenJPA (automatically) weaves entities, then I think
that is really nice, but I could not use OpenJPA (experienced some errors
or app wasn't working right), but Romain advised me to weave my entities,
and I still need to do that.

I am not familiar with the Enhancement feature of the OpenJPA, but as
I was able
to see the following lines in the eclipse console, I think the
Enhancement must have been weaved to Entity classes.
default  INFO   [main] openjpa.Tool - Enhancer running on type class A.
default  INFO   [main] openjpa.Tool - Enhancer running on type class B.
default  INFO   [main] openjpa.Tool - Enhancer running on type class C.
default  INFO   [main] openjpa.Tool - Enhancer running on type class D.

I was a Glassfish3.1.2.2 user as well, and just recently migrated to TomEE
1.5.1. Today, I still use eclipselink as my JPA provider (see my
persistence.xml below), but I had to do a few things in configuring my app
and then I had to tune my JPA queries (as well as my xhtml pages) for TomEE.

I see most of your concern is the performance of database updates (more
than performance of your queries). I think Romain recommended statement
caching; you can see that I did that in my persistence.xml below, but I
want to 'testify' and tell you that all day yesterday (and the day before),
I was working on this new @Stateless bean that has ONE entitymanager; for
now, the job of this @Stateless bean is to check formmail results
(containing data wrapped in JSON, so I could use Gson to get the data into
a POJO), and then update at least 6 to 8 different tables. On my
test/development server (Windows 2008 Server 64bit 16GB RAM), the entire
'database update' code is averaging 1 to 2 seconds in performance.
Retrieving the email from EMAIL server (via javamail) takes the longest
time for the @Stateless bean, but the database access is so very fast!

TomEE users/committers have seen me quite active in/on this user list,
because TomEE committers helped me migrate from
Glassfish3.1.2.2/JSF-managed-beans to TomEE/CDI-managed-beans (and yes,
still using EclipseLink 2.3.2 JAR, placed in tomee/lib folder). In the
beginning, my app was running s much faster on Glassfish, but now my
app runs (much) faster on TomEE, after putting some work in optimizing my
app 'for' TomEE container. :)

See below. Please note that I am using NetBeans 7.2 (instead of eclipse),
EclipseLink 2.3.2 (JAR dropped in tomee/lib folder), and recently upgraded
to Apache Derby 10.9.x (dropped JAR in tomee/lib folder).  Glassfish3.1.2.2
comes bundled with EclipseLink 2.3.2 and Apache Derby 10.8.6.x (I think
that's the version).


*src/conf/persistence.xml*

?xml version=1.0 encoding=UTF-8?
persistence version=2.0
 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
http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd;
persistence-unit name=mcmsPU transaction-type=JTA
providerorg.eclipse.persistence.jpa.PersistenceProvider/provider
jta-data-sourcejdbc/mcmsJta/jta-data-source
non-jta-data-sourcejdbc/mcmsNonJta/non-jta-data-source
exclude-unlisted-classesfalse/exclude-unlisted-classes
properties
property name=eclipselink.target-database

value=org.eclipse.persistence.platform.database.DerbyPlatform/
property name=eclipselink.jdbc.cache-statements value=true /
property name=eclipselink.jdbc.cache-statements.size value=100
/
property name=eclipselink.logging.parameters value=false /
/properties
/persistence-unit
/persistence


*META-INF/context.xml* (do not configure JDBC resources here; Romain
advised me of that some weeks ago)

?xml version=1.0 encoding=UTF-8?
Context antiJARLocking=true path=/


*{tomee-install-folder}/conf/tomee.xml*

Resource id=jdbc/mcmsJta type=javax.sql.DataSource
  JdbcDriver org.apache.derby.jdbc.EmbeddedDriver
  JdbcUrl jdbc:derby:C:/javadb/databases/mcmsdev;create=true
  UserName ***
  Password ***
  JtaManaged true
  jmxEnabled true
  LogSql false
  InitialSize 10
  MaxActive 100
  MaxIdle 30
  MaxWait 1
  removeAbandoned true
  removeAbandonedTimeout 18000
/Resource

Resource id=jdbc/mcmsNonJta type=javax.sql.DataSource
  JdbcDriver org.apache.derby.jdbc.EmbeddedDriver
  JdbcUrl jdbc:derby:C:/javadb/databases/mcmsdev;create=true
  UserName ***
  Password ***
  JtaManaged false
  jmxEnabled false
  LogSql false
  InitialSize 10
  MaxActive 100
  MaxIdle 30
  MaxWait 1
  removeAbandoned true
  removeAbandonedTimeout 18000
/Resource



On Mon, Dec 10, 2012 at 8:59 PM, knak55 naka...@xb4.so-net.ne.jp wrote:

 I am not familiar with the Enhancement feature of the OpenJPA, but as I was
 able to see the following

Re: WebappClassLoader checkThreadLocalMapForLeaks finding leaks related to Google Apps API

I was reading the following,

http://stackoverflow.com/questions/4327832/tomcat-webapp-error-application-started-thread-awt-windows-but-has-failed-to

and the answer below,

http://stackoverflow.com/a/4329717/933054

struck a bell. On the production server, I am running JMX, so I can login
at anytime to production server and open Java Visual VM to check
performance of the app. Is it best to run JMX in production (all the time)?
any performance setbacks? I guess this may be the cause of the first error
that I'm seeing.

I'll keep researching for the other exceptions. I do want to figure out how
to stop/disconnect my Google Calendar API connection. :)



On Tue, Dec 11, 2012 at 12:00 AM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:

 appears to have started a thread named [AWT-Windows] but has failed to
 stop it. This is very likely to create a memory leak.

Re: WebappClassLoader checkThreadLocalMapForLeaks finding leaks related to Google Apps API

Sorry, the answer below, struck a bell with me. :)

http://stackoverflow.com/a/10719485/933054



On Tue, Dec 11, 2012 at 6:22 AM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:

 I was reading the following,


 http://stackoverflow.com/questions/4327832/tomcat-webapp-error-application-started-thread-awt-windows-but-has-failed-to

 and the answer below,

 http://stackoverflow.com/a/4329717/933054

 struck a bell. On the production server, I am running JMX, so I can login
 at anytime to production server and open Java Visual VM to check
 performance of the app. Is it best to run JMX in production (all the time)?
 any performance setbacks? I guess this may be the cause of the first error
 that I'm seeing.

 I'll keep researching for the other exceptions. I do want to figure out
 how to stop/disconnect my Google Calendar API connection. :)



 On Tue, Dec 11, 2012 at 12:00 AM, Howard W. Smith, Jr. 
 smithh032...@gmail.com wrote:

 appears to have started a thread named [AWT-Windows] but has failed to
 stop it. This is very likely to create a memory leak.

Re: WebappClassLoader checkThreadLocalMapForLeaks finding leaks related to Google Apps API

Okay, found the following:

https://groups.google.com/forum/?fromgroups=#!topic/google-documents-list-api/b9MsCMdFtxc

but no solution there. will keep searching. :)

Re: DB access is very slow

Really

How did I miss that when I was reading and researching performance tuning?
  :)

Hmmm, I think I already set a value related to statement cache i my
persistence.xml. Will confirm and add this as advised. thanks!



the setting jdbcInterceptors is something important too:

 Resource  
   ...
   jdbcInterceptors=StatementCache(max=128)
   ...
 /Resource

Re: TomEE: StandardSession expire

Just now responding to this email. did you generate the JIRA? I can do it,
if you like.


On Tue, Dec 11, 2012 at 1:58 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 Think the session scoped bean (controller) is destroyed before the listener
 is called.

 So it depends why you need the controller in the listener. Replacing it by
 a not session scoped bean will work.

 Btw we need to have a look to it. Can you raise a jira please?
 Le 11 déc. 2012 06:03, Howard W. Smith, Jr. smithh032...@gmail.com a
 écrit :

  This exception occurs a different times throughout the day on production
 as
  well as test/development server. Is there anything I can do to prevent
 the
  exception (and I'm not asking to 'swallow' the exception).  Please
 advise.
  Thanks.
 
  Dec 10, 2012 9:03:14 PM org.apache.catalina.session.StandardSession
 expire
  SEVERE: Session event listener threw exception
  javax.enterprise.context.ContextNotActiveException: WebBeans context with
  scope type annotation @SessionScoped does not exist within current thread
  at
 
 
 org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:351)
   at
 
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:143)
   at
 
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:114)
   at
 
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:108)
   at
 
 
 jsf.users.pf_UsersController_$$_javassist_2.getUser(pf_UsersController_$$_javassist_2.java)
   at
 
 
 pf.UserHttpSessionListener.sessionDestroyed(UserHttpSessionListener.java:40)
  at
 
 
 org.apache.catalina.session.StandardSession.expire(StandardSession.java:806)
   at
 
 
 org.apache.catalina.session.StandardSession.isValid(StandardSession.java:658)
  at
 
 
 org.apache.catalina.session.ManagerBase.processExpires(ManagerBase.java:534)
   at
 
 
 org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase.java:519)
  at
 
 
 org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1352)
   at
 
 
 org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1530)
   at
 
 
 org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540)
   at
 
 
 org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540)
   at
 
 
 org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1519)
   at java.lang.Thread.run(Unknown Source)

Re: TomEE: StandardSession expire

Smiling... new snapshot? 1.5.1 or 1.5.2 snapshot?

please reply with repository URL where I can download the JAR. thanks.


On Tue, Dec 11, 2012 at 4:17 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 updated trunk (tomee-catalina.jar only)

 if you want to give it a try tomorrow with the new snapshot.

 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau



 2012/12/11 Romain Manni-Bucau rmannibu...@gmail.com:
  Think the session scoped bean (controller) is destroyed before the
 listener
  is called.
 
  So it depends why you need the controller in the listener. Replacing it
 by a
  not session scoped bean will work.
 
  Btw we need to have a look to it. Can you raise a jira please?
 
  Le 11 déc. 2012 06:03, Howard W. Smith, Jr. smithh032...@gmail.com a
  écrit :
 
  This exception occurs a different times throughout the day on production
  as
  well as test/development server. Is there anything I can do to prevent
 the
  exception (and I'm not asking to 'swallow' the exception).  Please
 advise.
  Thanks.
 
  Dec 10, 2012 9:03:14 PM org.apache.catalina.session.StandardSession
 expire
  SEVERE: Session event listener threw exception
  javax.enterprise.context.ContextNotActiveException: WebBeans context
 with
  scope type annotation @SessionScoped does not exist within current
 thread
  at
 
 
 org.apache.webbeans.container.BeanManagerImpl.getContext(BeanManagerImpl.java:351)
   at
 
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.getContextualInstance(NormalScopedBeanInterceptorHandler.java:143)
   at
 
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:114)
   at
 
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:108)
   at
 
 
 jsf.users.pf_UsersController_$$_javassist_2.getUser(pf_UsersController_$$_javassist_2.java)
   at
 
 
 pf.UserHttpSessionListener.sessionDestroyed(UserHttpSessionListener.java:40)
  at
 
 
 org.apache.catalina.session.StandardSession.expire(StandardSession.java:806)
   at
 
 
 org.apache.catalina.session.StandardSession.isValid(StandardSession.java:658)
  at
 
 
 org.apache.catalina.session.ManagerBase.processExpires(ManagerBase.java:534)
   at
 
 
 org.apache.catalina.session.ManagerBase.backgroundProcess(ManagerBase.java:519)
  at
 
 
 org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1352)
   at
 
 
 org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1530)
   at
 
 
 org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540)
   at
 
 
 org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1540)
   at
 
 
 org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1519)
   at java.lang.Thread.run(Unknown Source)

Re: DB access is very slow

Interesting and good to know. So, are you telling me that my
persistence.xml configuration is useless/invalid?

I seem to recall, when I first installed tomEE, deployed webapp, and first
tested on production server...that my config in persistence.xml was
wrong/incorrect, caused errors, changed it, and then it started working
without errors.

So, I need to add the following in tomee.xml resource?

jdbcInterceptors=StatementCache(max=128)



On Tue, Dec 11, 2012 at 7:08 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 you know eclipselinks doesn't manage your datasource (since that's
 openejb/tomee which provides it) so all the connection config of
 eclipselinks is useless normally (difference between JSE and JavaEE)

 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau



 2012/12/11 Howard W. Smith, Jr. smithh032...@gmail.com:
  Really
 
  How did I miss that when I was reading and researching performance
 tuning?
:)
 
  Hmmm, I think I already set a value related to statement cache i my
  persistence.xml. Will confirm and add this as advised. thanks!
 
 
 
  the setting jdbcInterceptors is something important too:
 
  Resource  
...
jdbcInterceptors=StatementCache(max=128)
...
  /Resource

Re: Why are Tomcat's threads more costly than background threads?

Wow, i'm reading this now, because I just experienced an issue on my
production server that is TomEE 1.5.1 (Tomcat 7.0.34), and the whole server
locked up all because I had a @Stateless EJB inserting data into multiple
tables in the database, because @Schedule timed event triggered the EJB to
check email server for incoming (customer) requests, and it literally took
down the server. I was on it as well as few other endusers, and then one
enduser captured a LOCK error and the screen capture (photo/pic) had an
error message that showed a long SQL query with datatable table and column
names t0..., t0...

What I primarily saw was the word 'lock' at the top of that, and we
definitely experienced a lockup. I'm about to check server logs and read
this article.

The @Stateless EJB had one transaction (entitymanager / persistence
context) that made database updates to multiple tables in the database. I
am only using entitymanager.persist(), flush(), and few lookups/queries
during that process.

But other endusers (including myself) could not do simple queries against
the database at all. Most of my queries contain query hints (readonly,
statement caching).

Also, I never seen this behavior at all, but this is first time I added
@Stateless EJB along with @Schedule that does database updates 'during
business hours'. I thought this would be a no-brainer, but I guess it's
not. Again, the server is TomEE 1.5.1 (tomcat 7.0.34).

Any advise, then please let me know. Onto reading this post now. Thanks. :)



On Tue, Dec 11, 2012 at 10:49 AM, Julien Martin bal...@gmail.com wrote:

 Thank you very much for this exhaustive reply Christopher.

 2012/12/11 Christopher Schultz ch...@christopherschultz.net

  -BEGIN PGP SIGNED MESSAGE-
  Hash: SHA256
 
  Julien,
 
  Warning: this is long. Like, André-or-Mark-Eggers long.
 
  On 12/11/12 7:30 AM, Julien Martin wrote:
   I am in reference to the following blog entry: Blog
   entry
 
 http://blog.springsource.org/2012/05/06/spring-mvc-3-2-preview-introducing-servlet-3-async-support
  
  
  
  about Spring MVC 3.2 asynchronous support.
  
   I understand Tomcat uses a thread pool in order to serve http/web
   requests. Furthermore, the above article seems to indicate that
   Spring MVC asynchronous support relieves Tomcat's thread pool and
   allows for better concurrency in the webapp by using background
   threads for heavy-lift operations.
 
  I believe you are misinterpreting what that post has to say. It's not
  that a background thread itself is more efficient, it's that
  processing that does not need to communicate with the client can be
  de-coupled from the request-processing thread-pool that exists for
  that purpose.
 
  An example - right from the blog post - will make much more sense than
  what I wrote above. Let's take the example of sending an email
  message. First, some assumptions:
 
  1. Sending an email takes a long time (say, 5 seconds)
  2. The client does not need confirmation that the email has been sent
 
  If your were to write a classic servlet, it would look something
  like this:
 
  doPost() {
validateOrder();
 
queueOrder();
 
sendOrderConfirmation(); // This is the email
 
response.sendRedirect(/order_complete.jsp);
  }
 
  Let's say that validation takes 500ms, queuing takes 800ms, and
  emailing (as above) takes 5000ms. That means that the request, from
  the client perspective, takes 6300ms (6.3 sec). That's a noticeable
 delay.
 
  Also, during that whole time, a single request-processing thread (from
  Tomcat's thread pool) is tied-up, meaning that no other requests can
  be processed by that same thread.
 
  If you have a thread pool of size=1 (foolish, yet instructive), it
  means you can only process a single transaction every 6.3 seconds.
 
  Lets re-write the servlet with a background thread -- no
  asynchronous stuff from the servlet API, but just with a simple
  background thread:
 
  doPost() {
validateOrder();
 
queueOrder();
 
(new Thread() {
  public void run() {
sendOrderConfirmation();
  }
}).start();
 
response.sendRedirect(order_complete.jsp);
  }
 
  So, now the email is being sent by a background thread: the response
  returns to the client after 1.3 seconds which is a significant
  improvement. Now, we can handle a request once every 1.3 seconds with
  a request-processing thread-pool of size=1.
 
  Note that a better implementation of the above would be to use a
  thread pool for this sort of thing instead of creating a new thread
  for every request. This is what Spring provides. It's not that Spring
  can do a better job of thread management, it's that Tomcat's thread
  pool is special: it's the only one that can actually dispatch client
  requests. Off-loading onto another thread pool for background
  processing means more client requests can be handled with a smaller
  (or same-sized) pool.
 
  Looking above, you might notice that the validateOrder() and

Re: Why are Tomcat's threads more costly than background threads?

)
at org.apache.derby.impl.store.access.heap.HeapScan.fetchNextGroup(Unknown
Source)
at
org.apache.derby.impl.sql.execute.BulkTableScanResultSet.reloadArray(Unknown
Source)
at
org.apache.derby.impl.sql.execute.BulkTableScanResultSet.getNextRowCore(Unknown
Source)
at
org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(Unknown
Source)
at
org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(Unknown
Source)
at
org.apache.derby.impl.sql.execute.SortResultSet.getRowFromResultSet(Unknown
Source)
at org.apache.derby.impl.sql.execute.SortResultSet.getNextRowFromRS(Unknown
Source)
at org.apache.derby.impl.sql.execute.SortResultSet.loadSorter(Unknown
Source)
at org.apache.derby.impl.sql.execute.SortResultSet.openCore(Unknown Source)
at org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(Unknown
Source)
at org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown
Source)
at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown
Source)
... 122 more

On Tue, Dec 11, 2012 at 2:10 PM, David Blevins david.blev...@gmail.comwrote:

First a tip. Next time the server locks up, immediately do a thread dump.

- http://docs.oracle.com/javase/1.5.0/docs/tooldocs/share/jstack.html

Second, it sounds like this locking issue isn't a threading issue, but a
transaction issue. Accessing all your databases in the same JTA
transaction is not advised unless you're doing something like withdrawing
$100 from database A and putting it in database B. This kind of work is
fine to do, but you want it to be as focused and razor sharp as possible --
only do it with the understanding you're locking the referenced tables/rows
on both databases while that transaction is open. This can be tragic if
pessimistic locking is used, less of a problem with more optimistic locking
options. These options are all database specific. Again, this kind of
thing is fine if the task requires it -- there's no other reliable way to
solve the transfer data from one database to the next problem other then
to enroll them both in a JTA transaction -- but such a thing must be done
with full understanding of the cost.

What kind of work are you attempting to do with this job that accesses all
your databases?

-David

On Dec 11, 2012, at 8:40 AM, Howard W. Smith, Jr.
smithh032...@gmail.com wrote:

Okay, TomEE committers/users, I need your help/advice on this one. Please
read what I wrote in the email below.

I am considering to use the @Asynchronous on one of the methods on
@Stateless EJB to complete this task, but I think I still may need to do
something on the Persistence end to avoid locking up the entire app,
database, etc...

I guess this my first time experiencing a DEADLOCK, but I could be
wrong. :)

On Tue, Dec 11, 2012 at 11:01 AM, Howard W. Smith, Jr.
smithh032...@gmail.com wrote:

Wow, i'm reading this now, because I just experienced an issue on my
production server that is TomEE 1.5.1 (Tomcat 7.0.34), and the whole
server
locked up all because I had a @Stateless EJB inserting data into
multiple
tables in the database, because @Schedule timed event triggered the EJB
to
check email server for incoming (customer) requests, and it literally
took
down the server. I was on it as well as few other endusers, and then one
enduser captured a LOCK error and the screen capture (photo/pic) had an
error message that showed a long SQL query with datatable table and
column
names t0..., t0...

What I primarily saw was the word 'lock' at the top of that, and we
definitely experienced a lockup. I'm about to check server logs and read
this article.

The @Stateless EJB had one transaction (entitymanager / persistence
context) that made database updates to multiple tables in the database.
I
am only using entitymanager.persist(), flush(), and few lookups/queries
during that process.

But other endusers (including myself) could not do simple queries
against
the database at all. Most of my queries contain query hints (readonly,
statement caching).

Also, I never seen this behavior at all, but this is first time I added
@Stateless EJB along with @Schedule that does database updates 'during
business hours'. I thought this would be a no-brainer, but I guess it's
not. Again, the server is TomEE 1.5.1 (tomcat 7.0.34).

Any advise, then please let me know. Onto reading this post now.
Thanks. :)

On Tue, Dec 11, 2012 at 10:49 AM, Julien Martin bal...@gmail.com
wrote:

Thank you very much for this exhaustive reply Christopher.

2012/12/11 Christopher Schultz ch...@christopherschultz.net

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Julien,

Warning: this is long. Like, André-or-Mark-Eggers long.

On 12/11/12 7:30 AM, Julien Martin wrote:
I am in reference to the following blog entry: Blog
entry

http://blog.springsource.org/2012/05/06/spring-mvc-3-2-preview-introducing-servlet-3-async

Re: Why are Tomcat's threads more costly than background threads?

I think I'm going to avoid the single transaction (via single @Stateless
EJB) approach, and use other @Stateless EJBs to make the database table
updates. This approach works everywhere else throughout the web app.

I'll just keep the @Stateless EJB for the purpose of being invoked by
@Schedule, and it will be the 'driver', and call the
already-defined-and-already-used other @Stateless EJBs that contain
Persistent context and entity manager to update tables, so this clearly
will be a multiple transaction commit, which should 'not' lock any tables.
:)



On Tue, Dec 11, 2012 at 3:21 PM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:

 Prior to adding this @Stateless EJB (that's invoked via @Schedule every 10
 minutes), my JSF web app has been running 100% okay without any deadlocks
 or anything else like that.

 So, is it okay if I just add optimistic locking, em.lock(entity,
 LockType.Optimistic) before any/all em.persist(...) that I have in the
 @Stateless EJB?

 JSF web app is working okay, because the JSF components call multiple
 @Stateless EJB that usually do any of the following, SELECT, UPDATE,
 DELETE,  on one table at time.



 On Tue, Dec 11, 2012 at 2:35 PM, Howard W. Smith, Jr. 
 smithh032...@gmail.com wrote:

 You're absolutely right, David. Thanks for the response.

 It is a transaction issue and the @Stateless EJB is holding a transaction
 open and writing into 6 to 10 tables in a single database, which is also
 the database accessed by JSF components (by endusers). The @Stateless EJB
 is on a timer ( @Schedule), checks email server for incoming requests from
 customers, and takes that data and inserts it into database, so endusers
 don't have to manually enter the data (that they receive from these
 formmail results).

 Below is the exception that I saw maybe an hour or two ago, and I
 confirmed that it's a locking/transaction issue, and from the stacktrace,
 it seems as though the JSF components cannot access the table, that is
 evidently locked by @Stateless EJB. The @Stateless @EJB updated all tables
 on my faster/dev/test server on average of 1 to 2 seconds, and/so in my
 opinion, the data is not that much at all, maybe a few kbytes of data being
 inserted into the database. Anyway, I've been reading up on pessismistic
 and optimistic locking, and that's where I was in my reading before I
 noticed your email. I really don't know what the database or JPA is
 defaulting to, because honestly, I have no code that specifies any locks.
 Recently, I only added query hint (readonly) to JPA queries. Personally, I
 feel as though I can use 'no locking' for these inserts, since this is
 brand new data, but the JSF components may be locking the entites/tables
 during simple queries (SELECT statements).  Feel free to change this
 email/topic to a more suitable topic/subject, if necessary. :)

Re: DB access is very slow

H... Glassfish is bundled with EclipseLink. Why did you go with
PostgreSQL instead of EclipseLink?

I was a Glassfish3.1.2.2 user, and yes, I know that Glassfish 3.1.2.2
database operations are very very fast. I don't know exactly what Glassfish
does 'for you' (automatically), but I really think Glassfish optimizes
EclipseLink for you straight-out-the-box. Remember, Glassfish and
EclipseLink are (somewhat) under the Oracle umbrella. EclipseLink is now
called TopLink (and shipped with Glassfish enterprise version, I think).
So, Glassfish folks know how to optimize EclipseLink for you.

Like I told you in my previous email/response, I had to tune EclipseLink
(persistence.xml), my JPA queries, and I already tuned my database via
indexes and unique primary key columns (that are Integer's; I didn't have
to change that though, i went with Integer primary key columns when I
developed the database...'before' I started coding the java apps).

Per my experience, I 'had to' optimize my app for TomEE, since TomEE does
'not' optimize Eclipselink, automatically. You're responsible for all that.
:)


On Tue, Dec 11, 2012 at 8:05 PM, knak55 naka...@xb4.so-net.ne.jp wrote:

 Thank you, Romain and smithh032772,

 Based on your suggestions, I changed the Resource configuration in the
 tomee.xml like the following.
 Resource id=jdbc/PostgreSqlDS type=DataSource
 #  PostgreSQL example
 #
 #  This connector will not work until you download the driver at:
 #  http://jdbc.postgresql.org/download.html
 JdbcDriver   org.postgresql.Driver
 JdbcUrl  jdbc:postgresql://localhost/glassfish
 UserName 
 Password ***
 JtaManaged true
 jmxEnabled true
 LogSql false
 InitialSize 10
 MaxActive 100
 MaxIdle 30
 MaxWait 1
 removeAbandoned true
 removeAbandonedTimeout 18000
 jdbcInterceptors=StatementCache(max=128)
 /Resource

 I added the lines from jmxEnabled to jdbcInterceptors.
 And I restarted the TomEE. But the performance does not change.

 I am sorry that I do not know how to check the Resource setting through
 jmx. I checked the bundled tomee application, but there does not seem to be
 the menu to check the parameters of the Resource.

 After enhancing the OpenJPA, I do not get any improvement in the DB access
 performance. Incidentally I use Build Time Enhancement with Maven for the
 Enhancement. The Enhancement seemed to be weaved, but the eclipse says
 Plugin execution not covered by lifecycle configuration:
 org.apache.openjpa:openjpa-maven-plugin:2.3.0- SNAPSHOT:enhance (execution:
 enhancer, phase: process-classes) in the editor window. I do not know why
 the eclipse says such a thing.

 If there is anything else I can do, please let me know.



 --
 View this message in context:
 http://openejb.979440.n4.nabble.com/DB-access-is-very-slow-tp4659326p4659441.html
 Sent from the OpenEJB User mailing list archive at Nabble.com.

Re: Why are Tomcat's threads more costly than background threads?

Done. testing now and watching JVM. I need to read that article you shared,
so i can learn a bit about heap dump. I see the heap dump button there, but
never used it 'yet'. :)

On Tue, Dec 11, 2012 at 3:53 PM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:

 I think I'm going to avoid the single transaction (via single @Stateless
 EJB) approach, and use other @Stateless EJBs to make the database table
 updates. This approach works everywhere else throughout the web app.

 I'll just keep the @Stateless EJB for the purpose of being invoked by
 @Schedule, and it will be the 'driver', and call the
 already-defined-and-already-used other @Stateless EJBs that contain
 Persistent context and entity manager to update tables, so this clearly
 will be a multiple transaction commit, which should 'not' lock any tables.
 :)



 On Tue, Dec 11, 2012 at 3:21 PM, Howard W. Smith, Jr. 
 smithh032...@gmail.com wrote:

 Prior to adding this @Stateless EJB (that's invoked via @Schedule every
 10 minutes), my JSF web app has been running 100% okay without any
 deadlocks or anything else like that.

 So, is it okay if I just add optimistic locking, em.lock(entity,
 LockType.Optimistic) before any/all em.persist(...) that I have in the
 @Stateless EJB?

 JSF web app is working okay, because the JSF components call multiple
 @Stateless EJB that usually do any of the following, SELECT, UPDATE,
 DELETE,  on one table at time.



 On Tue, Dec 11, 2012 at 2:35 PM, Howard W. Smith, Jr. 
 smithh032...@gmail.com wrote:

 You're absolutely right, David. Thanks for the response.

 It is a transaction issue and the @Stateless EJB is holding a
 transaction open and writing into 6 to 10 tables in a single database,
 which is also the database accessed by JSF components (by endusers). The
 @Stateless EJB is on a timer ( @Schedule), checks email server for incoming
 requests from customers, and takes that data and inserts it into database,
 so endusers don't have to manually enter the data (that they receive from
 these formmail results).

 Below is the exception that I saw maybe an hour or two ago, and I
 confirmed that it's a locking/transaction issue, and from the stacktrace,
 it seems as though the JSF components cannot access the table, that is
 evidently locked by @Stateless EJB. The @Stateless @EJB updated all tables
 on my faster/dev/test server on average of 1 to 2 seconds, and/so in my
 opinion, the data is not that much at all, maybe a few kbytes of data being
 inserted into the database. Anyway, I've been reading up on pessismistic
 and optimistic locking, and that's where I was in my reading before I
 noticed your email. I really don't know what the database or JPA is
 defaulting to, because honestly, I have no code that specifies any locks.
 Recently, I only added query hint (readonly) to JPA queries. Personally, I
 feel as though I can use 'no locking' for these inserts, since this is
 brand new data, but the JSF components may be locking the entites/tables
 during simple queries (SELECT statements).  Feel free to change this
 email/topic to a more suitable topic/subject, if necessary. :)

Re: Why are Tomcat's threads more costly than background threads?

Shaking my head... test results were not good at all.

1. @StatelessEJB EmailStatelessBean has @Schedule getEmails()
2. @EmailStatelessBean has multiple @EJB references to @Stateless
(sessionfacade) classes that are the DAO classes
3. EmailStatelessBean gets invoked when triggered by @Schedule
4. EmailStatelessBean execution locks the tables, still, and locks up the
entire app, and seems to take longer...since endusers (myself) are making
requests against database (and web app).
5. Last but not least, EmailStatelessBean failed to commit the changes;
transaction rolled back for EmailStatelessBean as well as enduser requests.

So, my workaround options include the following:

1. EmailStatelessBean, when invoked by @Schedule method, will check the CDI
@ApplicationScoped bean (ApplicationScopeBean), and see if any endusers are
logged in; i developed a sessionInfo class that is updated everytime
enduser does a HTTP request; if any endusers are logged in, then I can use
Atmosphere (PrimeFaces Push) to push a message to the endusers, notifying
them to 'please logout, as there are customer requests pending that need to
be retrieved and inserted into the web app's database', and
EmailStatelessBean will 'return' (or exit) and not perform the operation.
This way, everytime @Schedule invokes the bean method, it will continue to
check for an available time to perform the
get-emails-and-insert-into-database operation. Also, I'll set when
EmailStatelessBean begins the operation, then I'll set flag on
@ApplicationScoped bean (insertingCustomerRequestsIntoDatabase = true);
this flag will be checked when endusers attempt to login web app, and
FacesMessage will be displayed, Please login a few minutes later as system
is inserting customer requests into database.

2. Another option would be to send a message to all clients via Atmosphere
(PrimeFaces Push), and the UI will be locked immediately, and user will be
required to wait.

Honestly, I don't like either of these approaches, but I think the endusers
will accept the 1st option (above). If I go with 1st approach, then I may
revert back to single transaction, which will complete the entire operation
much faster than multiple transactions (via multiple EJB DAO classes).

As you can see, I don't have enough experience locking database for such a
batch operation as this. I know the endusers want the customer requests to
show up into the database 'immediately', and they want to know when it
happens. Right now, this is my only option until I redesign the business
website to interface directly with the web app. right now, the web app is
'only' used by 'personnel' (the owners of the business...which is my
family). hahaha :)

They love the app (honestly, they liked the speed and reliability of the
web app when it was on Glassfish), but I'm doing all i can to win them over
with TomEE. :)

Your thoughts, please.

Thanks,
Howard



On Tue, Dec 11, 2012 at 9:23 PM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:

 Done. testing now and watching JVM. I need to read that article you
 shared, so i can learn a bit about heap dump. I see the heap dump button
 there, but never used it 'yet'. :)


 On Tue, Dec 11, 2012 at 3:53 PM, Howard W. Smith, Jr. 
 smithh032...@gmail.com wrote:

 I think I'm going to avoid the single transaction (via single @Stateless
 EJB) approach, and use other @Stateless EJBs to make the database table
 updates. This approach works everywhere else throughout the web app.

 I'll just keep the @Stateless EJB for the purpose of being invoked by
 @Schedule, and it will be the 'driver', and call the
 already-defined-and-already-used other @Stateless EJBs that contain
 Persistent context and entity manager to update tables, so this clearly
 will be a multiple transaction commit, which should 'not' lock any tables.
 :)



 On Tue, Dec 11, 2012 at 3:21 PM, Howard W. Smith, Jr. 
 smithh032...@gmail.com wrote:

 Prior to adding this @Stateless EJB (that's invoked via @Schedule every
 10 minutes), my JSF web app has been running 100% okay without any
 deadlocks or anything else like that.

 So, is it okay if I just add optimistic locking, em.lock(entity,
 LockType.Optimistic) before any/all em.persist(...) that I have in the
 @Stateless EJB?

 JSF web app is working okay, because the JSF components call multiple
 @Stateless EJB that usually do any of the following, SELECT, UPDATE,
 DELETE,  on one table at time.



 On Tue, Dec 11, 2012 at 2:35 PM, Howard W. Smith, Jr. 
 smithh032...@gmail.com wrote:

 You're absolutely right, David. Thanks for the response.

 It is a transaction issue and the @Stateless EJB is holding a
 transaction open and writing into 6 to 10 tables in a single database,
 which is also the database accessed by JSF components (by endusers). The
 @Stateless EJB is on a timer ( @Schedule), checks email server for incoming
 requests from customers, and takes that data and inserts it into database,
 so endusers don't have to manually enter the data

Re: Why are Tomcat's threads more costly than background threads?

Also, are there any issues that I need to be made aware of...if @Stateless
EJB invokes a method on CDI @ApplicationScoped bean... @Stateless EJB
injects the CDI @ApplicationScoped bean via @Inject.

Is this a good practice or not? I think I read in Java EE 6 tutorial that
EJB timers cannot be used on stateful session beans, so I would assume it's
not an option to add @Schedule to method on the CDI @ApplicationScoped bean.


On Tue, Dec 11, 2012 at 10:10 PM, Howard W. Smith, Jr. 
smithh032...@gmail.com wrote:

 Shaking my head... test results were not good at all.

 1. @StatelessEJB EmailStatelessBean has @Schedule getEmails()
 2. @EmailStatelessBean has multiple @EJB references to @Stateless
 (sessionfacade) classes that are the DAO classes
 3. EmailStatelessBean gets invoked when triggered by @Schedule
 4. EmailStatelessBean execution locks the tables, still, and locks up the
 entire app, and seems to take longer...since endusers (myself) are making
 requests against database (and web app).
 5. Last but not least, EmailStatelessBean failed to commit the changes;
 transaction rolled back for EmailStatelessBean as well as enduser requests.

 So, my workaround options include the following:

 1. EmailStatelessBean, when invoked by @Schedule method, will check the
 CDI @ApplicationScoped bean (ApplicationScopeBean), and see if any endusers
 are logged in; i developed a sessionInfo class that is updated everytime
 enduser does a HTTP request; if any endusers are logged in, then I can use
 Atmosphere (PrimeFaces Push) to push a message to the endusers, notifying
 them to 'please logout, as there are customer requests pending that need to
 be retrieved and inserted into the web app's database', and
 EmailStatelessBean will 'return' (or exit) and not perform the operation.
 This way, everytime @Schedule invokes the bean method, it will continue to
 check for an available time to perform the
 get-emails-and-insert-into-database operation. Also, I'll set when
 EmailStatelessBean begins the operation, then I'll set flag on
 @ApplicationScoped bean (insertingCustomerRequestsIntoDatabase = true);
 this flag will be checked when endusers attempt to login web app, and
 FacesMessage will be displayed, Please login a few minutes later as system
 is inserting customer requests into database.

 2. Another option would be to send a message to all clients via Atmosphere
 (PrimeFaces Push), and the UI will be locked immediately, and user will be
 required to wait.

 Honestly, I don't like either of these approaches, but I think the
 endusers will accept the 1st option (above). If I go with 1st approach,
 then I may revert back to single transaction, which will complete the
 entire operation much faster than multiple transactions (via multiple EJB
 DAO classes).

 As you can see, I don't have enough experience locking database for such a
 batch operation as this. I know the endusers want the customer requests to
 show up into the database 'immediately', and they want to know when it
 happens. Right now, this is my only option until I redesign the business
 website to interface directly with the web app. right now, the web app is
 'only' used by 'personnel' (the owners of the business...which is my
 family). hahaha :)

 They love the app (honestly, they liked the speed and reliability of the
 web app when it was on Glassfish), but I'm doing all i can to win them over
 with TomEE. :)

 Your thoughts, please.

 Thanks,
 Howard



 On Tue, Dec 11, 2012 at 9:23 PM, Howard W. Smith, Jr. 
 smithh032...@gmail.com wrote:

 Done. testing now and watching JVM. I need to read that article you
 shared, so i can learn a bit about heap dump. I see the heap dump button
 there, but never used it 'yet'. :)


 On Tue, Dec 11, 2012 at 3:53 PM, Howard W. Smith, Jr. 
 smithh032...@gmail.com wrote:

 I think I'm going to avoid the single transaction (via single @Stateless
 EJB) approach, and use other @Stateless EJBs to make the database table
 updates. This approach works everywhere else throughout the web app.

 I'll just keep the @Stateless EJB for the purpose of being invoked by
 @Schedule, and it will be the 'driver', and call the
 already-defined-and-already-used other @Stateless EJBs that contain
 Persistent context and entity manager to update tables, so this clearly
 will be a multiple transaction commit, which should 'not' lock any tables.
 :)



 On Tue, Dec 11, 2012 at 3:21 PM, Howard W. Smith, Jr. 
 smithh032...@gmail.com wrote:

 Prior to adding this @Stateless EJB (that's invoked via @Schedule every
 10 minutes), my JSF web app has been running 100% okay without any
 deadlocks or anything else like that.

 So, is it okay if I just add optimistic locking, em.lock(entity,
 LockType.Optimistic) before any/all em.persist(...) that I have in the
 @Stateless EJB?

 JSF web app is working okay, because the JSF components call multiple
 @Stateless EJB that usually do any of the following, SELECT, UPDATE,
 DELETE,  on one table at time

Re: TomEE: java.lang.ClassCastException: eclipse QueryBasedValueHolder cannot be cast to eclipse UnitOfWorkValueHolder

2012-12-10 Thread Howard W. Smith, Jr.

Sorry, that's not the same exception. I'm searching google too. So far, I
see the following:

http://dev.eclipse.org/mhonarc/lists/eclipselink-users/msg02406.html

I know that I am using eclipselink query hint 'readonly' to improve the
performance of DB access via TomEE, but if I'm not mistaking, when I'm
editing or adding (or copying) data/rows, I have code that SELECTs the data
without query hint 'readonly'. Maybe I missed something, and this 'may' be
the cause of this exception, it seems to be happening when I'm inserting
rows related to the relationship between point of contact and customer or
point of contact and order.

I just wanted to buzz you to see if this might be something caused by
tomEE/openejb. I see my code footprint in that stacktrace, and I see
openejb footprint, too. :)


On Mon, Dec 10, 2012 at 9:50 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 Hi,

 seems that's a bug of eclipselinks (think it is referenced) -
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=325916

 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau



 2012/12/10 Howard W. Smith, Jr. smithh032...@gmail.com:
  Since I replaced Glassfish 3.1.2.2 with TomEE 1.5.1 on production server,
  sometimes I am seeing exceptions like the one below. Can someone please
  advise what might be the cause? Thanks.
 
  ce.internal.indirection.QueryBasedValueHolder cannot be cast to
  org.eclipse.persistence.internal.indirection.UnitOfWorkValueHolder
  at
 
 org.apache.openejb.core.ivm.BaseEjbProxyHandler.convertException(BaseEjbProxyHandler.java:363)
  at
 
 org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:283)
  at
 
 jpa.session.PointOfContactNotesFacade$LocalBeanProxy.create(jpa/session/PointOfContactNotesFacade.java)
  at
 
 jsf.pointOfContact.pf_PointOfContactController.create(pf_PointOfContactController.java:997)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
  at java.lang.reflect.Method.invoke(Unknown Source)
  at
 
 org.apache.webbeans.intercept.InterceptorHandler.invoke(InterceptorHandler.java:322)
  at
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:117)
  at
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:108)
  at
 
 jsf.pointOfContact.pf_PointOfContactController_$$_javassist_24.create(pf_PointOfContactController_$$_javassist_24.java)
  at
 jsf.orders.pf_OrdersController.createAs(pf_OrdersController.java:14874)
  at
 
 jsf.orders.pf_OrdersController.createUsingTemplate(pf_OrdersController.java:14680)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
  at java.lang.reflect.Method.invoke(Unknown Source)
  at
 
 org.apache.webbeans.intercept.InterceptorHandler.invoke(InterceptorHandler.java:322)
  at
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:117)
  at
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:108)
  at
 
 jsf.orders.pf_OrdersController_$$_javassist_6.createUsingTemplate(pf_OrdersController_$$_javassist_6.java)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
  at java.lang.reflect.Method.invoke(Unknown Source)
  at javax.el.BeanELResolver.invokeMethod(BeanELResolver.java:737)
  at javax.el.BeanELResolver.invoke(BeanELResolver.java:467)
  at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:246)
  at de.odysseus.el.tree.impl.ast.AstMethod.eval(AstMethod.java:91)
  at de.odysseus.el.tree.impl.ast.AstMethod.invoke(AstMethod.java:104)
  at de.odysseus.el.tree.impl.ast.AstEval.invoke(AstEval.java:71)
  at
 de.odysseus.el.TreeMethodExpression.invoke(TreeMethodExpression.java:132)
  at
 
 org.apache.myfaces.view.facelets.el.ContextAwareTagMethodExpression.invoke(ContextAwareTagMethodExpression.java:96)
  at
 
 javax.faces.event.MethodExpressionActionListener.processAction(MethodExpressionActionListener.java:83)
  at javax.faces.event.ActionEvent.processListener(ActionEvent.java:51)
  at
 javax.faces.component.UIComponentBase.broadcast(UIComponentBase.java:420)
  at javax.faces.component.UICommand.broadcast(UICommand.java:103)
  at javax.faces.component.UIViewRoot._broadcastAll(UIViewRoot.java:1028)
  at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:286)
  at javax.faces.component.UIViewRoot._process(UIViewRoot.java:1375

Re: TomEE: java.lang.ClassCastException: eclipse QueryBasedValueHolder cannot be cast to eclipse UnitOfWorkValueHolder

2012-12-10 Thread Howard W. Smith, Jr.

throw new CtrlCException() ??? are you telling me to throw my own exception
when that occurs?  funny. :)

On Mon, Dec 10, 2012 at 10:07 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 hmm right, throw new CtrlCException() ;)


 http://eclipse.1072660.n5.nabble.com/QueryBasedValueHolder-cannot-be-cast-to-UnitOfWorkValueHolder-td4745.html


 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau



 2012/12/10 Howard W. Smith, Jr. smithh032...@gmail.com:
  Sorry, that's not the same exception. I'm searching google too. So far, I
  see the following:
 
  http://dev.eclipse.org/mhonarc/lists/eclipselink-users/msg02406.html
 
  I know that I am using eclipselink query hint 'readonly' to improve the
  performance of DB access via TomEE, but if I'm not mistaking, when I'm
  editing or adding (or copying) data/rows, I have code that SELECTs the
 data
  without query hint 'readonly'. Maybe I missed something, and this 'may'
 be
  the cause of this exception, it seems to be happening when I'm inserting
  rows related to the relationship between point of contact and customer or
  point of contact and order.
 
  I just wanted to buzz you to see if this might be something caused by
  tomEE/openejb. I see my code footprint in that stacktrace, and I see
  openejb footprint, too. :)
 
 
  On Mon, Dec 10, 2012 at 9:50 AM, Romain Manni-Bucau
  rmannibu...@gmail.comwrote:
 
  Hi,
 
  seems that's a bug of eclipselinks (think it is referenced) -
  https://bugs.eclipse.org/bugs/show_bug.cgi?id=325916
 
  Romain Manni-Bucau
  Twitter: @rmannibucau
  Blog: http://rmannibucau.wordpress.com/
  LinkedIn: http://fr.linkedin.com/in/rmannibucau
  Github: https://github.com/rmannibucau
 
 
 
  2012/12/10 Howard W. Smith, Jr. smithh032...@gmail.com:
   Since I replaced Glassfish 3.1.2.2 with TomEE 1.5.1 on production
 server,
   sometimes I am seeing exceptions like the one below. Can someone
 please
   advise what might be the cause? Thanks.
  
   ce.internal.indirection.QueryBasedValueHolder cannot be cast to
   org.eclipse.persistence.internal.indirection.UnitOfWorkValueHolder
   at
  
 
 org.apache.openejb.core.ivm.BaseEjbProxyHandler.convertException(BaseEjbProxyHandler.java:363)
   at
  
 
 org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:283)
   at
  
 
 jpa.session.PointOfContactNotesFacade$LocalBeanProxy.create(jpa/session/PointOfContactNotesFacade.java)
   at
  
 
 jsf.pointOfContact.pf_PointOfContactController.create(pf_PointOfContactController.java:997)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
   at java.lang.reflect.Method.invoke(Unknown Source)
   at
  
 
 org.apache.webbeans.intercept.InterceptorHandler.invoke(InterceptorHandler.java:322)
   at
  
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:117)
   at
  
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:108)
   at
  
 
 jsf.pointOfContact.pf_PointOfContactController_$$_javassist_24.create(pf_PointOfContactController_$$_javassist_24.java)
   at
  jsf.orders.pf_OrdersController.createAs(pf_OrdersController.java:14874)
   at
  
 
 jsf.orders.pf_OrdersController.createUsingTemplate(pf_OrdersController.java:14680)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
   at java.lang.reflect.Method.invoke(Unknown Source)
   at
  
 
 org.apache.webbeans.intercept.InterceptorHandler.invoke(InterceptorHandler.java:322)
   at
  
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:117)
   at
  
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:108)
   at
  
 
 jsf.orders.pf_OrdersController_$$_javassist_6.createUsingTemplate(pf_OrdersController_$$_javassist_6.java)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
   at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
   at java.lang.reflect.Method.invoke(Unknown Source)
   at javax.el.BeanELResolver.invokeMethod(BeanELResolver.java:737)
   at javax.el.BeanELResolver.invoke(BeanELResolver.java:467)
   at javax.el.CompositeELResolver.invoke(CompositeELResolver.java:246)
   at de.odysseus.el.tree.impl.ast.AstMethod.eval(AstMethod.java:91)
   at de.odysseus.el.tree.impl.ast.AstMethod.invoke(AstMethod.java:104)
   at de.odysseus.el.tree.impl.ast.AstEval.invoke(AstEval.java:71)
   at
 
 de.odysseus.el.TreeMethodExpression.invoke

Re: TomEE: java.lang.ClassCastException: eclipse QueryBasedValueHolder cannot be cast to eclipse UnitOfWorkValueHolder

2012-12-10 Thread Howard W. Smith, Jr.

lol... okay, that elipselink discussion says it's an eclipselink bug, but
this error has not been occurring when my app was running in
Glassfish3.1.2.2, so I'm thinking that I need to review the TomEE/CDI code.

It seems like it is caused by my code that introduces the query hint
'readonly' (query based value holder, which I interpret as readonly value
holder), and I think I may be trying to use that data, and commit that
data, even though that data is 'detached'. I'll confirm.

You agree?


On Mon, Dec 10, 2012 at 10:51 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 lol no, meant i did a bad copy/paste

 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau



 2012/12/10 Howard W. Smith, Jr. smithh032...@gmail.com:
  throw new CtrlCException() ??? are you telling me to throw my own
 exception
  when that occurs?  funny. :)
 
  On Mon, Dec 10, 2012 at 10:07 AM, Romain Manni-Bucau
  rmannibu...@gmail.comwrote:
 
  hmm right, throw new CtrlCException() ;)
 
 
 
 http://eclipse.1072660.n5.nabble.com/QueryBasedValueHolder-cannot-be-cast-to-UnitOfWorkValueHolder-td4745.html
 
 
  Romain Manni-Bucau
  Twitter: @rmannibucau
  Blog: http://rmannibucau.wordpress.com/
  LinkedIn: http://fr.linkedin.com/in/rmannibucau
  Github: https://github.com/rmannibucau
 
 
 
  2012/12/10 Howard W. Smith, Jr. smithh032...@gmail.com:
   Sorry, that's not the same exception. I'm searching google too. So
 far, I
   see the following:
  
   http://dev.eclipse.org/mhonarc/lists/eclipselink-users/msg02406.html
  
   I know that I am using eclipselink query hint 'readonly' to improve
 the
   performance of DB access via TomEE, but if I'm not mistaking, when I'm
   editing or adding (or copying) data/rows, I have code that SELECTs the
  data
   without query hint 'readonly'. Maybe I missed something, and this
 'may'
  be
   the cause of this exception, it seems to be happening when I'm
 inserting
   rows related to the relationship between point of contact and
 customer or
   point of contact and order.
  
   I just wanted to buzz you to see if this might be something caused by
   tomEE/openejb. I see my code footprint in that stacktrace, and I see
   openejb footprint, too. :)
  
  
   On Mon, Dec 10, 2012 at 9:50 AM, Romain Manni-Bucau
   rmannibu...@gmail.comwrote:
  
   Hi,
  
   seems that's a bug of eclipselinks (think it is referenced) -
   https://bugs.eclipse.org/bugs/show_bug.cgi?id=325916
  
   Romain Manni-Bucau
   Twitter: @rmannibucau
   Blog: http://rmannibucau.wordpress.com/
   LinkedIn: http://fr.linkedin.com/in/rmannibucau
   Github: https://github.com/rmannibucau
  
  
  
   2012/12/10 Howard W. Smith, Jr. smithh032...@gmail.com:
Since I replaced Glassfish 3.1.2.2 with TomEE 1.5.1 on production
  server,
sometimes I am seeing exceptions like the one below. Can someone
  please
advise what might be the cause? Thanks.
   
ce.internal.indirection.QueryBasedValueHolder cannot be cast to
org.eclipse.persistence.internal.indirection.UnitOfWorkValueHolder
at
   
  
 
 org.apache.openejb.core.ivm.BaseEjbProxyHandler.convertException(BaseEjbProxyHandler.java:363)
at
   
  
 
 org.apache.openejb.core.ivm.BaseEjbProxyHandler.invoke(BaseEjbProxyHandler.java:283)
at
   
  
 
 jpa.session.PointOfContactNotesFacade$LocalBeanProxy.create(jpa/session/PointOfContactNotesFacade.java)
at
   
  
 
 jsf.pointOfContact.pf_PointOfContactController.create(pf_PointOfContactController.java:997)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
   
  
 
 org.apache.webbeans.intercept.InterceptorHandler.invoke(InterceptorHandler.java:322)
at
   
  
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:117)
at
   
  
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke(NormalScopedBeanInterceptorHandler.java:108)
at
   
  
 
 jsf.pointOfContact.pf_PointOfContactController_$$_javassist_24.create(pf_PointOfContactController_$$_javassist_24.java)
at
  
 jsf.orders.pf_OrdersController.createAs(pf_OrdersController.java:14874)
at
   
  
 
 jsf.orders.pf_OrdersController.createUsingTemplate(pf_OrdersController.java:14680)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at
   
  
 
 org.apache.webbeans.intercept.InterceptorHandler.invoke(InterceptorHandler.java:322)
at
   
  
 
 org.apache.webbeans.intercept.NormalScopedBeanInterceptorHandler.invoke

Re: TomEE/catalina log showing that someone trying to hack into my TomEE/tomcat7 server

Romain,

I have TomEE 1.5.1 running on production server, and I am getting
hack-attempts late at night (midnight) by someone, trying to login to
'admin' acct of TomEE (tomcat7).  I have a strong password and a different
admin-user-name in place.

I really would like to change configuration to put the tomee app on
localhost:4848 (port 4848) instead of port 80 or 8080.

I have not been successful at this yet. I think I read in tomee or tomcat7
user guide, that I can delete the tomee app? I can also delete manager/etc
apps as well, so they won't even be served. Right?

Howard


On Tue, Nov 27, 2012 at 6:06 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 By default in dev more you should get tomee user (but only to access tomee
 webapp, not tomcat one)

 if you set openejb.profile to something else (system property) you'll need
 to define it explicitely

 *Romain Manni-Bucau*
 *Twitter: @rmannibucau https://twitter.com/rmannibucau*
 *Blog: **http://rmannibucau.wordpress.com/*
 http://rmannibucau.wordpress.com/
 *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
 *Github: https://github.com/rmannibucau*




 2012/11/27 Howard W. Smith, Jr. smithh032...@gmail.com

  Wow, check this out. I'm so glad that you all ship tomee.xml with all
  users/passwords 'commented out'! :)
 
  Nov 27, 2012 5:48:05 AM org.apache.catalina.realm.LockOutRealm
 authenticate
  WARNING: An attempt was made to authenticate the locked user manager
  Nov 27, 2012 5:48:05 AM org.apache.catalina.realm.LockOutRealm
 authenticate
  WARNING: An attempt was made to authenticate the locked user manager
  Nov 27, 2012 5:48:06 AM org.apache.catalina.realm.LockOutRealm
 authenticate
  WARNING: An attempt was made to authenticate the locked user role1
  Nov 27, 2012 5:48:06 AM org.apache.catalina.realm.LockOutRealm
 authenticate
  WARNING: An attempt was made to authenticate the locked user role1
  Nov 27, 2012 5:48:07 AM org.apache.catalina.realm.LockOutRealm
 authenticate
  WARNING: An attempt was made to authenticate the locked user root
  Nov 27, 2012 5:48:07 AM org.apache.catalina.realm.LockOutRealm
 authenticate
  WARNING: An attempt was made to authenticate the locked user root
  Nov 27, 2012 5:48:07 AM org.apache.catalina.realm.LockOutRealm
 authenticate
  WARNING: An attempt was made to authenticate the locked user root
  Nov 27, 2012 5:48:08 AM org.apache.catalina.realm.LockOutRealm
 authenticate
  WARNING: An attempt was made to authenticate the locked user tomcat
  Nov 27, 2012 5:48:08 AM org.apache.catalina.realm.LockOutRealm
 authenticate
  WARNING: An attempt was made to authenticate the locked user tomcat
  Nov 27, 2012 5:48:09 AM org.apache.catalina.realm.LockOutRealm
 authenticate
  WARNING: An attempt was made to authenticate the locked user both
  Nov 27, 2012 5:48:09 AM org.apache.catalina.realm.LockOutRealm
 authenticate
  WARNING: An attempt was made to authenticate the locked user both
  Nov 27, 2012 5:48:09 AM org.apache.catalina.realm.LockOutRealm
 authenticate
  WARNING: An attempt was made to authenticate the locked user both
 
  88.191.100.2 - - [27/Nov/2012:05:47:58 -0500] HEAD /manager/html
 HTTP/1.0
  401 -
  88.191.100.2 - - [27/Nov/2012:05:47:59 -0500] HEAD /manager/html
 HTTP/1.0
  401 -
  88.191.100.2 - - [27/Nov/2012:05:47:59 -0500] HEAD /manager/html
 HTTP/1.0
  401 -
  88.191.100.2 - - [27/Nov/2012:05:47:59 -0500] HEAD /manager/html
 HTTP/1.0
  401 -
  88.191.100.2 - - [27/Nov/2012:05:47:59 -0500] HEAD /manager/html
 HTTP/1.0
  401 -
  88.191.100.2 - - [27/Nov/2012:05:47:59 -0500] HEAD /manager/html
 HTTP/1.0
  401 -
  88.191.100.2 - - [27/Nov/2012:05:48:00 -0500] HEAD /manager/html
 HTTP/1.0
  401 -
  88.191.100.2 - - [27/Nov/2012:05:48:00 -0500] HEAD /manager/html
 HTTP/1.0
  401 -
  88.191.100.2 - - [27/Nov/2012:05:48:00 -0500] HEAD /manager/html
 HTTP/1.0
  401 -
  88.191.100.2 - - [27/Nov/2012:05:48:00 -0500] HEAD /manager/html
 HTTP/1.0
  401 -
  88.191.100.2 - - [27/Nov/2012:05:48:01 -0500] HEAD /manager/html
 HTTP/1.0
  401 -
  88.191.100.2 - - [27/Nov/2012:05:48:01 -0500] HEAD /manager/html
 HTTP/1.0
  401 -
  88.191.100.2 - - [27/Nov/2012:05:48:01 -0500] HEAD /manager/html
 HTTP/1.0
  401 -
  88.191.100.2 - - [27/Nov/2012:05:48:01 -0500] HEAD /manager/html
 HTTP/1.0
  401 -
  88.191.100.2 - - [27/Nov/2012:05:48:01 -0500] HEAD /manager/html
 HTTP/1.0
  401 -
  88.191.100.2 - - [27/Nov/2012:05:48:02 -0500] HEAD /manager/html
 HTTP/1.0
  401 -
  88.191.100.2 - - [27/Nov/2012:05:48:02 -0500] HEAD /manager/html
 HTTP/1.0
  401 -
  88.191.100.2 - - [27/Nov/2012:05:48:02 -0500] HEAD /manager/html
 HTTP/1.0
  401 -
  88.191.100.2 - - [27/Nov/2012:05:48:02 -0500] HEAD /manager/html
 HTTP/1.0
  401 -
  88.191.100.2 - - [27/Nov/2012:05:48:02 -0500] HEAD /manager/html
 HTTP/1.0
  401 -
  88.191.100.2 - - [27/Nov/2012:05:48:03 -0500] HEAD /manager/html
 HTTP/1.0
  401 -
  88.191.100.2 - - [27/Nov/2012:05:48:03 -0500] HEAD /manager/html
 HTTP/1.0
  401 -
  88.191.100.2 - - [27/Nov/2012:05:48:03 -0500] HEAD

Re: TomEE/catalina log showing that someone trying to hack into my TomEE/tomcat7 server

Can you reply with a URL or two that advises how to configure server.xml?
thanks.


On Sun, Dec 9, 2012 at 11:23 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 That's right, tomee webapp only serve for default ejbd (remote ejb
 transport).

 For port just update server.xml
 Le 9 déc. 2012 17:20, Howard W. Smith, Jr. smithh032...@gmail.com a
 écrit :

  Romain,
 
  I have TomEE 1.5.1 running on production server, and I am getting
  hack-attempts late at night (midnight) by someone, trying to login to
  'admin' acct of TomEE (tomcat7).  I have a strong password and a
 different
  admin-user-name in place.
 
  I really would like to change configuration to put the tomee app on
  localhost:4848 (port 4848) instead of port 80 or 8080.
 
  I have not been successful at this yet. I think I read in tomee or
 tomcat7
  user guide, that I can delete the tomee app? I can also delete
 manager/etc
  apps as well, so they won't even be served. Right?
 
  Howard
 
 
  On Tue, Nov 27, 2012 at 6:06 AM, Romain Manni-Bucau
  rmannibu...@gmail.comwrote:
 
   By default in dev more you should get tomee user (but only to access
  tomee
   webapp, not tomcat one)
  
   if you set openejb.profile to something else (system property) you'll
  need
   to define it explicitely
  
   *Romain Manni-Bucau*
   *Twitter: @rmannibucau https://twitter.com/rmannibucau*
   *Blog: **http://rmannibucau.wordpress.com/*
   http://rmannibucau.wordpress.com/
   *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
   *Github: https://github.com/rmannibucau*
  
  
  
  
   2012/11/27 Howard W. Smith, Jr. smithh032...@gmail.com
  
Wow, check this out. I'm so glad that you all ship tomee.xml with all
users/passwords 'commented out'! :)
   
Nov 27, 2012 5:48:05 AM org.apache.catalina.realm.LockOutRealm
   authenticate
WARNING: An attempt was made to authenticate the locked user
 manager
Nov 27, 2012 5:48:05 AM org.apache.catalina.realm.LockOutRealm
   authenticate
WARNING: An attempt was made to authenticate the locked user
 manager
Nov 27, 2012 5:48:06 AM org.apache.catalina.realm.LockOutRealm
   authenticate
WARNING: An attempt was made to authenticate the locked user role1
Nov 27, 2012 5:48:06 AM org.apache.catalina.realm.LockOutRealm
   authenticate
WARNING: An attempt was made to authenticate the locked user role1
Nov 27, 2012 5:48:07 AM org.apache.catalina.realm.LockOutRealm
   authenticate
WARNING: An attempt was made to authenticate the locked user root
Nov 27, 2012 5:48:07 AM org.apache.catalina.realm.LockOutRealm
   authenticate
WARNING: An attempt was made to authenticate the locked user root
Nov 27, 2012 5:48:07 AM org.apache.catalina.realm.LockOutRealm
   authenticate
WARNING: An attempt was made to authenticate the locked user root
Nov 27, 2012 5:48:08 AM org.apache.catalina.realm.LockOutRealm
   authenticate
WARNING: An attempt was made to authenticate the locked user tomcat
Nov 27, 2012 5:48:08 AM org.apache.catalina.realm.LockOutRealm
   authenticate
WARNING: An attempt was made to authenticate the locked user tomcat
Nov 27, 2012 5:48:09 AM org.apache.catalina.realm.LockOutRealm
   authenticate
WARNING: An attempt was made to authenticate the locked user both
Nov 27, 2012 5:48:09 AM org.apache.catalina.realm.LockOutRealm
   authenticate
WARNING: An attempt was made to authenticate the locked user both
Nov 27, 2012 5:48:09 AM org.apache.catalina.realm.LockOutRealm
   authenticate
WARNING: An attempt was made to authenticate the locked user both
   
88.191.100.2 - - [27/Nov/2012:05:47:58 -0500] HEAD /manager/html
   HTTP/1.0
401 -
88.191.100.2 - - [27/Nov/2012:05:47:59 -0500] HEAD /manager/html
   HTTP/1.0
401 -
88.191.100.2 - - [27/Nov/2012:05:47:59 -0500] HEAD /manager/html
   HTTP/1.0
401 -
88.191.100.2 - - [27/Nov/2012:05:47:59 -0500] HEAD /manager/html
   HTTP/1.0
401 -
88.191.100.2 - - [27/Nov/2012:05:47:59 -0500] HEAD /manager/html
   HTTP/1.0
401 -
88.191.100.2 - - [27/Nov/2012:05:47:59 -0500] HEAD /manager/html
   HTTP/1.0
401 -
88.191.100.2 - - [27/Nov/2012:05:48:00 -0500] HEAD /manager/html
   HTTP/1.0
401 -
88.191.100.2 - - [27/Nov/2012:05:48:00 -0500] HEAD /manager/html
   HTTP/1.0
401 -
88.191.100.2 - - [27/Nov/2012:05:48:00 -0500] HEAD /manager/html
   HTTP/1.0
401 -
88.191.100.2 - - [27/Nov/2012:05:48:00 -0500] HEAD /manager/html
   HTTP/1.0
401 -
88.191.100.2 - - [27/Nov/2012:05:48:01 -0500] HEAD /manager/html
   HTTP/1.0
401 -
88.191.100.2 - - [27/Nov/2012:05:48:01 -0500] HEAD /manager/html
   HTTP/1.0
401 -
88.191.100.2 - - [27/Nov/2012:05:48:01 -0500] HEAD /manager/html
   HTTP/1.0
401 -
88.191.100.2 - - [27/Nov/2012:05:48:01 -0500] HEAD /manager/html
   HTTP/1.0
401 -
88.191.100.2 - - [27/Nov/2012:05:48:01 -0500] HEAD /manager/html
   HTTP/1.0
401 -
88.191.100.2 - - [27/Nov/2012:05:48:02

Re: TomEE/catalina log showing that someone trying to hack into my TomEE/tomcat7 server

Sorry, i don't understand. The following is in my server.xml, I added the
port 4848, but if I go to localhost:4848 and localhost:8080 in my browser,
then I'm seeing the same 'tomcat' page that has a way for hackers to click
on TomEE Gui, Server Status, Manager App, and Host manager. I only want to
see that page when access localhost:4848, I do not want to see that page
when accessing localhost:8080.


Connector port=8080 protocol=HTTP/1.1
   connectionTimeout=2
   redirectPort=8443 /
!-- A Connector using the shared thread pool--
Connector executor=tomcatThreadPool
   port=4848 protocol=HTTP/1.1
   connectionTimeout=2
   redirectPort=8443 /


On Sun, Dec 9, 2012 at 11:30 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:

 Just look tomcat site. Basically connector(s) ports and shutdown port
 (Server and  Connector)
 Le 9 déc. 2012 17:26, Howard W. Smith, Jr. smithh032...@gmail.com a
 écrit :

  Can you reply with a URL or two that advises how to configure server.xml?
  thanks.
 
 
  On Sun, Dec 9, 2012 at 11:23 AM, Romain Manni-Bucau
  rmannibu...@gmail.comwrote:
 
   That's right, tomee webapp only serve for default ejbd (remote ejb
   transport).
  
   For port just update server.xml
   Le 9 déc. 2012 17:20, Howard W. Smith, Jr. smithh032...@gmail.com
 a
   écrit :
  
Romain,
   
I have TomEE 1.5.1 running on production server, and I am getting
hack-attempts late at night (midnight) by someone, trying to login to
'admin' acct of TomEE (tomcat7).  I have a strong password and a
   different
admin-user-name in place.
   
I really would like to change configuration to put the tomee app on
localhost:4848 (port 4848) instead of port 80 or 8080.
   
I have not been successful at this yet. I think I read in tomee or
   tomcat7
user guide, that I can delete the tomee app? I can also delete
   manager/etc
apps as well, so they won't even be served. Right?
   
Howard
   
   
On Tue, Nov 27, 2012 at 6:06 AM, Romain Manni-Bucau
rmannibu...@gmail.comwrote:
   
 By default in dev more you should get tomee user (but only to
 access
tomee
 webapp, not tomcat one)

 if you set openejb.profile to something else (system property)
 you'll
need
 to define it explicitely

 *Romain Manni-Bucau*
 *Twitter: @rmannibucau https://twitter.com/rmannibucau*
 *Blog: **http://rmannibucau.wordpress.com/*
 http://rmannibucau.wordpress.com/
 *LinkedIn: **http://fr.linkedin.com/in/rmannibucau*
 *Github: https://github.com/rmannibucau*




 2012/11/27 Howard W. Smith, Jr. smithh032...@gmail.com

  Wow, check this out. I'm so glad that you all ship tomee.xml with
  all
  users/passwords 'commented out'! :)
 
  Nov 27, 2012 5:48:05 AM org.apache.catalina.realm.LockOutRealm
 authenticate
  WARNING: An attempt was made to authenticate the locked user
   manager
  Nov 27, 2012 5:48:05 AM org.apache.catalina.realm.LockOutRealm
 authenticate
  WARNING: An attempt was made to authenticate the locked user
   manager
  Nov 27, 2012 5:48:06 AM org.apache.catalina.realm.LockOutRealm
 authenticate
  WARNING: An attempt was made to authenticate the locked user
  role1
  Nov 27, 2012 5:48:06 AM org.apache.catalina.realm.LockOutRealm
 authenticate
  WARNING: An attempt was made to authenticate the locked user
  role1
  Nov 27, 2012 5:48:07 AM org.apache.catalina.realm.LockOutRealm
 authenticate
  WARNING: An attempt was made to authenticate the locked user
 root
  Nov 27, 2012 5:48:07 AM org.apache.catalina.realm.LockOutRealm
 authenticate
  WARNING: An attempt was made to authenticate the locked user
 root
  Nov 27, 2012 5:48:07 AM org.apache.catalina.realm.LockOutRealm
 authenticate
  WARNING: An attempt was made to authenticate the locked user
 root
  Nov 27, 2012 5:48:08 AM org.apache.catalina.realm.LockOutRealm
 authenticate
  WARNING: An attempt was made to authenticate the locked user
  tomcat
  Nov 27, 2012 5:48:08 AM org.apache.catalina.realm.LockOutRealm
 authenticate
  WARNING: An attempt was made to authenticate the locked user
  tomcat
  Nov 27, 2012 5:48:09 AM org.apache.catalina.realm.LockOutRealm
 authenticate
  WARNING: An attempt was made to authenticate the locked user
 both
  Nov 27, 2012 5:48:09 AM org.apache.catalina.realm.LockOutRealm
 authenticate
  WARNING: An attempt was made to authenticate the locked user
 both
  Nov 27, 2012 5:48:09 AM org.apache.catalina.realm.LockOutRealm
 authenticate
  WARNING: An attempt was made to authenticate the locked user
 both
 
  88.191.100.2 - - [27/Nov/2012:05:47:58 -0500] HEAD /manager/html
 HTTP/1.0
  401 -
  88.191.100.2 - - [27/Nov/2012:05:47:59 -0500] HEAD /manager/html
 HTTP/1.0
  401

Re: TomEE/catalina log showing that someone trying to hack into my TomEE/tomcat7 server

Jonathan,

Thanks for the detailed response. Yes, you're right, I want port 4848
(tomee/admin web apps) only available to myself (LAN), and port 8080
(business webapp) available to LAN and WAN.

I've done a lot of reading about apache httpd and tomcat, and for the most
part, I read that it's not necessary to run the two together, so I have not
done that yet (as I am new to Tomcat/TomEE), but if it is highly
recommended, then I might give it a try. Right now, TomEE is serving
dynamic web page content (JSF web app) to a small number of users at the
present. Hopefully, in the near future, the same web app (and tomEE) will
possibly serve static as well as dynamic web page content to customers.

Most of what you mentioned below, I read recently (within last 2 or 3
hours) in Tomcat docs, since Romain advised me to look there.

Right now, i have no need for tomee web app, and the other admin apps, but
I might find use for them in the near future. So, for right now, if I could
have tomee/admin web apps only on 4848 and business web app on 8080, then
I'm fine with that. Also, I have no need for load balancing at the present,
but may have a need for that some time in the future.

It's interesting how much I'm learning by talking to and interfacing with
Apache committers and users. Learning a lot...and loving it! :)

Thanks,
Howard

On Sun, Dec 9, 2012 at 4:26 PM, Jonathan Gallimore
jonathan.gallim...@gmail.com wrote:

Hi Howard,

Sounds like you want to make your application available on
http://localhost:8080/myapp, and have the usual Tomcat / TomEE
administrative applications available via
http://localhost:4848/[tomee|manager|etc]. Similarly, you don't want
http://localhost:4848/myapp or http://localhost:8080[tomee|manager|etc] to
work, with the overall goal being to restrict access to the admin apps to
just your machine, or users on your LAN - is that correct?

I have a couple of suggestions:

You might be able to achieve this by defining different connectors, engines
and hosts in server.xml. I haven't done it myself, but I'm happy to give it
a try, document it and provide a sample config if that would be helpful. I
found a couple of questions on StackOverflow trying to do something
similar, albeit with Tomcat 6 that might be helpful:

http://stackoverflow.com/questions/8823290/how-to-run-different-apps-on-single-tomcat-instance-behind-different-ports

http://stackoverflow.com/questions/4366843/how-to-deploy-mutiple-web-application-in-tomcat-which-will-run-on-different-port

I have a couple of alternative suggestions as well, that might be useful.

First is to try the RemoteAddressFilter valve:

http://tomcat.apache.org/tomcat-7.0-doc/config/valve.html#Remote_Address_Filter-
we used to use this within the TomEE .war file to restrict access from
everywhere except localhost. Everything would still be available on port
8080, but would access to specific apps would be allowed or blocked based
on IP address.

Alternatively, if you don't need the TomEE and Tomcat webapps, you can
remove them (take a backup first!). To remove the TomEE webapp, copy the
jars from $CATALINA_HOME/webapps/tomee/WEB-INF/lib
and $CATALINA_HOME/webapps/tomee/lib to $CATALINA_HOME/lib and then remove
the webapp (more info here: http://tomee.apache.org/tomee-webapp.html).
The
other webapps can safely be removed unless you are using them.

The downside to this is that remote EJB invocation via HTTP won't work
(i.e. if you are using a RemoteInitialContextFactory with a
http://localhost:8080/tomee/ejb URL). You can still use this mechanism
from
within your own webapp if you wish by adding this to your web.xml:

servlet
servlet-nameServerServlet/servlet-name

servlet-classorg.apache.openejb.server.httpd.ServerServlet/servlet-class
/servlet
servlet-mapping
servlet-nameServerServlet/servlet-name
url-pattern/ejb/url-pattern
/servlet-mapping

You can then use http://localhost:8080/myapp/ejb to access your EJBs
remotely.

One final suggestion - use Apache httpd in front of TomEE and use mod_proxy
to proxy to your app running on Tomcat's AJP port. Firewall off access to
TomEE completely to the outside world, and only allow httpd to serve up
your app. There are loads of options in the Apache httpd server to
configure access control, and you can also use httpd to load balance
several Tomcat instances as well if you wish. You can also serve up static
parts of your webapp directly from httpd rather than forwarding from
Tomcat, which can be quicker. I could knock an example configuration of
this as well if that would be helpful - if you're currently allowing users
straight on to port 8080, this option might be worth a look.

I'd be interested if others also put Apache httpd in front of Tomcat as
well or not.

Hope that helps!

Jon

On Sun, Dec 9, 2012 at 8:35 PM, Howard W. Smith, Jr.
smithh032...@gmail.com
wrote:

Sorry, i don't understand. The following is in my server.xml, I added

Re: TomEE/catalina log showing that someone trying to hack into my TomEE/tomcat7 server