Re: Settings for pooled datasources, timeout errors
Hi From: "Jens Stutte" [EMAIL PROTECTED] no, it is a SAP DB kernel problem. Does it mean this problem exists for R/3 installations - I mean they need a reboot after a couple of million SQL statements? Hard to believe! Do all SAP customers only have toy problems? ;-)) Never used Firebird (and, maybe i should be ashamed, never heard of it). SAP DB by now was the only database, that was solid enough to fit our needs (including some non-free software :-). If only this stupid max statement problem did not exist... Firebird used to be called Interbase from Borland. I recently posted here how to use it with Orion. Bye, Falk
Re: Settings for pooled datasources, timeout errors
Hi Jens, interesting posting! I think You still could get the JDBC source code (since it is open source now and there is a download option for it). Maybe, the bug is in jdbc, not the sapdb itself. Then You could fix it (maybe running a 36h debug session ;-) and post the fix. I mean, isn't it this open source is all about? I have a side question: I've set up Firebird and SapDB successfully with our EJB application. Performance seems to be the same while SapDB has much more options and Firebird has a much smaller footprint. Can You give any hint when to use which database? They are bith open source and both seem solid software. Bye, Falk - Original Message - From: "Jens Stutte" [EMAIL PROTECTED] com.sap.dbtech.jdbc.exceptions.DatabaseException: SAP DBTech SQL: [750] Too many SQL statements (work rolled back) I talked with someone from SAP and they told me, that there is a limit of "several million statements" that can be executed within one open connection, then it quits work (it does not matter, if these statements are within different transactions, it's a per session limit). Clearly, this is a SAP problem, but i tried to avoid it with orion's datasource settings. While
Re: Calibrating EJB Pooling in Orion
Hi again, - Original Message - From: Tibor Hegyi Furthermore, despite the overtime Entity instances are removed from the instance pool, the amount of memory does not reduce at all!. Quite strange and bad news (if true) to those of many complaining about memory problems. At least according to WinNT's Task-manager. Can anybody confirm this? Well, isn't this the default behaviour of the Java VM? I have seen that option '-incGC' (or similiar) can lead to memory returned to the OS but speed is sacrified somewhat. Falk
Re: Calibrating EJB Pooling in Orion
Hi Tibor, I may have no answers but volunteer to discuss the issue with You... - Original Message - From: Tibor Hegyi My test application scenario is: servlet-SLSB-SFSB-Entity. (A - B: means A instantiates B and calls business methods on it) 1. When the SLSB bean looks up the home interface of SFSB, the SFSB's ejbActivate is called a few dozens times. Why? Does Orion create pre-pooled instances of Stateful session beans (before they have been created explicitely)? Strange. The same number of ejbPassivate-calls are performed when I shut down the server. No. ejbActivate() is called when a bean needs to be in ready state. One possible explaination could be that Orion persists SFSB so that they survive a server restart. This is an option in the spec which Orion chooses to implement. Fine so far. Something looks dangerous: You create a SFSB from a SLSB. I would presume that each time you instantiate the SFSB you create a new instance - even if you are in the same session!! The correct way (IMHO) is to instantiate a SFSB from a servlet of session scope and store its reference in its session context. As always, I may be wrong. 2. What does the number of this kind of pre-pooled beans depend on? Strange. I changed the timeout value in orion-eib.jar from 1800 sec to 10 sec but Orion behaves the same way. Strange. The SFSB should go away (return to pooled state calling ejbPassivate()) after the session expires. It seems to me that Orion somehow remembers the maximum number of usage of a SFSB and next time after orion is RESTARTED it creates the same number of pseudo-instances as I described above. Could this be the case? No. cf. my text above. Entity beans: I set up max-instances and validity-timeout attributes in orion-ejb.jar. Despite this: 1. When issuing a findAll (or any multiple result findXXX method) method call on the Entity Home the number of instances may exceed the max-instances setting. Hence the number of entity instances can increase endlessly potentially causing an out-of-memory problem. Strange. Are you sure? Normally, EB are reused from one business method to another. Maybe, You touch *all* members of the collection returned from the finder within a single transaction? BTW, if two business methods overlap in time, an EB may exist in multiple instances even for the same primary key! When recursions occur you need to start to think about proper EB deployment settings. Orion has a flag wether to preload EBs on a finders. The flag defaults to true. Maybe, you need to set it to false? Anyway, the max-instance setting may only affect EBs not currently in a business method. 2. After the validity-timeout has elapsed AND the number of max-instances was exceeded AND a new instance is being created, the non-valid (over validity-timeout) ones are removed from the pool. Looks ok, because you are between two business methods. The max-instance setting can only become effective when a new instance is needed AND there *are* any idle EBs (when a new one is created the server needs to decide wether to passivate an existing EB or to create a new one. Why should the server ever touch an EB outside this decision making?). So that's it. If anyone could give us (some might also be interested in this topic) explanation or share his/her expreiences I would appreciate very much. Tibor Hegyi Falk -- Dr. Falk Langhammer Living Pages Research GmbH Holzstr. 19 D-80469 Munich, Germany mailto:[EMAIL PROTECTED] http://www.living-pages.de Phone +49 (89) 260 255 32Fax +49 (89) 260 255 35
Re: Orion crashed under load test
Orion crashed under load testHi Eyal, we've put Orion 1.4.7 here under a 1-cpu stress test (80 concurrent requests of type JSP(1)-EJB(1)-EJB(n)-DB(n)) and it was ok. Win2k and JDK1.3. It reached a throughput of 200 transactions per second (466 MHz Celeron with Firebird/Interbase). Latency then went up to about 4 seconds per transaction. It is reported that JBuilder debugging is unstable with IBM JDK under Linux but not Sun's JDK. Therefore, I speculate that you crosscheck with Sun's JDK. Bye, Falk - Original Message - From: Eyal Litman (Kamoon IL) I load tested orion under linux red hat 7 and IBM 1.3 JDK. Orion crashed after few minutes of "easy" load. Does anybody had some similar problems ? Could IBM 1.3 JDK could be the cause ? Thanks in advance, Eyal Litman Server Side Team, Kamoon Ltd.
Re: How to set orion to perform a timely task..
I think, the most clean approach would be to have a cron job which starts an EJB client every time. Bye, Falk - Original Message - From: [EMAIL PROTECTED] I need to have my EJB perform some DB operation at midnight everyday. How do I do that?
Re: EJB values into xml attributes (a little off topic, I know)
Hi Randahl, - Original Message - From: "Randahl Fink Isaksen" [EMAIL PROTECTED] XMLEscaper.escape(Book.getPreface()) for all the output you take from your beans and use to generate XML really sounds like a mess to me. While we are at it: If you just *have* to do this conversion, why not do it when you put information into the beans rather than when you take it back Well, we do need unescaped string properties in the beans to do the business logic right. If a companies name is "Smith Wesson" it is not "Smith amp; Wesson". Think that somebody is searching for this company in an EJB-client. As a general note, the entire problem belongs to the topic of "Java object - XML mapping". This is much researched right now with no de-facto standard I know of yet. There is a SUN community process for this topic. Until then, I suggest at least JDOM should handle Java Strings internally. Bye, Falk
JSP set-property bug
Hi list, I believe that there is a bug in Orion's JSP engine (1.4.5). jsp:setProperty name="webpublish" property="*" / About 6 out of 53 properties are not set. When I set those explicitely as in jsp:setProperty name="webpublish" property="previewCheckBoxState" / everything is ok. Because 12 properties are structurally identical (just different names) I guess that there is a hard number in the # of properties which Orion can handle via reflection (the "*"-tag). The JSP works ok under Tomcat. Anyone who can confirm this is a bug? Is it in bugzilla? I tend to enter it as a bug there but wanted to ask the list first. Bye, Falk
Re: EJB values into xml attributes (a little off topic, I know)
!DOCTYPE doc [ !ENTITY "amp;" ] I do not think this is legal. (1) Recursive entitity declaration (2) amp; is predefined, is reserved as entity prefix. I do not think that You can redefine the XML grammar by defining "" or "" as entities. In summary, You do not need the DOCTYPE at all. (I haven't read the spec recently, I may be wrong). Then, to my understanding, doc:p/doc:p should be p/p because doc: is a namespace prefix, not a DOCTYPE prefix. p/p should be pamp;/p (cf. above) Therefore, You have the same problem for elements and attributes. We do have the same problem and solve it by transforming all strings by our class XMLEscaper or (where elements may use CDATA when it must preserve whitespace and linefeeds) before generating XML. I would be surprised if there existed some magic avoiding this step. [EMAIL PROTECTED] has proposed this magic to the JDOM list such that Java strings can be passed in and out of elements and attributes without worry. Dunno what happened to this proposition. JDOM *is* the place where this problem should be fixed. Bye, Falk
Re: Database schema type mappings
- Original Message - long millisInMonth = (long)1000 * 60 * 60 * 24 * 30; This should probably go in some sort of Java-puzzle magazine article. :-) I think this is a standard situation in Java and C. Most programmers would probably write it as long millisInMonth = 1000L * 60L * 60L * 24L * 30L; only casting "(long)1000..." is safe only as long as the remainder of the expression fits an int. Use non-captital "l" rather than "L" as in long millisInMonth = 1000 * 60 * 60 * 24l * 30; // right long millisInMonth = 1000 * 60 * 60 * 241 * 30; // wrong for Your Java puzzle. Depending on the font used it may be impossible to spot the error ;-))
Re: Starting threads not permitted in servlet?
Somebody on this list said that you're not allowed to start threads inside a servlet container. Is this really in the spec (this was claimed), or is it implementation-dependent? I am not sure for the web container. But the situation is even fuzzy for an EJB container. I believe that in Orion, there isn't much difference between the two (except for the RMI and wrapper subclasses). Here is what the Borland BAS4.5 spec says about the EJB programming restrictions: ---8--- Verifies in accordance with pedantic EJB 1.1 rules. There are four warnings that have been classified as pedantic: -- Throwing java.rmi.RemoteException from a bean method is deprecated. -- Static fields in the bean class must be final. (This is actually a useful rule, which is violated by the Java compiler.) -- The primary key type must define the equals(Object) method. -- The primary key type must define the hashCode() method. The behavior of the verifier is that, by default, these rules are ignored. Choosing the Pedantic option causes violations of these rules to issue warnings. For deployment purposes, warnings are ignored, meaning that you can go ahead and deploy beans which have warnings. However, you cannot deploy beans which have errors. Keep in mind the following about pedantic verification: 1) Not actually required by our runtime, meaning that your code will work as is. 2) Questionable altogether, and may well be eliminated from the EJB specification when people realize how annoying they are. 3) Violated in almost every EJB program ever written, both in our product and in all the various books ever written about EJB. ---8--- Especially, note point 3) :-)) - Below is a list of programming restrictions defined in the EJB 1.1 specification. An enterprise bean is not allowed to manage threads and thread groups. It should not start new threads or resume suspended threads, nor should it terminate or suspend the running thread. In addition, an enterprise bean should not change a thread's priority or its name. An enterprise bean is not allowed to use read/write static fields. Using read-only static fields is allowed. Therefore, all static fields must be declared as final. An enterprise bean is not allowed to use thread synchronization primitives to synchronize the execution of multiple instances. An enterprise bean must not use the Java AWT functionality to output information to a display or to accept information from a keyboard. An enterprise bean should not use the java.io package to access files and directories in the file system. An enterprise bean should refrain from using sockets; in particularly, the bean should not listen on a socket, accept connections on a socket, or use a socket for multicast. In addition, it should not set the socket factory used by ServerSocket, Socket, or the stream handler factory used by URL. An enterprise bean must not access classes or packages, or attempt to obtain information about classes, in a manner normally disallowed by the Java programming language or if the classes are normally unavailable to the enterprise bean. An enterprise bean must not access the runtime environment functions normally handled by the container--create a class loader or access or change its context, set or create a security manager, stop the JVM, change input, output, or error streams. An enterprise bean must not obtain security policy information for a particular code source as this would compromise security. An enterprise bean must not load a native library. An enterprise bean must not define a class in a package, as this is a function reserved for the container for security reasons. An enterprise bean must not use the subclass and object substitution features of the Java Serialization Protocol. An enterprise bean should be careful if passing this as an argument or method result. It is safer for the bean to pass the result of SessionContext.getEJBObject() or EntityContext.getEJBObject(). An enterprise bean is not allowed to access or modify security configuration objects. For example, it is not allowed to change its java.security.Identity. Any such attempt will result in the java.security.SecurityException being thrown.
Re: HELP!!! - Using UserManagers - Logging in users without asking for credentials
Thanxs for the hint.
I could also think of a more portable solution to this problem.
If it is just to provide single sign-on, I would, from within the
client-servlet, first access any page known to be form-based login-proteced
and reply with a post containing j_username and j_password. Store the
session cookie in your servlet. Ignore the response.
Then it now comes to access the protected resource, rather than packaging
user-credentials into the request just set the cookie in the http-header and
You are done.
This has the added benefit that Your servlet may login over https while
accessing the protected resource over faster http. And it works with any
J2EE server.
Bye,
Falk
- Original Message -
Subject: RE: HELP!!! - Using UserManagers - Logging in users without asking
for credentials
You want to use the RoleManager:
Context ctx = new InitialContext();
RoleManager roleMan =
(RoleManager)ctx.lookup("java:comp/RoleManager");
try
{
roleMan.login(memberName, password);
}
catch (SecurityException ex)
{
return false;
}
return true;
-Original Message-
From: Chris Evans [mailto:[EMAIL PROTECTED]]
servlet accept requests from another website. Balled up in that request
would be user credentials(ie: username, password, etc...). From the
Fw: configuring jdbc with oracle...
I do not know the solution, but three things come to my mind...
- Original Message -
From: Paul Wilcox
Using DataSource ds = (DataSource)
ctx.lookup("java:comp/env/jdbc/DefaultDS");
instead of DataSource ds = (DataSource) ctx.lookup("jdbc/DefaultDS"); (or
jdbc/DefaultCoreDS)
---
javax.naming.NameNotFoundException: jdbc/DefaultDS not found in
defaultWebApp
I suggest You start Orion in console mode (java -jar orion.jar -console).
There, You see the datasources (Global application, Context).
For one thing, the JNDI-name to lookup is "jdbc/DefaultDS", not
"java:comp/jdbc/DefaultDS" and not at all "java:comp/env/jdbc/DefaultDS".
This is where You should see the datasource in the console tree.
Second, You can check if datasource is ok by clicking "list tables" in the
console. If this doen't work, its your setting, not your application.
Third, I do not know Oracle settings, but
url="jdbc:oracle:thin:@ultra:1521:account_type" looks strange to me. Does
this string contain a server name and no "/"-characters? Obviously (by
looking at the exception thrown), the Oracle-JDBC driver looks up a
character which it does not find (index -1). Maybe some "/"s? Anyway, what a
lousy driver not catching url-parse errors...
Bye,
Falk
Re: Win2k Pro. is mess... choosing the right database product
Hi Vimal, I got Interbase working and there *are* some traps. Therefore let me share my solution with this list: (1) Get Interclient 2.0 from http://inprise-svca.www.conxion.com/win_sources.zip (a link from http://www.inprise.com/interbase/downloads/) (2) Install (3) Get a recompiled interclient.jar from http://www.kpi.com.au/interbase/files/interclient.jar (the original will cause JavaVerify errors) (4) Overwrite interclient.jar (the test applet will cease to work because some applet-specific classes were omitted in new .jar - ignore) (5) Get Firebird 0.9.4 from http://sourceforge.net/project/showfiles.php?group_id=9028release_id=19364 (ie. http://download.sourceforge.net/firebird/fbinst_0_9-4_prod_2000_12_29-1.exe for Win2k) (6) Install (Firebird is Interbase 6.0 with OSS support - The version from Borland's site seems unsupported by both Borland and the OSS community now) Firebird is ~2 months old were Interbase6 is ~8 months old. This installs Firebird as a Win2k-service. (7) Using Interclient configurator, configure Interclient (ie., Interserver) as a Win2k-service. Start the service now. (8) Copy interclient.jar (the new one) to OrionInstall/lib. (9) Copy firebird.xml (cf. my attachment #1) to OrionInstall/config/database-schemas (I have seen many Interbase schemas - most of them had a bug. Mine follows the Borland Application Server 4.5 Spec for Interbase 5.0 plus 6.0 additional datatypes. Reserved words are incomplete!) (10) Modify OrionInstall/config/data-sources.xml to include the datasource (cf. my attachment #2 as an example - MODIFY!!) (11) Restart Orion and deploy your application. Hope this gets YOu up and running and saves YOu this weekend ;-) Falk Langhammer - Original Message - From: Vimal Patel To: Orion-Interest Sent: Thursday, August 03, 2000 10:44 PM Subject: Re: Win2k Pro. is mess... choosing the right database product Can you tell me what data-source settings you have to get interbase working with orion and the driver version. I can not get it to work with orion. Also if you could mail the database-schemas for interbase I would really appreciate it. Thanks, Vimal ?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="Hypersonic" location="jdbc/HypersonicCoreDS" xa-location="jdbc/xa/HypersonicXADS" ejb-location="jdbc/HypersonicDS" connection-driver="org.hsql.jdbcDriver" username="sa" password="" url="jdbc:HypersonicSQL:./database/defaultdb" inactivity-timeout="30" / -- data-source class="com.evermind.sql.DriverManagerDataSource" name="LivingTalksDB" schema="database-schemas/firebird.xml" location="jdbc/LivingTalksCore" xa-location="jdbc/xa/LivingTalksXA" ejb-location="jdbc/LivingTalks" connection-driver="interbase.interclient.Driver" username="SYSDBA" password="masterkey" url="jdbc:interbase://localhost/C:/Programme/JavaSoft/j2sdkee1.2/interbase/livingtalks.gdb" inactivity-timeout="30" / /data-sources ?xml version="1.0"? !DOCTYPE database-schema PUBLIC "-//Evermind//- Database schema" "http://www.orionserver.com/dtds/database-schemas.dtd" database-schema name="Firebird" not-null="not null" null="" primary-key="primary key" max-table-name-lenght="30" type-mapping type="boolean" name="SMALLINT" / type-mapping type="java.lang.Boolean"name="SMALLINT" / type-mapping type="byte" name="SMALLINT" / type-mapping type="java.lang.Byte" name="SMALLINT" / type-mapping type="char" name="CHAR(1)" / type-mapping type="java.lang.Character" name="CHAR(1)" / type-mapping type="double" name="DOUBLE PRECISION" / type-mapping type="java.lang.Double" name="DOUBLE PRECISION" / type-mapping type="float"name="FLOAT" / type-mapping type="java.lang.Float" name="FLOAT" / type-mapping type="int" name="INTEGER&qu
Re: JAXP
Richard Doust schrieb: have tried replacing the older ones with the newer ones because my code Hi Richard, to me it seems that what You do makes perfect sense and that Orion *must not* impose any restriction on which libraries/versions You are going to use in your EJB code. That Orion uses Xalan etc. internally should be a hidden implementation detail (one may make use of ;-)). Therefore, I guess that your code should work just ok if you package all your additional JAR-files into your ejb-jar file. Just don't replace Orion's own files. You are just not allowed to. If it still does *not* work, file a bug report to bugzilla at orionserver.com. Most application servers I know run a separate class loader for at least each deployed application. If it works it would be nice to see documented an application-local library path so that repacking is not needed every time. Hope I could help. Your problem seems to be of a general nature. Bye, Falk -- Dr. Falk Langhammer Living Pages Research GmbH Holzstr. 19 D-80469 Munich, Germany mailto:[EMAIL PROTECTED] http://www.living-pages.de Phone +49 (89) 260 255 32Fax +49 (89) 260 255 35 Mobil +49 (171) 79 39 667 mailto:[EMAIL PROTECTED] (urgent SMS with subject header)
Configuring security for EJB - what's my error?
Hi, I start to use Orion 1.4.5 which seems to be a great product. To get things started I ported our show-case J2EE application (a conference management tool) over to Orion and I am almost done. Except for this problem: Whenever I call an EJB method I get the following exception: ---8--- com.evermind.server.rmi.OrionRemoteException: falk is not allowed to call this EJB method, check your security settings (method-permission in ejb-jar.xml and security-role-mapping in orion-application.xml). at com.livis.livingtalks.model.LTUtils.handleException(LTUtils.java:72) at com.livis.livingtalks.model.LTUtils.createManage(LTUtils.java:163) at com.livis.livingtalks.web.TypeWebImpl.init(TypeWebImpl.java:24) at /types.jsp._jspService(/types.jsp.java:35) ... ---8--- (Tracking in the code it is a a create()-method on the home-interface of the 'ManageBean'. It is the first bean method called - so no method presumable may be invoked.) User 'falk' is a valid user which I configured and which I have successfully logged in on the web tier. User 'falk' has the following mapping in the corresponding files: ejb-jar.xml (for the ManageBean which contains the EJB method): ---8--- method-permission role-namemaster/role-name method ejb-nameManageBean/ejb-name method-name*/method-name /method /method-permission ---8--- orion-application.xml: ---8--- security-role-mapping name="master" group name="ltroot" / /security-role-mapping ---8--- principal.xml: ---8--- principals groups group name="ltroot" descriptionltroot/description permission name="rmi:login" / permission name="com.evermind.server.rmi.RMIPermission" / /group ... /groups users user username="falk" password="123" descriptionThe master/description group-membership group="ltroot" / /user ... /users /principals ---8--- This should mean that 'falk' is logged in and is in role 'master' and may execute any method in the ManageBean. Where is the problem Without any roles and corresponding mappings everything works ok. It works fine, eg. in Sun's RI with roles. I tried without 'permission name="rmi...' - no change. I run out of ideas. Any help? I also cannot see any documentation, sample code, not on orionserver or orionsupport or the security-primer. Thanks, Falk -- Dr. Falk Langhammer Living Pages Research GmbH Holzstr. 19 D-80469 Munich, Germany mailto:[EMAIL PROTECTED] http://www.living-pages.de Phone +49 (89) 260 255 32Fax +49 (89) 260 255 35 Mobil +49 (171) 79 39 667 mailto:[EMAIL PROTECTED] (urgent SMS with subject header)
Re: Configuring security for EJB - what's my error?
Falk Langhammer wrote:
This should mean that 'falk' is logged in and is in role 'master' and
I have verified that 'request.isUserInRole("master")==true' in the
web-tier. There must be a problem in the EJB container.
BTW
I meanwhile found a posting:
From: Peter Delahunty
Subject: I have solved the security problem in Orion
Date: Wed, 15 Nov 2000 05:30:38 -0800
This posting states that more than one role accessing a method cannot be
configured. This INHO would be a severe bug and would render the J2EE
security model close to useless with Orion.
We *do* have this situation: 4 roles of 'master', 'editor', 'publisher'
and 'any'.
In another posting I found that role and group names must be equal.
In turn this means that only one group can access any bean method.
Thus, do I have to leave Orion alone when it comes to security issues?
Any bugfixes which have appeared or which are announced. I have a hard
time to believe that these basics dont func.
Bye,
Falk
--
Dr. Falk Langhammer
Living Pages Research GmbH
Holzstr. 19 D-80469 Munich, Germany
mailto:[EMAIL PROTECTED] http://www.living-pages.de
Phone +49 (89) 260 255 32Fax +49 (89) 260 255 35
Mobil +49 (171) 79 39 667
mailto:[EMAIL PROTECTED] (urgent SMS with subject header)
Re: Configuring security for EJB - what's my error?
Falk Langhammer schrieb: This posting states that more than one role accessing a method cannot be configured. This INHO would be a severe bug and would render the J2EE security model close to useless with Orion. Peter posted a workaround to bugzilla as bug#193. I verified that this solves my problem. Thanxs to the mailing-list archive! The bug was reported on 11/16/00 for version 1.4.4 and still has status NEW... Depending on what tools for EJB DD editing You use, your application will deploy or not (when using roles). Bye, Falk -- Dr. Falk Langhammer Living Pages Research GmbH Holzstr. 19 D-80469 Munich, Germany mailto:[EMAIL PROTECTED] http://www.living-pages.de Phone +49 (89) 260 255 32Fax +49 (89) 260 255 35 Mobil +49 (171) 79 39 667 mailto:[EMAIL PROTECTED] (urgent SMS with subject header)
