RE: persistance
Al, Steps 1 and 2 are already done. But using the serialization class, although faster than reparsing, is still an io operation. What I would like is to have the objects member variables of an application bean, so they would always be available, and in memory. Maybe that is the trick. Most of the time we create member variables in the scope of the session or even (if you are talking of servlets or jsp's) the page or servlet scope. Sun's latest and greatest Blueprint must use something like this, because they map their responses with xml, and they couldn't be parsing the xml everytime the app got a request (that would be horribly slow). I am still investigating this issue. Regards, Elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Allen Fogleson Sent: Saturday, March 24, 2001 9:58 PM To: Orion-Interest Subject: RE: persistance why dont you create a class that parses them and another class that keeps the results in member variables... you could then serialize the class with the results. check the file dates whenever you need to get the results and reparse if necessary, otherwise just reload the serialized class. Al -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of elephantwalker Sent: Saturday, March 24, 2001 10:40 PM To: Orion-Interest Subject: persistance I have this problem with session beans. I have certain objects which I want to be persistant across all session beans. One approach is to use an entity bean. But that's a little overkill. These are several xml files which I use to setup some of the session beans properties, but they are not expected to change. Parsing the xml files each time a session is created is another approach. But that gives me the *lag time* during the parsing, and slows down my application. Is there another alternative? Can I load a bean each time the server is restarted, or when an event occurs (say, the *datetime* changes on the file)? Has anybody else faced this problem and solved it? regards, Elephantwalker
RE: persistance - App Server level
It seems the granularity of re-use you describe is at the application or web-application level. Obviously, such objects must exist internally to Orion. There may be reasons why they are not public, but I certainly would love to see something like HttpApplication or WebApplication or whatever it may be called exposed in order to persist values while a web-app is running. Just checked - yes there is a com.evermind.server.http.HttpApplication class ... but the class isn't in the API I assume that resource-ref in web.xml can be used for this purpose at WebApp level, but I have not tried it. There may be other custom stuff to persist at the OrionServer level, too, i.e. shared by all apps - orion.properties is the place to put them according to http://www.orionsupport.com/articles/properties.html - com.evermind.server.ApplicationServer is the class, but how do I get the props without an instance (or static method) - not in the API either, but maybe I am missing out on something obvious? --peter -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of elephantwalker Sent: Saturday, March 24, 2001 8:40 PM To: Orion-Interest Subject: persistance I have this problem with session beans. I have certain objects which I want to be persistant across all session beans. One approach is to use an entity bean. But that's a little overkill. These are several xml files which I use to setup some of the session beans properties, but they are not expected to change. Parsing the xml files each time a session is created is another approach. But that gives me the *lag time* during the parsing, and slows down my application. Is there another alternative? Can I load a bean each time the server is restarted, or when an event occurs (say, the *datetime* changes on the file)? Has anybody else faced this problem and solved it? regards, Elephantwalker
Problem unpacking a war generated by Ant 1.4alpha
Hi, I am using the latest version of Ant from CVS (1.4alpha) and I generate a war file using the war task. However, this war file fails to be unpacked by Orion with the following message (that happens after about 30 seconds) : [java] java.lang.StackOverflowError [java] at java.io.Win32FileSystem.normalize(Win32FileSystem.java:114) [java] at java.io.Win32FileSystem.normalize(Win32FileSystem.java:180) [java] at java.io.File.init(File.java:183) [java] at com.evermind.naming.file.FileContext.st(JAX) [java] at com.evermind.naming.file.FileContext.createSubcontext(JAX) [java] at com.evermind.zip.a.h(JAX) [java] at com.evermind.zip.a.h(JAX) [java] at com.evermind.zip.a.h(JAX) [java] at com.evermind.zip.a.h(JAX) [...] This is war file named emptytest1.war If I revert to version 1.3 of Ant, it works fine. I have also included as attachment the war file generated by Ant 1.3 : emptytest2.war I have also put the question to the Ant mailing list (thread : "Problem with latest CVS Ant and Zips") but so far they cannot see what could have cause the problem. Would you be able to help ? Or at least to tell me what I can do to further debug the problem ? thanks. Vincent Massol. emptytest2.war emptytest1.war
RE: persistance
I haven't tried solving this problem myself, so am really just guessing. I wonder if the thing to do is stash your serialized class in JNDI, and then do a lookup and grab it when your session bean is instantiated? I'm assuming you need acess to the information in an EJB as opposed to a servlet; it seems that the rule against singletons is only for EJB's. Gary elephantwalker ([EMAIL PROTECTED]) wrote: What I would like is to have the objects member variables of an application bean, so they would always be available, and in memory. Maybe that is the trick. Most of the time we create member variables in the scope of the session or even (if you are talking of servlets or jsp's) the page or servlet scope. Sun's latest and greatest Blueprint must use something like this, because they map their responses with xml, and they couldn't be parsing the xml everytime the app got a request (that would be horribly slow). I am still investigating this issue. Regards, Elephantwalker -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Allen Fogleson Sent: Saturday, March 24, 2001 9:58 PM To: Orion-Interest Subject: RE: persistance why dont you create a class that parses them and another class that keeps the results in member variables... you could then serialize the class with the results. check the file dates whenever you need to get the results and reparse if necessary, otherwise just reload the serialized class. Al -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of elephantwalker Sent: Saturday, March 24, 2001 10:40 PM To: Orion-Interest Subject: persistance I have this problem with session beans. I have certain objects which I want to be persistant across all session beans. One approach is to use an entity bean. But that's a little overkill. These are several xml files which I use to setup some of the session beans properties, but they are not expected to change. Parsing the xml files each time a session is created is another approach. But that gives me the *lag time* during the parsing, and slows down my application. Is there another alternative? Can I load a bean each time the server is restarted, or when an event occurs (say, the *datetime* changes on the file)? Has anybody else faced this problem and solved it? regards, Elephantwalker
RE: problem running oracle with orion: 'oracle.jdbc.driver.OracleDriver' not found!
Thanks everybody for helping me with this problems. It works now! However, I could not have the jsp example code work! Could someone send me a jsp code just for the purpose of testing the connection between Orion and Oracle? Thanks! Roland -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of denis despinoy Sent: Saturday, March 24, 2001 11:09 AM To: Orion-Interest Subject: Re: problem running oracle with orion: 'oracle.jdbc.driver.OracleDriver' not found! Hi, Just copy classes12.zip (Oracle jdbc driver) in your orion/lib directory - just alongside HypersonicSQL driver hsql.jar... In Orion/config/data-sources.xml u can setup the DataSource lookup along with the url,database name usr and pwd and instance of the database u ref etc... Post if u need a copy of my data-sources.xml ! denis --- Roland Dong [EMAIL PROTECTED] wrote: I tried to run oracl with orion. When I started orion I got the following error message: Error initializing server: DriverManagerDataSource driver 'oracle.jdbc.driver.OracleDriver' not found. Where is driver supposed to be located? I have set the environment so that the class12.zip is included in the classpath. Should class="com.evermind.sql.DriverManagerDataSource" include OracleDriver? this is my data-source.xml: ?xml version="1.0"? !DOCTYPE data-sources PUBLIC "Orion data-sources" "http://www.orionserver.com/dtds/data-sources.dtd" data-sources !-- An example/default DataSource that uses an ordinary JDBC-driver (in this case hsql) to create the connections. This tag creates all the needed kinds of data-sources, transactional, pooled and EJB-aware sources. The source generally used in application code is the "EJB" one - it provides transactional safety and connection pooling. -- data-source class="com.evermind.sql.DriverManagerDataSource" name="Oracle" location="jdbc/OracleCoreDS" xa-location="jdbc/xa/OracleEJBDS" ejb-location="jdbc/Oracle" connection-driver="oracle.jdbc.driver.OracleDriver" username="scott" password="tiger" url="jdbc:oracle:thin:@uxb.wiu.edu:1521:uxora" inactivity-timeout="30" / /data-sources Please help! Roland __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
RE: Using EJBs with Delphi
Your going to have to use CORBA from what I understand. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Sergei Batiuk Sent: Saturday, March 24, 2001 8:27 AM To: Orion-Interest Subject: Using EJBs with Delphi Hi EJB gurus, Does anynone know how to connect to an EJB from a dephi client app? Thanks in advance, Sergei Batiuk.
RE: problem running oracle with orion: 'oracle.jdbc.driver.OracleDriver' not found!
Try following code in your .jsp file:
InitialContext ctx = new InitialContext();
DataSource ds = (DataSource)ctx.lookup("jdbc/Oracle");
Connection conn = ds.getConnection();
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("SELECT * FROM dual");
while( rs.next() ){
out.println( rs.getString(1) + "br" );
}
conn.close();
with best wishes,
Taavi
Thanks everybody for helping me with this problems. It works now!
However, I
could not have the jsp example code work!
Performance problems...
I've been working on getting Orion running in a production environment for a little while now and just when I thought everything was working fine I go to push to production and something load/volume related is creating massive slowdowns. Basically every 250 database accesses or so there is a long pause (20 to 60 second), where nothing occurs. During this pause the CPU load *drops* to practically nothing and our entire site is frozen. I'm not sure exactly where the problem exists; it could be our code, our configuration, or even a bug in Orion. The environment is Redhat 6.2, JDK1.3, Oracle 8i. Its a pure J2EE app, but we're not using EJB. I initially thought it might be a memory issue, but I've played with the JDK heap size and carefully watched memory utilization and thats also not the issue. I even considered that maybe Evermind/IronFlare might have a throttle (to push you to get a license) so I put one of our production licenses on the QA box. I've since gotten a load tester and can reproduce the problem. Oddly, it only happens on pages which require database access. Even more interesting is that it occurs more frequently on pages which utilize more than one connection. But thats about as far as I can narrow it. I've tried the 8.15 and 8.17 type4 jdbc drivers from oracle and we've tried Oracles ConnectionCacheImpl and Orions XADataSource implimentation, both show the same behavior (though both are using the Oracle Driver). I've also tried Orions jdbc debug and it shows nothing of interest. So far I've put about a week straight into finding it, and I've just about run out of ideas. I'd really be appreciative if anyone has any good suggestions on where to look. ANyone seen behavior like this before?
RE: Performance problems...
Q: Are you running the JVM with -server? Q: Could it be a garbage collection related problem? If it's happening at odd times when heap usage is up, it might be gc collecting old jdbc objects? -mike -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Aaron Tavistock Sent: Monday, March 26, 2001 1:09 PM To: Orion-Interest Subject: Performance problems... I've been working on getting Orion running in a production environment for a little while now and just when I thought everything was working fine I go to push to production and something load/volume related is creating massive slowdowns. Basically every 250 database accesses or so there is a long pause (20 to 60 second), where nothing occurs. During this pause the CPU load *drops* to practically nothing and our entire site is frozen. I'm not sure exactly where the problem exists; it could be our code, our configuration, or even a bug in Orion. The environment is Redhat 6.2, JDK1.3, Oracle 8i. Its a pure J2EE app, but we're not using EJB. I initially thought it might be a memory issue, but I've played with the JDK heap size and carefully watched memory utilization and thats also not the issue. I even considered that maybe Evermind/IronFlare might have a throttle (to push you to get a license) so I put one of our production licenses on the QA box. I've since gotten a load tester and can reproduce the problem. Oddly, it only happens on pages which require database access. Even more interesting is that it occurs more frequently on pages which utilize more than one connection. But thats about as far as I can narrow it. I've tried the 8.15 and 8.17 type4 jdbc drivers from oracle and we've tried Oracles ConnectionCacheImpl and Orions XADataSource implimentation, both show the same behavior (though both are using the Oracle Driver). I've also tried Orions jdbc debug and it shows nothing of interest. So far I've put about a week straight into finding it, and I've just about run out of ideas. I'd really be appreciative if anyone has any good suggestions on where to look. ANyone seen behavior like this before?
RE: Performance problems...
What is the maximum number of connections that you have configured your database pool to? Could you be running out of connections? Are you properly releasing the connections back to the pool, and closing results set which might not be needed? During the time that the site is "frozen" (as you indicate 20 to 60 seconds) can you hit a page that is not database related (a simple .JSP perhaps)? Does that return fast (this would determine if your problem is database or Orion related). Have you tried to examine what's happening on the database server side when this occurs? Just some thoughts. -AP_ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Aaron Tavistock Sent: Sunday, March 25, 2001 7:09 PM To: Orion-Interest Subject: Performance problems... I've been working on getting Orion running in a production environment for a little while now and just when I thought everything was working fine I go to push to production and something load/volume related is creating massive slowdowns. Basically every 250 database accesses or so there is a long pause (20 to 60 second), where nothing occurs. During this pause the CPU load *drops* to practically nothing and our entire site is frozen. I'm not sure exactly where the problem exists; it could be our code, our configuration, or even a bug in Orion. The environment is Redhat 6.2, JDK1.3, Oracle 8i. Its a pure J2EE app, but we're not using EJB. I initially thought it might be a memory issue, but I've played with the JDK heap size and carefully watched memory utilization and thats also not the issue. I even considered that maybe Evermind/IronFlare might have a throttle (to push you to get a license) so I put one of our production licenses on the QA box. I've since gotten a load tester and can reproduce the problem. Oddly, it only happens on pages which require database access. Even more interesting is that it occurs more frequently on pages which utilize more than one connection. But thats about as far as I can narrow it. I've tried the 8.15 and 8.17 type4 jdbc drivers from oracle and we've tried Oracles ConnectionCacheImpl and Orions XADataSource implimentation, both show the same behavior (though both are using the Oracle Driver). I've also tried Orions jdbc debug and it shows nothing of interest. So far I've put about a week straight into finding it, and I've just about run out of ideas. I'd really be appreciative if anyone has any good suggestions on where to look. ANyone seen behavior like this before?
RE: Performance problems...
And from totally out in left field, how about conflicting database transaction/table locks. I doubt it, because those tend to be indefinite, but it's a thought anyway! I suspect that the running-out-of- connections idea is more likely to be correct, though... Gary -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Aaron Tavistock Sent: Sunday, March 25, 2001 7:09 PM To: Orion-Interest Subject: Performance problems... I've been working on getting Orion running in a production environment for a little while now and just when I thought everything was working fine I go to push to production and something load/volume related is creating massive slowdowns. Basically every 250 database accesses or so there is a long pause (20 to 60 second), where nothing occurs. During this pause the CPU load *drops* to practically nothing and our entire site is frozen. I'm not sure exactly where the problem exists; it could be our code, our configuration, or even a bug in Orion. The environment is Redhat 6.2, JDK1.3, Oracle 8i. Its a pure J2EE app, but we're not using EJB. I initially thought it might be a memory issue, but I've played with the JDK heap size and carefully watched memory utilization and thats also not the issue. I even considered that maybe Evermind/IronFlare might have a throttle (to push you to get a license) so I put one of our production licenses on the QA box. I've since gotten a load tester and can reproduce the problem. Oddly, it only happens on pages which require database access. Even more interesting is that it occurs more frequently on pages which utilize more than one connection. But thats about as far as I can narrow it. I've tried the 8.15 and 8.17 type4 jdbc drivers from oracle and we've tried Oracles ConnectionCacheImpl and Orions XADataSource implimentation, both show the same behavior (though both are using the Oracle Driver). I've also tried Orions jdbc debug and it shows nothing of interest. So far I've put about a week straight into finding it, and I've just about run out of ideas. I'd really be appreciative if anyone has any good suggestions on where to look. ANyone seen behavior like this before?
Re: Performance problems...
I've had similar symptoms with ATG Dynamo. It usually occurs when the VM decides to garbage collect. The way we get around this is to have multiple Dynamo instances each with it's own dedicated VM and CPU. This makes the user experience more acceptable across all sessions on the system since the garbage collection per user is less noticeable. are you only using 1 VM right now? just a thought. Sal
Re: Removing SBs when expiring HttpSessions ... the challenge continues.
Gerald, Thank you for your explanation. But my question was a little bit different. I was wondering why to take care of removing SBs when there is remote garbage collector which is responsible for it. But maybe you want to make some special cleanning up or you are facing another type of problems I am not aware of. You wrote (snipped): ... to remove session beans that would otherwise stay active and eventually consume all resources and cause the server to crash. My original question was: Why do you think that session beans would stay active after expiring HttpSession? Don't you trust remote garbage collector which I hope is responsible for cleanning invalid session beans instances? Regards Petr - Original Message - From: Gerald Gutierrez [EMAIL PROTECTED] To: Orion-Interest [EMAIL PROTECTED] Sent: Friday, March 23, 2001 8:07 PM Subject: RE: Removing SBs when expiring HttpSessions ... the challenge continues. As with anything, the devil is in the details. SBs expire in one of a number of ways. The two main ways are: you call remove() or they time out. This is well known. So if you have your SB bound to an HttpSession, everything works and you get get your SB from the session at any time. The REAL ISSUE is, however, the security issues with how you clean up that SB when the HttpSession expires. This is something it seems no one really understands, and it seems to me to be a fairly critical to the proper working of J2EE. The servlet spec does not say anything about WHO calls HttpSessionBindingListener.valueUnbound() when an HttpSession expires. Assume (arbitrarly) that it is an "unauthenticated user" (Orion calls this a "guest"), then if you call ejb.remove() within valueUnbound(), the EJB will be called with the guest user. Well, what if the remove() method is protected by security constraints and guest is not allowed? What if you had to call other methods to clean up that session? Well, someone said "log in with a special user before calling remove()". It doesn't work because one tries to JNDI-lookup a RoleManager to log in, Orion throws an exception saying "javax.naming.NamingException: Not in an application scope". Okay, so just call remove() and do the login in there. That DID work, but WHY? I have my remove() method secured so only authenticated users can hit it. And what if you had to call OTHER methods in addition to remove()? From the responses, it seems either that no one has previously recognized this as a problem, or that they're ignoring it, or I'm just all wrong. So please, am I wrong, or is there an issue here? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Petr Podsednik Sent: Friday, March 23, 2001 12:37 AM To: Orion-Interest Subject: Re: Removing SBs when expiring HttpSessions ... the challenge continues. Hi, If It is possible I have a question regarding this problem. Until now I was thinking there is no problem regarding HttpSession expiring because of garbage collector which knows what remote references became invalid. Please tell me, if I am wrong and why. If it is must be handled in code what about for example Swing clients machine's crashing? Regards Petr When an HttpSession expires, it calls valueUnbound() on all session-bound variables that implement the HttpSessionBindingListener interface. So this provides a way for expiring HTTP sessions to remove session beans that would otherwise stay active and eventually consume all resources and cause the server to crash.
Re: access to pooled datasources through JNDI?
As far as I know, you can't access datasource connections 'remotely'. On Sun, 25 Mar 2001, Duane Fields wrote: I've a problem accessing a pooled datasource from OUTSIDE the web application. I can access and use the regular datasource, but when I try to get a connection from the pooled datasource I get null pointer exceptions from orion's pooled driver. The scenario is this: I have defined a data-source with Sybase... data-source name="Default data-source" class="com.evermind.sql.ConnectionDataSource" location="jdbc/DefaultDS" pooled-location="jdbc/DefaultPooledDS" xa-location="jdbc/xa/DefaultXADS" ejb-location="jdbc/DefaultEJBDS" url="jdbc:sybase:Tds:dfields:4201/sponsortool" connection-driver="com.sybase.jdbc2.jdbc.SybDriver" username="myuser" password="mypassword" schema="database-schemas/sybase.xml" min-connections="5" max-connections="10" inactivity-timeout="30" / In my app and my outside clients and test code, I use JNDI to grab a default datasource, and use it, my JNDI properties are: java.naming.factory.initial=com.evermind.server.ApplicationClientInitialCont extFactory #java.naming.factory.initial=com.evermind.server.rmi.RMIInitialContextFactor y java.naming.provider.url=ormi://localhost/ java.naming.security.principal=admin java.naming.security.credentials=123 From the servlets and JSPs, I can access both the pooled datasource and the regular datasource just fine, but not from outside applications. Outside applications only work with the core datasource, not the pooled. It's not that they fail to get the datasource reference from JNDI, It's that orionserver gets NULL POINTER exceptions when I try to get a connection from it. Observe: java.lang.NullPointerException at com.evermind.sql.OrionPooledDataSource.d7(JAX) at com.evermind.sql.OrionPooledDataSource.d8(JAX) at com.evermind.sql.OrionPooledDataSource.getConnection(JAX) I've tried both the RMI and ApplicationContext Factories, with the same results, although my outside applications are not ejb-client applications. In fact, I'm deploying my app as a j2ee application but am not using EJBs. I've been banging my head on this problem for several weeks, and would appreciate any insight anyone out ther would have into this. Thanks! -- Duane Fields [EMAIL PROTECTED] Sr. Software Engineer NetSpend Corporation
SV: Problem with Filters and RequestDispatcher in Orion 1.4.5
I like that I can just apply my filter to any application without changing anything in the application itself. Anders -Ursprungligt meddelande- Frn: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Fr Marcel Schutte Skickat: den 23 mars 2001 14:42 Till: Orion-Interest mne: Re: Problem with Filters and RequestDispatcher in Orion 1.4.5 Just out of curiosity, but why don't you use the standard servlet provisions for authentication? Are there things you can do more easily using filters? I'm just starting to look at what filters can do, so any comments are welcome. Marcel - Original Message - From: "Anders Janmyr" [EMAIL PROTECTED] To: "Orion-Interest" [EMAIL PROTECTED] Sent: Friday, March 23, 2001 1:02 PM Subject: SV: Problem with Filters and RequestDispatcher in Orion 1.4.5 SV: Problem with Filters and RequestDispatcher in Orion 1.4.5My filter and it's mapping is shown below. Tomcat does not invoke the filter when the RequestDispatcher is used. Since the RequestDispatcher is internal it would seem that it should not invoke the filters. This is however not specified in the Servlet2.3 spec. As you can see in this configuration the LoginPage is in the protected directory. If I move it out everything works properly unless I try to include a file from the protected directory. Then the filter is invoked again. I don't think this is the way it should work. Anders filter filter-nameHtmlLoginFilter/filter-name filter-classcom.netpuls.servlet.LoginFilter/filter-class init-param param-nameloginPage/param-name param-value/html/login.jsp/param-value /init-param init-param param-namefailedLoginPage/param-name param-value/html/failedLogin.jsp/param-value /init-param init-param param-nameloginHandler/param-name param-valuecom.netpuls.np.WebUser/param-value /init-param /filter filter-mapping filter-nameHtmlLoginFilter/filter-name url-pattern/html/*/url-pattern /filter-mapping -Ursprungligt meddelande- Frn: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]Fr Magnus Rydin Skickat: den 23 mars 2001 09:46 Till: Orion-Interest mne: SV: Problem with Filters and RequestDispatcher in Orion 1.4.5 How does your filter mapping look? Does Tomcat ivoke filters on forward/include? WR -Ursprungligt meddelande- Frn: Anders Janmyr [mailto:[EMAIL PROTECTED]] Skickat: den 23 mars 2001 00:25 Till: Orion-Interest mne: Problem with Filters and RequestDispatcher in Orion 1.4.5 Hello, I am trying to use filters for authenticating users. My filter uses RequestDispatcher.forward to show a login page when the user needs to authenticate himself. This results in the filter beeing invoked again. It seems that the RequestDispatcher in orion (both forward and include) invokes the filter again. Tomcat does not do this. What is the correct behavior? The spec does not say how it should be working. Any help would be appreciated. Anders
