Re: [JBoss-user] Key generation by random numbers
On 2001-06-27 at 15:24 +0200, Philipp Meier wrote: On Tue, Jun 26, 2001 at 04:14:43PM -0400, Michael Bilow wrote: Fourth, the probability of a collision between your next randomly chosen number and any prior randomly chosen number is going to follow a Poisson distribution, which may not be obvious at first. This means that the likelihood of collison is by no means neglible for databases of practical size even when using fairly big arbitrary numbers. Exactly what does constitute negligible is a judgment call, not a technical decision. Although a 128-bit hash seems unlikely to be a problem, it is certainly conceivable that a 64-bit hash could be. Optimal behavior also depends upon the hash being properly seeded, as discussed. In general, I think that these kinds of subtleties make using a random hash approach for primary key generation more trouble than it is worth. If you absolutely need to eliminate a singleton constraint and you can afford to check for collisions, it may be worth the effort. You can reduce the probability for random id collision by including a time stamp. Given millisecond sampling the probability for a id clash is reduced to 2^128 in one millisecond -- which indeed is less than 2^128 in the lifetime of the id space. The increased collision probability in a cluster environment can be reduced by inserting a unique node id into the id -- the ip-address e.g. or the MAC of the network interface. Resolution: Using a time stamp (ignoring the 2038 problem ;-)) can reduce the probability of id collisiong of 128 random ids to a level which is IMHO sufficient for most production environments. Any would be comment appreciated. I am not sure I understand you at all. If you mean to suggest that the primary key could be constructed by concatenating a 64-bit timestamp with a 128-bit hash, I suppose that is actually true. However, this would have the side effect of making primary keys 196 bits long. Another possibility to keep the key at 128 bits would be to use some arbitrary part of the hash output, choosing 64 bits of the hash to concatenate with the 64-bit timestamp. This, however, would likely INCREASE the probability of collision significantly while introducing platform dependence. As I pointed out in a separate message, Java has millisecond _resolution_ but this is not the same thing as millisecond _accuracy_ against real world time. For example, on the IBM S/390 mainframe, time of day is only accurate to a full second, so you see time with millisecond resolution stepping 0.000, 1.000, 2.000, and so on. Even on Windows, danch said that he sees time moving in 10ms steps, so using a millisecond timestamp is just going to throw away about three bits of keyspace. Java also has no way to represent time in a convenient 64-bit format. The closest you can get is with java.lang.System.currentTimeMillis(), as far as I know,which has an accessor that returns a long. However, you lose one bit on the high side because a time stamp will never be negative, and you lose some bits on the low side if your platform does not report time with 1ms accuracy. As a practical matter, several of the bits on the high side will change so slowly that they will be fixed over the lifetime of the database, so they are also effectively removed from the keyspace and thrown away. If, on the other hand, you mean to concatenate the timestamp with the seed for the hash, this makes no mathematical difference in the probability of collision. The main design goal of a hash, especially a cryptographic hash, it to provide fairly wide distribution of outputs with minimally different inputs, so there will be essentially no correlation between the seeds or initializers and the hash output. -- Mike ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] ONLINE FORUM AVAILABLE
It is extremely common for firewalls to restrict access to certain well known services using well known ports. For example, many ISPs no longer allow direct connection to port 25 (SMTP) on a remote machine, and many corporate firewalls take the approach of prohibiting anything which is not specifically allowed. This is usually done to prevent people inside the firewall from accessing certain unapproved services such as IRC or streaming multimedia, and even telnet. Other corporate security policies will prevent any access to the outside network except through an HTTP proxy server, and these proxy servers will be restricted as to what they may access. The proxy server may strip user-agent headers, cookies, and sometimes even Javascript from viewed pages. This is usually done to prevent outside observers, including web site operators, from gleaning confidential company information based upon traffic analysis. By moving jboss-user to a web forum, you are certain to cut off access for a large number of people, either because of security policies or increased inconvenience. -- Mike On 2001-06-27 at 12:09 -0400, marc fleury wrote: how can your firewall filter out a port on my machine... will your firewall only allow outgoing traffic that goes to port 80 on a distant machine? if that is the case then we will probably merge the sites marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Chris |Kimpton |Sent: Wednesday, June 27, 2001 11:25 AM |To: [EMAIL PROTECTED] |Subject: Re: [JBoss-user] ONLINE FORUM AVAILABLE | | |Hi, | |--- marc fleury [EMAIL PROTECTED] wrote: | | the jivesoftware folks have put their new software on our site, so | go check | it out. | | http://www.jboss.org:8081/jive/ | | this is a beta site and use jboss-user on it. | | |Great although, I don't suppose there is a chance of getting it |on port 80 - some of us are stuck behind corporate firewalls that |only allow that port through... | |Thanks, |Chris | |= |Need somewhere to Live in London - http://freeflats.com ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] ONLINE FORUM AVAILABLE
It's totally non-functional for me. I tried to create an account, entered all of the fields and hit the button, and then was simply returned to the start page. I was expecting some sort of indication as to whether I was logged in and, if so, as whom? When I tried to login using the information I created, Jive errored out and presented this: Not Found (404) Original request: /jive/null Not found request: /jive/null This does not seem ready for prime time. -- Mike On 2001-06-27 at 16:08 -0400, marc fleury wrote: yep we will put it on 80 when we go final, BUT USE IT PEOPLE ARE NOT BANGING ON IT AS MUCH AS WE WANTED COME ON marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Jim Archer |Sent: Wednesday, June 27, 2001 3:20 PM |To: [EMAIL PROTECTED] |Subject: RE: [JBoss-user] ONLINE FORUM AVAILABLE | | |Hi Marc | |--On Wednesday, June 27, 2001 12:09 PM -0400 marc fleury |[EMAIL PROTECTED] wrote: | | will your firewall only allow outgoing traffic that goes to port 80 on a | distant machine? | |This will be a common problem. Most companies run firewalls and most of |those only allow outgoing traffic on a few ports. I have had to |battle with |IS departments to get them to open ports for POP and IMAP. | |Jim ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Stability problems on Linux
This is not a weak implementation. It is simply an implementation choice. On Intel hardware, you are effectively limited to about 4000 threads, which is the default in Windows. If you need to do so, you can increase the number of task slots available in Linux by editing include/linux/tasks.h in the kernel source and recompiling. The important constants are NR_TASKS, which defaults to 512, and MAX_TASKS_PER_USER, which defaults to NR_TASKS/2. Assuming you are running jBoss under a dedicated system user account, you can set NR_TASKS to something like 4000 and NR_TASKS_PER_USER to something like 3800, and then you will get substantially the same behavior on Linux as you would on Windows. Note, however, that this does not _guarantee_ stability of the system on either Linux or Windows, but simply raises the bar before jBoss wedges itself and has to be killed externally by the operating system. Linux is designed with these low defaults on the assumption that any process that is creating hundreds of threads is going crazy and should be halted, so this ordinarily improves system stability. In the case of jBoss/Tomcat, it is normal behavior to see hundreds of threads created, and the assumption embodied in the Linux kernel defaults is inapplicable. One option you do not have with Windows that you do have with Linux is to set the installed JVM to use green threads instead of native threads. This will use an internal scheduler in the JVM to switch between threads, and they will not consume system task slots. Green threads are somewhat less efficient than native threads in most cases, but you may get better stability by using them under very heavy load. One disadvantage to green threads is that, on SMP hardware, all threads within a JVM will be confined to a single processor, while with native threads different threads in the same JVM can run simultaneously. You would be well advised to upgrade to JDK/JRE 1.3.1, which has some improvements. You may also want to see that Java is started with the -Xincgc switch, which spreads out the garbage collection penalty and prevents major bottlenecks from developing that can cause avalanche. Finally, you may also find that behavior differs between Linux using the 2.2 kernel as opposed to the 2.4 kernel, so you might want to try each if your distribution supports this. -- Mike On 2001-06-28 at 11:32 +0200, Frank Fröse wrote: We have severe problems bringing stability to our Apache/Tomcat/JBoss based application on Linux OS. Every thing seems to run stable while traffic is low. But when traffic increases the VM forkes hundered of OS processes what causes thousands (40,000) of open files. At the end all OS resources are consumed and the application dies. I read about Linux's weak thread implementation which uses an OS process for each thread. Could this be the source of our problems? Is there a way to control this resources greed of our application? Our configuration: Linux 2.2.18 JDK 1.3.0 (Sun HotSpot) JBoss 2.2.2 Tomcat 3.2.2 Apache 1.3.19 Would you probably recommend to better switch to Windows or Solaris OS? If so, which is the preferred OS for a JBoss application? - Frank ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Init scripts for SuSE
You might want to take a look at a message I posted earlier which touches on this issue in a Debian context and contains an example script: http://www.mail-archive.com/jboss-user%40lists.sourceforge.net/msg07745.html In our experience, usually jBoss will respond to SIGTERM (15) and shut down gracefully, but sometimes it will be wedged and unresponsive. In such cases, we need to make sure that we have the ability to shut it down, and we need to send SIGKILL (9). The approach I chose was to send SIGTERM and start a time-of-day limit, by default 300 seconds (5 minutes) after the SIGTERM was sent. If that limit was reached and jBoss was still running, it would be sent SIGKILL. Under normal circumstances, jBoss takes about 15-20 seconds after SIGTERM to exit completely and shut down gracefully. -- Mike On 2001-06-28 at 20:17 +0200, [EMAIL PROTECTED] wrote: On Thu, Jun 28, 2001 at 07:24:42PM +0200, Tristan Donaldson wrote: Looking through the scripts I noticed you are shutting the server down with a kill -9. I don't think this is wise as this terminates the process immediately without allowing it to close itself. Changing the kill -9 to straight kill fixes the problem and the server seems to shutdown properly. Fixed, thank you very much. ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] installing the JDBC driver
The PostgreSQL driver is not a legitimate part of the EAR. In theory, an EAR should be deployable on any EJB platform regardless of the back-end database. One of the main goals of EJB is to hide stuff like that from your application. I am not sure why the error would be no such file, but I cannot see how this could work even if the file were to be found. The JAR file in question is loaded during mbean initialization as jBoss starts up. By the time deployment happens, it is too late. Furthermore, there would be substantial practical problems with putting such a driver into the EAR which would make it undesirable to do. For example, your EAR would only work with a specific version of PostgreSQL; if the back-end database were upgraded to a new version, everything would break. So this is a really not a good idea. -- Mike On 2001-06-25 at 20:06 -0500, G.L. Grobe wrote: I'm trying to get rid of the following error when I startup with ./run_with_tomcat.sh. [J2EE Deployer Default] couldnt add ./jdbc7.0-1.2.jar to common classpath: /u/public/JBoss-2.2.2_Tomcat-3.2.2/jboss/deploy/jdbc7.0-1.2.jar (No such file or directory) * * * Chapter 3 (JDBC) of the docs say I must copy the driver file (jdbc7.0-1.2.jar) to the lib/ext directory in the JBoss distribution. Because I'm trying to get my J2EE app in a format to where it will distribute w/ one EAR file that I can give to my customers and will work accross several servers, I'd like to not have to pull the driver out and place it into the ~/lib/ext dir. Anyway this will work w/o doing that? ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Having problems with HotSpot server on RedHat 7.1?
We are running on Debian 2.3 (Woody) using a 2.2.19 kernel and Sun JDK 1.3.1 on a dual processor system. We certainly do not see your problems. First of all, the JVM should be hard-limited to consume a maximum of 64MB unless you use the quasi-documented '-Xmxsize' switch when invoking Java. In the case of jBoss, this means editing the 'run.sh' file. If you are not using this switch and memory is getting sucked up, you may have a problem independent of the JVM. If you are using the '-Xmxsize' switch and you are allowing the JVM to have a very large amount of memory, more than a few hundred megabytes, then it will usually be a good idea to force garbage collection to even out over time with the likewise quasi-documented '-Xincgc' switch. This would also involve editing the 'run.sh' file. You seem to be testing uniprocessor mode on a separate machine, which would be worthless if you are seeing some sort of problem with the kernel or network stack. For debugging purposes, you can force Linux to run in uniprocessor mode with a multiprocessor kernel on an multiprocessor machine by specifying the keyword 'nosmp' at the boot prompt. If you are using Lilo to boot, you can create an alternate boot block in the file '/etc/lilo.conf' with the additional line 'append=nosmp' like this: image=/boot/vmlinuz-2.2.19 label=Linux read-only image=/boot/vmlinuz-2.2.19 label=Linux-NOSMP read-only append=nosmp Alternatively, if you will not need this regularly, just stop the boot with the 'Alt' key and enter Linux nosmp at the 'boot:' prompt. It is also worth distinguishing between consumption of memory as opposed to consumption of mere address space. For example, here is jBoss running on one of our SMP machines with the configuration described above, with the JVM authorized to consume up to 480MB: # ps u -C java | head -2 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND jboss19954 0.0 23.5 794452 60796 ? SJun21 0:36 /usr/local/share/jdk1.3.1/bin/i386/native_threads/java -server -Xms8m -Xmx480m -Xincgc -Djavax.xml.parsers.DocumentBuilderFactory=org.apache.crimson.jaxp.DocumentBuilderFactoryImpl -Djavax.xml.parsers.SAXParserFactory=org.apache.crimson.jaxp.SAXParserFactoryImpl -classpath :/lib/tools.jar:run.jar:../lib/crimson.jar org.jboss.Main tomcat The other main task here is PostgreSQL, using only a few megabytes: test1:/home/mikebw# ps u -C postmaster | head -2 USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND postgres 17804 0.0 0.6 8116 1632 ?SJun21 0:00 /usr/lib/postgresql/bin/postmaster -D /var/lib/postgres/data Although the JVM has allocated nearly 800MB of address space (VSZ or virtual size), it is only really using 61MB (RSS or resident size). This is evident from looking at the system memory picture, showing that we have never started swapping on our machine which has 256MB RAM and a 1GB swap file, and actually have half the RAM being used for low priority tasks such as filesystem buffers: # free total used free sharedbuffers cached Mem:257640 221968 35672 56324 119220 24896 -/+ buffers/cache: 77852 179788 Swap: 1048560 01048560 In other words, a report that jBoss is using lots of memory opens the door to more questions about your situation than answers. I hope this gives you some clue what to look for. -- Mike On 2001-06-25 at 22:37 -0400, Bill Burke wrote: Anybody having problems with SUN JDK 1.3 HotSpot server on RedHat 7.1(2.4 kernel) Dual processor? We're getting reproducable memory problems when invoking some code(mem usage jumps from 100M to 1.3Gig!) But can't reproduce the problem with -client or -classic. Nor can we reproduce on RedHat 6.2 server, client, or classic with a single processor machine. TIA, Bill ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] downloadable manual...where?
Most Linux distributions offer a large choice of tools which can do this. Here is a selection from Debian: http://packages.debian.org/wget http://packages.debian.org/pavuk http://packages.debian.org/w3mir http://packages.debian.org/omt Both 'w3mir' and 'omt' are in Perl and therefore may work on Windows. -- Mike On 2001-06-26 at 09:50 +0200, Roman Kunert wrote: under linux I am using the program pavuk (comes with my SuSE7.1) to fetch the updated docs automatically, it stores the whole documentation tree on your drive and remaps all links so you can use it locally. but you are right, a zipped documentation snapshot would make sense... For those of us who don't have a full time internet connection, it would be really great if, from time to time, somebody made a .zip of the manual and put it in the downloads section. Right now I have to download and save each page individually, and the links all point to jboss, not localhost. ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] mysql driver
While you are perfectly correct about this, I think it is advantageous to remove any of the databases which you are not using. That is, if you are talking only to MySQL, then you probably would be better off excising all of the Enhydra stuff from the jboss.jcml file. Hypersonic especially eats memory at a prodigious rate. -- Mike On 2001-06-26 at 08:02 -0500, Mike Thompson wrote: Ok, think I figured it out. The docs led me to believe that I could have more than one mbean code=org.jboss.jdbc.JdbcProvider name=DefaultDomain:service=JdbcProvider attribute name=Driversorg.gjt.mm.mysql.Driver/attribute /mbean in my jboss.jcml. I found that if I bundle all my drivers into one i.e mbean code=org.jboss.jdbc.JdbcProvider name=DefaultDomain:service=JdbcProvider attribute name=Driversorg.gjt.mm.mysql.Driver,org.hsql.jdbcDriver,org.enhydra.insta ntdb.jdbc.idbDriver/attribute /mbean that all works ok. --m ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Key generation by random numbers
Keep a couple of points in mind. First of all, since you are using MD5 as
what amounts to a random number generator rather than for a cryptographic
purpose, you may be undertaking more processing than would be required to
do this in a more straightforward manner. This is because crypto hashes
are designed to be infeasible to replicate without lots of iterative
processing in order to make it hard to attack them by brute force; they
are therefore computationally intensive. Most decent psuedo-random number
generators can produce equivalent results in terms of distribution with
orders of magnitude less processing, although with more predictability.
Second, in terms of randomness, any arbitrary selection from a random set
of bits is just as random. That is, a simple method for getting a random
64-bit number given a random 128-bit number is to use only the most- or
least-significant half, or XOR'ing both halves together.
Third, crypto hashes may be slightly less random than you think when used
to digest short messages. In general, the distribution of crypto hashes
is only expected to be sufficiently random for large enough messsages,
although no one currently knows how to estimate a lower bound. I doubt
this has any practical significance for you, but you ought to try to hash
a reasonably large amount of data, say 1024 bytes, relative to the size of
the hash itself when using a 128-bit hash such as MD5. Above all, avoid
using initializers which are actually shorter than the hash, such as a
32-bit time stamp. Note that the information content of data may be far
smaller than it seems; for example, the Unix 'date' command outputs 29
bytes of ASCII (Tue Jun 26 16:10:53 EDT 2001) which we know has only 4
bytes (32 bits) of information content, so date | md5sum is a very bad
idea to do. You can get around this by using the output of each hash in
the input to the next hash, but then you may as well use a simple sequence
generator class.
Fourth, the probability of a collision between your next randomly chosen
number and any prior randomly chosen number is going to follow a Poisson
distribution, which may not be obvious at first. This means that the
likelihood of collison is by no means neglible for databases of practical
size even when using fairly big arbitrary numbers. Exactly what does
constitute negligible is a judgment call, not a technical decision.
Although a 128-bit hash seems unlikely to be a problem, it is certainly
conceivable that a 64-bit hash could be. Optimal behavior also depends
upon the hash being properly seeded, as discussed.
In general, I think that these kinds of subtleties make using a random
hash approach for primary key generation more trouble than it is worth.
If you absolutely need to eliminate a singleton constraint and you can
afford to check for collisions, it may be worth the effort.
See http://www.ietf.org/rfc/rfc2795.txt for details. :-)
-- Mike
On 2001-06-26 at 15:28 +0200, [EMAIL PROTECTED] wrote:
Well... I use similar technique for generating unique IDs, but I utilize the
MD5 hash function. It is believed that it provides enough uniqueness. The
only problem is that you cannot use the long as primary key field (in my
case I use String). But you may convert 128-bit digest into 2x64-bit longs.
It has similar pros and cons, however the max value is now 2^128 which is
quite large number :).
Regards,
Roman.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Dienstag, 26. Juni 2001 14:54
To: jboss
Subject: [JBoss-user] Key generation by random numbers
As a follow-up to the debate on how to get auto-increment primary
keys:
Is it feasible to use a random number generator to generate primary
keys? I don't really need my records to have steadily increasing keys
and my number of records will presumably be much smaller than the size
of my value space (4 billion? depending on data type for prim-key). So
if I do something along the following when making a new record;
boolean created = false;
do
{
Long key = generateRandomLong();
created = ejb.create(key, contents);
}
while (!created);
(here, ejb.create() takes the primary key of the new record as its
first param and returns true if success, false if not success)
My theory is that most of the time, the creation will succeed on the
first attempt, based on the assumption that number of records is
insignificant compared to the value space of Long.
Pros:
I don't need to do manual synchronisation with a central
key-generating bean.
I don't need to do DB-specific calls to get it to generate for me.
Cons:
Unpredictable time use for creation.
Unusable if number of records becomes significant compared to value
space of Long.
I am assuming also that the creation of a random Long is a fast
process.
Cheers
Bent D
___
JBoss-user
RE: [JBoss-user] Key generation by random numbers
Note that Java represents time with millisecond _resolution_ which is not at all the same thing as millisecond _accuracy_ in the real world. Relying upon this sort of thing has the effect of introducing a platform dependency which could make the whole design fall over. For example, on the IBM System/390 mainframe, real world accuracy is limited to one full second, so millisecond resolution just sees the seconds incrementing 0.000, 1.000, 2.000, and so on. -- Mike On 2001-06-26 at 15:57 -0400, Jim Kimball wrote: If you are looking for a simple unique ID generator that is also (somewhat) evenly distributed, use a reverse timestamp. Use System.getCurrentTimeMillis(), turn it into a string, then reverse it. If you have performance problems with such a simple algorithm, you might want to write your own routine to do the reversing of a long without using the generic String methods. Jim ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] mysql driver
I really hope not, since we took everything but PostgreSQL support out of the jboss.jcml file and made that the DefaultDS. It may be that there is a requirement that DefaultDS exist, but I don't know. We are not using JMS for anything special, but so far things seem to work. Probably one of the people on this list who knows what he is talking about could answer your question better than I can. -- Mike On 2001-06-26 at 13:25 -0500, Mike Thompson wrote: Yikes! (Note: feel free to laugh if this is a stupid question). Doesn't the JBoss JMS service use one of these DBs to persist messages? --m - Original Message - From: Michael Bilow [EMAIL PROTECTED] To: List: jBoss users [EMAIL PROTECTED] Sent: Tuesday, June 26, 2001 1:16 PM Subject: Re: [JBoss-user] mysql driver While you are perfectly correct about this, I think it is advantageous to remove any of the databases which you are not using. That is, if you are talking only to MySQL, then you probably would be better off excising all of the Enhydra stuff from the jboss.jcml file. Hypersonic especially eats memory at a prodigious rate. -- Mike ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Re: random keys
On 2001-06-27 at 00:24 +0200, [EMAIL PROTECTED] wrote: On Tue, Jun 26, 2001 at 05:32:43PM -0400, Michael Bilow wrote: On 2001-06-26 at 21:45 +0200, [EMAIL PROTECTED] wrote: Why would this matter? Do databases assume that records with primary keys near one another will often be used together? Yes, this is why they are called primary keys. Traditionally, database engines would try to entry-sequence records by primary key, and there remains an expectation that access by primary key will always be the fastest and most efficient mechanism for accessing a table. It seems strange to me that locality would be important in this case. The assumption that record number 5 and record number 6 are inherently linked more than record 5 and record 8793 are would certainly hold for some databases, but that it should be true in the general case (or even just often enough that it matters)? I can only see the usefulness for binary search, but there you would presumably build index tables anyway so actual location of data doesn't matter. The main reason why primary key access is expected to be more efficient is because experience has shown that databases tend to made up of two flavors of table: tables which are read frequently and written infrequently, which are usually searched on the same key, and tables which are inserted to frequently and read not too much more often than they are written. An example is something like an order entry system where orders are created in an orders table for customers in a customers table to sell items that are in an items table. The items table will be written very rarely, only when new items are introduced, but will be read frequently. Although there might be occasional need to search the items table on some key other than the primary key, such as a description field, the vast majority of accesses from the point of view of the database engine will be to resolve references from other tables and these will all be done by primary key. For example, whenever an order is viewed, the orders table references to items by primary key will have to be resolved through the items table. Because of this, optimizing for primary key will usually result in an order of magnitude performance improvement. The customers table may be modified more frequently than the items table, but if there are regular customers then the customers table will still be modified much less frequently than the orders table. The orders table, in turn, is mostly being modified by insertion operations. There might be occasions to modify an order record, say to notate than an order has been shipped or that part of an order is backordered, but the basic common operation regarding an order table will be to either insert a new order or to locate all orders associated with some other entity, such as a customer. Looking up all orders for a customer will require resolving through a secondary index on the orders table, but those references will themselves resolve back to primary keys in the orders table. So the end result is that all database accesses are eventually going to become a search by primary key, and optimizing for that is invariably a huge win. -- Mike ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Suggested way of calling Session Beans from JSP
http://jakarta.apache.org/velocity/index.html -- Mike On 2001-06-27 at 09:18 +1000, Devraj Mukherjee wrote: Tell me more ... can I find some documentation about Velocity somewhere ?? Devraj At 23:01 26/06/01 +0200, you wrote: Why not using Velocity... ? I have been trying it with Jboss. You just have to write simple servlet that select beans and give references to your pages. With a good session bean design it's very simple. I allows to create nice pages without embedding too much code in it and editable with a simple html editor François ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] E-mail vs. web vs news support
I think a web-based system would be a disaster. It is far easier to take a simple thing such as mail and layer over it more complicated things such as newsgroup or web interfaces, while is it effectively impossible to do the reverse. There are some extremely large projects which use mail as their lingua franca, some involving hundreds of developers, including Linux itself and the Debian Project. If discussions become so active that they cannot be followed by mail, the only solution is a human editor along the lines of what has happened with Linux Kernel Traffic or Debian Weekly News. To see examples of how this is done, see: http://kt.zork.net/kernel-traffic/latest.html The Debian Weekly News can be fairly eccentric at times; a recent issue led with the Debian Bug Tracking System celebrating its 100,000th bug: http://www.debian.org/News/weekly/2001/14/ The point is that mail has proven itself as the preferred way for many developers and users to coordinate. I would support splitting a busy list into smaller lists, but moving to some scheme such as web forums would be a major aggravation for me. Using straightforward mail software (Pine and Procmail), I can quickly blow through several dozen mailing lists, all using the same interface from my perspective. With web forums, I have to run around to each one individually and adapt to its particular interface, which is comparatively slow and frustrating -- not least because I use the Lynx browser; if a web page requires client-side Javascript, I'm done. Also, I can read my mail off-line just by synchronizing the mail client on my laptop via IMAP, while reading a web forum off-line is impossible. Many people around the world are still paying for their connection time by the minute, and forcing them to use a web forum is unfair. -- Mike On 2001-06-25 at 13:43 -0500, danch (Dan Christopherson) wrote: That's a very good idea. Note that this list will be moving over to a Jive based web forum thing 'soon'. Will that help? I think there could be a lot of advantages to also having a sight with concise summaries of conversations on the list/forum. Maybe something more along the lines of Linux Weekly News? Maybe with a bit more of a faq involved? Please, though, no FAQ-O-Matic - I've never seen one that answered the question I needed to ask. A site like this would need dedicated maintainers, wouldn't it? Or are you thinking of something different? ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Apache+Tomcat+JBoss
The jBoss documentation is simply wrong and grossly outdated in any meaningful way. See my extensive post on a related issue a few days ago: http://www.mail-archive.com/jboss-user%40lists.sourceforge.net/msg07518.html Linux, as of the 2.2 kernel and 1.3 Sun JVM, certainly does have real native thread support, and this is the default installation. See: http://developer.java.sun.com/developer/technicalArticles/Programming/linux/ Basically, the choice between native threads and green threads is an issue of whether the threads are to be scheduled by the system kernel scheduler or by the JVM internal scheduler. If the system scheduler is used, the switching takes place in kernel mode and more efficient use of resources can be made; in particular, an SMP machine can have multiple JVM threads running simultaneously on different processors. If the JVM internal scheduler is used, the switching takes place in user mode which is going to be somewhat slower, and all of the threads within the JVM will be limited to a single processor on an SMP machine. There is a trade-off here: for nearly all practical Java applications, running with native threads is going to result in better performance, even for a uniprocessor machine. The exception is a Java application which needs to create a huge number of threads, maybe into the several hundreds, in which case green threads might be a realistic option. Note that any application which has hundreds of threads is going to thrash the scheduler regardless of whether that scheduler is inside the JVM or the kernel, and serious consideration should be given to rearchitecture. There is some sort of nasty myth that Linux threads are somehow less thready than Windows threads because they show up in the process table. This is an implementation choice that has negligible effect on performance (after a thread has been initially created) because threads share task descriptors which, on most hardware (including Intel), have physical meaning in the CPU. In other words, the Linux kernel switches between threads as quickly and with essentially the same amount of overhead as a thread switch on Windows, although Linux does take some penalty in initial thread creation. This is again a trade-off, because the Linux thread model allows a single-tier scheduling algorithm while Windows requires a double-tier scheduling algorithm. What green threads on Linux do is closer to the Windows scheduling model, although on Windows the thread scheduler runs in kernel mode and is therefore faster than the user-mode JVM internal scheduler on Linux that is only used with green threads. The reason Linux will impose limitations on jBoss capacity that are not present in Windows is because the Linux kernel is designed with the assumption that any process spawning hundreds of threads has lost its mind and should be stopped for the good of the system. If one chooses to do so, one can -- as I explain in my earlier post referenced above -- recompile the Linux kernel to raise the task count limit up into the stratosphere; a little more than 4000 tasks can be allowed systemwide on Intel hardware. (This has a physical hardware basis: there are 8192 descriptor slots on Intel hardware, and each Linux task needs two, so the dead maximum capacity on Intel hardware is 4096. In turn, no single user is allowed more than half the systemwide supply of task slots, so when jBoss hits 2048 the kernel will deny it the ability to start new threads. Note that this is a factor of 8 greater than the kernel default.) With the kernel recompiled to allow more tasks, Linux will have essentially the same capacity in terms of thread count as Windows, with the difference that Linux will continue running if a non-root application requests every available thread while Windows in that situation will crash. In summary: 1. Linux has native thread support as of the 2.2 kernel and 1.3 Sun JVM, 2. SMP, if available, is fully utilized with native thread support, 3. There are reasons why one might choose not to use native thread support on Linux and use green threads instead, 4. The capacity of Linux in terms of thread count can be boosted to a level equivalent to that of Windows by changing a number in the kernel source and recompiling, and 5. It is undesirable to have very large numbers of threads because then the system will spend an increasingly larger portion of time in thread switching and scheduling overhead at the expense of useful work. -- Mike On 2001-06-24 at 14:08 +0800, Fei Wang wrote: I have found the following at http://www.jboss.org/documentation/HTML/ch10s02.html. Linux users probably already know that linux does not support real threads. Under heavy load, JBoss will for example crash with 200 concurrent users under linux, whereas it can handle 1000 of them on the same box with Windows 2000. Of course, if you use Apache or Jetty in front of JBoss to handle the thread pooling, this will not be a
Re: [JBoss-user] Apache+Tomcat+JBoss
See my immediately prior post on the subject of native thread support in Linux. The short answer is that it is present -- and the referenced jBoss documentation already wrong -- as of kernel 2.2 and Sun JVM 1.3. The Linux 2.4 kernel makes substantial internal changes to the scheduler, especially with regard to SMP, but this is transparent to applications such as jBoss. (The exception to transparency is that threading errors, such as failure to synchronize properly, may be exposed by a 2.4 kernel if the same code was working by coincidence on a 2.2 kernel.) From the perspective of a Java application, the 2.4 kernel should be regarded as architecturally equivalent to a 2.2 kernel, although there would likely be significant performance benefits, especially with SMP. -- Mike On 2001-06-24 at 11:25 +0100, Julian Gosnell wrote: Further context to this quote suggests that Linux 2.2 is being discussed. Firstly, can anyone confirm this from a reliable source - it's the first I've heard of it. Secondly, is this still the case with a 2.4 kernel, in which I thought similar issues had been very successfully addressed ? Thirdly, It would be useful to have dates on documentation, so that it is possible to tell when they become stale - if 2.4 does address this (I have no idea), or a better Linux JVM has since been released, then it would be helpful to know when this statement was made. Jules Fei Wang wrote: I have found the following at http://www.jboss.org/documentation/HTML/ch10s02.html. Linux users probably already know that linux does not support real threads. Under heavy load, JBoss will for example crash with 200 concurrent users under linux, whereas it can handle 1000 of them on the same box with Windows 2000. Of course, if you use Apache or Jetty in front of JBoss to handle the thread pooling, this will not be a problem. So if it is ture, I think that Apache should be a reasonable front part, especially for production use. Fei Wang ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] load
1. We ran jBoss/Tomcat on Linux using a creaking old 166MHz Pentium with 64MB RAM and 256MB swap space. This configuration thrashed noticeably because of memory limitations, but we tested with our load simulator and the system never fell over. Enormous amounts of memory are consumed by the Hypersonic SQL engine which comes in the box with jBoss, and it is not appropriate for production use. When we switched to PostgreSQL running on the same machine and totally deconfigured Hypersonic in jboss.jcml, the memory requirements dropped and performance was actually quite tolerable. Note that I am not recommending you run such a system in production, but I thought knowing this would help you gauge just how far you can push things toward minimum. 2. In our experience, the bottleneck on Linux is not connection count but thread count. As I have discussed in two immediately prior posts here, jBoss under heavy load will exhaust the systemwide supply of task slots and essentially wedge. This can be worked around by modifying the kernel source and recompiling the kernel with a higher number of task slots. In theory, changing to the green threads configuration would remove the thread count limitation at the expense of performance. 3. In turn, the limiting factor on thread count is demand resulting from the internal architecture of jBoss. I really do not know enough to discuss this issue, but I understand it is a development concern. In general, jBoss on Linux benefits from throwing as much RAM and CPU resources at it as can be reasonably afforded. This is doubly a concern when you run the database back-end on the same machine as the jBoss application server. Our current test configuration is a dual 300MHz Pentium III system with 256MB RAM, and I would probably not put quite that low-powered a machine into production use. On the other hand, with our present test configuration, the swap file is so far untouched with under 90MB actually utilized: total used free sharedbuffers cached Mem:257640 235616 22024 65512 116680 36996 -/+ buffers/cache: 81940 175700 Swap: 1048560 01048560 My advice is to buy as much CPU power as you can at the outset because this is expensive to upgrade later, and install whatever memory you think you can get away with while keeping as many RAM slots unused as possible. Since memory is very cheap now, adding more will just be a matter of filling up those slots. Even 1GB or 2GB RAM is entirely affordable now. Fast disks will also help the back-end database a lot. If you are going to use more than two CPUs or exceed 2GB RAM, you are strongly advised to run the 2.4 Linux kernel. -- Mike On 2001-06-24 at 09:45 -0700, Richard Bottoms wrote: Since the question has been raised about the maximum user load of JBoss I'm in need of some concrete numbers as far as is currently known. 1. What is the minimum configuration recommended 2. What's the maximum concurrent connections allowed under Linux. 3. Is this affected by processor speed, memory or chip type? I have a commercial app I want to develop, but I, and I would guess others need these answers if we are to proceed. Thanks, r.b. ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Exceptions starting and stopping JBoss-2.2.2_Jetty-3.1.RC5
The obvious solution would be to make sure that the directly is non-empty in the distribution archive. :-) -- Mike On 2001-06-23 at 08:36 -0700, Scott M Stark wrote: It may not be your build. It could be the tool the user is using to unarchive. If either drops empty directories this problem shows up. - Original Message - From: Julian Gosnell [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, June 23, 2001 7:16 AM Subject: Re: [JBoss-user] Exceptions starting and stopping JBoss-2.2.2_Jetty-3.1.RC5 Thanks Guys, I'll look into why my build sequence is stripping out this directory. I'll make sure it doesn't happen in the next release. Getting there, Slowly :-) Jules ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Deploying problem
Are you on a live network with an Internet connection? My guess is that you are trying to start the XML parser -- without which nothing is going to work -- and it is trying to get the DTD from the host specified. If you are really, really stuck, it is possible to modify DOCTYPE so that it references a locally cached static copy of the DTD, but most people do not have to do that. For example, in the EAR file you are trying to deploy, you will often have something like a META-INF/application.xml file (or any XML file, for that matter) which begins like this: ?xml version=1.0? !DOCTYPE application PUBLIC -//Sun Microsystems, Inc.//DTD J2EE Application 1.2//EN http://java.sun.com/j2ee/dtds/application_1_2.dtd; Once you start down that road, you need to be able to get the DTD file. If your machine is not on a live network, you need to supply a local copy of the DTD file and modify the DOCTYPE attribute to point to it. -- Mike On 2001-06-23 at 19:05 +0200, Marek Sedliak wrote: Hi all, I am new in JBoss and please I would like to ask you for help. I am using JBoss-Tomcat installation and when deploying my .ear file (containing EJB jar file and Servlets war file) I am getting the following exception: [Auto deploy] java.net.UnknownHostException: java.sun.com [Auto deploy] at org.apache.crimson.parser.Parser2.fatal(Parser2.java:3035) [Auto deploy] at org.apache.crimson.parser.Parser2.externalParameterEntity(Par ser2.java:2723) [Auto deploy] at org.apache.crimson.parser.Parser2.maybeDoctypeDecl(Parser2.ja va:1154) [Auto deploy] at org.apache.crimson.parser.Parser2.parseInternal(Parser2.java: 488) [lots of stuff removed] ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] jboss/db/jbossmq disappearing....
The Info-ZIP compression/decompression tools have radically different default behaviors than the old PK-derived tools. For example, on DOS, PKUNZIP flattens all files into the current directory by default and strips all subdirectory information unless the -d switch is given. With the Info-ZIP tools, like tar you get subdirectories by default unless you explicitly junk them with the -j switch. WiZ, a freeware clone of WinZip from the Info-ZIP project, obviously uses the Info-ZIP engine on Windows in DLL form, so it has the default Info-ZIP behavior. Some people are probably using jar to unzip distribution ZIP files! Considering how little control you will ever have over how people choose to extract your distribution archive, I think your only safe option is to put something like a README.txt file into the directory to ensure that it is not empty. As far as I know, this will guarantee on all tools that the directory is created (if the tool is subdirectory-aware at all). There is no way for you to deal with ownership and permissions issues except as part of a larger policy which provides a framework for this. For example, on our systems all parts of the distribution are owned by root in group jboss, and those parts to which the running jBoss system needs read-only access have mode 750 for directories or 640 for files, while those parts for which the running jBoss system needs read-write access have mode 770 for directories or 660 for files. This guarantees that jBoss does not have sufficient privilege to modify its own code or configuration on disk, one of the most commonly exploited security vulnerabilities on Unix. The jBoss process itself runs as the jboss system user, who (like users mail or ftp) has no login privilege. Such a framework for ownership and permission would be a huge help on Unix, since that would effectively standardize the installation format and centralize maintenance of it. Right now, we have to manually configure the ownership and permission of every single directory and file which is unpacked from the distribution on Unix. There is also at present no expectations that any two different Unix installations have comparable configurations, which makes bugs more likely and diagnosis more difficult. Part of the problem, of course, is that ZIP files have no standard way of carrying ownership and permission information. The tar file format does, since it is POSIX-standardized, but people do not seem to like using tar format on DOS/Windows. Info-ZIP defines a private extension on operating systems which have ownership and permission capabilities, so that this information can be carried by the ZIP file if Info-ZIP tools are used for both archiving and dearchiving. Oddly, the default behavior on Unix is for zip to put ownership and permission information into the archive and then for unzip to throw it away upon dearchiving! (Use the -X switch to override the default behavior on Unix. That is, zip -X will NOT record ownership and permission information, and unzip -X will NOT throw it away.) Although there is no standard extension format for ZIP, there is a standard format (originally definied by PKZIP) for declaring extensions. As a result, any ZIP tool should be able to tell that there is some sort of extension present, but it may not be able to distinguish whether the extension is Unix ownership and permission information, an OS/2 extended attribute block, or a MacOS resource fork. Info-ZIP supports all of these types of extensions, but they are only meaningful if Info-ZIP tools are used for both archiving and dearchiving, even across platforms. The Unix zipinfo tool (really unzip -Z ...) can display these. Note that Sun uses the Info-ZIP tools (or at least their file formats) to distribute the Linux JDK. This is necessary because there is no other way to encapsulate critical information needed by Linux, such as symbolic links in the filesystem. Distribution file j2sdk-1_3_1-linux-i386 examined with zipinfo shows Info-ZIP extensions decoded. Here is the main java binary in the archive: -rwxrwxr-x 2.2 unx27058 bx defN 6-May-01 06:15 jdk1.3.1/jre/bin/i386/native_threads/java Here is a symbolic link (the contents of which when uncompressed are the link's target): lrwxrwxrwx 2.2 unx 13 bx stor 6-May-01 06:41 jdk1.3.1/jre/bin/java The coding 2.2 unx means that the archive was created (by Sun) using Info-ZIP v2.2 on Unix. If the ZIP distributions for jBoss are built on Linux using the Info-ZIP tools, this would make life a great deal easier for Unix installations and remain perfectly compatible with Windows. -- Mike On 2001-06-23 at 19:24 +0100, Julian Gosnell wrote: All the .tgz files I have checked in to binaries have this directory intact : /home/jules/cvs/JBoss/binaries/JBoss-2.2.2_Jetty-3.1.RC5-2.tgz drwxrwxr-x jules/jules 0 2001-06-10 23:29:02 JBoss-2.2.2_Jetty-3.1.RC5-2/jboss/db/jbossmq/
Re: [JBoss-user] problems with server with 2 network cards
You might try the brute force approach of reversing the interfaces, such that the external IP is on eth0 and the internal IP is on eth1. Many processes which are not multiple interface-aware will simply pick up the address of the first interface they find. Note that this does not involve reversing the physical cards or wires, just the interface labels. Is your DNS valid and consistent, both forward and reverse? As a general rule, when a machine is addressable by more than one IP address, we like to configure DNS for an identical perspective both inside and outside the firewall. The way we usually do this is by suffixing the letter i and e to the respective hostname component. That is, for a machine whose hostname is aaa001, we would define in the zone file a name aaa001-i which maps to the internal address only and a name aaa001-e which maps to the external address only. We regard this is enormously preferable to having desynchronized DNS zones, which is how most people handle the situation. (This is especially important if there are cryptograpic protocols in use, as with SSH, which will try to validate the hostname, but that is beyond the scope of your problem with jBoss.) Does the application work from outside if you put the internal interface down before starting your services? Then the external interface would be forced to be the first enumerated interface. You may need to specify the RMI server address manually when starting Java on the server if the system guesses wrong, editing run.sh: java -Djava.rmi.server.hostname=212.172.122.17 ... This is something of an RMI FAQ, and would be applicable to any situation where multiple interfaces or even virtual interfaces with different IP addresses are involved: http://java.sun.com/j2se/1.3/docs/guide/rmi/faq.html#nethostname Clearly, no route to host is a correct error message for an address like 192.168.0.100, which is a fake net guaranteed to be publicly unrouteable by RFC1918/BCP0005. The problem is why the client is attempting to connect to this IP address in the first place, and that seems almost certain to be related to one or another of the directory services. If you can look at the client's network table and see what port on the unreachable address is being attempted, you should be able to see whether this is related to web access (port 80 or 8080), in which case DNS is likely at fault, or related to Java internals such as RMI (port 1099) or JNDI (port ), in which case you have a property set wrong. At this point, it is hard to tell from your description what sort of connection is actually failing without more detailed information. -- Mike On 2001-06-22 at 11:21 +0200, Patrick Buchinger wrote: hi everybody! i have a server with 2 network cards in it, one is connecting to the internal network (let's say ip=192.168.0.100) and one is connecting to the internet (let's say ip=212.172.122.17). the os of the server is linux (kernel 2.2.16). the server also is the gateway from the internal network to the world (using NAT). now the problem is, when i try to connetct to jboss from outside the internal network (to ip 212.172.122.17), i always get a NoRouteToHostException to host 192.168.0.100!!??!!! is this a jboss problem or a server configuration problem? has someone ever made such a configuration successfully run with jboss? ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Jboss and RMI problem on Solaris
See: http://java.sun.com/j2se/1.3/docs/guide/rmi/faq.html#nethostname Explicitly tell the RMI server where it lives when starting Java: java -Djava.rmi.server.hostname=198.136.189.254 ... If the RMI server is running on a different machine, then trying to find it on localhost [127.0.0.1] is not going to work. -- Mike On 2001-06-21 at 22:12 +0530, Bhavin Patel wrote: hi friends, we r running jboss2.2 on solaris and tomcat on linux. the scenario is as under. our naming service is on port 8080 on solaris and rmi is at 1099 on linux. problem: we are calling a remote method on RMIObject(running on tomcat on linux) from Session Bean(on JBoss on Solaris). we are able to lookup the RMI object from session bean, but when we try to call any method on that object , the jboss shows following error. [SessionBeanA] from session Bean java.rmi.ConnectException: Connectio n refused to host: 127.0.0.1; nested exception is: java.net.ConnectException: Connection refused [SessionBeanA] java.rmi.ConnectException: Connection refused to host: 127.0.0.1; nested exception is: java.net.ConnectException: Connection refused ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Re: Re: MVCSoft Persistence Manager and JBoss
Keep in mind that DefaultDS can be mapped to any back-end you like. For example, we map it to PostgreSQL in the jboss.jcml file and use this with MVCSoft, and we do not even configure Hypersonic or InstantDB: mbean code=org.jboss.jdbc.JdbcProvider name=DefaultDomain:service=JdbcProvider attribute name=Driversorg.postgresql.Driver/attribute /mbean mbean code=org.jboss.jdbc.XADataSourceLoader name=DefaultDomain:service=XADataSource,name=PostgresDB attribute name=DataSourceClassorg.opentools.minerva.jdbc.xa.wrapper.XADataSourceImpl/attribute attribute name=PoolNameDefaultDS/attribute attribute name=URLjdbc:postgresql://127.0.0.1/dbname/attribute attribute name=JDBCUserusername/attribute attribute name=Passwordpassword/attribute /mbean mbean code=com.mvcsoft.persistence.jboss.spi.PersistenceSPIService name=:service=PersistenceSPI / Jim Archer, who answered your question originally and whose post you quoted below, is obviously far more knowledgeable about MVCSoft than I am, but the above excerpts from my working jboss.jcml file should give you a clear idea of how easy it is to point MVCSoft at any arbitrary back-end. -- Mike On 2001-06-22 at 10:21 -0600, Da-Ming Duan wrote: Thanks Jim. It realy helps. I think there should be someway to specify different datasources with MVC PM, otherwise it is useless for any enterprise application that has its own database. Da-Ming Message: 9 Date: Thu, 21 Jun 2001 20:22:46 -0400 From: Jim Archer [EMAIL PROTECTED] To: Da-Ming Duan [EMAIL PROTECTED] cc: [EMAIL PROTECTED] Subject: [JBoss-user] Re: MVCSoft Persistence Manager and JBoss Reply-To: [EMAIL PROTECTED] Hello... Let me take a shot at these... --On Thursday, June 21, 2001 4:43 PM -0600 Da-Ming Duan [EMAIL PROTECTED] wrote: How and where to specify a datasource in a EJB2.0 jar with MVCSoft Persistence Manager? Can I incude jaws.xml in an EJB2.0 jar to specify a datasource with jawsdatasourceMyOracleDBPool/datasource/jwas? The code generated by the MVC PM uses DefaultDS. I'm noit sure if this can be easily changed, as I have never tried. You won;t need Jaws with the MVC PM, as it generates BMP code for you. 2. There are 4 elements for MVCSoft Code Generator: EJB2.0 input jar, EJB1.1 output jar, a temperory directory and the file with the DDL output for the tables. What is this file and what are these tables? Where to put this file when archiving the beans? The DDL file is actually just a bunch of SQL create statements you can use to create your tables in your database. You don't put this file anywhere. Since your now using BMP, jBoss won;t create the tables for you, so you'll have to use this file to do that yourself. Using a mapping.xml file, you can control the names and schemas of each table you'll need. 3. Can jboss.xml still be put in the directory META-INF for an EJB2.0 jar? Yes, and depending upon what your doing you may still need it. 4. Are mapping.xml and default_mapping.xml used to replace JBoss' jaws.xml and standardjaws.xml? If yeas, the mapping.xml--jaws.mxl is OK No, not at all. These files tell the code generator what table an field names and field types and sizes to use for the database tables. Nothing more. By the way, is there any user email list for MVCSoft Persistence Manager? Yes, they have a mail list on Yahoo Groups called ejb20-persistence. Its a very low volume and helpfull list. Good luck! Jim ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] here's a simple start/stop script
successfully for some time. I have delimited the beginning and end of
the script with a row of , but these are for clarity in this message
only and are not part of the script.
#!/bin/sh
#
# By Michael Bilow, [EMAIL PROTECTED], 2001-05-09
# This Debian init script is in the public domain
#
# Loosely based upon prior contributed work by [EMAIL PROTECTED]
# which was published into the public domain on SourceForge:
# http://www.mail-archive.com/jboss-user%40lists.sourceforge.net/msg02919.html
#
###
#
# Install this script into /etc/init.d and create links to
# start and stop with position control values 95 and 15,
# respectively. Use the 'update-rc.d' utility to do this:
#
#update-rc.d jboss_local defaults 95 15
#
###
#
# We are assuming also that a system user jboss has been
# created with group jboss, and that the jBoss tree has been
# installed in such a way that the jboss user has necessary
# access to run it. We choose to have most of the jBoss tree
# owned by root with owner group jboss, and then to grant
# either read-only or read-write privilege to the jboss group
# as needed. The details of this installation are beyond the
# scope of this comment. The jboss user should NOT have any
# privilege to log in.
#
# If jBoss/Tomcat absolutely must attach a listener directly
# to port 80 or some other privileged port, use the ipchains
# facility rather than running as root. For example, configure
# jBoss/Tomcat to listen on port 10080 and then issue:
#
#ipchains -A input --destination-port 80 -p tcp -j REDIRECT 10080
#
###
#
# Since 'start-stop-daemon' will make / the pwd for the
# backgrounded process when the '--background' switch is used,
# we need to have a wrapper script 'debian_wrapper.sh' which
# contains simply:
#
##!/bin/sh
#cd $DAEMONPATH
#./run_with_tomcat.sh
#
# This wrapper script needs its ownership and permissions such
# that the jboss user can read and execute it, and it must be
# placed into the directory where 'run_with_tomcat.sh' resides.
#
###
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
export DAEMONPATH=/var/local/jboss/tomcat/jboss/bin/
DAEMONNAME=debian_wrapper.sh
DAEMON=${DAEMONPATH}${DAEMONNAME}
PKGNAME=jboss_local
JVM=java# Name of the running JVM in /proc/pid/stat
DESC=jBoss with Tomcat application server
LIMIT=300 # Seconds we try sending SIGTERM before sending SIGKILL
test -x $DAEMON || exit 0
set -e
case $1 in
start)
echo -n Starting $DESC:
start-stop-daemon --quiet --start --background \
--chuid jboss --exec $DAEMON
echo $PKGNAME.
;;
stop)
echo -n Stopping $DESC:
# 'date +%s' gives seconds since Unix epoch
STOPSTAMP=`date +%s`
STOPLIMIT=`expr $LIMIT + $STOPSTAMP`
if start-stop-daemon --quiet --stop --signal 0 \
--user jboss --name $JVM
then
start-stop-daemon --quiet --stop --oknodo \
--user jboss --name $JVM
# jBoss could take considerable time to shut down
while start-stop-daemon --quiet --stop --signal 0 \
--user jboss --name $JVM 2/dev/null
do
if [ `date +%s` -le $STOPLIMIT ]
then
sleep 1
echo -n .
else
start-stop-daemon --quiet --stop --signal 9 \
--user jboss --name $JVM --oknodo
fi
done
echo $PKGNAME.
else
echo $PKGNAME was not running.
fi
;;
restart|force-reload)
echo -n Restarting $DESC:
$0 stop
sleep 3
$0 start
;;
*)
N=/etc/init.d/$PKGNAME
echo Usage: $N {start|stop|restart|force-reload} 2
exit 1
;;
esac
exit 0
Note that there are certain aspects of this script which remain in doubt.
For example, it is not clear whether restart works in all cases because
jBoss might not cleanly release and unbind the sockets it was using for
its listeners, requiring that the sockets go through a TIME_WAIT stage
before they can be reacquired and bound to the new server instance. In
this case, the sleep 3 in the restart code may need to be lengthened.
Also, since jBoss is not (yet) an official Debian package, the use of 95
and 15 to control the start and stop order relative to other packages
Re: [JBoss-user] Memory Leak problem
Please see my rather detailed reply to David Ward [EMAIL PROTECTED] in a post I sent a few minutes ago. I include the entire startup script as part of that message, explaining the use of the standard Debian utility start-stop-daemon which is at issue here. -- Mike On 2001-06-21 at 14:57 -0700, Scott M Stark wrote: How are you starting the server process? The only way I can see doing this is redirecting the stderr descriptor to a file as parting of the startup process and then sending the vm a SIGQUIT signal. - Original Message - From: Michael Bilow [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, June 21, 2001 1:13 PM Subject: Re: [JBoss-user] Memory Leak problem In our installation (Linux), jBoss runs as a server process, which means it has no console. In fact, it runs under the privilege of the jboss system user, who cannot even log in. All ownership and permission information is tied to this system user, so running under any other user would be prohibitively difficult. It is ordinary to set up something like jBoss this way, since otherwise it would be tied to the user console and die when the user logged out, which is obviously undesirable in real production. It is possible to rig up a test environment where a console is set up by a shell running as the jboss user and then jBoss is started through the nohup utility or some similar method to redirect stdout and stderr to disk files, but this is a pretty awkward configuration and I think it would require modifying the run.sh file. Is there any other way to get dump information to go to a file instead of to the usually non-existent stderr? This would be very helpful on Unix. -- Mike On 2001-06-21 at 08:41 -0700, Scott M Stark wrote: Obtain a thread dump of the vm in this situation to see where the threads are via a Ctrl-\ or SIGQUIT. This gets dumped to stderr so you need to redirect this or have a huge console buffer or logging. ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] More Out of Memory Errors!
Maybe I can throw a little light on this. I don't know too much about
what goes on inside jBoss or the JVM, but I can tell you what I see
happening on a Linux system.
When something is wrong with the deployable EAR, and I am not really sure
exactly what, jBoss can get into a state where it just starts creating
threads until the operating system puts a stop to it. In Linux, each
thread gets a process identifier ('pid') and threads are 'lightweight
processes' which run on the operating system scheduler. The threads share
memory and descriptors so the overhead is much less than for heavyweight
processes, which is the whole purpose of threads.
However, the system limitations applicable to heavyweight processes apply
equally to lightweight processes, in particular that a single non-root
user may never exceed half of the available system pids. By default when
building a Linux 2.2 kernel, the system has a global limit of 512 pids.
This is configurable in the linux source (include/linux/tasks.h):
#define NR_TASKS512 /* On x86 Max about 4000 */
#define MAX_TASKS_PER_USER (NR_TASKS/2)
#define MIN_TASKS_LEFT_FOR_ROOT 4
It is possible on most platforms which run Linux to increase this number
in the source code and rebuild the kernel. (It is problematic on SPARC,
but that it beyond the scope of the discussion here.) Nevertheless, it is
important to realize that (a) there is always some finite limit which
usually has a grounding in actual hardware, (b) scheduling lots of threads
requires time and effort on the part of the kernel which is by definition
done at the expense of useful work, and (c) Linux typically runs on large
servers using only the defaults such that increasing the task count is so
rare that it requires a source edit rather than a configuration option.
As long as jBoss is not run by the root user, which is obviously extremely
dangerous and undesirable for other reasons anyway, the maximum number of
pids it can own concurrently is going to be limited to 255 on a default
kernel. Once this thread limit is reached, jBoss will essentially wedge
to the point where it no longer even responds to SIGTERM to shut down
gracefully, but requires SIGKILL to stop it. I think that jBoss sees this
situation as an out of memory condition as reflected by the JVM, but I
am not sure about this. Of course, if jBoss is run by the root user for
some reason, the entire machine will be wedged at this point and the only
remedy would be something as drastic as the reset switch or the watchdog.
These observations apply to JBoss-2.2.1/Tomcat-3.2.1 running on Debian
(Woody) using Java HotSpot(TM) Server VM (build 1.3.1-b24, mixed mode).
The Linux kernel is 2.2.19 SMP. The run.sh file has been modified to
include the switches -Xms8m -Xmx480m so as to allow the JVM to allocate
much more than the default 64MB, but in fact it usually only allocates
between 45MB and 65MB before wedging. The machine has 256MB physical RAM
and 1GB of swap, and in practice never swaps. Here is a snapshot with
jBoss running under moderate load:
total used free sharedbuffers cached
Mem:257640 191672 65968 73588 77708 22528
-/+ buffers/cache: 91436 166204
Swap: 1048560 01048560
The main thread of the JVM at this point shows:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME
jboss19954 0.6 25.3 923052 65184 ? S05:01 0:36
Notice that the operating system virtual machine size of 923MB is a little
large, but this is just address space and is fairly far divorced from
actual memory. The real resident size of the JVM is only 65MB, and the
whole machine has only about 200MB allocated and none of the 1GB swap
space in use at all. I am not sure why the JVM has such a large amount of
address space allocated, even if not actual memory, when it has been told
that it can use only about half of that. Remember that the data above
comes from a snapshot of a normally running jBoss installation. However,
maybe out of memory means exactly what it says.
-- Mike
On 2001-06-21 at 05:43 -0400, Jim Archer wrote:
Were are battling this even as I type...
It seem that if jBoss hits the operating systems pid (thread) limit for a
process, it throws out of memory exceptions. We just ran some load test
scripts and when we get too many threads, pop goes the weasil.
I'm looking at two possibilities... Catch the out of memory exceptions in
my code and then sleep for a bit and try again (not a great olution) or
throw more hardware / operating system at it.
Maybe both.
Does anyone know what jBoss should do when the thread limit is hit?
Thanks...
Jim
--On Thursday, June 21, 2001 10:11 AM +0100 Nicolai P Guba
[EMAIL PROTECTED] wrote:
Hello
The problem is much more drastic than I initially thought. I just
asked a question about closing PreparedStatements. Obviously, I had a
Re: [JBoss-user] Memory Leak problem
In our installation (Linux), jBoss runs as a server process, which means it has no console. In fact, it runs under the privilege of the jboss system user, who cannot even log in. All ownership and permission information is tied to this system user, so running under any other user would be prohibitively difficult. It is ordinary to set up something like jBoss this way, since otherwise it would be tied to the user console and die when the user logged out, which is obviously undesirable in real production. It is possible to rig up a test environment where a console is set up by a shell running as the jboss user and then jBoss is started through the nohup utility or some similar method to redirect stdout and stderr to disk files, but this is a pretty awkward configuration and I think it would require modifying the run.sh file. Is there any other way to get dump information to go to a file instead of to the usually non-existent stderr? This would be very helpful on Unix. -- Mike On 2001-06-21 at 08:41 -0700, Scott M Stark wrote: Obtain a thread dump of the vm in this situation to see where the threads are via a Ctrl-\ or SIGQUIT. This gets dumped to stderr so you need to redirect this or have a huge console buffer or logging. ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] jBoss mention in IBM developerWorks article
jBoss received positive mention in an article in IBM developerWorks: http://www-106.ibm.com/developerworks/library/co-tipejbs.html Obviously, since IBM sells WebSphere, the article is focused on that. -- Mike ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Documentation issues (was: Unable to resolve JNDIname)
On 2001-05-15 at 12:12 +0200, [EMAIL PROTECTED] wrote: Is it a bug? Shouldn't jBoss report that it could not find jboss.xml during deployment? No, if no jboss.xml found, it uses the standardjboss.xml in the configuration dir. Same applies to the jaws.xml (it uses standardjaws.xml instead). Only ejb-jar.xml is required. This sort of thing, although not this particular one, bit me before between jboss.xml and jboss-auto.xml. It might be a good idea to put the start-up sequence and the complete list of files and their alternatives into a single place in the documentation under a heading like Starting Sequence. Many of these issues are documented, but are scattered all over the documentation. I think it might be prudent for jBoss at least to make a log entry, something like jboss.xml not found; using standardjboss.xml default instead. This would make it a lot easier to figure out what is going on. While on the subject of documentation, it would be really handy to have a keyword index of the on-line HTML manual. A utility such as ht://Dig -- http://www.htdig.org/ -- could be used to generate this off-the-shelf. For example, if someone wants to know how to configure jBoss for Postgres, they need to look under Minerva. Having a keyword index would allow them to look under Postgres and produce fruitful results. -- Mike P.S. Personal note to Manu Srivastava, who started this thread (his words are those marked with ): Are you the same person as Manoj Srivastava? If so, hello! ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] jboss startup problems postgresql driver
I have a few suggestions. First, if you are not using Hypersonic at all, which appears to be the case, then you should remove the reference to org.hsql.jdbcDriver as a JdbcProvider. We had long hangs at the same point you did, depending upon how much memory and CPU power we were throwing at the installation. On a throw-away 166 MHz machine with 64 MB RAM running Debian Linux, we saw a hang of 45 minutes before jBoss woke up and continued initializing! Admittedly, we were specifically trying to test how far down the hardware curve we could push this. Second, I have heard that there is some sort of bug in connecting with Postgres where a password must be specified. I have not personally tried using Postgres with a blank password, so I do not know if this is true. -- Mike On 2001-05-15 at 13:46 +0200, Haug Bürger wrote: Hi, my jboss doesn't start propperly, it hangs at [myWMS] Starting [myWMS] XA Connection pool myWMS bound to java:/myWMS I removed the jboss-auto config file and moved the drivers jar-file to lib/ext. I can access the database with isqlview which uses the same driver. I trimmed the jbos.jcml to the necessary stuff that i guess it's necessary. What is wrong with my configuration? * * * !-- JDBC -- !-- Drivers that could be used by jBoss -- mbean code=org.jboss.jdbc.JdbcProvider name=DefaultDomain:service=JdbcProvider attribute name=Driversorg.postgresql.Driver,org.hsql.jdbcDriver/attribute /mbean mbean code=org.jboss.jdbc.XADataSourceLoader name=DefaultDomain:service=XADataSource,name=myWMS attribute name=PoolNamemyWMS/attribute attribute name=DataSourceClassorg.opentools.minerva.jdbc.xa.wrapper.XADataSourceImpl/attribute attribute name=Properties/attribute attribute name=URLjdbc:PostgreSQL://mona/myWMS/attribute attribute name=GCMinIdleTime120/attribute attribute name=JDBCUserbuerger/attribute attribute name=MaxSize10/attribute attribute name=Password / attribute name=GCEnabledfalse/attribute attribute name=InvalidateOnErrorfalse/attribute attribute name=TimestampUsedfalse/attribute attribute name=Blockingtrue/attribute attribute name=GCInterval12/attribute attribute name=IdleTimeout180/attribute attribute name=IdleTimeoutEnabledfalse/attribute attribute name=LoggingEnabledfalse/attribute attribute name=MaxIdleTimeoutPercent1.0/attribute attribute name=MinSize0/attribute /mbean ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
[JBoss-user] Distribution formats: tar vs. zip
Just to add a comment here, even bare tar would be really nice instead of just zip. Unlike zip, tar preserves Unix ownership and permissions. At present, these have to be set by trial and error, since as far as I know the necessary information is not even documented. It is possible to set everything in jBoss to -rwxrwxrwx or something similarly foolish, but from a security perspective on Unix this is suicidal. -- Mike On 2001-05-14 at 09:51 +0530, Vinay Ram P S wrote: The format of jboss installation is .zip Isn't there any .rpm format for linux? ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] jBoss architecture question
Here is something interesting which I just discovered was added into the man/man1/java.1 file which comes with the April 23 Release Candidate 2 of JDK 1.3.1 for Linux: -Xrs Reduce usage of operating-system sig- nals by Java virtual machine (JVM). Sun's JVM catches signals to implement shutdown hooks for abnormal JVM termi- nation. The JVM uses SIGHUP, SIGINT, and SIGTERM to initiate the running of shutdown hooks. The JVM uses SIGQUIT to perform thread dumps. Applications that embed the JVM fre- quently need to trap signals like SIG- INT or SIGTERM, and in such cases there is the possibility of interfer- ence between the applications' signal handlers and the JVM shutdown-hooks facility. To avoid such interference, the -Xrs option can be used to turn off the JVM shutdown-hooks feature. When -Xrs is used, the signal masks for SIGINT, SIGTERM, SIGHUP, and SIGQUIT are not changed by the JVM, and signal han- dlers for these signals are not installed. As I read this, it seems to imply that the Sun JVM (at least as of 1.3.1) does install some sort of default handler for signals such as TERM, and that this new switch allows suppressing the installation of these default handlers so that the signal is passed through to the application in the raw, as it were. Whatever the implications of this, it does seem that jBoss will have to take this new switch into account, even if only to document that it may be incompatible. I do not yet know if the existence of this new switch means that the default behavior changed from JDK 1.3.0 to 1.3.1. Any comments or observations would be welcomed. -- Mike On 2001-05-13 at 15:51 -0400, Samuel Bucholtz wrote: Yes, you are quite right. However, we are, as you say stuck with whatever implementation is made by the JVM. Other than wrapping some native C code to handle signals and then communicate them to the java threads using some means, like sockets, there is nothing that can be done. It seems simple enough to test this on whatever implementation you happen to be on. Write a small program that spawns some threads, kill -TERM pid one of the threads and see what happens. Most likely you will have to do this for every VM and OS you routinely use. I know that we here have scripts that kill iPlanet threads automatically to keep the app server from dying, I do not know if these scripts are sending TERMs or KILLs though. This of course might work on a website where the only thing that is lost when the thread is killed is the request, it would not if there are interdependencies between threads. Samuel -Original Message- From: Michael Bilow [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 13, 2001 13:36 To: '[EMAIL PROTECTED]' Subject: RE: [JBoss-user] jBoss architecture question No, no... I agree that, in the abstract, it makes sense to send the TERM signal only to the initial or master thread. Furthermore, I entirely agree with you that it might be appropriate for a thread to ignore TERM if the necessary shut down processing is handled by the master thread. There is no way, at least on Linux, to distinguish processes and threads from userland. A thread has a process ID (pid) and runs on the system scheduler just like any other process. The distinction between a process and a thread in Linux is made in terms of kernel memory mapping during task switching, since the defining characteristic of a thread is that it shares the complete memory descriptor table of all other fellow threads. The end result is that threads show up on the process list because they have pids and they are therefore subject to being sent signals. This is absolutely unavoidable in a Linux environment. Therefore, there must be some facility in each thread to handle signals when they are sent. If the proper behavior is for threads to ignore TERM signals, then they must install handlers to do so. If the threads should ignore signals and they do not, then the application is, in fact, unstable. If the JVM can be depended up to sort this out and call the signal handler in the master thread even when the signal is actually sent by the system to the child thread, then that is a solution. However, I do not know enough about the internals of any JVM to be sure that this is the case, and I doubt that such behavior is guaranteed to occur on every JVM even if it does occur on some JVMs. The Sun and IBM JVMs might do exactly opposite things in this regard, although I have no idea what they do. This discussion arose because, in the quoted post to the list, danch said that it was a bad thing to send TERM to child threads and that TERM should should only be sent to the master thread. So the issue for me is what happens if TERM is sent to all of the threads instead of just the master thread? Are the TERM signals
RE: [JBoss-user] jBoss architecture question
No, no... I agree that, in the abstract, it makes sense to send the TERM signal only to the initial or master thread. Furthermore, I entirely agree with you that it might be appropriate for a thread to ignore TERM if the necessary shut down processing is handled by the master thread. There is no way, at least on Linux, to distinguish processes and threads from userland. A thread has a process ID (pid) and runs on the system scheduler just like any other process. The distinction between a process and a thread in Linux is made in terms of kernel memory mapping during task switching, since the defining characteristic of a thread is that it shares the complete memory descriptor table of all other fellow threads. The end result is that threads show up on the process list because they have pids and they are therefore subject to being sent signals. This is absolutely unavoidable in a Linux environment. Therefore, there must be some facility in each thread to handle signals when they are sent. If the proper behavior is for threads to ignore TERM signals, then they must install handlers to do so. If the threads should ignore signals and they do not, then the application is, in fact, unstable. If the JVM can be depended up to sort this out and call the signal handler in the master thread even when the signal is actually sent by the system to the child thread, then that is a solution. However, I do not know enough about the internals of any JVM to be sure that this is the case, and I doubt that such behavior is guaranteed to occur on every JVM even if it does occur on some JVMs. The Sun and IBM JVMs might do exactly opposite things in this regard, although I have no idea what they do. This discussion arose because, in the quoted post to the list, danch said that it was a bad thing to send TERM to child threads and that TERM should should only be sent to the master thread. So the issue for me is what happens if TERM is sent to all of the threads instead of just the master thread? Are the TERM signals sent to the child threads ignored, which would be fine? Are the TERM signals sent to the child threads reflected by the JVM to the master thread, which would also be fine? Or do the TERM signals sent to the child threads pass through unhandled and kill those threads abruptly, which presumably would NOT be fine? -- Mike On 2001-05-13 at 02:35 -0400, Samuel Bucholtz wrote: This is not 100% true. On Unix any process should expect to receive and handle a TERM signal. Threads on the other hand do not need to and should not be expected to handle a TERM. Remember, threads only act and look like processes when using native threads as opposed to pure java threads. The threads, logically, must act the same and be as similar as possible whether Native or Pure. Since pure threads run within the JVM process and will never see or handle a signal, there is no reason to expect the native threads to do so either. Rather, in the case of some kind of impending shutdown, etc. the signal should reach the master process which spawned (and therefore controls) the threads. It is that processes responsibility to gracefully stop the threads, flush buffers, sync files, etc. A thread does not control its resources, scheduling, etc. It may or may not even be able to communicate with it's scheduler/parent. There is no way to expect it to be able to receive a TERM and know how to handle it in a graceful manner. As long as the parent can control/stop threads, and do the proper thing when it received a signal, there is no reason to consider the application unstable, just because the threads ignore signals. Samuel -Original Message- From: Michael Bilow [mailto:[EMAIL PROTECTED]] Sent: Sunday, May 13, 2001 2:10 To: List: jBoss users Subject: Re: [JBoss-user] jBoss architecture question On 2001-05-11 at 22:09 -0500, danch wrote: Jim Archer wrote: * * * All the threads also raise a shutdown question. We have written an init.d script to gracefully start and stop jBoss as a server task, in the same manner as other Debian processes. If the script issues a kill to each thread, will this produce a gracefull shutdown, or will it terminate each thread ungracefully? The kill should be sent to the parent of all the threads. If you look at ps -axf output you'll see that run.sh spawns one process, which is then the parent for all the threads. A change in run.sh to save the pid of the java process into a file in var would be the best way to accomplish this. I have a concern about this. On Unix, any process/thread should expect to receive a TERM signal and is obligated to handle it appropriately. If the process/thread elects not to install a handler to catch the TERM signal, then the default is for the system to kill the process abruptly, which is usually inappropriate for anything except the most trivial programs. It is not possible on Unix
Re: [JBoss-user] Re: JBoss-user -- confirmation of subscription --request 343542
The client is not finding the RMI Registry Server because it assumes it is running on the same machine (127.0.0.1). You should be able to fix this by invoking the client with an explicit declaration of the hostname or IP address of the machine on which the RMI Registry Server is actually running, like this (all on one line): java -Djava.rmi.server.hostname=xxx.xxx.xxx.xxx -cp all the jar files in the client directory InterestClient where xxx.xxx.xxx.xxx is the IP address of the machine which hosts the RMI Registry Server in dotted-quad notation. Where the RMI Registry Server is actually running, by default it will install a TCP listener on port 1099. You should be able to see it: $ netstat -tan | grep 1099 tcp0 0 0.0.0.0:10990.0.0.0:* LISTEN This is actually a configurable system property; see: http://java.sun.com/products/jdk/1.2/docs/guide/rmi/faq.html#nethostname http://java.sun.com/j2se/1.3/docs/guide/rmi/faq.html#nethostname -- Mike On 2001-05-13 at 06:51 -, Kobi Schecider wrote: I am new to JBoss and have been trying to get the interestclient example running (the client and the EBJ running on different machines) without * * * java -cp all the jar files in the client directory InterestClient Got context javax.naming.CommunicationException [Root exception is java.rmi.ConnectException: Connection refused to host: 127.0.0.1; nested exception is: java.net.ConnectException: Connection refused: no further information] My CLASSPATH is empty. The same configuration (with the java.naming.provider.url set to localhost) works perfectly when both client and JBoss server are running on the same machine. ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] jBoss architecture question
On 2001-05-11 at 22:09 -0500, danch wrote: Jim Archer wrote: * * * All the threads also raise a shutdown question. We have written an init.d script to gracefully start and stop jBoss as a server task, in the same manner as other Debian processes. If the script issues a kill to each thread, will this produce a gracefull shutdown, or will it terminate each thread ungracefully? The kill should be sent to the parent of all the threads. If you look at ps -axf output you'll see that run.sh spawns one process, which is then the parent for all the threads. A change in run.sh to save the pid of the java process into a file in var would be the best way to accomplish this. I have a concern about this. On Unix, any process/thread should expect to receive a TERM signal and is obligated to handle it appropriately. If the process/thread elects not to install a handler to catch the TERM signal, then the default is for the system to kill the process abruptly, which is usually inappropriate for anything except the most trivial programs. It is not possible on Unix to guarantee that the graceful shutdown script will always be followed so that the right signals are sent to the right recipient processes/threads. In the case of a power failure notification from a UPS daemon or an emergency shutdown initiated by the watchdog daemon, a TERM signal will be sent directly to every process/thread. The process/thread TERM handler should then do whatever is necessary to close files, commit data, notify network partners, and otherwise assure at least a stable shutdown if not a graceful one. If a process/thread elects to catch TERM and do something in response, then it had better do it fairly quickly because, if time runs out, then the system can be expected to send the uncatchable KILL signal and then the process/thread is guaranteed to go down hard. Really bad things can then happen, such as the filesystem being closed with process/thread data uncommitted to disk. For a process/thread to be considered stable on Unix, it _must_ catch and handle the TERM signal intelligently if failing to do so would lead to data corruption or other instability. This means that it should be safe for every thread in jBoss, whatever it may be doing, to be sent TERM asynchronously in indeterminate order, and it must also be safe for any of these threads to be sent TERM more than once. -- Mike ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Postgres woes
How is the data source declared in jboss.jcml? Are you on Potato (with Postgres 7.0.2) or Woody (with Postgres 7.1)? Are you relying on the libpgjava package or did you build the JAR? -- Mike On 2001-05-10 at 01:41 +0100, Jim Downing wrote: Hi, I'm trying to port our J2EE app from NT/Oracle to Debian/Postgresql. The postgres datasource is connecting fine on startup, but when any ejbCreate method is called (i.e. an INSERT is called) postgresql throws this: java.lang.reflect.UndeclaredThrowableException: javax.transaction.RollbackException: Unable to commit, tx=XidImpl [FormatId=257, GlobalId=lovestuffer.internal.paribus.com//3, BranchQual=] status=STATUS_ROLLEDBACK at org.jboss.tm.TxCapsule.commit(TxCapsule.java:368) at org.jboss.tm.TransactionImpl.commit(TransactionImpl.java:76) at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:318) ... I've been able to create and drop tables through jdbc with the ant task sql, I have the right driver, and the same application deploys and runs successfully with an Oracle datasource. I'm confused! Any tips gladly received. jim ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] problem with uncompressing of JBoss on Linux
The gunzip utility (usually actually implemented as a symlink) is the decompressor for gzip. Although the compression schemes used by gzip/gunzip and zip/unzip are compatible, the file formats are not. The standard portable freeware unzip/zip tools from the Info-ZIP project can be built on Unix/Linux and are usually available as precompiled packages. Debian, for example, offers the zip and unzip standard packages (and the zip-crypt and unzip-crypt alternative packages with encryption); as usual on a Debian system they can be installed with a single command (apt-get install zip or apt-get install unzip): http://packages.debian.org/zip http://packages.debian.org/unzip http://packages.debian.org/zip-crypt http://packages.debian.org/unzip-crypt Full information and source code is available: http://www.info-zip.org/pub/infozip/ The Info-ZIP tools are very high quality and emulate the behavior of PKZIP, which is what Java uses for jar-style files. The zip/unzip tools supplied by IBM with OS/2, for example, are built from Info-ZIP source. The JDK jar utility can used with tar syntax to decompress a PKZIP-format file (jar -xvf filename). Note that PKZIP format is an inconvenient way to distribute things for Unix/Linux, since ownership and permission information is lost. Once the files and directories have been extracted, ownership and permissions must be configured manually by the system administrator for each file and directory. This process is often mostly done by trial and error. -- Mike On 2001-04-29 at 22:00 -0400, Jim Archer wrote: You don't have gunzip ??? Jim --On Monday, April 30, 2001 9:46 AM +1000 Scott Warren [EMAIL PROTECTED] wrote: just a hunch - I am not a linux user. Try using the Jar util. HTH Regards Scott Warren Lead Internet Technologies Developer * * * -Original Message- From: jquest jquest [mailto:[EMAIL PROTECTED]] Sent: Saturday, 28 April 2001 9:04 PM To: [EMAIL PROTECTED] Subject: [JBoss-user] problem with uncompressing of JBoss on Linux Hi all, I try to install JBoss on Linux Mandrake 8.0. I downloadet the .Zip and can not unzip this file. I can not find any unzip command on my system. I trayed to use gunzip but have no success. Any idea? Thanks in advance. ___ JBoss-user mailing list [EMAIL PROTECTED] http://lists.sourceforge.net/lists/listinfo/jboss-user
