Drew Lane

Ranch Hand
+ Follow
since May 13, 2001
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Drew Lane

I seem to be having a similar problem.

Did you ever find a solution?

Which JRE were you using?
I'm stumped.

I'm trying to parse an xml file on my server but I keep getting a TransformerConfigurationException with no detail as to what is causing the problem.

Here is where the exception occurs:
Templates stylesheet = factory.newTemplates(xslSource);

I am using IBM Java 1.4.2 on the server (This was parsing correctly at some point in the past).

I just tested this on my desktop with Sun Java 1.6 and it worked fine.

This is how I get the xslSource:
StreamSource xslSource = new StreamSource("/var/www/webapp/WEB-INF/xsl/myxsl.xsl");

I have verified the path to the xsl file is correct.

Has anyone seen this before?

How can I get some details about what is causing the exception?

Thanks!
How do I generate a new .keystore file in my home directory?

I'm afraid I may have messed it up trying to import a certificate.

What should the .keystore file contain?

Thanks,

Drew
14 years ago
Say I have two threads, A & B.

Thread A is started from the main event thread.

Thread B is started inside Thread A at the very end of its run method.

Does thread A stay alive until thread B is finished?
Okay. I better leave it alone now. :-)

Thanks again!
15 years ago
Just found this is dmesg:


What does that mean?
15 years ago

Originally posted by Charles Lyons:
Setting the commit time higher than the default (5 seconds) would seem sensible if that's what's causing the problem. I guess your other machine doesn't have a journalling system like ext3, or its commit is longer too?



Hmm...I just checked this.

The other system is using ext3 and the commit time is set to 5 seconds also but it's certainly a lot quieter.

I just ran fsck and it found some problems and dropped me into a shell, so I did it again and it came up clean.

Perhaps there was a corrupt file in one of my java apps?

Or it could be that my hard drive is going south...

However, it seems fine now and I got the performance up a bit by using the correct Apache module for Resin. Seems to be on par with the other system now.
15 years ago
Okay, this seems to be working:

/etc/fstab


/etc/sysctl.conf


Let me know if you see any problems with that.

Thanks for your help!
15 years ago
Cool!

Kjournald? Journaling file system? Can I turn it off?

Also, what is dirtied inode?

15 years ago
The hard drive activity mostly stops when I shut down resin. I would say it sounds normal when resin is not running. I wish I knew what it was doing because it's not in production and nothing much is running on it. I'm not using any utility to check it but I can see the green light go on every 4-5 seconds. That sucker is a loud SCSI drive too!

I suppose the other difference is that I've got resin 2.x on the other machine and resin 3.x on the one with the newer kernel.

The JVM's are from IBM and are quite good.

In fact, I just installed the Java 5 SDK so I'll try that now.

Is there any way to tell what the heck that hard drive is doing?
15 years ago
Well, okay...

But why am I getting hard drive access every 4-5 seconds?

Also, it's taking quite a bit longer to compile java files.

It just seems to be a little less peppy overall.
15 years ago
I'm using Yellow Dog Linux 4.0 on an old Mac.

cat /proc/meminfo
15 years ago

Originally posted by Charles Lyons:
It is also possible that your server isn't set to overcommit (seems unlikely given you say not much RAM is in use). A JVM allocates a lot more memory than it ever uses, so that can be a problem. Here's a quote about this 2.6 kernel feature: There's more advice in this article on Linux Memory Overcommit.



Overcommit sounds like it might be whats happening.

I'm not sure how I set this and make it stick?

There is definitely some differences in memory management with the 2.6 kernel.

When I look at top, the VIRT heading show 353m for Java. The top manual says VIRT is the amount of Virtual memory for the task.

How do I tell linux not to use virtual memory for this task?
15 years ago

Originally posted by Charles Lyons:
Have a look at this article on Tuning Swappiness (and swapping behaviour). It may or may not help (post back and let us know).

512MB is not a lot of RAM for a Java EE server under load though. I generally recommend at least 1GB for any server these days, with RAM being so cheap. How large is your swap?

[ December 16, 2008: Message edited by: Charles Lyons ]



I set the swappiness to 0 but I'm not seeing any dif.

I hear you about the RAM, but this is a very old computer and it's not so cheap - not worth investing more money into but it's been such a workhorse it's hard to give it up. :-)

The swap size is 458MB and I don't even see it getting used when I run top!

I don't know...maybe I should go back to the 2.4 kernel for this old dog.

Any idea why it's only using half of the RAM? The computer with the 2.4 kernel is using almost all of the RAM in the computer.
15 years ago
I have two computers that I use as servers.
They both have the same hardware.
They are kind of old but they both work. :-)

Both have 512MB RAM

One has Linux kernel 2.4 with Java 1.4.1

I recently upgraded the other machine to kernel 2.6 with Java 1.4.2

I seem to be having a problem with the JVM using virtual memory instead of RAM on the "upgraded" computer.

After I start my Java application server (Resin) there is hard drive activity every 5 seconds and the performance is slower on the computer with the newer kernel. The top command shows about half of the real memory is being used on this computer.

The computer without the upgrade shows almost all of the memory is being used by the system and I don't get the hard drive activity every 5 seconds.

Does anyone know what's going on here?
15 years ago