[Bug 53138] Not able to download a file size of 740KB using NIO connector in tomcat version 7.0.27. But with the same configuration I was able to download that in tomcat 7.0.26.

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=53138

--- Comment #17 from Giuseppe Schiavo  ---
It is an old issue but it still happening it seems. We get this error in Chrome
Electron 51, but not with other browsers. My guess is that the error is being
ignored by other browsers. We haven't validated yet with 8.0.43, but we see it
with 8.0.18. I will open a new bug after I validate with 8.0.43 in case it
still happens with this version.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: TC 8.5 and Log4J2 via Juli: Wrong location info

[Rainer Jung]

Am 17.04.2017 um 11:49 schrieb Rémy Maucherat:

2017-04-15 23:32 GMT+02:00 Rainer Jung :


Coming back to this.

Reminder:

- in TC 8.5 we removed explicit support for Log4J(2)

- we direct users at the Log4J2 JUL bridge

- the Log4J2 JUL bridge works by adding the additional Log4J2 jar files to
the CLASSPATH and setting LOGGING_MANAGER to -Djava.util.logging.manager=or
g.apache.logging.log4j.jul.LogManager

Now there's a problem: the log4j2 implementation of retrieving location
info (e.g. %C, %l, %F, %L) from the stack isn't aware of our juli sitting
between the real jul classes and log4J2 and so always results in
org.apache.juli.logging.DirectJDKLog as location of the log event instead
of the real class containing the log statement.

Of course location info patterns are not recommended for performance
reasons, nevertheless I think they should work correctly for debugging
purposes.

One suggested solution was:

- add a org.apache.juli.logging.Log impl that delegates to Log4J2 (instead
of the JUL bridge)

and

- add a Log4jLogEventFactory that additionally skips our DirectJDKLog when
looking for the location info in the stack.

I implemented this. See the patch for 8.5 at

http://home.apache.org/~rjung/patches/tc8.5.x-juli-log4j2.patch

The way I did it, is adding back a tomcat-juli-adapters.jar, which
contains the above two classes. Adding this instead of the Log4J2 JUL
bridge to the CLASSPATH (plus the Log4J2 api and core jars, but no changes
to LOGGING_MANAGER) result in Log4J2 being used and logging with correct
location info.

Would that make a useful addition for TC 8.5 (and 9)?

Ok, so the dependency from extras to log4j is removed just to be added

back 5 minutes later as a real dependency. Interesting !
Personally, I'm probably going to vote "no".


The idea here is not to remove some dependency but to fix the "wrong 
location info" problem/bug.


Or do you see a new dependency creeping in here? The patch does 
introduce a compile time dependency to log4j but not a runtime 
dependency unless you are using the optional adapters jar (to fix the 
location info bug).


I still do not see a better way to fix the problem.

Or maybe I misunderstood you.

Regards,

Rainer

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: TC 8.5 and Log4J2 via Juli: Wrong location info

[Rémy Maucherat]

2017-04-15 23:32 GMT+02:00 Rainer Jung :

> Coming back to this.
>
> Reminder:
>
> - in TC 8.5 we removed explicit support for Log4J(2)
>
> - we direct users at the Log4J2 JUL bridge
>
> - the Log4J2 JUL bridge works by adding the additional Log4J2 jar files to
> the CLASSPATH and setting LOGGING_MANAGER to -Djava.util.logging.manager=or
> g.apache.logging.log4j.jul.LogManager
>
> Now there's a problem: the log4j2 implementation of retrieving location
> info (e.g. %C, %l, %F, %L) from the stack isn't aware of our juli sitting
> between the real jul classes and log4J2 and so always results in
> org.apache.juli.logging.DirectJDKLog as location of the log event instead
> of the real class containing the log statement.
>
> Of course location info patterns are not recommended for performance
> reasons, nevertheless I think they should work correctly for debugging
> purposes.
>
> One suggested solution was:
>
> - add a org.apache.juli.logging.Log impl that delegates to Log4J2 (instead
> of the JUL bridge)
>
> and
>
> - add a Log4jLogEventFactory that additionally skips our DirectJDKLog when
> looking for the location info in the stack.
>
> I implemented this. See the patch for 8.5 at
>
> http://home.apache.org/~rjung/patches/tc8.5.x-juli-log4j2.patch
>
> The way I did it, is adding back a tomcat-juli-adapters.jar, which
> contains the above two classes. Adding this instead of the Log4J2 JUL
> bridge to the CLASSPATH (plus the Log4J2 api and core jars, but no changes
> to LOGGING_MANAGER) result in Log4J2 being used and logging with correct
> location info.
>
> Would that make a useful addition for TC 8.5 (and 9)?
>
> Ok, so the dependency from extras to log4j is removed just to be added
back 5 minutes later as a real dependency. Interesting !
Personally, I'm probably going to vote "no".

Rémy

[Tomcat Wiki] Update of "SupportAndTraining" by markt

[Apache Wiki]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change 
notification.

The "SupportAndTraining" page has been changed by markt:
https://wiki.apache.org/tomcat/SupportAndTraining?action=diff=65=66

Comment:
Better link for pivotal OSS support

  -
  = Support =
  -
- 
[[https://www.pivotal.io/support/offerings|{{http://www.apache.org/foundation/images/pivotal-platinum.png|http://www.pivotal.io/support/offerings|width=150}}]]
+ 
[[https://www.pivotal.io/support/offerings|{{http://www.apache.org/foundation/images/pivotal-platinum.png|https://pivotal.io/support/oss|width=150}}]]
  
- Pivotal provides global, 24x7, 
[[http://www.pivotal.io/support/offerings|enterprise support]] for production 
users of Apache Tomcat. Pivotal employs the leading experts on Apache Tomcat to 
ensure that support customers can get their questions answered quickly and 
accurately and that bug fixes are incorporated into the open source code base.
+ Pivotal provides global, 24x7, [[https://pivotal.io/support/oss|enterprise 
support]] for production users of Apache Tomcat. Pivotal employs the leading 
experts on Apache Tomcat to ensure that support customers can get their 
questions answered quickly and accurately and that bug fixes are incorporated 
into the open source code base.
  
  
[[http://www.kippdata.de|{{http://www.kippdata.de/site/themes/kippdata/img/elements/kippdata_logo.gif|http://www.kippdata.de}}]]
  

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[Bug 60997] New: Enhance SemaphoreValve to support denied status and path matching

[bugzilla]

https://bz.apache.org/bugzilla/show_bug.cgi?id=60997

Bug ID: 60997
   Summary: Enhance SemaphoreValve to support denied status and
path matching
   Product: Tomcat 9
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: enhancement
  Priority: P2
 Component: Catalina
  Assignee: dev@tomcat.apache.org
  Reporter: rmannibu...@gmail.com
  Target Milestone: -

Hi,

would be great to enrich the SemaphoreValve to support few more things. Obvious
and easy ones are:

1. deniedStatus and have a default implementation of permitDenied setting this
status (Note: if not possible in current valve a EnhancedSemaphoreValve would
be good enough)
2. controlConcurrency should enable to match a requestUri, I guess a
includeRequestUris and excludeRequestUris is the way to go

On probably a bit more difficult side, it would be great to support
asynchronism limiting. This one can require to move the valve to a filter to be
able to wrap the AsyncContext to have the right hooks but this would make it
fully functional.

Finally: this valve provides concurrent limit but is there any plan to have
rate limiting (based on a time slot)?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org