RE: ActionServlet Action caching problem

2003-03-11 Thread Whitmire, Jeffrey
Found it.  Turns out it wasn't a caching problem at all.  I have a threaded
job manager that was being used by this action class.  There was a weird
exception being thrown that wasn't getting caught which was locking the
thread.  This action was getting reused by Struts, but never did anything
because it was still blocking on the locked thread.

I've fixed it and learned much, but is there any way to get more control
over the caching?  Do you have to subclass ActionServlet or the
RequestProcessor to do that?  I would think there would be instances where
you would want a pool of actions instead of only one instance of each.  Once
this release gets out I'm going to look at it more, but I was just curious
about whether anybody has looked into this.

Jeff.

-Original Message-
From: Whitmire, Jeffrey [mailto:[EMAIL PROTECTED]
Sent: Monday, March 10, 2003 4:07 PM
To: '[EMAIL PROTECTED]'
Subject: ActionServlet Action caching problem


I've got a weird one.  I'm hoping that somebody else has encountered this
before and can help.  We are in the midst of load testing our app before
rolling it out to production.  I have one action class (only one) that
starts failing well over an hour into the test.

It appears that the instance of that action class cached by the
ActionServlet becomes invalid.  I can see no reason why the change in
behaviour, but at some point the RequestProcessor gets an instance to the
Action that is no longer valid.  It is not null, but it never executes it.
The rest of the app works perfectly, but that button (tied to that specific
Action) never works again until the tomcat instance is restarted.  It just
hangs, and the last indication in the log is the RequestProcessor finding
and returning an instance of that action class.

Has anyone ever had problems with Action instances going stale?  or some
other config problem that could cause this?

Thanks, I'm a bit desparate,
Jeff.

-
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: ActionServlet Action caching problem

2003-03-11 Thread David Graham
RequestProcessor.processActionCreate() is probably where you could customize 
how many Action instances to create.  I'm not sure why you would need 
multiple instances but the customization is available.

David



From: Whitmire, Jeffrey [EMAIL PROTECTED]
Reply-To: Struts Users Mailing List [EMAIL PROTECTED]
To: 'Struts Users Mailing List' [EMAIL PROTECTED]
Subject: RE: ActionServlet Action caching problem
Date: Tue, 11 Mar 2003 12:16:33 -0500
Found it.  Turns out it wasn't a caching problem at all.  I have a threaded
job manager that was being used by this action class.  There was a weird
exception being thrown that wasn't getting caught which was locking the
thread.  This action was getting reused by Struts, but never did anything
because it was still blocking on the locked thread.
I've fixed it and learned much, but is there any way to get more control
over the caching?  Do you have to subclass ActionServlet or the
RequestProcessor to do that?  I would think there would be instances where
you would want a pool of actions instead of only one instance of each.  
Once
this release gets out I'm going to look at it more, but I was just curious
about whether anybody has looked into this.

Jeff.

-Original Message-
From: Whitmire, Jeffrey [mailto:[EMAIL PROTECTED]
Sent: Monday, March 10, 2003 4:07 PM
To: '[EMAIL PROTECTED]'
Subject: ActionServlet Action caching problem
I've got a weird one.  I'm hoping that somebody else has encountered this
before and can help.  We are in the midst of load testing our app before
rolling it out to production.  I have one action class (only one) that
starts failing well over an hour into the test.
It appears that the instance of that action class cached by the
ActionServlet becomes invalid.  I can see no reason why the change in
behaviour, but at some point the RequestProcessor gets an instance to the
Action that is no longer valid.  It is not null, but it never executes it.
The rest of the app works perfectly, but that button (tied to that specific
Action) never works again until the tomcat instance is restarted.  It just
hangs, and the last indication in the log is the RequestProcessor finding
and returning an instance of that action class.
Has anyone ever had problems with Action instances going stale?  or some
other config problem that could cause this?
Thanks, I'm a bit desparate,
Jeff.
-
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]


_
Add photos to your messages with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: ActionServlet Action caching problem

2003-03-11 Thread Whitmire, Jeffrey
I'll have to look into it, but it seems to me that if the action is doing a
non-trivial amount of work (which mine is), then if there are multiple
requests, they will get serialized through the single instance of the
action.  It may be that I need to redesign how my action works, but
currently it will submit a job and block until it completes.  If there were
a pool of actions instead of a single one it seems like it would be more
efficient.

Jeff.

-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 11, 2003 12:40 PM
To: [EMAIL PROTECTED]
Subject: RE: ActionServlet Action caching problem


RequestProcessor.processActionCreate() is probably where you could customize

how many Action instances to create.  I'm not sure why you would need 
multiple instances but the customization is available.

David



From: Whitmire, Jeffrey [EMAIL PROTECTED]
Reply-To: Struts Users Mailing List [EMAIL PROTECTED]
To: 'Struts Users Mailing List' [EMAIL PROTECTED]
Subject: RE: ActionServlet Action caching problem
Date: Tue, 11 Mar 2003 12:16:33 -0500

Found it.  Turns out it wasn't a caching problem at all.  I have a threaded
job manager that was being used by this action class.  There was a weird
exception being thrown that wasn't getting caught which was locking the
thread.  This action was getting reused by Struts, but never did anything
because it was still blocking on the locked thread.

I've fixed it and learned much, but is there any way to get more control
over the caching?  Do you have to subclass ActionServlet or the
RequestProcessor to do that?  I would think there would be instances where
you would want a pool of actions instead of only one instance of each.  
Once
this release gets out I'm going to look at it more, but I was just curious
about whether anybody has looked into this.

Jeff.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: ActionServlet Action caching problem

2003-03-11 Thread nash e. foster
My execute/perform methods aren't normally synchronized. The javadocs 
don't indicate they expect it to be, so, calls to that methods 
shouldn't get blocked. However, you could have concurrency problems 
if you're using static, class, or instance variables. The 
execute/perform method should limit itself to using local variables or 
data passed by reference and you won't have this problem. Unless you 
explicitly declare some class methods synchronized, in which case 
you're exactly right. If you do that, however, you ought to mean to 
produce that effect and limit your critical section to a small block of 
code-- ideally one that doesn't block on anything. ;-)

Maybe I'm out to lunch, though. Its been a while since I've coded java 
threads.

-nash

On Tuesday, March 11, 2003, at 12:52  PM, Whitmire, Jeffrey wrote:

I'll have to look into it, but it seems to me that if the action is 
doing a
non-trivial amount of work (which mine is), then if there are multiple
requests, they will get serialized through the single instance of the
action.  It may be that I need to redesign how my action works, but
currently it will submit a job and block until it completes.  If there 
were
a pool of actions instead of a single one it seems like it would be 
more
efficient.

Jeff.


***
This message is intended only for the use of the intended recipient and
may contain information that is PRIVILEGED and/or CONFIDENTIAL.  If you
are not the intended recipient, you are hereby notified that any use,
dissemination, disclosure or copying of this communication is strictly
prohibited.  If you have received this communication in error, please
destroy all copies of this message and its attachments and notify us
immediately.
***
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: ActionServlet Action caching problem

2003-03-11 Thread David Graham
The servlet container is multi-threaded with many threads calling the 1 
action's execute method.  So, you don't have to worry about pooling actions. 
 If your execute method doesn't use instance variables, then it doesn't 
need to be synchronized.

Even though there's only 1 instance of each Action, it can be executed 
simultaneously by many threads.

David



From: Whitmire, Jeffrey [EMAIL PROTECTED]
Reply-To: Struts Users Mailing List [EMAIL PROTECTED]
To: 'Struts Users Mailing List' [EMAIL PROTECTED]
Subject: RE: ActionServlet Action caching problem
Date: Tue, 11 Mar 2003 12:52:45 -0500
I'll have to look into it, but it seems to me that if the action is doing a
non-trivial amount of work (which mine is), then if there are multiple
requests, they will get serialized through the single instance of the
action.  It may be that I need to redesign how my action works, but
currently it will submit a job and block until it completes.  If there were
a pool of actions instead of a single one it seems like it would be more
efficient.
Jeff.

-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 11, 2003 12:40 PM
To: [EMAIL PROTECTED]
Subject: RE: ActionServlet Action caching problem
RequestProcessor.processActionCreate() is probably where you could 
customize

how many Action instances to create.  I'm not sure why you would need
multiple instances but the customization is available.
David



From: Whitmire, Jeffrey [EMAIL PROTECTED]
Reply-To: Struts Users Mailing List [EMAIL PROTECTED]
To: 'Struts Users Mailing List' [EMAIL PROTECTED]
Subject: RE: ActionServlet Action caching problem
Date: Tue, 11 Mar 2003 12:16:33 -0500

Found it.  Turns out it wasn't a caching problem at all.  I have a 
threaded
job manager that was being used by this action class.  There was a weird
exception being thrown that wasn't getting caught which was locking the
thread.  This action was getting reused by Struts, but never did anything
because it was still blocking on the locked thread.

I've fixed it and learned much, but is there any way to get more control
over the caching?  Do you have to subclass ActionServlet or the
RequestProcessor to do that?  I would think there would be instances 
where
you would want a pool of actions instead of only one instance of each.
Once
this release gets out I'm going to look at it more, but I was just 
curious
about whether anybody has looked into this.

Jeff.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


_
Add photos to your e-mail with MSN 8. Get 2 months FREE*.  
http://join.msn.com/?page=features/featuredemail

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: ActionServlet Action caching problem

2003-03-11 Thread Whitmire, Jeffrey
Thanks guys, you are right (of course).  I was so focused on the fact that
only one instance is created, I was losing site of the forest for the trees.
As long as there are no instance variables (which there are not) then
everything should work as planned and only one instance is all you ever
need.

I'm still curious though.  When I was having the problem, it was because an
uncaught exception was skipping the call to notifyAll to wake up the action
which was blocked until job completion.  This seemed to hose the instance of
the action such that no future requests for that action responded.  The rest
of the app worked perfectly fine, but that action never responded until the
app was restarted.  Unless I'm totally off my rocker (more likely than not),
other threads calling that action should still have worked.

Sometimes threading can really make your brain go fuzzy.

Jeff.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



RE: ActionServlet Action caching problem

2003-03-11 Thread Moore, Jason
If notifyAll() was never called, then the object that held the lock on the
Action class never released it, so all future calls to the execute method on
your action would block waiting for the lock to be released. The action
wasn't hosed in any way. The problem was the object that never released the
lock.

-Original Message-
From: Whitmire, Jeffrey [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 11, 2003 2:00 PM
To: 'Struts Users Mailing List'
Subject: RE: ActionServlet Action caching problem


Thanks guys, you are right (of course).  I was so focused on the fact that
only one instance is created, I was losing site of the forest for the trees.
As long as there are no instance variables (which there are not) then
everything should work as planned and only one instance is all you ever
need.

I'm still curious though.  When I was having the problem, it was because an
uncaught exception was skipping the call to notifyAll to wake up the action
which was blocked until job completion.  This seemed to hose the instance of
the action such that no future requests for that action responded.  The rest
of the app worked perfectly fine, but that action never responded until the
app was restarted.  Unless I'm totally off my rocker (more likely than not),
other threads calling that action should still have worked.

Sometimes threading can really make your brain go fuzzy.

Jeff.

-
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]



ActionServlet Action caching problem

2003-03-10 Thread Whitmire, Jeffrey
I've got a weird one.  I'm hoping that somebody else has encountered this
before and can help.  We are in the midst of load testing our app before
rolling it out to production.  I have one action class (only one) that
starts failing well over an hour into the test.

It appears that the instance of that action class cached by the
ActionServlet becomes invalid.  I can see no reason why the change in
behaviour, but at some point the RequestProcessor gets an instance to the
Action that is no longer valid.  It is not null, but it never executes it.
The rest of the app works perfectly, but that button (tied to that specific
Action) never works again until the tomcat instance is restarted.  It just
hangs, and the last indication in the log is the RequestProcessor finding
and returning an instance of that action class.

Has anyone ever had problems with Action instances going stale?  or some
other config problem that could cause this?

Thanks, I'm a bit desparate,
Jeff.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: ActionServlet Action caching problem

2003-03-10 Thread David Graham
Does that Action contain member variables?  Maybe 2 threads are overwritting 
member data and causing the Action to fail.

David



From: Whitmire, Jeffrey [EMAIL PROTECTED]
Reply-To: Struts Users Mailing List [EMAIL PROTECTED]
To: '[EMAIL PROTECTED]' [EMAIL PROTECTED]
Subject: ActionServlet Action caching problem
Date: Mon, 10 Mar 2003 16:07:29 -0500
I've got a weird one.  I'm hoping that somebody else has encountered this
before and can help.  We are in the midst of load testing our app before
rolling it out to production.  I have one action class (only one) that
starts failing well over an hour into the test.
It appears that the instance of that action class cached by the
ActionServlet becomes invalid.  I can see no reason why the change in
behaviour, but at some point the RequestProcessor gets an instance to the
Action that is no longer valid.  It is not null, but it never executes it.
The rest of the app works perfectly, but that button (tied to that specific
Action) never works again until the tomcat instance is restarted.  It just
hangs, and the last indication in the log is the RequestProcessor finding
and returning an instance of that action class.
Has anyone ever had problems with Action instances going stale?  or some
other config problem that could cause this?
Thanks, I'm a bit desparate,
Jeff.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


_
The new MSN 8: advanced junk mail protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: ActionServlet Action caching problem

2003-03-10 Thread nash e. foster
I've had problems with references to beans on instance variables in an 
Action object getting stale. I'm on Jboss and in my experience the 
stale references hork a nice fat RMI exception. Can you turn debug 
logging on in your execute / perform method and see if that's ever 
getting called? In my case, it always was. My  issue relates to Action 
objects hanging around after a session bean has been removed or 
passivated by the EJB container. It would be really nice if someone 
decided to implement a timeout on the Action objects so that if they 
were older than a certain age, they wouldn't be used.

Don't know if we're seeing the same behavior from different angles or 
not.

ciao,

	-nash

On Monday, March 10, 2003, at 04:07  PM, Whitmire, Jeffrey wrote:

I've got a weird one.  I'm hoping that somebody else has encountered 
this
before and can help.  We are in the midst of load testing our app 
before
rolling it out to production.  I have one action class (only one) that
starts failing well over an hour into the test.

It appears that the instance of that action class cached by the
ActionServlet becomes invalid.  I can see no reason why the change in
behaviour, but at some point the RequestProcessor gets an instance to 
the
Action that is no longer valid.  It is not null, but it never executes 
it.
The rest of the app works perfectly, but that button (tied to that 
specific
Action) never works again until the tomcat instance is restarted.  It 
just
hangs, and the last indication in the log is the RequestProcessor 
finding
and returning an instance of that action class.

Has anyone ever had problems with Action instances going stale?  or 
some
other config problem that could cause this?

Thanks, I'm a bit desparate,
Jeff.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


***
This message is intended only for the use of the intended recipient and
may contain information that is PRIVILEGED and/or CONFIDENTIAL.  If you
are not the intended recipient, you are hereby notified that any use,
dissemination, disclosure or copying of this communication is strictly
prohibited.  If you have received this communication in error, please
destroy all copies of this message and its attachments and notify us
immediately.
***
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


RE: ActionServlet Action caching problem

2003-03-10 Thread Mohan Radhakrishnan
Hi,
   Ours is not exactly the same problem because it is  diagnosed as a cache
problem. Sometimes when the session times out and a particular action URL 

  menu.addMenuItem(Menu,location='test.action');

  was the last one to be executed and we log out and log in, this URL
somehow gets stuck in the browser cache. Other similar URL's work properly.

  So eventhough we use

init-param
  param-namenocache/param-name
  param-valuetrue/param-value
/init-param

 still the browser cache has to be cleared. We haven't checked the logs
properly but this particular action never prints anything to the console.

Mohan

-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 11, 2003 3:00 AM
To: [EMAIL PROTECTED]
Subject: Re: ActionServlet Action caching problem


Does that Action contain member variables?  Maybe 2 threads are overwritting

member data and causing the Action to fail.

David



From: Whitmire, Jeffrey [EMAIL PROTECTED]
Reply-To: Struts Users Mailing List [EMAIL PROTECTED]
To: '[EMAIL PROTECTED]' [EMAIL PROTECTED]
Subject: ActionServlet Action caching problem
Date: Mon, 10 Mar 2003 16:07:29 -0500

I've got a weird one.  I'm hoping that somebody else has encountered this
before and can help.  We are in the midst of load testing our app before
rolling it out to production.  I have one action class (only one) that
starts failing well over an hour into the test.

It appears that the instance of that action class cached by the
ActionServlet becomes invalid.  I can see no reason why the change in
behaviour, but at some point the RequestProcessor gets an instance to the
Action that is no longer valid.  It is not null, but it never executes it.
The rest of the app works perfectly, but that button (tied to that specific
Action) never works again until the tomcat instance is restarted.  It just
hangs, and the last indication in the log is the RequestProcessor finding
and returning an instance of that action class.

Has anyone ever had problems with Action instances going stale?  or some
other config problem that could cause this?

Thanks, I'm a bit desparate,
Jeff.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


_
The new MSN 8: advanced junk mail protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail


-
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: [Redirect] Caching problem with redirect... (new attempt)

2002-09-06 Thread James Mitchell

 -Original Message-
 From: Michael Delamere [mailto:[EMAIL PROTECTED]]
 Sent: Friday, September 06, 2002 2:29 AM


 Hi,

 I hope you don´t mind me asking again, but I got no answer yesterday


 I´m programming an application with a shopping cart.  Originally I used a
 normal forward.  The downside of this though, was that when the
 user pressed
 the refresh button, the article incremented by one every time.

You can eliminate this by utilizing token verification that is part of the
framework.
See the code in the struts-example or docs for exact usage and benefits.


 Michael



HTH

James Mitchell
Software Engineer\Struts Evangelist
Struts-Atlanta, the Open Minded Developer Network
http://www.open-tools.org/struts-atlanta



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Re: [Redirect] Caching problem with redirect... (new attempt)

2002-09-06 Thread Michael Delamere

Thanks, hopefully I´ll know what you are talking about once I´ve read the
docs... :-)

Regads,

Michael


- Original Message -
From: James Mitchell [EMAIL PROTECTED]
To: Struts Users Mailing List [EMAIL PROTECTED]
Sent: Friday, September 06, 2002 8:45 AM
Subject: RE: [Redirect] Caching problem with redirect... (new attempt)


  -Original Message-
  From: Michael Delamere [mailto:[EMAIL PROTECTED]]
  Sent: Friday, September 06, 2002 2:29 AM
 
 
  Hi,
 
  I hope you don´t mind me asking again, but I got no answer yesterday
 
 
  I´m programming an application with a shopping cart.  Originally I used
a
  normal forward.  The downside of this though, was that when the
  user pressed
  the refresh button, the article incremented by one every time.

 You can eliminate this by utilizing token verification that is part of the
 framework.
 See the code in the struts-example or docs for exact usage and benefits.

 
  Michael
 
 

 HTH

 James Mitchell
 Software Engineer\Struts Evangelist
 Struts-Atlanta, the Open Minded Developer Network
 http://www.open-tools.org/struts-atlanta



 --
 To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
 For additional commands, e-mail:
mailto:[EMAIL PROTECTED]



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: [Redirect] Caching problem with redirect... (new attempt)

2002-09-06 Thread James Mitchell

Here's a good response from Craig..

http://www.mail-archive.com/struts-user@jakarta.apache.org/msg35600.html

Scroll down to see explaination


James Mitchell
Software Engineer\Struts Evangelist
Struts-Atlanta, the Open Minded Developer Network
http://www.open-tools.org/struts-atlanta




 -Original Message-
 From: Michael Delamere [mailto:[EMAIL PROTECTED]]
 Sent: Friday, September 06, 2002 3:22 AM
 To: Struts Users Mailing List
 Subject: Re: [Redirect] Caching problem with redirect... (new attempt)


 Thanks, hopefully I´ll know what you are talking about once I´ve read the
 docs... :-)

 Regads,

 Michael


 - Original Message -
 From: James Mitchell [EMAIL PROTECTED]
 To: Struts Users Mailing List [EMAIL PROTECTED]
 Sent: Friday, September 06, 2002 8:45 AM
 Subject: RE: [Redirect] Caching problem with redirect... (new attempt)


   -Original Message-
   From: Michael Delamere [mailto:[EMAIL PROTECTED]]
   Sent: Friday, September 06, 2002 2:29 AM
  
  
   Hi,
  
   I hope you don´t mind me asking again, but I got no answer
 yesterday
  
  
   I´m programming an application with a shopping cart.
 Originally I used
 a
   normal forward.  The downside of this though, was that when the
   user pressed
   the refresh button, the article incremented by one every time.
 
  You can eliminate this by utilizing token verification that is
 part of the
  framework.
  See the code in the struts-example or docs for exact usage and benefits.
 
  
   Michael
  
  
 
  HTH
 
  James Mitchell
  Software Engineer\Struts Evangelist
  Struts-Atlanta, the Open Minded Developer Network
  http://www.open-tools.org/struts-atlanta
 
 
 
  --
  To unsubscribe, e-mail:
 mailto:[EMAIL PROTECTED]
  For additional commands, e-mail:
 mailto:[EMAIL PROTECTED]
 


 --
 To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




[Redirect] Caching problem with redirect...

2002-09-05 Thread Michael Delamere

Hi,

I´m programming an application with a shopping cart.  Originally I used a
normal forward.  The downside of this though, was that when the user pressed
the refresh button, the article incremented by one every time.

Ok, so I thought (and read) that the idea would be to use the
forward-redirect.  The only problem I have now is that the pages are cached!

I solved the problem originally by adding pragma no-cache to the response
header.  This actually worked when using the normal forward.  The pages
where no longer cached.  Now why doesn´t this work with a redirect?  What´s
the difference?

I could really do with some help.

Regards,

Michael


--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




[Redirect] Caching problem with redirect... (new attempt)

2002-09-05 Thread Michael Delamere

Hi,

I hope you don´t mind me asking again, but I got no answer yesterday


I´m programming an application with a shopping cart.  Originally I used a
normal forward.  The downside of this though, was that when the user pressed
the refresh button, the article incremented by one every time.

Ok, so I thought (and read) that the idea would be to use the
forward-redirect.  The only problem I have now is that the pages are cached!

I solved the problem originally by adding pragma no-cache to the response
header.  This actually worked when using the normal forward.  The pages
where no longer cached.  Now why doesn´t this work with a redirect?  What´s
the difference?

I could really do with some help.

Regards,

Michael




--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




Caching problem with bean:message ...

2002-06-04 Thread tamer . kavlak

Hi all

we need to get some nls-resource out of a db. to implement this I started with 
a own subclass of
org.apache.struts.util.PropertyMessageResources and the factroy class.

for the beginning, I just overwrote the following method: 


public String getMessage(Locale locale, String key) 
{
System.out.println(MyMessageResource::getMessage : +key+, for 
+locale);

// simulating some real dynamic message
if( key.equals(test) )
{
// in future this would be a dbaccess
return (new Date()).toString();
}
else
{
return super.getMessage(locale, key);
}
}

on my test page I can set 2 locales dynamicly (en and de). the method above is 
only called once for each bean:message key=key tag and locale. this means:
- first time access to the jsp with de = method will be called with a output 
like MyMessageResource::getMessage : test, for de. on the page the actual 
Date object is shown
- i change the locale to en = method will be called again with a output like 
MyMessageResource::getMessage : test, for en. again the actual Date object 
(newer than befor) is shown.

after this, the method is never called again, even
- not, when i change locale (it changes between the english and german page, 
but do not call the method)
- not, when i reload the page



my jsp contains following lines to avoid caching
meta http-equiv=expires content=0
meta http-equiv=cache-control content=no-cache
meta http-equiv=pragma content=no-cache

the change of locale is a link to an action, which sets the locale and forwards 
to the same jsp back.

when I start another browser (I had nescape and started opera afterthat); I see 
the old date object created when I accessed the page from the other browser.
this looks like there is some caching on the serverside ?? 

any ideas about that ?

regards

tamer



--
To unsubscribe, e-mail:   mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]




RE: Caching Problem

2001-05-16 Thread Dinesh Chaturvedi

Hi David 

You got the problem right well i have tried using only the last
line of your code 
response.addDateHeader(Expires, 1);
in my code it does not work maybe this will solve the problem. 



Hi Dinesh,
Not sure if this is what you mean, but here goes:
If you set the following headers into the JSPs response, the page will
not
be cached.
Use the following scriptlet in the page to take care of this
%
response.addHeader(Pragma, NoCache);
response.addHeader(Cache-Control, no-cache);
response.addDateHeader(Expires, 1);
%

Take a look at 
http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg245850.pdf 
Section 6.5.6 for more information on this subject.

Hope this helps.
Rgds
David

-Original Message-
From: Dinesh Chaturvedi [mailto:[EMAIL PROTECTED]]
Sent: 15 May 2001 14:02
To: [EMAIL PROTECTED]
Subject: Caching Problem



Hello Every body

I am facing a problem ,i want  My JSP Page not
to take content from chache can anybody help me.
Thanks  Regards

Dinesh Chaturvedi
Programmer Analyst 
Nihilent Technologies Pvt Ltd.
Pune 091-20-6054452 Ext 349





The information in this email is confidential and is intended solely
for the addressee(s).
Access to this email by anyone else is unauthorised. If you are not
an intended recipient, you must not read, use or disseminate the
information contained in the email.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Capco.

http://www.capco.com
***




Caching Problem

2001-05-15 Thread Dinesh Chaturvedi


Hello Every body

I am facing a problem ,i want  My JSP Page not
to take content from chache can anybody help me.
Thanks  Regards

Dinesh Chaturvedi
Programmer Analyst 
Nihilent Technologies Pvt Ltd.
Pune 091-20-6054452 Ext 349







RE: Caching Problem

2001-05-15 Thread Firmin David

Hi Dinesh,
Not sure if this is what you mean, but here goes:
If you set the following headers into the JSPs response, the page will not
be cached.
Use the following scriptlet in the page to take care of this
%
response.addHeader(Pragma, NoCache);
response.addHeader(Cache-Control, no-cache);
response.addDateHeader(Expires, 1);
%

Take a look at 
http://www.redbooks.ibm.com/pubs/pdfs/redbooks/sg245850.pdf 
Section 6.5.6 for more information on this subject.

Hope this helps.
Rgds
David

-Original Message-
From: Dinesh Chaturvedi [mailto:[EMAIL PROTECTED]]
Sent: 15 May 2001 14:02
To: [EMAIL PROTECTED]
Subject: Caching Problem



Hello Every body

I am facing a problem ,i want  My JSP Page not
to take content from chache can anybody help me.
Thanks  Regards

Dinesh Chaturvedi
Programmer Analyst 
Nihilent Technologies Pvt Ltd.
Pune 091-20-6054452 Ext 349





The information in this email is confidential and is intended solely
for the addressee(s).
Access to this email by anyone else is unauthorised. If you are not
an intended recipient, you must not read, use or disseminate the
information contained in the email.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Capco.

http://www.capco.com
***




RE: Caching Problem

2001-05-15 Thread Nanduri, Amarnath


In your web.xml file set the following ...

  servlet
servlet-nameaction/servlet-name
servlet-classorg.apache.struts.action.ActionServlet/servlet-class
init-param
  param-nameapplication/param-name
  param-valueApplicationResources/param-value
/init-param
init-param
  param-nameconfig/param-name
  param-value/WEB-INF/struts-config.xml/param-value
/init-param
init-param
  param-namevalidate/param-name
  param-valuetrue/param-value
/init-param
init-param
  param-namenocache/param-name
  param-valuetrue/param-value
/init-param
  /servlet


-Original Message-
From: Dinesh Chaturvedi [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 15, 2001 9:02 AM
To: [EMAIL PROTECTED]
Subject: Caching Problem



Hello Every body

I am facing a problem ,i want  My JSP Page not
to take content from chache can anybody help me.
Thanks  Regards

Dinesh Chaturvedi
Programmer Analyst 
Nihilent Technologies Pvt Ltd.
Pune 091-20-6054452 Ext 349