IllegalStateException
Hi! I have a strange problem which I can't find a solution to. I am running a system with a two message-driven beans and a couple of entity beans. They are all listening to (and able to publish messages to) the same Topic. One of the entity beans contains a Timer with a couple of TimerTasks that publish messages to the topic that tells to mdb:s to do different things. I also have a jsp that refreshes itself every couple of minutes. When the system has been up and running for a while I suddenly get a very strange error. When the self-refreshing jsp-page (or load any other jsp-page connected to the system) is loaded I get "java.lang.IllegalStateException: Transaction expired (Committed)" and a reference to the line in the jsp where I try to connect to the Home interface and run the create(), findByPrimaryKey() or findAll() methods. Does anybody know why this happens and have a sollution? I log all the messages sent to the topic, and the timer-bean keeps sending messages after the error occurs... Thanks, Magnus -- Magnus Hoem [EMAIL PROTECTED] Phone: +46-8-343206 Cell: +46-733-343206
ClassDefNotFound Exception
I was setting up SOAP on Orion and have run into a problem. Anytime I try to use any of the SOAP admin pages( List, Deploy, and un-deploy) I get a ClassDefNotFound Exception for HttpServlet on this line: ServiceManager serviceManager = org.apache.soap.server.http.ServerHTTPUtils.getServiceManagerFromContext(application); I believe it is having a problem on the application call. I guessing that if can not find orion.jar or ejb.jar or it is looking for j2ee.jar. I've set up SOAP by following the HOWTO on Atlassian and it looks fine and can find the soap.jar. Has anyone seen this before and can give me some insight as to what the problem might be? Jonathan Bricker Lilly Research Labs Java ATG
getHeaderNames();
Does anyone know why the request.getHeaderNames() returns the headernames as uppercase in orion? regards /Linus
TX Was Null
We're coming up on our deployment date, so we're considering our deployment options (notably, at this point, JBoss and Orion). The system is running and working under JBoss, and I've been re-porting it to Orion so that we can do some testing, try and resolve some issues we had under Orion (for which we got some help from Atlassian that we haven't had a chance to try out yet). In the process, we've re-adjusted most or all of the finders, and fixed a few bugs here and there between what JBoss does and what Orion does. It's been enlightening, as usual. That said, we've run up against a brick wall. One of our transactional saves uses a session bean to save two entities in a combined declarative transaction. Each of these beans can throw validation exceptions when passed data that's meant to save. We have two unit tests, one which throws invalid data into the first object, and another which throws invalid data into the second object. The second object is relatively easy -- if it has problems, the session bean sets the transaction to rollback only, and lets the server do the rest of the work. This works under both Orion and JBoss as expected. If the first object fails, though, there are larger issues -- we still want to find out if there's a problem with the data being passed to the second object. Under JBoss, if we tried to do this in the same transaction, it complained that the transaction was already rolled back, which is sensible. So we put the validation method into a 'requires new' transaction. On JBoss, if the first object fails, the second one tests its data in a new transaction, gathers the validation errors, and rolls back. On Orion, this seems to create an exception: Testcase: testProgramRollback took 4.703 sec Caused an ERROR Transaction was rolled back: Error in transaction: java.lang.InternalError: TX was null; nested exception is: java.lang.InternalError: TX was null com.evermind.server.rmi.OrionRemoteException: Transaction was rolled back: Error in transaction: java.lang.InternalError: TX was null at TransactionalSaver_StatelessSessionBeanWrapper176.saveProgramAndCaseStudy(Tr ansactionalSaver_StatelessSessionBeanWrapper176.java:104) at java.lang.reflect.Method.invoke(Native Method) at com.evermind._dh._gc(Unknown Source) at com.evermind._if.run(Unknown Source) at connection to localhost/127.0.0.1 as thesquareUser at com.evermind._cd.EXCEPTION_ORIGINATES_FROM_THE_REMOTE_SERVER(Unknown Source) at com.evermind._cd.invokeMethod(Unknown Source) at com.evermind._dn.invoke(Unknown Source) at __Proxy7.saveProgramAndCaseStudy(Unknown Source) at com.mediumone.thesquare.ejb.transactionalSaver.liveTest.TransactionalSaverTe st.testProgramRollback(TransactionalSaverTest.java:69) at java.lang.reflect.Method.invoke(Native Method) at junit.framework.TestCase.runTest(TestCase.java:166) at junit.framework.TestCase.runBare(TestCase.java:140) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:131) at junit.framework.TestSuite.runTest(TestSuite.java:173) at junit.framework.TestSuite.run(TestSuite.java:168) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRu nner.java:231) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestR unner.java:409) Nested exception is: java.lang.InternalError: TX was null at com.evermind.server.ejb.EntityEJBObject.endTransaction(Unknown Source) at com.evermind.server.ApplicationServerTransactionSynchronization._vib(Unknown Source) at com.evermind.server.ApplicationServerTransaction._vib(Unknown Source) at com.evermind.server.ApplicationServerTransactionSynchronization.afterComplet ion(Unknown Source) at com.evermind.server.ApplicationServerTransaction._end(Unknown Source) at com.evermind.server.ApplicationServerTransaction.end(Unknown Source) at TransactionalSaver_StatelessSessionBeanWrapper176.saveProgramAndCaseStudy(Tr ansactionalSaver_StatelessSessionBeanWrapper176.java:100) at java.lang.reflect.Method.invoke(Native Method) at com.evermind._dh._gc(Unknown Source) at com.evermind._if.run(Unknown Source) at connection to localhost/127.0.0.1 at com.evermind.server.rmi.OrionRemoteException._os(Unknown Source) at com.evermind._cd._mx(Unknown Source) at com.evermind._cd.run(Unknown Source) at java.lang.Thread.run(Thread.java:484) I'm basically unable to diagnose why this error would occur. Does anyone have any suggestions? - Geoffrey __ Geoffrey Wiseman: Internet Applications Manager Medium One :
RE: IllegalStateException
You mention that one of the entity beans contains a timer, but you have not mentioned how are you holding on to that timer. Is it a "Static" reference in the entity bean or is it a Member of the EJB? Container could physically remove the EJB from memory at any time, how are you dealing with this? A typical Timer implementation uses a thread. You cannot start or stop threads in an EJB object. If you want to use a timer, you might want to consider using an external object that lives outside of EJB and triggers events on a periodic basis. If you need access to that object you might want to create an RMI object, and deploy it into the orion JNDI tree so you can have access to it from EJB. -AP_ -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Magnus HoemSent: Monday, January 28, 2002 3:33 AMTo: Orion-InterestSubject: IllegalStateExceptionHi!I have a strange problem which I can't find a solution to. I am running a system with a two message-driven beans and a couple of entity beans. They are all listening to (and able to publish messages to) the same Topic. One of the entity beans contains a Timer with a couple of TimerTasks that publish messages to the topic that tells to mdb:s to do different things. I also have a jsp that refreshes itself every couple of minutes. When the system has been up and running for a while I suddenly get a very strange error. When the self-refreshing jsp-page (or load any other jsp-page connected to the system) is loaded I get "java.lang.IllegalStateException: Transaction expired (Committed)" and a reference to the line in the jsp where I try to connect to the Home interface and run the create(), findByPrimaryKey() or findAll() methods. Does anybody know why this happens and have a sollution?I log all the messages sent to the topic, and the timer-bean keeps sending messages after the error occurs...Thanks,Magnus--Magnus Hoem[EMAIL PROTECTED]Phone: +46-8-343206Cell: +46-733-343206
What is a Dirty Connection (using -Djdbc.debug=true)
I already asked this question in a different thread but didn't get a reply, so let's try again. What is a Dirty Connection (when using -Djdbc.debug=true)? What causes it and what repercussions does it have? Is a Dirty Connection a bad thing, and if so, what can we do to avoid it (if anything)? Are there any settings that control when and if they are cleaned up? are they cleaned up at all? I appreciate any information you may have. Thanks in advance, Jeff.
RE: Job Scheduler pattern
Hmm, want us to write it for you? But seriously, there are commercial apps for J2EE scheduling if that's the kind of thing you are after, just use google... Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Justin Crosbie Sent: Saturday, January 26, 2002 2:49 AM To: Orion-Interest Subject: RE: Job Scheduler pattern Yes I have seen that, it is very bare-bones. It doesn't even use the Timer classes. I need to know how to make this robust. Thanks, Justin -Original Message- From: Joseph B. Ottinger [mailto:[EMAIL PROTECTED]] Sent: 25 January 2002 12:04 To: Orion-Interest Subject: Re: Job Scheduler pattern The www.orionsupport.com site has a sample scheduler that can easily be converted to do something like this. On Fri, 25 Jan 2002, Justin Crosbie wrote: Hi, I'm not sure if I've asked this before, or if I should be asking on a general EJB list. I'd like to implement a job scheduler in J2EE. This would shcedule the execution of EJB methods at a specified time in the future. It would have to be persistent, and jobsd would be rescheduled upon appserver restart. Is it as simple as using the Timer and TimerTask in java.util to implement an app that is started with the client-module tag? Does it matter as far as Orion goes whether I use a java.util.Timer as a daemon or not? What can I do if the app, or the Timer object dies at any stage? I've had problems where after some time something goes wrong I get a strange Remote Exception, and the only solution is to restart the VM. What might cause this? Any opinions on this? How do I make this solution robust is what I am asking. Thanks for any help, Justin --- Joseph B. Ottinger [EMAIL PROTECTED] http://adjacency.org/ IT Consultant
cgi question [EXPIRED TRIAL LICENCE]
Does anyone know if orion can server cgi and what needs to be done if so. Thanks
Re: Job Scheduler pattern
There is an interesting article on DevX regarding timer tasks. http://www.devx.com/premier/mgznarch/Javapro/2002/02feb02/eb0202/eb0202-2.asp It looks like it does what you want. Cheers, Scott Scott Farquhar [EMAIL PROTECTED] Atlassian :: www.atlassian.com Supporting YOUR world Geoff Soutter wrote: Hmm, want us to write it for you? But seriously, there are commercial apps for J2EE scheduling if that's the kind of thing you are after, just use google... Geoff -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Justin Crosbie Sent: Saturday, January 26, 2002 2:49 AM To: Orion-Interest Subject: RE: Job Scheduler pattern Yes I have seen that, it is very bare-bones. It doesn't even use the Timer classes. I need to know how to make this robust. Thanks, Justin -Original Message- From: Joseph B. Ottinger [mailto:[EMAIL PROTECTED]] Sent: 25 January 2002 12:04 To: Orion-Interest Subject: Re: Job Scheduler pattern The www.orionsupport.com site has a sample scheduler that can easily be converted to do something like this. On Fri, 25 Jan 2002, Justin Crosbie wrote: Hi, I'm not sure if I've asked this before, or if I should be asking on a general EJB list. I'd like to implement a job scheduler in J2EE. This would shcedule the execution of EJB methods at a specified time in the future. It would have to be persistent, and jobsd would be rescheduled upon appserver restart. Is it as simple as using the Timer and TimerTask in java.util to implement an app that is started with the client-module tag? Does it matter as far as Orion goes whether I use a java.util.Timer as a daemon or not? What can I do if the app, or the Timer object dies at any stage? I've had problems where after some time something goes wrong I get a strange Remote Exception, and the only solution is to restart the VM. What might cause this? Any opinions on this? How do I make this solution robust is what I am asking. Thanks for any help, Justin --- Joseph B. Ottinger [EMAIL PROTECTED] http://adjacency.org/ IT Consultant
RE: TX Was Null
I don't think that relying on your Entity Beans for front line data validation is a good design. As a rule of thumb to get the best performance in applications you want to validate as early as you can to save the trouble of having to process all the steps for a transaction only to find the data is invalid when you want to save things and use this to throw an error. In most app servers you usaully set transaction retries to at least 2 (incase there was a network/temporary error on the first attempt this increases the reliablity) - by throwing data validation exceptions at the EJB level you are looking at doing a TX twice before reporting the error ... terrible performance. What I have done in projects is to abstract validation to a set of Validation classes that are normal java classes which can be used on the jsp/ejb etc etc tier. These classes interact with the database via singleton caches allowing for dynamic validation updates (worth their weight in gold). This also means that the stand alone validation objects can be easily reused in other projects, expecially the rules that are generic enough :). Using a separate set of validation classes I would suggest: 1) Validate the TX at the point where it starts right up front if you are using jsp etc if this is an option. 2) Validate the TX in the actual session bean. We use a custom exception with a Vector of string mappings that allows us to complain about more than one error etc. 3) If you are really paranoid/have mutiple update points you can also validate at the entity bean and even a littel at the db level (not null, size etc). Since you are using a shared validation library, changing the validation is done in one place. In addition your application = 100 times faster since you are not rolling back transactions a million times over. And the big bonus is it will work on 99% of app servers. Regards, Manuel -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of [EMAIL PROTECTED] Sent: Monday, January 28, 2002 5:13 PM To: Orion-Interest Cc: [EMAIL PROTECTED] Subject: TX Was Null We're coming up on our deployment date, so we're considering our deployment options (notably, at this point, JBoss and Orion). The system is running and working under JBoss, and I've been re-porting it to Orion so that we can do some testing, try and resolve some issues we had under Orion (for which we got some help from Atlassian that we haven't had a chance to try out yet). In the process, we've re-adjusted most or all of the finders, and fixed a few bugs here and there between what JBoss does and what Orion does. It's been enlightening, as usual. That said, we've run up against a brick wall. One of our transactional saves uses a session bean to save two entities in a combined declarative transaction. Each of these beans can throw validation exceptions when passed data that's meant to save. We have two unit tests, one which throws invalid data into the first object, and another which throws invalid data into the second object. The second object is relatively easy -- if it has problems, the session bean sets the transaction to rollback only, and lets the server do the rest of the work. This works under both Orion and JBoss as expected. If the first object fails, though, there are larger issues -- we still want to find out if there's a problem with the data being passed to the second object. Under JBoss, if we tried to do this in the same transaction, it complained that the transaction was already rolled back, which is sensible. So we put the validation method into a 'requires new' transaction. On JBoss, if the first object fails, the second one tests its data in a new transaction, gathers the validation errors, and rolls back. On Orion, this seems to create an exception: Testcase: testProgramRollback took 4.703 sec Caused an ERROR Transaction was rolled back: Error in transaction: java.lang.InternalError: TX was null; nested exception is: java.lang.InternalError: TX was null com.evermind.server.rmi.OrionRemoteException: Transaction was rolled back: Error in transaction: java.lang.InternalError: TX was null at TransactionalSaver_StatelessSessionBeanWrapper176.saveProgramAndCaseStudy(Tr ansactionalSaver_StatelessSessionBeanWrapper176.java:104) at java.lang.reflect.Method.invoke(Native Method) at com.evermind._dh._gc(Unknown Source) at com.evermind._if.run(Unknown Source) at connection to localhost/127.0.0.1 as thesquareUser at com.evermind._cd.EXCEPTION_ORIGINATES_FROM_THE_REMOTE_SERVER(Unknown Source) at com.evermind._cd.invokeMethod(Unknown Source) at com.evermind._dn.invoke(Unknown Source) at __Proxy7.saveProgramAndCaseStudy(Unknown Source) at com.mediumone.thesquare.ejb.transactionalSaver.liveTest.TransactionalSaverTe st.testProgramRollback(TransactionalSaverTest.java:69) at java.lang.reflect.Method.invoke(Native Method)
