Home » Language IDEs » ServerTools (WTP) » "Publishing to Tomcat" takes forever!
| "Publishing to Tomcat" takes forever! [message #153001] |
Tue, 20 December 2005 12:07  |
Eclipse User |
|
|
|
Originally posted by: dserodio.gmail.com
I have a web project that is deployed to a Tomcat 5.5.12.
Eveytime I make a change, the progress bar says it's "Publishing to
Tomcat server (0%)", and when I open the Progress view, there is a
"Publishing to Tomcat v5.5 Server @ localhost... - Performing Tasks"
task, followed by lots (10+) of "Extract the Content Descriptor of
Children (Waiting)". Apparently, it hung, so I have to kill Eclipse and
Tomcat, then restart Eclipse. Eventually, it works.
How can I find out what is taking so long? Does anyone have a clue?
Thanks,
Daniel Serodio
|
|
| | |
| Re: "Publishing to Tomcat" takes forever! [message #153044 is a reply to message #153036] |
Tue, 20 December 2005 16:02  |
| Eclipse User |
|
|
|
Originally posted by: caclark.etechsolutions.net
Vincent Jenks said the following on 12/20/2005 9:21 AM:
> Agreed, this is insanely slow. I've had this problem since moving from
> eclipse 3.0.1 to 3.1.1 with webtools 0.7.1 through 1.0RC5.
>
> Not only is publishing extremely slow...but so much as saving a servlet
> or jsp while Tomcat is running within webtools will make it drag even
> more slowly, entirely outside of publishing to tomcat. Turning off
> validation helped a *little* bit but there was hardly a difference...and
> validation is pretty important for productivity...IMO.
>
> I've been see-sawing between Netbeans and Eclipse WTP for a long time
> for J2EE development and unfortunately, I'm going to have to check back
> w/ WTP at a later time to see if this problem has gone away...meanwhile,
> though I don't particularly like it, this issue has forced me to use
> Netbeans as a lesser of two evils. If it weren't for the speed problems
> I'd be a 100% dedicated WTP user instead...because otherwise it's
> fantastic!
>
> I wish I knew more about SWT + Eclipse - I'd quit complaining and
> contribute some optimizations. Not trying to flame anyone, so I
> apologize in advance!
>
> -v
>
<rant>
Well, after suffering through horribly slow save times, I did some
investigation.
Seems they've replaced the .deployables with a <workspace
dir> \.metadata\.plugins\org.eclipse.wst.server.core\tmp1\webapps \ <web
app> directory. This is apparently where it's running from.
What I don't understand is why. Certainly the plugin should be able to
get my project\WebContents directory and refer to it. Instead, it's
trying to "publish" to the directory under the workspace. Well, my
project has 16MB+ of jar files and 20MB+ of classes and other stuff. On
a nicely configured machine, it "only" takes 1min 45secs. Gee, hope you
don't need to make any small changes to your JSP's or, in my case, .lzx
files to fine tune anything. Or, if you do, hope you're not in any hurry.
My question is why the server plugin can't take the Context attribute:
source="org.eclipse.jst.j2ee.server:Citizen Portal" and ask the
workspace where Citizen Portal resides on disk and run from there. It's
apparently asking it for the directory where the .metadata resides and
appending paths to it to come up with a location now.
BTW, I went into my server definition, unfolded the Automatic Publishing
section on the Overview tab, and unchecked Override default settings
(which was set to 1 second!) and it quit eating up my machine in a
seamingly idle state.
So, 0.7.1 was definitely better. Even building the project and updating
the .deployables directory was MUCH faster than this.
</rant>
Cary
|
|
| |
| Re: "Publishing to Tomcat" takes forever! [message #153058 is a reply to message #153028] |
Tue, 20 December 2005 19:10 |
| Eclipse User |
|
|
|
Originally posted by: dserodio.gmail.com
Francois Masurel wrote:
> Yep, I've the same pb. And it seems to me that it has appeared between
> RC4 and RC5. May be it's coz my web app is depending on quite a few J2EE
> modules. And as far as I remember the project was synchronizing before
> startup without the need for a full republication before.
I also think it started in RC5. I just filed bug #121603; I'd *really*
like it to be fixed before 1.0 final, but I don't know how to help.
I hope someone in the WTP team notices it.
Daniel Serodio
|
|
|
| Re: "Publishing to Tomcat" takes forever! [message #153090 is a reply to message #153044] |
Wed, 21 December 2005 10:10 |
 Darryl Miles
Messages: 123
Registered: July 2009 |
Senior Member |
|
|
Cary wrote:
> Well, after suffering through horribly slow save times, I did some
> investigation.
>
> Seems they've replaced the .deployables with a <workspace
> dir> \.metadata\.plugins\org.eclipse.wst.server.core\tmp1\webapps \ <web
> app> directory. This is apparently where it's running from.
Just to correct you. I think you'll find the tmp1 sub-tree always
existed even when .deployables was around, but then I wasn't taking too
much notice at the time. There is no direct replacement for .deployables.
> What I don't understand is why. Certainly the plugin should be able to
> get my project\WebContents directory and refer to it.
Some people don't want to clutter their workspace source tree with
additional items need at deployment time. For example most people don't
want to put JARs into project\WebContents\WEB-INF\lib but want to make
use of linked JARs and references JARs and let Eclipse copy into the
runtime working tree as necessary.
This keeps your project\ subtree nice and clean with just the minimal
set of things that actually make up the project within it.
It presents a huge problem to run TC directly out of project\WebContent,
some people use revision control systems and they will be forever trying
to manage the .cvsignore files.
> Instead, it's
> trying to "publish" to the directory under the workspace. Well, my
> project has 16MB+ of jar files and 20MB+ of classes and other stuff. On
> a nicely configured machine, it "only" takes 1min 45secs. Gee, hope you
> don't need to make any small changes to your JSP's or, in my case, .lzx
> files to fine tune anything. Or, if you do, hope you're not in any hurry.
Even on my dual P3-550MHz 512mb box the initial publish only take
downward of 10 seconds and a normal incrememtal publish less than 2. I
have a 35Mb total fileset set for the project I'm speaking of.
Maybe the problem isn't where you are implying or your configuration
shows up a performance bottleneck other people cant see.
If I make a small change to a JSP and click publish the operation
complete within 2 seconds.
> BTW, I went into my server definition, unfolded the Automatic Publishing
> section on the Overview tab, and unchecked Override default settings
> (which was set to 1 second!) and it quit eating up my machine in a
> seamingly idle state.
I have opened bug reports today that describe this sort of behaviour you
are seeing. This being unwanted / unecessary publish operations going
on in some situations.
I've not found a problem generally though with 1 second, since if there
is nothing to publish (i.e. no changes have been made in the workspace
within the last second) the operation does nothing.
Darryl
|
|
|
| Re: "Publishing to Tomcat" takes forever! [message #153096 is a reply to message #153001] |
Wed, 21 December 2005 10:15 |
Darryl Miles
Messages: 123
Registered: July 2009 |
Senior Member |
|
|
Daniel Serodio wrote:
> Eveytime I make a change, the progress bar says it's "Publishing to
> Tomcat server (0%)", and when I open the Progress view, there is a
> "Publishing to Tomcat v5.5 Server @ localhost... - Performing Tasks"
> task, followed by lots (10+) of "Extract the Content Descriptor of
> Children (Waiting)". Apparently, it hung, so I have to kill Eclipse and
> Tomcat, then restart Eclipse. Eventually, it works.
>
> How can I find out what is taking so long? Does anyone have a clue?
The (10+) jobs listed maybe explained in reading:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=116314
If the problem you are seeing is the same cause then Eclipse 3.2 should
fix that problem.
I am noticing regular publish operations taking longer than I expect
too, but dont know why. I first thought it was JVM GC collection but
its happening too often now to put it down to that.
Darryl
|
|
| |
| Re: "Publishing to Tomcat" takes forever! [message #153137 is a reply to message #153090] |
Wed, 21 December 2005 13:27 |
| Eclipse User |
|
|
|
Originally posted by: tuomas_kiviaho.hotmail.com
Darryl L. Miles wrote:
> Cary wrote:
>> Seems they've replaced the .deployables with a <workspace
>> dir> \.metadata\.plugins\org.eclipse.wst.server.core\tmp1\webapps \ <web
>> app> directory. This is apparently where it's running from.
>
> Just to correct you. I think you'll find the tmp1 sub-tree always
> existed even when .deployables was around, but then I wasn't taking too
> much notice at the time. There is no direct replacement for .deployables.
The serverdefinions/buildfiles ant deploy.j2ee.* targets give a
possibility alter how publishing is done. In my case using rsync to gain
full leverage of JBoss hot deployment. For projects that don't contain
dependent-module entries in the .component file I can use rsync
efficiently. I believe everything is just copied to the temp folder from
project folders declared inside wb-resource elements.
>> What I don't understand is why. Certainly the plugin should be able
>> to get my project\WebContents directory and refer to it.
>
> Some people don't want to clutter their workspace source tree with
> additional items need at deployment time. For example most people don't
> want to put JARs into project\WebContents\WEB-INF\lib but want to make
> use of linked JARs and references JARs and let Eclipse copy into the
> runtime working tree as necessary.
>
> This keeps your project\ subtree nice and clean with just the minimal
> set of things that actually make up the project within it.
>
> It presents a huge problem to run TC directly out of project\WebContent,
> some people use revision control systems and they will be forever trying
> to manage the .cvsignore files.
But these linked projects (dependent-module) are posing a problem even
without using web content folder directly. They are packed prior ant
targets get invoked in the publishing process and placed into the temp
folder as they should be without me having any control over what's done.
If the packaging would not touch the file timestamps I'd only be glad
about the automation, since I could still unpack them for hot deployment
purposes causing only slight overhead to the process.
But since linked projects do not exist in the temp folder after
publishing is over, I believe the packaging is done from scratch every
time. This is again only timeconsuming operation, but still I wonder why
files inside package have different timestamps than the ones in the
actual project.
Other that I my self am satisfied with the change and dislike workspace
cluttering when it means duplication of already existing files. Of
course having dependent module packaging as an option in *.serverdef
files I my self would not have to unpack every single package that could
possibly be dependent modules and not just plain' ol' .jars.
|
|
|
| Re: "Publishing to Tomcat" takes forever! [message #153144 is a reply to message #153090] |
Wed, 21 December 2005 13:30 |
| Eclipse User |
|
|
|
Originally posted by: caclark.cox.net
Darryl L. Miles wrote:
> Cary wrote:
>
>> Well, after suffering through horribly slow save times, I did some
>> investigation.
>>
>> Seems they've replaced the .deployables with a <workspace
>> dir> \.metadata\.plugins\org.eclipse.wst.server.core\tmp1\webapps \ <web
>> app> directory. This is apparently where it's running from.
>
>
> Just to correct you. I think you'll find the tmp1 sub-tree always
> existed even when .deployables was around, but then I wasn't taking too
> much notice at the time. There is no direct replacement for .deployables.
That could well be. I didn't look before because on the same machine
running the same project it didn't take upwards of 1 minute to save a
< 2K text file and another 1:45 to publish it.
>
>
>> What I don't understand is why. Certainly the plugin should be able
>> to get my project\WebContents directory and refer to it.
>
>
> Some people don't want to clutter their workspace source tree with
> additional items need at deployment time. For example most people don't
> want to put JARs into project\WebContents\WEB-INF\lib but want to make
> use of linked JARs and references JARs and let Eclipse copy into the
> runtime working tree as necessary.
>
Well, I suppose that's one way to do it. But I'm of the opinion that
WEB-INF\lib was meant for placing jars into, so I do it.
> This keeps your project\ subtree nice and clean with just the minimal
> set of things that actually make up the project within it.
I don't understand this statement since the jar's in my WEB-INF/lib are
part of what actually makes up my project.
>
> It presents a huge problem to run TC directly out of project\WebContent,
> some people use revision control systems and they will be forever trying
> to manage the .cvsignore files.
>
So the drawback of running Tomcat directly from the workspace is that
you could access .cvsignore files and other project artifacts from a
development application server? What's the issue?
>
>
>> Instead, it's trying to "publish" to the directory under the
>> workspace. Well, my project has 16MB+ of jar files and 20MB+ of
>> classes and other stuff. On a nicely configured machine, it "only"
>> takes 1min 45secs. Gee, hope you don't need to make any small changes
>> to your JSP's or, in my case, .lzx files to fine tune anything. Or,
>> if you do, hope you're not in any hurry.
>
>
> Even on my dual P3-550MHz 512mb box the initial publish only take
> downward of 10 seconds and a normal incrememtal publish less than 2. I
> have a 35Mb total fileset set for the project I'm speaking of.
>
That's good for you. However, me an several others on this thread find
a very different situation.
> Maybe the problem isn't where you are implying or your configuration
> shows up a performance bottleneck other people cant see.
>
Maybe, but maybe not. I'm running the same project on the same machine
that was running 0.7.1 which was not slow; it performed rather well. As
far as other people not seeing it, I think this thread with other people
venting about slowness rebutts that. The question is, how the heck are
we going to find out what the slowness is?
> If I make a small change to a JSP and click publish the operation
> complete within 2 seconds.
>
That's the way 0.7.1 was with me. 1.0RC5 is in the tank, though.
>
>> BTW, I went into my server definition, unfolded the Automatic
>> Publishing section on the Overview tab, and unchecked Override default
>> settings (which was set to 1 second!) and it quit eating up my machine
>> in a seamingly idle state.
>
>
> I have opened bug reports today that describe this sort of behaviour you
> are seeing. This being unwanted / unecessary publish operations going
> on in some situations.
Thanks. Me and others will appreciate a fix.
>
> I've not found a problem generally though with 1 second, since if there
> is nothing to publish (i.e. no changes have been made in the workspace
> within the last second) the operation does nothing.
I could click on the Progress view and see several tasks stacked up. I
think there were several Publishes, but it's been a couple of days so I
might be remembering that incorrectly.
>
>
> Darryl
|
|
|
| Re: "Publishing to Tomcat" takes forever! [message #153152 is a reply to message #153090] |
Wed, 21 December 2005 13:39 |
| Eclipse User |
|
|
|
Originally posted by: dserodio.gmail.com
Darryl L. Miles wrote:
> Cary wrote:
>> Well, after suffering through horribly slow save times, I did some
>> investigation.
>>
>> Seems they've replaced the .deployables with a <workspace
>> dir> \.metadata\.plugins\org.eclipse.wst.server.core\tmp1\webapps \ <web
>> app> directory. This is apparently where it's running from.
>
> Just to correct you. I think you'll find the tmp1 sub-tree always
> existed even when .deployables was around, but then I wasn't taking too
> much notice at the time. There is no direct replacement for .deployables.
>
>
>> What I don't understand is why. Certainly the plugin should be able
>> to get my project\WebContents directory and refer to it.
+1 on that.
> Some people don't want to clutter their workspace source tree with
> additional items need at deployment time. For example most people don't
> want to put JARs into project\WebContents\WEB-INF\lib but want to make
> use of linked JARs and references JARs and let Eclipse copy into the
> runtime working tree as necessary.
>
> This keeps your project\ subtree nice and clean with just the minimal
> set of things that actually make up the project within it.
>
> It presents a huge problem to run TC directly out of project\WebContent,
> some people use revision control systems and they will be forever trying
> to manage the .cvsignore files.
I don't think this is a problem; the Sysdeo Tomcat Plugin works this way
and when I used it I only had to add "work" and "temp" to .cvsignore
(svn:ignore actually).
>> Instead, it's trying to "publish" to the directory under the
>> workspace. Well, my project has 16MB+ of jar files and 20MB+ of
>> classes and other stuff. On a nicely configured machine, it "only"
>> takes 1min 45secs. Gee, hope you don't need to make any small changes
>> to your JSP's or, in my case, .lzx files to fine tune anything. Or,
>> if you do, hope you're not in any hurry.
>
> Even on my dual P3-550MHz 512mb box the initial publish only take
> downward of 10 seconds and a normal incrememtal publish less than 2. I
> have a 35Mb total fileset set for the project I'm speaking of.
>
> Maybe the problem isn't where you are implying or your configuration
> shows up a performance bottleneck other people cant see.
>
> If I make a small change to a JSP and click publish the operation
> complete within 2 seconds.
>
>
>> BTW, I went into my server definition, unfolded the Automatic
>> Publishing section on the Overview tab, and unchecked Override default
>> settings (which was set to 1 second!) and it quit eating up my machine
>> in a seamingly idle state.
>
> I have opened bug reports today that describe this sort of behaviour you
> are seeing. This being unwanted / unecessary publish operations going
> on in some situations.
Which bugs? I'd like to track them.
> I've not found a problem generally though with 1 second, since if there
> is nothing to publish (i.e. no changes have been made in the workspace
> within the last second) the operation does nothing.
Daniel Serodio
|
|
|
| Re: "Publishing to Tomcat" takes forever! [message #153160 is a reply to message #153137] |
Wed, 21 December 2005 13:39 |
| Eclipse User |
|
|
|
Originally posted by: dserodio.gmail.com
Tuomas Kiviaho wrote:
> Darryl L. Miles wrote:
>> Cary wrote:
>>> Seems they've replaced the .deployables with a <workspace
>>> dir> \.metadata\.plugins\org.eclipse.wst.server.core\tmp1\webapps \ <web
>>> app> directory. This is apparently where it's running from.
>>
>> Just to correct you. I think you'll find the tmp1 sub-tree always
>> existed even when .deployables was around, but then I wasn't taking
>> too much notice at the time. There is no direct replacement for
>> .deployables.
>
> The serverdefinions/buildfiles ant deploy.j2ee.* targets give a
> possibility alter how publishing is done. In my case using rsync to gain
> full leverage of JBoss hot deployment. For projects that don't contain
> dependent-module entries in the .component file I can use rsync
> efficiently. I believe everything is just copied to the temp folder from
> project folders declared inside wb-resource elements.
That sounds interesting. Is there documentation for this feature somewhere?
Daniel Serodio
|
|
|
| Re: "Publishing to Tomcat" takes forever! [message #153175 is a reply to message #153160] |
Wed, 21 December 2005 14:51 |
| Eclipse User |
|
|
|
Originally posted by: tuomas_kiviaho.hotmail.com
Daniel Serodio wrote:
>>The serverdefinions/buildfiles ant deploy.j2ee.* targets give a
>>possibility alter how publishing is done. In my case using rsync to gain
>>full leverage of JBoss hot deployment. For projects that don't contain
>>dependent-module entries in the .component file I can use rsync
>>efficiently. I believe everything is just copied to the temp folder from
>>project folders declared inside wb-resource elements.
>
> That sounds interesting. Is there documentation for this feature somewhere?
Gorkem has written basics how to write your own server definitions
< http://www.eclipse.org/webtools/jst/components/server/tutori als/genericServers/ServerDefinitionExplained.html>
You find from JST server component overview, but not from normal
documentation section?
* * *
JBoss 4.0.x was missing and what was already available (Pro JST book had
one) was outdated and incompatible with WTP 1.0, so I had to make few
modifications based on the existing JBoss 3.2.3 server. That was one of
the simplest of the out-of-the box definitions.
It's all under org.eclipse.jst.server.generic.serverdefinitions plugin.
The part that I could not find any documentation over is the plugin.xml
it self where you insert the server definition basics like supported
versions etc. This file is nothing more that bunch of extension points.
The final part is the ant scripts that Gorkems *.serverdef file point
to. There are three ant targets - web, ejb and ear - that get
${server.publish.dir}, ${module.name} and ${module.dir} as properties.
1. Module is the context root defined in project file
..settings/.component formerly known as .wtpmodules
2. Module directory is the temporary location where publishing dumps
(semi-)unpacked version of package that you're about to deploy
3. Server publish directory is combined from the server creation
properties defined in the *.serverdef file.
Based on this information I'm able to publish unpacked builds to the
JBoss server and using rsync minimizes the file updates to redeploying
is up to me completely. The only problem is that files are touched every
time publishing done. rsync can't see directly from timestamp wether or
not the file has actually changed.
But what is missing is the current definition of .component file. I
guess this is about to change in the future. At least there is an open
bug around missing web library projects after publishing. That file
changes a lot when you make J2EE dependencies to other projects or alter
WEB-INF/lib folder (that one I believe is a bug). There are bunch of
suggestions around what that file should have or shouldn't have, so I'm
just glad that there is no flexibility in how the publishing process
interpretes dependencies or copies files to the temp folder.
|
|
|
| Re: "Publishing to Tomcat" takes forever! [message #153207 is a reply to message #153044] |
Wed, 21 December 2005 15:52 |
| Eclipse User |
|
|
|
Originally posted by: dserodio.gmail.com
Cary wrote:
<snip/>
> <rant>
>
> Well, after suffering through horribly slow save times, I did some
> investigation.
>
> Seems they've replaced the .deployables with a <workspace
> dir> \.metadata\.plugins\org.eclipse.wst.server.core\tmp1\webapps \ <web
> app> directory. This is apparently where it's running from.
>
> What I don't understand is why. Certainly the plugin should be able to
> get my project\WebContents directory and refer to it. Instead, it's
> trying to "publish" to the directory under the workspace. Well, my
> project has 16MB+ of jar files and 20MB+ of classes and other stuff. On
> a nicely configured machine, it "only" takes 1min 45secs. Gee, hope you
> don't need to make any small changes to your JSP's or, in my case, .lzx
> files to fine tune anything. Or, if you do, hope you're not in any hurry.
>
> My question is why the server plugin can't take the Context attribute:
> source="org.eclipse.jst.j2ee.server:Citizen Portal" and ask the
> workspace where Citizen Portal resides on disk and run from there. It's
> apparently asking it for the directory where the .metadata resides and
> appending paths to it to come up with a location now.
>
> BTW, I went into my server definition, unfolded the Automatic Publishing
> section on the Overview tab, and unchecked Override default settings
> (which was set to 1 second!) and it quit eating up my machine in a
> seamingly idle state.]
Is this "Overview tab" you mention in 0.7.1 or RCx? I can't find it in
RC4 or RC5.
Daniel Serodio
|
|
|
| Re: "Publishing to Tomcat" takes forever! [message #153237 is a reply to message #153207] |
Wed, 21 December 2005 17:35 |
| Eclipse User |
|
|
|
Originally posted by: caclark.cox.net
Daniel Serodio wrote:
> Cary wrote:
>
> <snip/>
>
>><rant>
>>
>>Well, after suffering through horribly slow save times, I did some
>>investigation.
>>
>>Seems they've replaced the .deployables with a <workspace
>>dir> \.metadata\.plugins\org.eclipse.wst.server.core\tmp1\webapps \ <web
>>app> directory. This is apparently where it's running from.
>>
>>What I don't understand is why. Certainly the plugin should be able to
>> get my project\WebContents directory and refer to it. Instead, it's
>>trying to "publish" to the directory under the workspace. Well, my
>>project has 16MB+ of jar files and 20MB+ of classes and other stuff. On
>>a nicely configured machine, it "only" takes 1min 45secs. Gee, hope you
>>don't need to make any small changes to your JSP's or, in my case, .lzx
>>files to fine tune anything. Or, if you do, hope you're not in any hurry.
>>
>>My question is why the server plugin can't take the Context attribute:
>>source="org.eclipse.jst.j2ee.server:Citizen Portal" and ask the
>>workspace where Citizen Portal resides on disk and run from there. It's
>>apparently asking it for the directory where the .metadata resides and
>>appending paths to it to come up with a location now.
>>
>>BTW, I went into my server definition, unfolded the Automatic Publishing
>>section on the Overview tab, and unchecked Override default settings
>>(which was set to 1 second!) and it quit eating up my machine in a
>>seamingly idle state.]
>
>
> Is this "Overview tab" you mention in 0.7.1 or RCx? I can't find it in
> RC4 or RC5.
It's in both. If you double click a server definition in the Servers
view, it's the first tab to show. The other tab is the Modules.
>
> Daniel Serodio
|
|
|
| Re: "Publishing to Tomcat" takes forever! [message #153259 is a reply to message #153144] |
Thu, 22 December 2005 02:17 |
Darryl Miles
Messages: 123
Registered: July 2009 |
Senior Member |
|
|
Cary Clark wrote:
> Well, I suppose that's one way to do it. But I'm of the opinion that
> WEB-INF\lib was meant for placing jars into, so I do it.
And Eclipse is happy with this method of working too.
But a significant number of people dont want to do that inside their
project, they want to manage their 3rd party JARs differently, because
the management of those 3rd party JARs across multiple projects, across
multiple versions of their products with multiple development teams is a
huge headache for them.
>> This keeps your project\ subtree nice and clean with just the minimal
>> set of things that actually make up the project within it.
>
> I don't understand this statement since the jar's in my WEB-INF/lib are
> part of what actually makes up my project.
Yes they make up your "deployable project". The .settings/ directory
makes up your project too, but it doesn't make up your "deployable project".
I could say there are many view points to what a project actually is, to
me its what I take care to backup.
>> It presents a huge problem to run TC directly out of
>> project\WebContent, some people use revision control systems and they
>> will be forever trying to manage the .cvsignore files.
>>
>
> So the drawback of running Tomcat directly from the workspace is that
> you could access .cvsignore files and other project artifacts from a
> development application server? What's the issue?
No the basic maintainance is the issue. For example say I had multiple
developers working on the same application which was under revision
control. Those developers ran TC directly in what is effectivly their
source tree (the place they checked out the application from revision
control).
It only takes one developer to accidentally commit a file they shouldn't
have to cause a headache for everybody else.
The runtime performance on my lowly Dual P3 550MHz 512Mb is good enough
to use with the current method and a 35Mb WAR web-app file set, so I am
much more interested in following up why your setup isn't performing the
same as mine than exchanging opinions as to why IYHO the current method
is shit (when this opinion seems to be based on a possibly unrelated
performance bottleneck that can be fixed).
Can we start over ? What spec is your computer ? How big is your
project (data size and file count) ? When you are experiencing 1m45s
slow down is your computer connected to the internet ? What type of
internet connection is it ? What version of Tomcat are you trying to
publish too ? Is it just saving JSP files that have this delay ? Does
the problem go away somewhat if you delete the Tomcat server instance
and start over ? What value did you set the Automatic Publish to when
it quit "eating up my machine" ? Do you have multiple source folders in
your project ?
> The question is, how the heck are
> we going to find out what the slowness is?
Please give everyone more helpful clues from your observations. I am
seeing an increase in the amount of time RC5 takes to publish but
nothing in the 1m45s realm, 20 seconds tops for projects that used to
take 8.
In RC5 I think how the API that exposes the resources that make up a
deployable project to the server tools was changed. The implementation
behind the members() function.
So the big questions is what critical factors make up your workspace ?
Maybe you have 10 source folders, 50 3rd party JARs and 12000 files in
your project running on a PDP11.
Darryl
|
|
| |
| Re: "Publishing to Tomcat" takes forever! [message #153906 is a reply to message #153259] |
Tue, 27 December 2005 15:37 |
| Eclipse User |
|
|
|
Originally posted by: caclark.etechsolutions.net
Darryl L. Miles said the following on 12/21/2005 8:17 PM:
> Cary Clark wrote:
>
>> Well, I suppose that's one way to do it. But I'm of the opinion that
>> WEB-INF\lib was meant for placing jars into, so I do it.
>
>
> And Eclipse is happy with this method of working too.
>
> But a significant number of people dont want to do that inside their
> project, they want to manage their 3rd party JARs differently, because
> the management of those 3rd party JARs across multiple projects, across
> multiple versions of their products with multiple development teams is a
> huge headache for them.
>
>
>>> This keeps your project\ subtree nice and clean with just the minimal
>>> set of things that actually make up the project within it.
>>
>>
>> I don't understand this statement since the jar's in my WEB-INF/lib
>> are part of what actually makes up my project.
>
>
> Yes they make up your "deployable project". The .settings/ directory
> makes up your project too, but it doesn't make up your "deployable
> project".
>
> I could say there are many view points to what a project actually is, to
> me its what I take care to backup.
>
>
>>> It presents a huge problem to run TC directly out of
>>> project\WebContent, some people use revision control systems and they
>>> will be forever trying to manage the .cvsignore files.
>>>
>>
>> So the drawback of running Tomcat directly from the workspace is that
>> you could access .cvsignore files and other project artifacts from a
>> development application server? What's the issue?
>
>
> No the basic maintainance is the issue. For example say I had multiple
> developers working on the same application which was under revision
> control. Those developers ran TC directly in what is effectivly their
> source tree (the place they checked out the application from revision
> control).
>
> It only takes one developer to accidentally commit a file they shouldn't
> have to cause a headache for everybody else.
Hmmm..isn't that what RCS's are for - to rollback a bad version or
delete a file that shouldn't have been placed under version control?
Also, how does this differ from running Tomcat from a directory where
all the source files are copied into from that very same source tree?
If a bad file update is pulled into the source tree and then published
to the directory underneath tmpX and run from there, how is that
different than running it directly from the WebContent directory? Isn't
the bad file/version going to appear in the directory under tmpX just
like it would in the WebContent?
I know we're belaboring this point, but I'm legitimately trying to see
how your use case is solved by copying files to another directory.
Maybe I'm dense, but I'm not seeing it yet.
On the point of 3rd party jar's: Those have to be copied from somewhere
into the tmpX directory don't they? If people aren't keeping them in
the WEB-INF/lib, where/how is WTP getting them and putting them? And
regardless of where it's getting them from, X number of jar's that total
Y bytes in size remains constant. Are people just manually placing this
in the common/lib folder and not copying them in? If so, how do they
deal with different projects that require different versions of jars?
>
>
> The runtime performance on my lowly Dual P3 550MHz 512Mb is good enough
> to use with the current method and a 35Mb WAR web-app file set, so I am
> much more interested in following up why your setup isn't performing the
> same as mine than exchanging opinions as to why IYHO the current method
> is shit (when this opinion seems to be based on a possibly unrelated
> performance bottleneck that can be fixed).
>
> Can we start over ?
While I believe this has been properly reported in Bugzilla #121603,
I'll add a few comments.
> What spec is your computer ?
2.0Ghz, 1.25G Ram, 35G+ Disk with 1G+ free. Disk is defragmented every
night with a scheduled Diskeeper run.
>How big is your
> project (data size and file count) ?
From the root of the project, there are 1,699 files in 273 folders
totalling 32,438,007 bytes.
>When you are experiencing 1m45s
> slow down is your computer connected to the internet ?
Yes, it's always connected
>What type of
> internet connection is it ?
Via a 100M LAN going out over multiple T3's
>What version of Tomcat are you trying to
> publish too ?
5.5.9
>Is it just saving JSP files that have this delay ?
No, any file that I save while Tomcat is running takes way too long.
>Does
> the problem go away somewhat if you delete the Tomcat server instance
> and start over ?
I whacked the Tomcat server def before moving to RC5 and then added my
project to it.
>What value did you set the Automatic Publish to when
> it quit "eating up my machine" ?
I set it to Use default publishing settings. They haven't been changed
from the defaults - they publish when the server starts, don't sync when
the server starts, and don't automatically publish to local or remote
servers.
>Do you have multiple source folders in
> your project ?
Only JavaSource and WebContent
>
>
>> The question is, how the heck are we going to find out what the
>> slowness is?
>
>
> Please give everyone more helpful clues from your observations. I am
> seeing an increase in the amount of time RC5 takes to publish but
> nothing in the 1m45s realm, 20 seconds tops for projects that used to
> take 8.
WTP 0.7.1 would save a text file very quickly. I mapped the Ctrl + W
key to publish the project, so I would do Ctrl + S, Ctrl + W. Total
time to save and publish was < 2 seconds.
>
>
> In RC5 I think how the API that exposes the resources that make up a
> deployable project to the server tools was changed. The implementation
> behind the members() function.
>
> So the big questions is what critical factors make up your workspace ?
> Maybe you have 10 source folders, 50 3rd party JARs and 12000 files in
> your project running on a PDP11.
No, the only reasonably high factor is the 62 jar's.
The fact that on the same machine running WTP 0.7.1 everything worked
very quickly should be a big clue that it's not an environmental factor.
>
>
> Darryl
Cary
|
|
|
| Re: "Publishing to Tomcat" takes forever! [message #153983 is a reply to message #153906] |
Wed, 28 December 2005 00:37 |
Darryl Miles
Messages: 123
Registered: July 2009 |
Senior Member |
|
|
Cary wrote:
>> It only takes one developer to accidentally commit a file they
>> shouldn't have to cause a headache for everybody else.
>
>
> Hmmm..isn't that what RCS's are for - to rollback a bad version or
> delete a file that shouldn't have been placed under version control?
Yes sure, we're not discussing what the features of an RCS are. So
someone now has to regularly maintain mistakes in RCS due to the way
your developers are working.
Most people would analyse that situation and come up with a solution
that changed the way of working the developers used to one which did not
leave them in the position to accidentally commit files that needed to
be rolled back. So we end up closer to the same place we're at now dont we?
> Also, how does this differ from running Tomcat from a directory where
> all the source files are copied into from that very same source tree? If
> a bad file update is pulled into the source tree and then published to
> the directory underneath tmpX and run from there, how is that different
> than running it directly from the WebContent directory? Isn't the bad
> file/version going to appear in the directory under tmpX just like it
> would in the WebContent?
Your scenario supposes the bad update occured, in my world its not a
normal occurance for this to happen. In my world if you mucked up your
source tree (in any way you can think of, bad update or a random mouse
clicking and dragging fit) it would only affect you, and not the other
developers in your team, as those changes are localized to your box
only. You mucked up your own source tree, so you get to fix it, this is
acceptable damage and happens with everyone from time to time, one
corrective action would be to compare with RCS again (which you cant do
if that had been spoilt). But if you muck up your RCS tree your whole
team suffers, this is not acceptable damage, this causes downtime for
all affected members and the cost of that time multiplies up.
> I know we're belaboring this point, but I'm legitimately trying to see
> how your use case is solved by copying files to another directory. Maybe
> I'm dense, but I'm not seeing it yet.
Lets suppose the current performance regression in the J2EE component
that is affecting the server tools is fixed (which is the root reason
this discussion got started). Lets suppose the performance level is now
the same or better than you are describing for 0.7.1.
Then there is really no undesirable performance impact for the delta
copy with the current method of working. This is where a complete copy
of the J2EE Deployable project view is performed when you first add the
project to the tomcat runtime instance. Then from that point onwards
only modifications (delta changes) are copied.
The deployable view of your project in its runnable state is what is
copied to another directory. Not your whole project (as seem from the
filesystem), this seems a completely natural way or working to me.
I usually build my project, export it to WAR then run the WAR on the
container. I don't normaly take my source tree to my container and
build it in place.
> On the point of 3rd party jar's: Those have to be copied from somewhere
> into the tmpX directory don't they? If people aren't keeping them in
> the WEB-INF/lib, where/how is WTP getting them and putting them? And
> regardless of where it's getting them from, X number of jar's that total
> Y bytes in size remains constant. Are people just manually placing this
> in the common/lib folder and not copying them in? If so, how do they
> deal with different projects that require different versions of jars?
Euh, I'm not sure I am following this one completely, but will try.
The tmpX directory copy is transparent and from a development point of
view its function should not concern the developer. The developer
simply configures his project up (build path, exported JARs, external
JARs, etc..) and you let WTP do its stuff and end up with a working
runtime environment which you can test your web-app within.
As said above, the copy of the JARs themselves is only done when you
first add a project and then only when you modify or add another (delta
updates) so the total size is of little overall performance impact.
Yes WEB-INF/lib is the recommended place to keep JARs relating to an
application. I don't understand where you got the notion I was
suggesting otherwise, if you did, sorry this was not intended.
Management of exactly which 3rd party JARs and their versions against a
specific version of your project it the problem I was highlighting.
I think this make the question "how do they deal with different projects
...." moot ? There are as many way of dealing with this problem as there
are developers in the world.
> While I believe this has been properly reported in Bugzilla #121603,
> I'll add a few comments.
This is true, I was only speculating on the cause when I wrote this
reply to you and was not aware of that bug report. The problem reminds
me of the same thing around 2 weeks after .deployable was removed (Bug
#116149) a few months ago, calling the members() function now seems to
incur a mandatory CPU bound processing delay (dependant upon the
complexity of your project, source folder, 3rd party JARs, dependant
projects, etc...) the point of my inqusition was to find out why your
setup jumped so much % while my small but moderatly complex projects did
not.
>> What spec is your computer ?
>
> 2.0Ghz, 1.25G Ram, 35G+ Disk with 1G+ free. Disk is defragmented every
> night with a scheduled Diskeeper run.
LOL, Its really 10 years old performance diagnosis to suggest disk
fragmentation will play part in any performance problem on a modern OS.
Providing you've upped your eclipse JVM working memory with -Xms/-Xmx
with that level of ram and such a small project, fragmentation certainly
isn't something I'd be looking towards.
I think the following in my Unix eclipse configuration does the trick
with -Xms/-Xmx should work on windows too:
# cat /opt/eclipse/eclipse.ini
-vmargs
-Xms256m
-Xmx1024m
>> How big is your project (data size and file count) ?
>
> From the root of the project, there are 1,699 files in 273 folders
> totalling 32,438,007 bytes.
Useful scalebility info for someone, whats that around 19 Kb/file and a
6:1 file:dir ratio. Seems average in my experience and good to confirm.
>> When you are experiencing 1m45s slow down is your computer connected
>> to the internet ?
>
> Yes, it's always connected
>
>> What type of internet connection is it ?
>
> Via a 100M LAN going out over multiple T3's
Ok this rules out things like the builder/validator trying to load
online XML schemas blocking a publish operation (making it seem slower).
>> What version of Tomcat are you trying to publish too ?
>
> 5.5.9
>
>> Is it just saving JSP files that have this delay ?
>
> No, any file that I save while Tomcat is running takes way too long.
Okay this can be explained by the 1 second default automatic publish
picking up resource change events every second and if the members()
function has a ~10 second delay (I'm guessing from your project size and
hardware) then this does interrupt saving a file.
I have filed Bug #121699 (currently open) in relation to an obvious case
where this delay is undesirable even when the outcome of the members()
regression is fixed in Bug #121603.
I had also filed Bug #116149 (now closed the first time members() was a
performance bottleneck for publishing, a few wks after .deployables was
removed a few months ago).
>> Does the problem go away somewhat if you delete the Tomcat server
>> instance and start over ?
>
> I whacked the Tomcat server def before moving to RC5 and then added my
> project to it.
>
>> What value did you set the Automatic Publish to when it quit "eating
>> up my machine" ?
>
> I set it to Use default publishing settings. They haven't been changed
> from the defaults - they publish when the server starts, don't sync when
> the server starts, and don't automatically publish to local or remote
> servers.
>
>> Do you have multiple source folders in your project ?
>
> Only JavaSource and WebContent
This one supprises me for your 1m45s timing. I was speculating this
might be a contributing factor, it seems not.
> WTP 0.7.1 would save a text file very quickly. I mapped the Ctrl + W
> key to publish the project, so I would do Ctrl + S, Ctrl + W. Total
> time to save and publish was < 2 seconds.
I'm sure WTP will get back to this performance level when the J2EE
regression is addressed.
>> In RC5 I think how the API that exposes the resources that make up a
>> deployable project to the server tools was changed. The
>> implementation behind the members() function.
>>
>> So the big questions is what critical factors make up your workspace ?
>> Maybe you have 10 source folders, 50 3rd party JARs and 12000 files in
>> your project running on a PDP11.
>
> No, the only reasonably high factor is the 62 jar's.
>
> The fact that on the same machine running WTP 0.7.1 everything worked
> very quickly should be a big clue that it's not an environmental factor.
Agreed. All of the bottlenecks here are in the members() regression and
the bug you cited should clearup most/all of your peaves.
What I've been particular interested from you is isolating which
critical factor has caused your 2 seconds to jump to 1m45s with the same
h/w when I've a project around 75% the number of files, but larger total
filesize 48Mb and the performance change is only 4:1 slower, not 50:1
slow that you are seeing. I only have 1/3 the number of 3rd party JARs
as you.
So if 3rd party JARs are the factor then someone will want to know that
and investigate this particular bottleneck to improve things. 62 JARs
while high doesn't feel too extreme to me if I can easily knock up a
simple web-app and need 15 to get started.
Thanks for your response.
Darryl
|
|
|
Goto Forum:
Current Time: Fri Apr 26 00:28:03 GMT 2024
Powered by FUDForum. Page generated in 0.05445 seconds |
] 
Search
Help
Register
Login
Home
