Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java

2004-05-01 Thread Remy Maucherat
Glenn Nielsen wrote:
Remy,

I am sick and tired of your crap. For whatever reason you don't like
any of my contributions.  You always try to find some way to justify
a -1 of anything I contribute.  Frankly you are the main reason why
I rarely contribute to Tomcat any more.  I just got tired of dealing
with your shit. IMHO your interactions with people on this list and in
bugzilla hurts the Tomcat community.
I get the message. Frankly, I do not miss your contributions, as I have 
always considered to be of average quality. You're not the only one who 
hasn't appreciated working with the other.

I'd like to point out that:
- I do listen to feedback, so I have retracted my -1
- I don't see how you can expect to be well recieved if you make an 
unnanouced risky patch on a really mature branch after having been away 
from months

Of course, I will reflect this in light of my involvement with the 
community. I think this can wait until the new release, which is a few 
days away.

And of course I did discusss this patch before I committed it.
I posted a summary of the patch on Apr 20 which contained the
same information as my commit message. From anyone else I would
expect an apology, but not from an egotistical piece of shit like you.
I somehow did miss the original message, so I apologize. Really a bad 
mistake on my part, and I suggest using [PROPOSAL] to attract more 
attention, and esp when proposing core changes.

Now, as for the rest of the paragraph, I obviously don't want to have to 
interact with you anymore.

And for those of you watching from the sidelines this is the first
time on any of the ASF/Tomcat lists I have attacked someone personally.
I have always tried to keep discussions technical rather than get
personal.
Whatever.

Rémy

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


Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java

2004-05-01 Thread Glenn Nielsen
On Sat, May 01, 2004 at 02:26:34PM +0200, Remy Maucherat wrote:
 Glenn Nielsen wrote:
 Remy,
 
 I am sick and tired of your crap. For whatever reason you don't like
 any of my contributions.  You always try to find some way to justify
 a -1 of anything I contribute.  Frankly you are the main reason why
 I rarely contribute to Tomcat any more.  I just got tired of dealing
 with your shit. IMHO your interactions with people on this list and in
 bugzilla hurts the Tomcat community.
 
 I get the message. Frankly, I do not miss your contributions, as I have 
 always considered to be of average quality. You're not the only one who 
 hasn't appreciated working with the other.

Thats your opinion. Others can judge based on the major contributions
I have made. Such as implementing the Java Security Manager and the
major jasaper refactoring I did which boosted performance 25-33%.

 I'd like to point out that:
 - I do listen to feedback, so I have retracted my -1
 - I don't see how you can expect to be well recieved if you make an 
 unnanouced risky patch on a really mature branch after having been away 
 from months

As is normal for any feedback from you on my contributions, you rarely
provide any technical reason, you just make some characterization such as
risky patch without stating any valid technical reason why. Considering
that someone on the list immediately posted a message thanking me for
fixing some problems they were having with Sessions and JDBCStore your
knee-jerk reaction to -1 anything I contribute obviously hurts Tomcat.

 Of course, I will reflect this in light of my involvement with the 
 community. I think this can wait until the new release, which is a few 
 days away.

 And of course I did discusss this patch before I committed it.
 I posted a summary of the patch on Apr 20 which contained the
 same information as my commit message. From anyone else I would
 expect an apology, but not from an egotistical piece of shit like you.
 
 I somehow did miss the original message, so I apologize. Really a bad 
 mistake on my part, and I suggest using [PROPOSAL] to attract more 
 attention, and esp when proposing core changes.

It was posted with [PATCH] on the subject line. Apology accepted.

 Now, as for the rest of the paragraph, I obviously don't want to have to 
 interact with you anymore.

I dont' care what you think of me personally. But when your animosity
towards me impacts Tomcat I had to say something.

Regards,

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java

2004-05-01 Thread Remy Maucherat
Glenn Nielsen wrote:
I dont' care what you think of me personally. But when your animosity
towards me impacts Tomcat I had to say something.
I'm sure it fully justifies the egotistical piece of shit like you 
comment ;)
Jon is funny at least, but this is just pathetic.

Rémy

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


Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java

2004-05-01 Thread Glenn Nielsen
On Sat, May 01, 2004 at 06:39:15PM +0200, Remy Maucherat wrote:
 Glenn Nielsen wrote:
 I dont' care what you think of me personally. But when your animosity
 towards me impacts Tomcat I had to say something.
 
 I'm sure it fully justifies the egotistical piece of shit like you 
 comment ;)
 Jon is funny at least, but this is just pathetic.

Sometimes you have to jump on the table and rant a bit to grab
peoples attention.

I did go over the line with the statement you quoted above.
Please accept my apology for that one.

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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



Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java

2004-05-01 Thread Remy Maucherat
Glenn Nielsen wrote:
Please accept my apology for that one.
Accepted.

Rémy

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


Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java

2004-04-30 Thread Remy Maucherat
[EMAIL PROTECTED] wrote:

glenn   2004/04/30 12:15:26

  Modified:catalina/src/share/org/apache/catalina/session
JDBCStore.java PersistentManagerBase.java
StandardManager.java StandardSession.java
StoreBase.java
  Log:
  The JDBCStore required a great deal of unnecessary db
  queries to manage the persisted data. This could severly
  impact its ability to scale to large numbers of sessions.
  
  1. When a JSESSIONID cookie was submitted with a request where
 the Session no longer exists multiple queries of the db occurred
 to try and load a persisted Session from the Store. I was
 seeing four attempts to load from the persistence store
 each request when a Session did not exist for a JSESSIONID.
  
 PersistentManagerBase swapIn() and swapOut() were patched
 to maintain a Hashtable of JSESSIONID's which do not exist
 in the Store so that they don't have to be checked multiple
 times.  Each checkInterval the Hashtable is cleared to
 prevent it from consuming too much memory.
  
  2. The StoreBase.processExpires() method triggers a load of
 each Session persisted to the db each checkInterval to
 perform its test to determine if the Session has expired.
 This incurred alot of overhead on the db, especially
 if there was a large amount of session data. The number
 of queries performed each checkInterval is 1 + number of
 sessions persisted to the db + number of expired sessions
 removed.
  
 The StoreBase.processExpires() method was overridden
 in JDBCStore.  The method in JDBCStore performs a
 query of the db to find only those Sessions which should
 be expired. The number of queries performed here is 1 +
 2 * the number of expired sessions (load then remove
 of expired session).
  
  3. JDBCStore.remove() is being called sometimes with a null
 sessionid String causing an unnecessary synchronization
 and db query.
  
 Added a check for a null sessionid String at top of method.
  
  Problems with expiring sessions have been reported numerous times.
  The basic problem is as follows, starting at time 0 min and with
  a max inactive interval of 30 minutes:
  
  00 min: First request, new session created, LastAccessedTime 0
  02 min: Second request, reuse session, LastAccessedTime 0
  31 min: Third request, reuse session, LastAccessedTime now 2
  33 min: Background manager thread expires session even though
  it has only been two minutes since the remote clients
  last request.
  
  The argument for not changing how this works is based on how
  the Servlet Spec defines Session.getLastAccessedTime().
  
  But I agree with all those who have complained about this
  behaviour that Tomcat session timeouts are buggy.
  
  So I came up with a compromise that still allows the
  HttpSession.getLastAccessedTime() to return the time of the
  previous request for those who are Servlet Spec purists.
  
  But internally sessions are expired when
  current time  last request + max inactive interval.
  
  When we do a major revision we should consider adding
  the StandardSession.getLastUsedTime() method to the
  org.apache.catalina.Session interface.
And of course you don't discuss this before making the change ?
This is the old branch, so this is clearly not acceptable.
I have to -1 regardless of the possible merits.
Rémy

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


Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java

2004-04-30 Thread Filip Hanik - Dev
- Original Message -
From: Remy Maucherat [EMAIL PROTECTED]

And of course you don't discuss this before making the change ?
This is the old branch, so this is clearly not acceptable.
I have to -1 regardless of the possible merits.

Ok, so he forgot to ask the developers if this would be ok, no big deal. Can happen to 
anybody.
But if someone is fixing code and improving it, I don't think a -1 is fair just
because you felt that you werent able to control the changes.

If there is more to the story which would require the -1 to go into effect, you would 
need to share that. take-it-lightlyAfter
all, we are not running a Boss/JBoss show here :)/take-it-lightly

So if there is more to it, share is please, so that we can all know why this change is 
not reasonable. It is not the -1 that I am
against, it is the lack of explanation to it.

Filip




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



Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java

2004-04-30 Thread Remy Maucherat
Filip Hanik - Dev wrote:
And of course you don't discuss this before making the change ? 
This is the old branch, so this is clearly not acceptable. I have
to -1 regardless of the possible merits.
Ok, so he forgot to ask the developers if this would be ok, no big
deal. Can happen to anybody. But if someone is fixing code and
improving it, I don't think a -1 is fair just because you felt that
you werent able to control the changes.
If there is more to the story which would require the -1 to go into
effect, you would need to share that. take-it-lightlyAfter all, we
are not running a Boss/JBoss show here :)/take-it-lightly
I'm not very amused. Obviously the changes have nothing to do with JBoss.

So if there is more to it, share is please, so that we can all know
why this change is not reasonable. It is not the -1 that I am 
against, it is the lack of explanation to it.
I consider the change is inappropriate for Tomcat 4.1.x. But actually, I 
really don't care anoymore about this branch, so make my vote a -0.

Rémy

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


Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java

2004-04-30 Thread Tom Anderson
I'm just a list lurker (so my opinion doesn't count) but I'm really 
happy to see these fixes.   I have had to override JDBCStore and 
PersistentManagerBase at my site to make similar fixes so that things 
work acceptably (yes, I submitted patches but they weren't accepted).   
Having these fixes in would allow me to upgrade to 4.1.x and get rid of 
my old overridden classes.

Thanks Glenn!
~Tom
On Apr 30, 2004, at 1:15 PM, [EMAIL PROTECTED] wrote:

glenn   2004/04/30 12:15:26

  Modified:catalina/src/share/org/apache/catalina/session
JDBCStore.java PersistentManagerBase.java
StandardManager.java StandardSession.java
StoreBase.java
  Log:
  The JDBCStore required a great deal of unnecessary db
  queries to manage the persisted data. This could severly
  impact its ability to scale to large numbers of sessions.
  1. When a JSESSIONID cookie was submitted with a request where
 the Session no longer exists multiple queries of the db occurred
 to try and load a persisted Session from the Store. I was
 seeing four attempts to load from the persistence store
 each request when a Session did not exist for a JSESSIONID.
 PersistentManagerBase swapIn() and swapOut() were patched
 to maintain a Hashtable of JSESSIONID's which do not exist
 in the Store so that they don't have to be checked multiple
 times.  Each checkInterval the Hashtable is cleared to
 prevent it from consuming too much memory.
  2. The StoreBase.processExpires() method triggers a load of
 each Session persisted to the db each checkInterval to
 perform its test to determine if the Session has expired.
 This incurred alot of overhead on the db, especially
 if there was a large amount of session data. The number
 of queries performed each checkInterval is 1 + number of
 sessions persisted to the db + number of expired sessions
 removed.
 The StoreBase.processExpires() method was overridden
 in JDBCStore.  The method in JDBCStore performs a
 query of the db to find only those Sessions which should
 be expired. The number of queries performed here is 1 +
 2 * the number of expired sessions (load then remove
 of expired session).
  3. JDBCStore.remove() is being called sometimes with a null
 sessionid String causing an unnecessary synchronization
 and db query.
 Added a check for a null sessionid String at top of method.

  Problems with expiring sessions have been reported numerous times.
  The basic problem is as follows, starting at time 0 min and with
  a max inactive interval of 30 minutes:
  00 min: First request, new session created, LastAccessedTime 0
  02 min: Second request, reuse session, LastAccessedTime 0
  31 min: Third request, reuse session, LastAccessedTime now 2
  33 min: Background manager thread expires session even though
  it has only been two minutes since the remote clients
  last request.
  The argument for not changing how this works is based on how
  the Servlet Spec defines Session.getLastAccessedTime().
  But I agree with all those who have complained about this
  behaviour that Tomcat session timeouts are buggy.
  So I came up with a compromise that still allows the
  HttpSession.getLastAccessedTime() to return the time of the
  previous request for those who are Servlet Spec purists.
  But internally sessions are expired when
  current time  last request + max inactive interval.
  When we do a major revision we should consider adding
  the StandardSession.getLastUsedTime() method to the
  org.apache.catalina.Session interface.


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


Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java

2004-04-30 Thread Remy Maucherat
Tom Anderson wrote:
I'm just a list lurker (so my opinion doesn't count) but I'm really 
happy to see these fixes.   I have had to override JDBCStore and 
PersistentManagerBase at my site to make similar fixes so that things 
work acceptably (yes, I submitted patches but they weren't accepted).   
Having these fixes in would allow me to upgrade to 4.1.x and get rid of 
my old overridden classes.
The optimization part of the patch is useful. The session expiration 
fixes ae risky and change the API of some rather visible objects. The 
patch does not seem to cause any regressions, but obviously, there has 
been tons of examples where it looked to be the case, and problems occurred.

So overall, I think the patch is too risky for that branch. But however, 
since I don't use it anymore, my opinion is not worth much.

Rémy

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


Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java

2004-04-30 Thread Glenn Nielsen
On Fri, Apr 30, 2004 at 09:19:30PM +0200, Remy Maucherat wrote:
 [EMAIL PROTECTED] wrote:
 
 glenn   2004/04/30 12:15:26
 
   Modified:catalina/src/share/org/apache/catalina/session
 JDBCStore.java PersistentManagerBase.java
 StandardManager.java StandardSession.java
 StoreBase.java
   Log:
   The JDBCStore required a great deal of unnecessary db
   queries to manage the persisted data. This could severly
   impact its ability to scale to large numbers of sessions.
   
   1. When a JSESSIONID cookie was submitted with a request where
  the Session no longer exists multiple queries of the db occurred
  to try and load a persisted Session from the Store. I was
  seeing four attempts to load from the persistence store
  each request when a Session did not exist for a JSESSIONID.
   
  PersistentManagerBase swapIn() and swapOut() were patched
  to maintain a Hashtable of JSESSIONID's which do not exist
  in the Store so that they don't have to be checked multiple
  times.  Each checkInterval the Hashtable is cleared to
  prevent it from consuming too much memory.
   
   2. The StoreBase.processExpires() method triggers a load of
  each Session persisted to the db each checkInterval to
  perform its test to determine if the Session has expired.
  This incurred alot of overhead on the db, especially
  if there was a large amount of session data. The number
  of queries performed each checkInterval is 1 + number of
  sessions persisted to the db + number of expired sessions
  removed.
   
  The StoreBase.processExpires() method was overridden
  in JDBCStore.  The method in JDBCStore performs a
  query of the db to find only those Sessions which should
  be expired. The number of queries performed here is 1 +
  2 * the number of expired sessions (load then remove
  of expired session).
   
   3. JDBCStore.remove() is being called sometimes with a null
  sessionid String causing an unnecessary synchronization
  and db query.
   
  Added a check for a null sessionid String at top of method.
   
   Problems with expiring sessions have been reported numerous times.
   The basic problem is as follows, starting at time 0 min and with
   a max inactive interval of 30 minutes:
   
   00 min: First request, new session created, LastAccessedTime 0
   02 min: Second request, reuse session, LastAccessedTime 0
   31 min: Third request, reuse session, LastAccessedTime now 2
   33 min: Background manager thread expires session even though
   it has only been two minutes since the remote clients
   last request.
   
   The argument for not changing how this works is based on how
   the Servlet Spec defines Session.getLastAccessedTime().
   
   But I agree with all those who have complained about this
   behaviour that Tomcat session timeouts are buggy.
   
   So I came up with a compromise that still allows the
   HttpSession.getLastAccessedTime() to return the time of the
   previous request for those who are Servlet Spec purists.
   
   But internally sessions are expired when
   current time  last request + max inactive interval.
   
   When we do a major revision we should consider adding
   the StandardSession.getLastUsedTime() method to the
   org.apache.catalina.Session interface.
 
 And of course you don't discuss this before making the change ?
 This is the old branch, so this is clearly not acceptable.
 I have to -1 regardless of the possible merits.
 
 Rémy
 

Remy,

I am sick and tired of your crap. For whatever reason you don't like
any of my contributions.  You always try to find some way to justify
a -1 of anything I contribute.  Frankly you are the main reason why
I rarely contribute to Tomcat any more.  I just got tired of dealing
with your shit. IMHO your interactions with people on this list and in
bugzilla hurts the Tomcat community.

And of course I did discusss this patch before I committed it.
I posted a summary of the patch on Apr 20 which contained the
same information as my commit message. From anyone else I would
expect an apology, but not from an egotistical piece of shit like you.

And for those of you watching from the sidelines this is the first
time on any of the ASF/Tomcat lists I have attacked someone personally.
I have always tried to keep discussions technical rather than get
personal.

My warmest regards,

Glenn

--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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

Re: cvs commit: jakarta-tomcat-4.0/catalina/src/share/org/apache/catalina/session JDBCStore.java PersistentManagerBase.java StandardManager.java StandardSession.java StoreBase.java

2004-04-30 Thread Glenn Nielsen
Thanks for the words of encouragement.

Glenn

On Fri, Apr 30, 2004 at 03:27:00PM -0600, Tom Anderson wrote:
 I'm just a list lurker (so my opinion doesn't count) but I'm really 
 happy to see these fixes.   I have had to override JDBCStore and 
 PersistentManagerBase at my site to make similar fixes so that things 
 work acceptably (yes, I submitted patches but they weren't accepted).   
 Having these fixes in would allow me to upgrade to 4.1.x and get rid of 
 my old overridden classes.
 
 Thanks Glenn!
 ~Tom
 
 On Apr 30, 2004, at 1:15 PM, [EMAIL PROTECTED] wrote:
 
 glenn   2004/04/30 12:15:26
 
   Modified:catalina/src/share/org/apache/catalina/session
 JDBCStore.java PersistentManagerBase.java
 StandardManager.java StandardSession.java
 StoreBase.java
   Log:
   The JDBCStore required a great deal of unnecessary db
   queries to manage the persisted data. This could severly
   impact its ability to scale to large numbers of sessions.
 
   1. When a JSESSIONID cookie was submitted with a request where
  the Session no longer exists multiple queries of the db occurred
  to try and load a persisted Session from the Store. I was
  seeing four attempts to load from the persistence store
  each request when a Session did not exist for a JSESSIONID.
 
  PersistentManagerBase swapIn() and swapOut() were patched
  to maintain a Hashtable of JSESSIONID's which do not exist
  in the Store so that they don't have to be checked multiple
  times.  Each checkInterval the Hashtable is cleared to
  prevent it from consuming too much memory.
 
   2. The StoreBase.processExpires() method triggers a load of
  each Session persisted to the db each checkInterval to
  perform its test to determine if the Session has expired.
  This incurred alot of overhead on the db, especially
  if there was a large amount of session data. The number
  of queries performed each checkInterval is 1 + number of
  sessions persisted to the db + number of expired sessions
  removed.
 
  The StoreBase.processExpires() method was overridden
  in JDBCStore.  The method in JDBCStore performs a
  query of the db to find only those Sessions which should
  be expired. The number of queries performed here is 1 +
  2 * the number of expired sessions (load then remove
  of expired session).
 
   3. JDBCStore.remove() is being called sometimes with a null
  sessionid String causing an unnecessary synchronization
  and db query.
 
  Added a check for a null sessionid String at top of method.
 
   Problems with expiring sessions have been reported numerous times.
   The basic problem is as follows, starting at time 0 min and with
   a max inactive interval of 30 minutes:
 
   00 min: First request, new session created, LastAccessedTime 0
   02 min: Second request, reuse session, LastAccessedTime 0
   31 min: Third request, reuse session, LastAccessedTime now 2
   33 min: Background manager thread expires session even though
   it has only been two minutes since the remote clients
   last request.
 
   The argument for not changing how this works is based on how
   the Servlet Spec defines Session.getLastAccessedTime().
 
   But I agree with all those who have complained about this
   behaviour that Tomcat session timeouts are buggy.
 
   So I came up with a compromise that still allows the
   HttpSession.getLastAccessedTime() to return the time of the
   previous request for those who are Servlet Spec purists.
 
   But internally sessions are expired when
   current time  last request + max inactive interval.
 
   When we do a major revision we should consider adding
   the StandardSession.getLastUsedTime() method to the
   org.apache.catalina.Session interface.
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
--
Glenn Nielsen [EMAIL PROTECTED] | /* Spelin donut madder|
MOREnet System Programming   |  * if iz ina coment.  |
Missouri Research and Education Network  |  */   |
--

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