On 22/01/18 18:16, Daniel Fuchs wrote:
> Hi Mark,
>
> On 22/01/2018 17:33, Mark Thomas wrote:
>> Notes:
>> - You should see a stack trace if you use Java10 ea38
>
> I'm happy to report that I am observing the stack trace
> in catalina.out without my fix, and t
trace if you build Tomcat from source (the
workaround is in all current versions)
Mark
>
> http://cr.openjdk.java.net/~dfuchs/webrev_8195096/webrev.01/
>
> best regards,
>
> -- daniel
>
> On 20/01/2018 13:17, Daniel Fuchs wrote:
>> Hi Mark,
>>
>> Th
On 19/01/18 20:14, Mark Thomas wrote:
> Thanks to both of you for the hints that have got me thinking in new
> directions for a workaround.
Thanks again for the hints. I have a work-around that seems to work:
https://svn.apache.org/viewvc?view=revision&revision=1821708
It feels a
M.
I'm not sure what is possible at this point. I need to do some more
research.
Thanks to both of you for the hints that have got me thinking in new
directions for a workaround.
Mark
>
> best regards,
>
> -- daniel
>
> On 19/01/2018 17:34, Mark Thomas wrote:
>&g
On 19/01/18 14:22, Daniel Fuchs wrote:
> Hi,
>
> For the record, I updated the JBS issue [1] with Jason's suggestion
> and asked to get feedback from the submitter.
Providing feedback, as requested.
Thanks for looking at this so quickly. The speedy response is appreciated.
I did look to try and
On 12/05/2016 10:33, e...@zusammenkunft.net wrote:
> Hello,
>
> Should this also care about overwriting threadlocals, threadgroup,
> securitycontext and default exception handler (i.e. using the new
> constructor for managed threads and some).
>
> Gruss
> Bernd
>
I have only observed memory
On 12/05/2016 07:13, Alan Bateman wrote:
>
>
> On 11/05/2016 12:18, Mark Thomas wrote:
>> :
>> Sure. Done.
>> Review ID: 9087338
>>
> I found it, and moved it to the JDK project in JIRA:
>
> https://bugs.openjdk.java.net/browse/JDK-8156824
Thanks.
Mark
On 11/05/2016 08:18, Alan Bateman wrote:
> On 10/05/2016 23:05, Mark Thomas wrote:
>> Hi,
>>
>> While working my way through Tomcat's memory leak protection / detection
>> / fixing code, I have found an issue that remains unresolved in the
>> latest JDK
Hi,
While working my way through Tomcat's memory leak protection / detection
/ fixing code, I have found an issue that remains unresolved in the
latest JDK 9 source.
The PoolCleaner thread started by the LdapPoolManager when the idle
timeout is positive does not explicitly set the context class l
While working my way through Tomcat's memory leak protection / detection
/ fixing code, I have found an issue that remains unresolved in the
latest JDK 9 source.
The thread created by the GC class does not explicitly set the context
class loader so it inherits the current context class loader. Con
On 25/04/2016 22:26, Stuart Marks wrote:
> On 4/22/16 3:03 AM, Mark Thomas wrote:
Sorry for the delayed reply. I got distracted on other things.
>> The good news is that, with the information above, this leak is
>> something that modules/applications can and should do somethin
x27;t retained a reference to the exported
objects, is there any way to unexport those objects?
Thanks for all the great pointers provided so far in this thread.
I've updated and expanded the demonstration code in the GitHub repo
based on the new information.
Many thanks,
Mark
>
> s&#x
Continuing the previous thread but with a more precise subject.
Calling
LocateRegistry.createRegistry(Registry.REGISTRY_PORT);
is sufficient to pin the Thread Context Class Loader (TCCL) in memory
with no public API available (that I can find) to remove the reference.
This is a problem for modu
d to work on this some more before I come back with a much clearer
statement of the problem. I hope to be in a position to do that later
today or tomorrow.
I'll probably do that in a new thread.
Thanks for the pointers.
Mark
>
> On 4/18/16 11:58 AM, Mark Thomas wrote:
>> H
Hi,
The Apache Tomcat community was asked by Rory O'Donnell for feedback on
JDK 9 + Project Jigsaw. Having provided that feedback we were directed
here so I have reproduced that feedback below.
I've started testing Tomcat trunk with JDK 9 + Project Jigsaw and it
looks like we are going to hit a
On 22/09/2014 22:46, Xueming Shen wrote:
> On 09/22/2014 01:14 PM, Ivan Gerasimov wrote:
>> Hello!
>>
>> The UTF-8 encoding allows characters that are 4 bytes long.
>> However, CharsetEncoder.maxBytesPerChar() currently returns 3.0, which
>> is not always enough.
>>
>> Would you please review the s
On 22/09/2014 22:23, Martin Buchholz wrote:
> I think you are mistaken. It's maxBytesPerChar, not maxBytesPerCodepoint!
You are going to have to explain that some more. The Javadoc for
CharsetEncoder.maxBytesPerChar() is explicit:
Returns the maximum number of bytes that will be produced for each
All,
As you may know I am one of the Apache Tomcat committers. The Tomcat
project was approached recently[1] to see what, if any, internal APIs
Tomcat was using as part of the JDK 9 preparations.
My response was that the only place Tomcat does this is in the memory
leak prevention class [2]. I al
Hi,
I'm currently working on the implementation of the WebSocket
permessage-deflate extension for Apache Tomcat. I am using the JRE
provided classes java.util.zip.[Inflator|Defaltor] to do the compression
and decompression.
I have a working implementation but there is one feature I can't
implemen
On 09/04/2014 15:51, Xueming Shen wrote:
> Hi,
>
> Please help review the fix for JDK-8039751.
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8039751
> webrev: http://cr.openjdk.java.net/~sherman/8039751/webrev/
>
>
> This is the corner case (in 4 bytes sequence) we missed when fixing
20 matches
Mail list logo
