Re: Socket Create not supported
Hello Jeanfrancois Arcand, No. I didn't know if by default installation of J2sdk1.4.x enable Security Manager. Currently I didn't have laptop. But I will send you error log as soon as possible. Thanks for your mail. ./Nikhil Jeanfrancois Arcand wrote: Nikhil Sidhaye wrote: Hello Friends, Recently I got strange error on tomcat startup. I tried tomcat 4.0 as well as tomcat 5.0. But it shut down by giving strange error. Socket "create" is not supported. while in tomcat 5.0 it gives the same error indicating port no 8005 which is for tomcat shutdown port. I change ports but in vain. Machine Configuration : Old Laptop having win98 with 32MB RAM. Java 1.4.1 is installed. Same tomcat runs well on everywhere. What may be the problem? Are you running with the SecurityManager enabled? What is the exception? -- Jeanfrancois ./Nikhil - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: registering Tomcat as service
Well, you can modify the service.bat or follow the instructions on the page I mentioned previously to change paramters from the command line. And, yes, I think this stuff is probably stored in the registry, although I haven't looked at the entries (haven't needed to). Some of the parameters documented for procrun aren't valid anymore with changes since that page was published which is why I recommended the GUI. Look in service.bat to see use of the latest parameters. Jake At 06:21 PM 5/28/2004 +0200, you wrote: Hi there. The GUI is not always going to be good for me as I need to make the change command line settings via my own web based server management interface. I assume that the app changes registry enties? Is there documentation on the registry entries? I could then make changes directly in the registry Carl -Original Message- From: Jacob Kjome [mailto:[EMAIL PROTECTED] Sent: 28 May 2004 04:53 PM To: Tomcat Users List Subject: RE: registering Tomcat as service You can modify the service parameters via the GUI. See... http://jakarta.apache.org/commons/daemon/procrun.html Even though most of the instructions on that page are outdated, the information near the bottom of the page is still useful. In particular... "Changing the Service Parameters from the GUI" tomcat5w //ES//Tomcat5 That pops up a GUI where you can see all the parameters that are currently added to the service. Add/Remove as needed. Jake Quoting Carl Olivier <[EMAIL PROTECTED]>: > Hi. > > On this subject - in the older Tomcat service executable (specifically > jk_nt_service.exe for TC 3) the executable was pointed at a > wrapper.properties file. > > This wrapper.properties provided the means to add new -X and -D > properties to the executable without having to re-install the service > as it was read in at start time. > > Is there any plan/chance that this could also be possible for the new > tomcat5.exe? > > The main reason is if you wanted to change the -Xmx setting (as a good > example) through code - it is a lot simpler to do this in a > wrapper.properties and then simply restart the service - as opposed to > removing the service and then re-installing it. > > Thanks in advance. > > Carl > > -Original Message- > From: None None [mailto:[EMAIL PROTECTED] > Sent: 28 May 2004 03:17 PM > To: [EMAIL PROTECTED] > Subject: RE: registering Tomcat as service > > > Take a look in tomcat/bin. There is a service.bat file that can > install and > > uninstall the service. Should do the trick for you. > > >From: "Paul Wallace" <[EMAIL PROTECTED]> > >Reply-To: "Tomcat Users List" <[EMAIL PROTECTED]> > >To: <[EMAIL PROTECTED]> > >Subject: registering Tomcat as service > >Date: Fri, 28 May 2004 16:31:57 +1000 > > > >Hello, > > I installed Tomcat, formally run from the console. I am now > >trying to get it to run as a service. I have in the registry: > > > >HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tomcat\Parameter > >s: > > > >JVM Option Count REG_DWORD0X0004 (4) > > > >JVM Option Number 0 REG_SZ-Xms256m > >JVM Option Number 1 REG_SZ-Xmx512m > >JVM Option Number 2 REG_SZ > >-Djava.class.path=C:\eCommerce\Tomcat-4.1.30\bin\bootstrap.jar;C:\eCo > >mm > >e > >rce\Tomcat-4.1.30\common\lib\servlet.jar;C:\j2sdk1.4.2_04\lib\tools.jar > >JVM Option Number 3 REG_SZ > >-Dcatalina.home=C:\eCommerce\Tomcat-4.1.30 > > > >the paths are correct (JDK/Tomcat) but when I try to start Tomcat > >from the service window, I get a popup: > > > >"The Tomcat Service on a Local Computer started and then stopped. > >Some services stop automatically if they have no work to do, for > >example, the Performance Logs and Alerts service" > > > >The service does not subsequently run. Now my service may not have > >any work to do, but I most certainly do. > > > >Any info is much appreciated. > > > >Paul. > > > > > > _ > FREE pop-up blocking with the new MSN Toolbar - get it now! > http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Managing Session Objects - Preventing a Degredation in Performance
I asked these question in the Struts list and only received a minimal response: Does anyone have any good ideas on managing session objects? In a complex application how do you insure that the session does not become over burdened with unnecessary objects, thus degrading system performance? You could try to map every process exit and remove unneeded objects at then end of a process; however, implementing this might be burdensome in a complex application. You could call a session cleanup method at the beginning of every new process and remove all the unnecessary objects at that point. Any other ideas? Thx. Mike __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Managing Session Objects - Preventing a Degredation in Performance
On Sat, May 29, 2004 at 11:31:26AM -0700, Mike Duffy wrote:
: I asked these question in the Struts list and only received a minimal response:
Does anyone have
: any good ideas on managing session objects? In a complex application how do you
insure that the
: session does not become over burdened with unnecessary objects, thus degrading
system performance?
In no particular order:
1/ Use the Request object when you can; use the Session when you must.
(Paraphrasing a line I hear a lot in the C++ world...)
If you don't put something in the session, it certainly can't
stick around and take up space.
2/ Make sure each process that puts an object in the session is
designed to remove it. Obviously a "process" in this case may
span several requests; so, like good code, you'll have to
account for removing the object even in the event the process
short-circuits (e.g. when the user hits an error page instead
of reaching the proper ending). Unlike good code, you don't
have a handy "finally{}" clause... =)
3/ Load-test your app and size memory accordingly. Even with the
best-laid cleanup plans, people will close browsers without
formally logging out, etc. You simply have to deal with this
and make sure your app has enough heap space to handle the number
of concurrent users. Size per your worst-case scenario.
1 and 2 are coding practices, and must be enforced by the architect (by
explaining to the developers). This takes place before and during
development.
3 is an architectural issue, addressed during development and after a
good portion of the app has come to life.
ps - please create a new message when mailing the list. Responding to
an old (unrelated) message plays hell with thread-aware mailers, even if
you change the subject. Thank you.
-QM
--
software -- http://www.brandxdev.net
tech news -- http://www.RoarNetworX.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: creating web applications
On Sat, May 29, 2004 at 06:15:07AM +, swapna gupta wrote: : THANKS for directing me to the link. But my problem doesnt get solved by : the solution provided, i.e. : [snip] : :invoker :/servlet/* : You're missing something, aka the "" tag. Without that, "" tags aren't so useful. ;) -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: ajp13 protocol specifications
http://jakarta.apache.org/tomcat/tomcat-4.1-doc/jk2/common/AJPv13.html "Nitin Verma" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Where will I get ajp13 protocol specifications? I need to make my own mod_jk2's java variant. > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Managing Session Objects - Preventing a Degredation in Performance
One more option, if you absolutely cannot control the lifetimes of the session objects because the user at the browser is in control and may or may not need the object for some time to come, create a caching system by writing the oldest, largest or least used objects to a database in such a way they can be recovered if needed. -- Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
XP tomcat service account access rights
So I set up a limited user account to run my Tomcat service on XP Pro. My question is, what specific rights are need for which folders under CATALINA_HOME? It seems to run ok with "read & execute", "list directory", and "read" for the whole branch with "write" specifically for the logs directory. I'm not clear on what else might be needed. 'Temp' for instance looks suspiciously write-needy. And I seee log messages about trying to rename /conf/tomcat-user.xml.old (which doesn't exist anyway but presumably would need write access for if it did). I haven't come across this info anywhere yet. The place I would like to have found it is on the page: http://jakarta.apache.org/tomcat/tomcat-5.0-doc/setup.html in that first paragraph under 'Installation as a service'. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XP tomcat service account access rights
On Sat, May 29, 2004 at 05:28:44PM -0400, Stuart Mackey wrote:
: So I set up a limited user account to run my Tomcat service on XP Pro. My
: question is, what specific rights are need for which folders under
: CATALINA_HOME? It seems to run ok with "read & execute", "list directory",
: and "read" for the whole branch with "write" specifically for the logs
: directory.
Maybe I can help: I separate the webapp (CATALINA_BASE) from the Tomcat
files (CATALINA_HOME). That means nothing in the Tomcat install dir need
be writable to the webapp owner.
Additionally, within CATALINA_BASE, I have a dir structure similar to the
following:
{CATALINA_BASE}
|
+- bin/ (Tomcat start scripts, etc)
|
+- conf/ (global web.xml, server.xml)
| |
| +-Standalone (where Tomcat writes context.xml data, etc)
|
+- logs/ (catalina.out, Tomcat logs, etc)
|
+- webapps/ (web apps, either WAR files or exploded dirs)
|
+- work/ (Tomcat temp files, e.g. compiled JSPs)
For my setup, this is all writable to the Tomcat user; but that could be
limited to:
conf/Standalone/
logs/
work/
(If another user is responsible for installing the WAR file and global
configs, then bin/, conf/, and webapps/ needn't be writable.)
This is all off the top of my head so I may be missing something... but
it's a start.
I've had to do similar work several times in the past; it requires a lot of
patience and some knowledge of what the app/user must do at a given time.
If NT/XP has decent trace tools (Solaris truss, Linux strace, etc), you can
see what files the app tries to open and base your decisions on that.
That's helped me a *lot*.
Good luck!
-QM
--
software -- http://www.brandxdev.net
tech news -- http://www.RoarNetworX.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Managing Session Objects - Preventing a Degredation in Performance
As I said in my original email: You could try to map every process exit and remove
unneeded
objects at then end of a process; however, implementing this might be burdensome in a
complex
application.
Suggestion #2 fro QM makes this point and adds clarification: "Obviously a "process"
in this case
may span several requests; so, like good code, you'll have to account for removing the
object even
in the event the process short-circuits (e.g. when the user hits an error page instead
of reaching
the proper ending). Unlike good code, you don't have a handy "finally{}" clause... =)"
The tricky part is, cleaning up after a multi-request process terminates because the
process could
terminate in unexpected ways (someone simply abandons the process by clicking another
link, etc.).
Here is what I think might be a pragmatic solution within a Struts framework:
Assume we are building a CRM application and we are creating the process that enters
customer
contacts. The first page of the process is contactEntryOne.jsp. The page is
displayed by
clicking a link that is mapped to DisplayContactEntryAction.java (an action class that
simply
forwards to contactEntryOne.jsp).
A submit button on contactEntryOne.jsp is mapped to ProcessContactEntryOne.java, an
action class
that does some processing, stores some objects in the session and then sends the user
to another
JSP which has another submit button mapped to ProcessContactEntryTwo.java, and so on.
The process
ends with a call to DisplayContactEnteredAction.java (which may simply forward to a
success page).
By convention, we could agree that all processes begin and end with a call to an
action class that
begins with "Display...": DisplayContactEntryAction.java , and
DisplayContactEnteredAction.java.
We could also agree that all intermediate processes are done by a call to an action
class that
begins with "Process..."
If we assume that once a process ends or a new process begins, all the session objects
for the old
process are invalid, life becomes simple :). In every "Display..." action class
(which may begin
or end a process or just display a single page) we can make a call to a utility method
that clears
the session of all objects except a predetermined set.
The overhead of making a call to a session cleanup utility method would be marginal
compared to
the increase in system efficiency.
Please note, the degradation in performance due to session objects is not just a
matter of system
speed and memory. You reach a point in a complex system where the number of objects
chokes the
JVM's garbage collector. Buying a faster system with more memory will help, but
writing good code
might be a better solution
What are your thoughts on the merits of this solution?
Mike
--- QM <[EMAIL PROTECTED]> wrote:
> On Sat, May 29, 2004 at 11:31:26AM -0700, Mike Duffy wrote:
> : I asked these question in the Struts list and only received a minimal response:
> Does anyone
> have
> : any good ideas on managing session objects? In a complex application how do you
> insure that
> the
> : session does not become over burdened with unnecessary objects, thus degrading
> system
> performance?
>
> In no particular order:
>
> 1/ Use the Request object when you can; use the Session when you must.
> (Paraphrasing a line I hear a lot in the C++ world...)
> If you don't put something in the session, it certainly can't
> stick around and take up space.
>
> 2/ Make sure each process that puts an object in the session is
> designed to remove it. Obviously a "process" in this case may
> span several requests; so, like good code, you'll have to
> account for removing the object even in the event the process
> short-circuits (e.g. when the user hits an error page instead
> of reaching the proper ending). Unlike good code, you don't
> have a handy "finally{}" clause... =)
>
> 3/ Load-test your app and size memory accordingly. Even with the
> best-laid cleanup plans, people will close browsers without
> formally logging out, etc. You simply have to deal with this
> and make sure your app has enough heap space to handle the number
> of concurrent users. Size per your worst-case scenario.
>
> 1 and 2 are coding practices, and must be enforced by the architect (by
> explaining to the developers). This takes place before and during
> development.
>
> 3 is an architectural issue, addressed during development and after a
> good portion of the app has come to life.
>
>
> ps - please create a new message when mailing the list. Responding to
> an old (unrelated) message plays hell with thread-aware mailers, even if
> you change the subject. Thank you.
>
> -QM
>
> --
>
> software -- http://www.brandxdev.net
> tech news -- http://www.RoarNetworX.com
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-ma
Re: Managing Session Objects - Preventing a Degredation in Performance
On Sat, May 29, 2004 at 07:18:27PM -0700, Mike Duffy wrote: : As I said in my original email: You could try to map every process exit : and remove unneeded objects at then end of a process; however, : implementing this might be burdensome in a complex application. -which is why I tend to push for Suggestion #3: Load Test and Size Accordingly. =) You even have your choice of GC algos with JDK 1.4+, so the garbage collection shouldn't be too much of a concern. Otherwise: - Each Action keeps a list of keys, for objects it stores in the session. This list would be the same for every Action in the same process. Store said list in the Request object under a known key, each time the Action is called. (Same key, app-wide.) - Create a custom tag that looks for said key, and deletes every session object named there. Call this tag, "" - Place "" at the end of every error page and "end of process" page. That's effectively your "finally" clause right there. YMMV, but if you use Struts declarative exception handling (i.e. you have just a handful of error pages) then this wouldn't be a lot of work to implement, nor to maintain. -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Managing Session Objects - Preventing a Degredation in Performance
H It doesn't seem like the tag concept would work if a user just clicked out of a process. Also, I do not like the idea of putting this type of cleanup in a custom tag (View tier). I'd like to keep the functionality of the MVC tiers as clean as possible. BTW: What is "YMMV"? Thx. Mike --- QM <[EMAIL PROTECTED]> wrote: > On Sat, May 29, 2004 at 07:18:27PM -0700, Mike Duffy wrote: > : As I said in my original email: You could try to map every process exit > : and remove unneeded objects at then end of a process; however, > : implementing this might be burdensome in a complex application. > > -which is why I tend to push for Suggestion #3: Load Test and Size > Accordingly. =) You even have your choice of GC algos with JDK 1.4+, so > the garbage collection shouldn't be too much of a concern. > > > Otherwise: > > - Each Action keeps a list of keys, for objects it stores in > the session. This list would be the same for every Action > in the same process. > > Store said list in the Request object under a known key, > each time the Action is called. (Same key, app-wide.) > > - Create a custom tag that looks for said key, and deletes every > session object named there. Call this tag, "" > > - Place "" at the end of every error page and > "end of process" page. > > That's effectively your "finally" clause right there. > > YMMV, but if you use Struts declarative exception handling (i.e. you have > just a handful of error pages) then this wouldn't be a lot of work to > implement, nor to maintain. > > -QM > > -- > > software -- http://www.brandxdev.net > tech news -- http://www.RoarNetworX.com > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > __ Do you Yahoo!? Friends. Fun. Try the all-new Yahoo! Messenger. http://messenger.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
