Re: DB access is very slow
Hmm, weird, please stress your app and share some stacktraces. I benchmarked hibernate/openjpa/eclipselinks and the difference was very small. Le 12 déc. 2012 02:48, "Howard W. Smith, Jr." a écrit : > 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 wrote: > > > Thank you, Romain and smithh032772, > > > > Based on your suggestions, I changed the configuration in the > > tomee.xml like the following. > > > > # 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) > > > > > > 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 setting through > > jmx. I checked the bundled tomee application, but there does not seem to > be > > the menu to check the parameters of the . > > > > 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?
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
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
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: 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 wrote: > Thank you, Romain and smithh032772, > > Based on your suggestions, I changed the configuration in the > tomee.xml like the following. > > # 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) > > > 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 setting through > jmx. I checked the bundled tomee application, but there does not seem to be > the menu to check the parameters of the . > > 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: DB access is very slow
Thank you, Romain and smithh032772, Based on your suggestions, I changed the configuration in the tomee.xml like the following. # 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) 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 setting through jmx. I checked the bundled tomee application, but there does not seem to be the menu to check the parameters of the . 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?
Yes, that is funny. I was away from my desk, and saw that your previous email, and I was already on the same page as you, but your (previous) email was confirmation to me that that is what I needed to do. All around the same time, I sent an email to the endusers and explained the problem and what I was planning to do to resolve the issue. Now, time to get to work and get this done. Thanks again for the help, assistance, and responses! On Tue, Dec 11, 2012 at 4:26 PM, David Blevins wrote: > Funny, I just sent that suggestion :) But it took me too long to type it > -- didn't see your response came in before I finished :) > > -David > > On Dec 11, 2012, at 12: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?
Funny, I just sent that suggestion :) But it took me too long to type it -- didn't see your response came in before I finished :) -David On Dec 11, 2012, at 12:53 PM, "Howard W. Smith, Jr." 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?
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() {
List emails = fetchEmail();
for (Email email : emails) {
// parse email and insert records
}
}
// TRANSACTION END
You want:
@Schedule(...)
public void processPendingEmail() {
List 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."
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?
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?
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. :)
enCore(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)
... 126 more
javax.ejb.EJBException: The bean encountered a non-application exception;
nested exception is:
Exception [EclipseLink-4002] (Eclipse Persistence Services -
2.3.2.v2025-r10461):
org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: java.sql.SQLTransactionRollbackException: A lock could
not be obtained within the time requested
Error Code: 3
Call: SELECT t0.ORDER_ID, t0.BALANCE, t0.CANCELLED, t0.CANCELLED_DATE,
t0.CHANGED_DT, t0.CONFIRMED, t0.CONFIRMED_DATE, t0.CONTRACT_SENT,
t0.CONTRACT_SENT_DATE, t0.CREATED_BY, t0.CREATED_DT, t0.DEPOSIT,
t0.DEPOSIT_PAID, t0.DEPOSIT_PAID_DATE, t0.DISCOUNT, t0.DISCOUNT_RATE,
t0.INTRASTATE, t0.INVOICE_SENT, t0.INVOICE_SENT_DATE, t0.PAID_IN_FULL,
t0.PAID_IN_FULL_DATE, t0.PASSENGERS, t0.QUOTE_SENT, t0.QUOTE_SENT_DATE,
t0.REPORT_DATE_TIME, t0.RETURN_DATE_TIME, t0.TOTAL_COST, t0.TRIP_DATE_TIME,
t0.BANK_FOR_BALANCE_ID, t0.BANK_FOR_DEPOSIT_ID, t0.CUSTOMER_ID,
t0.DETAILS_ID, t0.METHOD_OF_PAYMENT_FOR_BALANCE_ID,
t0.METHOD_OF_PAYMENT_FOR_DEPOSIT_ID, t0.NOTES_ID, t0.ROUTES_ID,
t0.TEMPLATE_ID FROM ORDERS t0 WHERE (t0.TRIP_DATE_TIME BETWEEN {ts
'2012-12-06 00:00:00.0'} AND {ts '2012-12-06 23:59:59.0'}) OR
(t0.RETURN_DATE_TIME BETWEEN {ts '2012-12-06 00:00:00.0'} AND {ts
'2012-12-06 23:59:59.0'})) OR ({ts '2012-12-06 00:00:00.0'} BETWEEN
t0.TRIP_DATE_TIME AND t0.RETURN_DATE_TIME)) OR ({ts '2012-12-06
23:59:59.0'} BETWEEN t0.TRIP_DATE_TIME AND t0.RETURN_DATE_TIME)) AND NOT
EXISTS (SELECT 1 FROM ORDER_TEMPLATE t2, ORDER_TEMPLATE t1 WHERE
((t1.TEMPLATE_ID = t2.TEMPLATE_ID) AND (t2.TEMPLATE_ID = t0.TEMPLATE_ID)))
) ORDER BY t0.REPORT_DATE_TIME ASC, t0.TRIP_DATE_TIME ASC
Query: ReadAllQuery(name="Orders.findAllBookedTrips" referenceClass=Orders
sql="SELECT t0.ORDER_ID, t0.BALANCE, t0.CANCELLED, t0.CANCELLED_DATE,
t0.CHANGED_DT, t0.CONFIRMED, t0.CONFIRMED_DATE, t0.CONTRACT_SENT,
t0.CONTRACT_SENT_DATE, t0.CREATED_BY, t0.CREATED_DT, t0.DEPOSIT,
t0.DEPOSIT_PAID, t0.DEPOSIT_PAID_DATE, t0.DISCOUNT, t0.DISCOUNT_RATE,
t0.INTRASTATE, t0.INVOICE_SENT, t0.INVOICE_SENT_DATE, t0.PAID_IN_FULL,
t0.PAID_IN_FULL_DATE, t0.PASSENGERS, t0.QUOTE_SENT, t0.QUOTE_SENT_DATE,
t0.REPORT_DATE_TIME, t0.RETURN_DATE_TIME, t0.TOTAL_COST, t0.TRIP_DATE_TIME,
t0.BANK_FOR_BALANCE_ID, t0.BANK_FOR_DEPOSIT_ID, t0.CUSTOMER_ID,
t0.DETAILS_ID, t0.METHOD_OF_PAYMENT_FOR_BALANCE_ID,
t0.METHOD_OF_PAYMENT_FOR_DEPOSIT_ID, t0.NOTES_ID, t0.ROUTES_ID,
t0.TEMPLATE_ID FROM ORDERS t0 WHERE (t0.TRIP_DATE_TIME BETWEEN ? AND ?)
OR (t0.RETURN_DATE_TIME BETWEEN ? AND ?)) OR (? BETWEEN t0.TRIP_DATE_TIME
AND t0.RETURN_DATE_TIME)) OR (? BETWEEN t0.TRIP_DATE_TIME AND
t0.RETURN_DATE_TIME)) AND NOT EXISTS (SELECT ? FROM ORDER_TEMPLATE t2,
ORDER_TEMPLATE t1 WHERE ((t1.TEMPLATE_ID = t2.TEMPLATE_ID) AND
(t2.TEMPLATE_ID = t0.TEMPLATE_ID))) ) ORDER BY t0.REPORT_DATE_TIME ASC,
t0.TRIP_DATE_TIME ASC")
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.OrdersFacade$LocalBeanProxy.filterBy(jpa/session/OrdersFacade.java)
at jsf.orders.pf_OrdersController.fi
Re: Why are Tomcat's threads more costly than background threads?
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." 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 wrote: >> >>> Thank you very much for this exhaustive reply Christopher. >>> >>> 2012/12/11 Christopher Schultz >>> -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
Re: Why are Tomcat's threads more costly than background threads?
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 wrote:
>
>> Thank you very much for this exhaustive reply Christopher.
>>
>> 2012/12/11 Christopher Schultz
>>
>> > -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 backg
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 wrote:
> Thank you very much for this exhaustive reply Christopher.
>
> 2012/12/11 Christopher Schultz
>
> > -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
> > pr
Re: DB access is very slow
yep, at least 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. : > 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 > wrote: > >> 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. : >> > 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: >> >> >> >> >> >> ... >> >> jdbcInterceptors=StatementCache(max=128) >> >> ... >> >> >> >> >> >> >> >> >>
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 wrote: > 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. : > > 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: > >> > >> > >> ... > >> jdbcInterceptors=StatementCache(max=128) > >> ... > >> > >> > >> > >> >
Re: TomEE: StandardSession expire
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. : > 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 > wrote: > >> 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 : >> > 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." 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
did it before commiting to attach my commit to it 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. : > 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 > wrote: > >> 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." 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 wrote: > 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 : > > 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." 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
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 wrote: > 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." 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
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. : > 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: >> >> >> ... >> jdbcInterceptors=StatementCache(max=128) >> ... >> >> >> >>
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: > > > ... > jdbcInterceptors=StatementCache(max=128) > ... > > > >
Re: DB access is very slow
the setting jdbcInterceptors is something important too:
...
jdbcInterceptors=StatementCache(max=128)
...
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. :
> 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*
>
>
> 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";>
>
> org.eclipse.persistence.jpa.PersistenceProvider
> jdbc/mcmsJta
> jdbc/mcmsNonJta
> false
>
>
> value="org.eclipse.persistence.platform.database.DerbyPlatform"/>
>
> />
>
>
>
>
>
>
> *META-INF/context.xml* (do not configure JDBC resources here; Romain
> advised me of that some weeks ago)
>
>
>
>
>
> *{tomee-install-folder}/conf/tomee.xml*
>
>
> 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
>
>
>
> 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
>
>
>
>
> On Mon, Dec 10, 2012 at 8:59 PM, knak55 wrote:
>
>> 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
Re: WebappClassLoader checkThreadLocalMapForLeaks finding leaks related to Google Apps API
simply look sources, the threadlocal is private, and the remove method is not accessible so the impl has a potential memory leak. In practise these ones shouldn't hurt that much. 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. : > Okay, found the following: > > https://groups.google.com/forum/?fromgroups=#!topic/google-documents-list-api/b9MsCMdFtxc > > but no solution there. will keep searching. :)
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: 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
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: 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*
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";>
org.eclipse.persistence.jpa.PersistenceProvider
jdbc/mcmsJta
jdbc/mcmsNonJta
false
*META-INF/context.xml* (do not configure JDBC resources here; Romain
advised me of that some weeks ago)
*{tomee-install-folder}/conf/tomee.xml*
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
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
On Mon, Dec 10, 2012 at 8:59 PM, knak55 wrote:
> 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".
>
Re: EAR IN TOMEE
Ok. I will discuss with my own and my team and think what we want. And let you know. Thanks for the advice. El dic 11, 2012 3:14 AM, "Romain Manni-Bucau" escribió: > yep, > > put all in the same ear if you want injections > > otherwise you'd need to do remote calls and there is no standard ways > to get injections > > 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 José Luis Cetina : > > My wars are outside from ear, each of one are deploy in webapps > separately. > > > > I know they can be in the same ear in different war module but i dont > like > > the idea of undeploy my entire ear if i have a change in only one war > > webapp. > > > > Im not close to have all in the same ear. I dont know if this is the way > > of ear works. > > > > Do you recommend to have all in the same ear file? > > > > Do you have any advice? > > El dic 11, 2012 1:07 AM, "Romain Manni-Bucau" > > escribió: > > > >> Wait, your wars are not in the ear? > >> Le 11 déc. 2012 02:35, "José Luis Cetina" a > écrit : > >> > >> > Anybody use ear + war files? > >> > El dic 10, 2012 3:12 PM, "José Luis Cetina" > >> > escribió: > >> > > >> > > What i need is this: > >> > > > >> > > EJB in EAR > >> > > WEBAPP1 IN WAR > >> > > WEBAPP2 IN WAR > >> > > > >> > > All of this in the same JVM in the same server. > >> > > > >> > > I want to inject my EJB's (that are in EAR file) inside of managed > bean > >> > in > >> > > webapp1 and webapp2. This because i want to reuse my Business Layer > in > >> > my 2 > >> > > webapps. > >> > > How can i do this in TomEE? > >> > > > >> > > When an EJB is consider remote? in this case my ejb's are inside an > ear > >> > > file, in this case the ejb are consider remote? or EJB's just are > >> > consider > >> > > remote when they are in different jvm's? > >> > > > >> > > > >> > > > >> > > > >> > > 2012/12/10 José Luis Cetina > >> > > > >> > >> Why i get NoClassDefFounError?? Apparently my managedbean try to > >> lookup > >> > >> EJBTest class inside of the war but how can i indicate that this > class > >> > in > >> > >> the ear file? > >> > >> > >> > >> > >> > >> 2012/12/10 José Luis Cetina > >> > >> > >> > >>> Sorry i can see i copy/paste a filter in web.xml > >> > >>> > >> > >>> This line has to be removed: > >> > >>> > >> > >>> > >> > >>> PrimeFaces FileUpload Filter > >> > >>> Faces Servlet > >> > >>> > >> > >>> > >> > >>> > >> > >>> 2012/12/10 José Luis Cetina > >> > >>> > >> > Sorry i mean, the ear its deploying WITHOUT ANY problem, but the > >> > webapp > >> > CANT find my EJB class > >> > > >> > > >> > 2012/12/10 José Luis Cetina > >> > > >> > > Here it is an example: > >> > > > >> > > http://www.sendspace.com/file/wfnwii > >> > > > >> > > The zip contains an ear maven project and webapp maven project. > >> > > > >> > > I copy the ear to apps folder now i can see that the ear its > >> > deploying > >> > > with problems, now my webapp CANT find the EJB class. > >> > > > >> > > > >> > > 2012/12/10 Romain Manni-Bucau > >> > > > >> > >> Hi, > >> > >> > >> > >> can you share the project please? > >> > >> > >> > >> 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 José Luis Cetina : > >> > >> > I cant get my EJB injected. > >> > >> > > >> > >> > 1. I drop an ear in apps folder > >> > >> > 2. Deploy my webapp in webapps folder > >> > >> > 3. Try to use @EJB in my webapp > >> > >> > > >> > >> > I always get this error: > >> > >> > > >> > >> > WARNING: Injection data not found in JNDI context: > >> > >> > > >> > >> > >> > > >> > jndiName='comp/env/com.grupokx.mailing.controlador.inicio.LoginWebMBean/local', > >> > >> > > >> target=com.grupokx.mailing.controlador.inicio.LoginWebMBean/local > >> > >> > > >> > >> > If i try with CODI: > >> > >> > UsuariosFacadeLocal facade = > >> > >> > > >> > >> > >> > > >> > BeanManagerProvider.getInstance().getContextualReference(UsuariosFacadeLocal.class); > >> > >> > > >> > >> > i get this: > >> > >> > Dec 10, 2012 9:27:55 AM > >> > >> > org.apache.webbeans.component.AbstractInjectionTargetBean > >> > >> > postConstructDefault > >> > >> > SEVERE: An error occurred while executing [@PostConstruct.] > >> > >> > java.lang.IllegalStateException: Could not find beans for > >> > >> Type=interface > >> > >> > com.grupokx.globalconfig.api.ejb.local.UsuariosFacadeLocal > and > >> > >> qualifiers:[] > >> > >> > > >> > >> > > >> > >> > 2012/12/7 Romain Manni-Bucau >
Re: TomEE: StandardSession expire
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 : > 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." 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: EAR IN TOMEE
yep, put all in the same ear if you want injections otherwise you'd need to do remote calls and there is no standard ways to get injections 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 José Luis Cetina : > My wars are outside from ear, each of one are deploy in webapps separately. > > I know they can be in the same ear in different war module but i dont like > the idea of undeploy my entire ear if i have a change in only one war > webapp. > > Im not close to have all in the same ear. I dont know if this is the way > of ear works. > > Do you recommend to have all in the same ear file? > > Do you have any advice? > El dic 11, 2012 1:07 AM, "Romain Manni-Bucau" > escribió: > >> Wait, your wars are not in the ear? >> Le 11 déc. 2012 02:35, "José Luis Cetina" a écrit : >> >> > Anybody use ear + war files? >> > El dic 10, 2012 3:12 PM, "José Luis Cetina" >> > escribió: >> > >> > > What i need is this: >> > > >> > > EJB in EAR >> > > WEBAPP1 IN WAR >> > > WEBAPP2 IN WAR >> > > >> > > All of this in the same JVM in the same server. >> > > >> > > I want to inject my EJB's (that are in EAR file) inside of managed bean >> > in >> > > webapp1 and webapp2. This because i want to reuse my Business Layer in >> > my 2 >> > > webapps. >> > > How can i do this in TomEE? >> > > >> > > When an EJB is consider remote? in this case my ejb's are inside an ear >> > > file, in this case the ejb are consider remote? or EJB's just are >> > consider >> > > remote when they are in different jvm's? >> > > >> > > >> > > >> > > >> > > 2012/12/10 José Luis Cetina >> > > >> > >> Why i get NoClassDefFounError?? Apparently my managedbean try to >> lookup >> > >> EJBTest class inside of the war but how can i indicate that this class >> > in >> > >> the ear file? >> > >> >> > >> >> > >> 2012/12/10 José Luis Cetina >> > >> >> > >>> Sorry i can see i copy/paste a filter in web.xml >> > >>> >> > >>> This line has to be removed: >> > >>> >> > >>> >> > >>> PrimeFaces FileUpload Filter >> > >>> Faces Servlet >> > >>> >> > >>> >> > >>> >> > >>> 2012/12/10 José Luis Cetina >> > >>> >> > Sorry i mean, the ear its deploying WITHOUT ANY problem, but the >> > webapp >> > CANT find my EJB class >> > >> > >> > 2012/12/10 José Luis Cetina >> > >> > > Here it is an example: >> > > >> > > http://www.sendspace.com/file/wfnwii >> > > >> > > The zip contains an ear maven project and webapp maven project. >> > > >> > > I copy the ear to apps folder now i can see that the ear its >> > deploying >> > > with problems, now my webapp CANT find the EJB class. >> > > >> > > >> > > 2012/12/10 Romain Manni-Bucau >> > > >> > >> Hi, >> > >> >> > >> can you share the project please? >> > >> >> > >> 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 José Luis Cetina : >> > >> > I cant get my EJB injected. >> > >> > >> > >> > 1. I drop an ear in apps folder >> > >> > 2. Deploy my webapp in webapps folder >> > >> > 3. Try to use @EJB in my webapp >> > >> > >> > >> > I always get this error: >> > >> > >> > >> > WARNING: Injection data not found in JNDI context: >> > >> > >> > >> >> > >> jndiName='comp/env/com.grupokx.mailing.controlador.inicio.LoginWebMBean/local', >> > >> > >> target=com.grupokx.mailing.controlador.inicio.LoginWebMBean/local >> > >> > >> > >> > If i try with CODI: >> > >> > UsuariosFacadeLocal facade = >> > >> > >> > >> >> > >> BeanManagerProvider.getInstance().getContextualReference(UsuariosFacadeLocal.class); >> > >> > >> > >> > i get this: >> > >> > Dec 10, 2012 9:27:55 AM >> > >> > org.apache.webbeans.component.AbstractInjectionTargetBean >> > >> > postConstructDefault >> > >> > SEVERE: An error occurred while executing [@PostConstruct.] >> > >> > java.lang.IllegalStateException: Could not find beans for >> > >> Type=interface >> > >> > com.grupokx.globalconfig.api.ejb.local.UsuariosFacadeLocal and >> > >> qualifiers:[] >> > >> > >> > >> > >> > >> > 2012/12/7 Romain Manni-Bucau >> > >> > >> > >> >> For injections youll need ear i think. Wonder about lookups >> (was >> > >> my idea) >> > >> >> Le 8 déc. 2012 00:18, "José Luis Cetina" > > >> > a >> > >> écrit : >> > >> >> >> > >> >> > Hi Romain i did this: >> > >> >> > >> > >> >> > 1. Create a jar file with just 1 EJB class EJBTest.class >> > >> (myejb.jar) >> > >> >> > 2. Look at the tomee.xml and found this line: > > >> dir="apps/" /> >> > >> >> > 3. I c
Re: EAR IN TOMEE
My wars are outside from ear, each of one are deploy in webapps separately. I know they can be in the same ear in different war module but i dont like the idea of undeploy my entire ear if i have a change in only one war webapp. Im not close to have all in the same ear. I dont know if this is the way of ear works. Do you recommend to have all in the same ear file? Do you have any advice? El dic 11, 2012 1:07 AM, "Romain Manni-Bucau" escribió: > Wait, your wars are not in the ear? > Le 11 déc. 2012 02:35, "José Luis Cetina" a écrit : > > > Anybody use ear + war files? > > El dic 10, 2012 3:12 PM, "José Luis Cetina" > > escribió: > > > > > What i need is this: > > > > > > EJB in EAR > > > WEBAPP1 IN WAR > > > WEBAPP2 IN WAR > > > > > > All of this in the same JVM in the same server. > > > > > > I want to inject my EJB's (that are in EAR file) inside of managed bean > > in > > > webapp1 and webapp2. This because i want to reuse my Business Layer in > > my 2 > > > webapps. > > > How can i do this in TomEE? > > > > > > When an EJB is consider remote? in this case my ejb's are inside an ear > > > file, in this case the ejb are consider remote? or EJB's just are > > consider > > > remote when they are in different jvm's? > > > > > > > > > > > > > > > 2012/12/10 José Luis Cetina > > > > > >> Why i get NoClassDefFounError?? Apparently my managedbean try to > lookup > > >> EJBTest class inside of the war but how can i indicate that this class > > in > > >> the ear file? > > >> > > >> > > >> 2012/12/10 José Luis Cetina > > >> > > >>> Sorry i can see i copy/paste a filter in web.xml > > >>> > > >>> This line has to be removed: > > >>> > > >>> > > >>> PrimeFaces FileUpload Filter > > >>> Faces Servlet > > >>> > > >>> > > >>> > > >>> 2012/12/10 José Luis Cetina > > >>> > > Sorry i mean, the ear its deploying WITHOUT ANY problem, but the > > webapp > > CANT find my EJB class > > > > > > 2012/12/10 José Luis Cetina > > > > > Here it is an example: > > > > > > http://www.sendspace.com/file/wfnwii > > > > > > The zip contains an ear maven project and webapp maven project. > > > > > > I copy the ear to apps folder now i can see that the ear its > > deploying > > > with problems, now my webapp CANT find the EJB class. > > > > > > > > > 2012/12/10 Romain Manni-Bucau > > > > > >> Hi, > > >> > > >> can you share the project please? > > >> > > >> 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 José Luis Cetina : > > >> > I cant get my EJB injected. > > >> > > > >> > 1. I drop an ear in apps folder > > >> > 2. Deploy my webapp in webapps folder > > >> > 3. Try to use @EJB in my webapp > > >> > > > >> > I always get this error: > > >> > > > >> > WARNING: Injection data not found in JNDI context: > > >> > > > >> > > > jndiName='comp/env/com.grupokx.mailing.controlador.inicio.LoginWebMBean/local', > > >> > > target=com.grupokx.mailing.controlador.inicio.LoginWebMBean/local > > >> > > > >> > If i try with CODI: > > >> > UsuariosFacadeLocal facade = > > >> > > > >> > > > BeanManagerProvider.getInstance().getContextualReference(UsuariosFacadeLocal.class); > > >> > > > >> > i get this: > > >> > Dec 10, 2012 9:27:55 AM > > >> > org.apache.webbeans.component.AbstractInjectionTargetBean > > >> > postConstructDefault > > >> > SEVERE: An error occurred while executing [@PostConstruct.] > > >> > java.lang.IllegalStateException: Could not find beans for > > >> Type=interface > > >> > com.grupokx.globalconfig.api.ejb.local.UsuariosFacadeLocal and > > >> qualifiers:[] > > >> > > > >> > > > >> > 2012/12/7 Romain Manni-Bucau > > >> > > > >> >> For injections youll need ear i think. Wonder about lookups > (was > > >> my idea) > > >> >> Le 8 déc. 2012 00:18, "José Luis Cetina" > > > a > > >> écrit : > > >> >> > > >> >> > Hi Romain i did this: > > >> >> > > > >> >> > 1. Create a jar file with just 1 EJB class EJBTest.class > > >> (myejb.jar) > > >> >> > 2. Look at the tomee.xml and found this line: > >> dir="apps/" /> > > >> >> > 3. I create the "apps" directory in APACHE-HOME/ > > >> >> > 4. Copy myejb.jar file to APACHE-HOME/directory > > >> >> > 5. Copy myejb.jar file to APACHE-HOME/lib > > >> >> > 6. Start my webapps (resides in webapps folder) > > >> >> > 7. Then try to inject my EJBTest.class with @EJB even with > CODI > > >> like > > >> >> this: > > >> >> > EJBTest facade = > > >> >> > > > >> > > BeanManagerProvider.getInstance().getContextualReference(EJBTest.class); > > >> >> > > > >>
