[Bug 56614] Add a switch to ignore annotations detection on tag instances for performance reason
https://issues.apache.org/bugzilla/show_bug.cgi?id=56614 --- Comment #8 from hzha...@ebay.com --- Created attachment 32032 --> https://issues.apache.org/bugzilla/attachment.cgi?id=32032&action=edit Document for this issue -- 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: [Bug 56739] Error response body generated only occasionally
On 18/09/2014 04:01, Violeta Georgieva wrote: > Hi, > > 2014-08-07 11:53 GMT+03:00 : >> >> https://issues.apache.org/bugzilla/show_bug.cgi?id=56739 >> >> Mark Thomas changed: >> >>What|Removed |Added >> > >> Component|Catalina|Catalina >> Version|8.0.9 |7.0.55 >> Product|Tomcat 8|Tomcat 7 >>Target Milestone||--- >> >> --- Comment #4 from Mark Thomas --- >> This has been fixed in 8.0.x for 8.0.11 onwards. >> >> I'm going to leave it a little while to give folks a chance to review the >> changes before back-porting it to 7.0.x. > > Can I port this to 7.0.x or we need more time for user feedback? Functionally, I'm happy with the back-port. I'm more concerned about API changes. The API changes are all to o.a.coyote.Response: 1. Remove field protected error 2. pubic void setError() -> public boolean setError() 3. Remove public boolean isErrorAfterCommit() 4. Add public boolean setErrorReported() These all fall under an area where we said we could change the API between point releases so I am leaning towards making the changes and if we get any complaints about breakage deal with them on a case by case basis. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
[Bug 56614] Add a switch to ignore annotations detection on tag instances for performance reason
https://issues.apache.org/bugzilla/show_bug.cgi?id=56614 --- Comment #9 from hzha...@ebay.com --- I just find that a "SimpleInstanceManager" has been integrated on the TRUNK. It seems that it has solved the problem. Would you please back-port it to 7.0.x? -- 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
svn commit: r1625938 - /tomcat/tc6.0.x/trunk/STATUS.txt
Author: kkolinko Date: Thu Sep 18 10:57:51 2014 New Revision: 1625938 URL: http://svn.apache.org/r1625938 Log: Comments Modified: tomcat/tc6.0.x/trunk/STATUS.txt Modified: tomcat/tc6.0.x/trunk/STATUS.txt URL: http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=1625938&r1=1625937&r2=1625938&view=diff == --- tomcat/tc6.0.x/trunk/STATUS.txt (original) +++ tomcat/tc6.0.x/trunk/STATUS.txt Thu Sep 18 10:57:51 2014 @@ -42,11 +42,28 @@ PATCHES PROPOSED TO BACKPORT: * Assert that MappingData object is empty before performing mapping work. It is backport of r1604663 + + Motivation: Remove dead branches. Protect Mapper from operating on + non-recycled MappingData. Using non-recycled MappingData might result in + mapping request onto a different target, like an issue that prevented us + from releasing 8.0.4 and fixed by r1580080/r1580083. I do not know such + bugs in Tomcat 6, but I want the code to be more safe. + Just a single (mappingData.host != null) check is enough to discern + recycled vs. non-recycled data. Checks for other MappingData fields are + removed by this patch, simplifying the code. + + A patch generated with "svn diff -x --ignore-space-change" for easier + overview of the change is + https://people.apache.org/~kkolinko/patches/2014-06-23_tc6_Mapper_diff-x-b.patch + https://people.apache.org/~kkolinko/patches/2014-06-23_tc6_Mapper.patch +1: kkolinko -1: * Fix generics warnings in Mapper. + + Motivation: Resolve IDE warnings to make it easier to spot more serious + errors when working on this class. It is just some local variables. No change in functionality or APIs. https://people.apache.org/~kkolinko/patches/2014-06-23_tc6_Mapper_generics.patch +1: kkolinko - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: adding an internal filter
changed to:
private void addFilterConfig(final Context context, final FilterDef filterDef) {
// hack to force filter to get a config otherwise it is
ignored in the http routing
try {
final Constructor cons =
ApplicationFilterConfig.class.getDeclaredConstructor(Context.class,
FilterDef.class);
if (!cons.isAccessible()) {
cons.setAccessible(true);
}
final ApplicationFilterConfig config =
cons.newInstance(context, filterDef);
((Map)
Reflections.get(context,
"filterConfigs")).put(filterDef.getFilterName(), config);
} catch (final Exception e) {
throw new IllegalStateException(e);
}
}
works fine even if not sexy
Thanks Konstantin for the feedback
Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau
2014-09-16 15:50 GMT+02:00 Romain Manni-Bucau :
> 2014-09-16 15:16 GMT+02:00 Konstantin Kolinko :
>> 2014-09-15 23:01 GMT+04:00 Romain Manni-Bucau :
>>> Hi guys,
>>>
>>> in TomEE I'd like to add a filter but after context filter are started
>>> (means filterStart() from StandardContext is called).
>>>
>>
>> Why? What is the use case?
>>
>
> we add a filter with a tomee service (passing after tomee started)
>
>> You code adds filter definitions. A filter definitions just associates
>> filter with a name. A filter is unreachable if it has no mappings for
>> it.
>> Where are filter mappings for your filter? How do you add filter mappings?
>>
>
> full code is:
>
> final FilterDef filterDef = new FilterDef();
> filterDef.setAsyncSupported("true");
> filterDef.setDescription(description);
> filterDef.setFilterName(description);
> filterDef.setDisplayName(description);
> filterDef.setFilter(new CXFJAXRSFilter(cxfRsHttpListener,
> context.findWelcomeFiles()));
> filterDef.setFilterClass(CXFJAXRSFilter.class.getName());
> context.addFilterDef(filterDef);
>
> String mapping = completePath;
> if (!completePath.endsWith("/*")) {
> if (completePath.endsWith("*")) {
> mapping = completePath.substring(0, completePath.length() -
> 1);
> }
> mapping = mapping + "/*";
> }
>
> final String urlPattern = removeWebContext(webContext, mapping);
> cxfRsHttpListener.setUrlPattern(urlPattern.substring(0,
> urlPattern.length() - 1));
>
> final FilterMap filterMap = new FilterMap();
> filterMap.addURLPattern(urlPattern);
> filterMap.setFilterName(filterDef.getFilterName());
> context.addFilterMap(filterMap);
>
> addFilterConfig(context, filterDef); // the hack I sent previously
>
>
>> When do you add your new filter? Is context already started and
>> serving requests, or it has not started yet? Why cannot you add
>> filter definition before a filterStart() call?
>>
>> Do you use "StandardContext" class directly, or you can subclass it?
>>
>
> directly, tomee doesn't change StandardContext (one big goal)
>
>> The proper solutions should be to add new API, but I would like the
>> answers on the above questions first, as
>> a) There shall be some API for filter mappings as well.
>> b) If context has already been started, implementation would be more
>> complicated.
>>
>>> What I do today is:
>>>
>>
>> Where do I start with this?
>>
>> Just several notes on the code.
>>
>> 1. Missing synchronization. filterStart() uses "synchronized
>> (filterConfigs)" Your code does not use synchronization.
>>
>
> Actually we don't care that much here since that's still in the start
> context (app is not yet fully usable) so multithreading shouldnt
> occur, does it in tomcat?
>
>> 2. If you using "setAccessible(true)",
>>
>> A simpler way would be to mark ApplicationFilterConfig constructor as
>> accessible and call it directly instead of playing with filterStart().
>>
>> Playing with filterStart() without accompanying filterStop() call is broken
>>
>> filterStart() does "filterConfigs.clear();" as one of the first steps.
>> A lot of code in your method are a workaround against that clear()
>> call. (You copy the filterConfigs into a temporary map to preserve the
>> map entries from being cleared). Essentially this clear() call throws
>> away filter instances (wrapped in ApplicationFilterConfig classes)
>> without properly destroying them.
>>
>> You code might break if "filterConfigs" field were marked as"final"
>> (as it should be).
>>
>
> we already got this before in webapp classloader and until tomcat
> supports our feature we forced by reflection the field to not be
> final. That said I agree (and why I ask for a simpler API) that it is
> mainly workarounds but I don't see why StandardContext is not exposing
> it (what would be blocking).
>
>>
>>
>>> try {
>>> final Field def =
>>> StandardContext.class.getD
[Bug 56994] New: REST Services not working inside war
https://issues.apache.org/bugzilla/show_bug.cgi?id=56994 Bug ID: 56994 Summary: REST Services not working inside war Product: Tomcat 8 Version: 8.0.12 Hardware: PC Status: NEW Severity: major Priority: P2 Component: Jasper Assignee: dev@tomcat.apache.org Reporter: wecu...@gmail.com Hi, RESTful services are not working inside WAR as usual if you modify your server.xml and set unpackWARs to FALSE. Tomcat fails to load/find the root classes -- 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
[Bug 56871] Apparent corruption of Servlet InputStreams
https://issues.apache.org/bugzilla/show_bug.cgi?id=56871
--- Comment #5 from Konstantin Kolinko ---
> I traced it as best I could, and it *seems* that the
> InternalNioInputBuffer$SocketInputBuffer is reading the data
> from the socket 'out of order' (very, very rarely)
>From EchoServlet.java
>if( !sb.toString().equals("a246722a276771371e1807a92f3bc86f") ) {
> System.err.println("Unexpected data value: \n"+ new
> String(bytes));
>}
1. I see that your code detects broken data by their MD5 digest and prints them
to System.err. Can you provide samples of such output? If data are read out of
order, it will be visible in the printed text.
> while( (len=sis.read(buffer, 0, 8*1024)) >0 ) {
2. Just as a note: My first impression was that I want ">=0" in the above line.
The end of data is signaled by value of "-1", not by 0.
On further reading of javadoc of InputStream.read(byte[]) I see that this
method has to block until at least one byte is read and is not allowed to
return "0".
3. ServletInputStream.read() is allowed to throw an IOException. E.g. it may
throw SocketTimeoutException.
>From client.js:
> var options = {
> ...
> headers: { "Content-Length": 3668}
>};
> ...
> req.write('Lorem ipsum dolor sit amet [...]
4. So I guess that it uses explicit Content-Length length and not chunked
transfer-encoding.
My text editor shows that "Lorem ipsum dolor" string is 3678 characters, not
3668.
--
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
[Bug 56871] Apparent corruption of Servlet InputStreams
https://issues.apache.org/bugzilla/show_bug.cgi?id=56871 --- Comment #6 from Konstantin Kolinko --- > My text editor shows that "Lorem ipsum dolor" string is 3678 characters, not > 3668. My miscalculation. The difference in values is due to \r\n characters. If I change the content-length value in client.js script, I get plenty of SocketTimeoutExceptions on console and in localhost.2014-09-19.log, so it confirms that those exceptions are rather visible. I am unable to reproduce this issue in my environment - Tomcat 7.0.55, configured Nio connector, removed AJP connector and AccessLogValve from configuration. Removed all standard applications except ROOT one. - Java 7u67 32-bit - nodejs 0.10.32 64-bit All running on the same Windows 7 machine. -- 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
[Bug 56995] New: Errors from servlet writer flush() causing threads in BLOCK state
https://issues.apache.org/bugzilla/show_bug.cgi?id=56995 Bug ID: 56995 Summary: Errors from servlet writer flush() causing threads in BLOCK state Product: Tomcat 7 Version: 7.0.55 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P2 Component: Connectors Assignee: dev@tomcat.apache.org Reporter: charles...@yahoo.com We are using tomcat 7.0.55 with bio connector. We are seeing threads go into bad BLOCKED state when client's throw IOException when trying to flush and the process tries to call setErrorState which then calls processSocketAsync. But processSocketAsync waits to hold a lock on the socket which previously held by the processor. Below is part of the stacktrace where it shows this. "http-bio-0.0.0.0-8042-exec-35" daemon prio=10 tid=0x03647000 nid=0x3605 waiting on condition [0x7f0e02d8c000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method) - parking to wait for <0x00073d3d20b0> (a com.google.common.util.concurrent.AbstractFuture$Sync) at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186) at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834) at java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:994) at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1303) at com.google.common.util.concurrent.AbstractFuture$Sync.get(AbstractFuture.java:285) at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:116) at com.yahoo.yql.plus.writer.ResultEnvelope.processResults(ResultEnvelope.java:140) at com.yahoo.yql.plus.writer.ResultEnvelope.write(ResultEnvelope.java:64) at com.yahoo.yql.plus.writer.ResultEnvelope.write(ResultEnvelope.java:57) at com.yahoo.yql.plus.ProgramEngine.write(ProgramEngine.java:247) at com.yahoo.yql.plus.ProgramEngine.execute(ProgramEngine.java:221) at com.yahoo.yql.plus.ProgramEngine.execute(ProgramEngine.java:263) at com.yahoo.yql.core.Container.executeProgramRequest(Container.java:340) at com.yahoo.yql.container.servlet.filter.DispatchFilter.doFilter(DispatchFilter.java:154) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at yjava.servlet.FilterChainInvoker$ServletFilterChainInvoker.invoke(FilterChainInvoker.java:49) at yjava.servlet.filter.YHdrsFilter.doFilter(YHdrsFilter.java:69) at yjava.servlet.filter.YHdrsFilter.doFilter(YHdrsFilter.java:53) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at yjava.servlet.FilterChainInvoker$ServletFilterChainInvoker.invoke(FilterChainInvoker.java:49) at yjava.cookie.CookieDataFilter.doFilter(CookieDataFilter.java:135) at yjava.cookie.CookieDataFilter.doFilter(CookieDataFilter.java:111) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at yjava.servlet.FilterChainInvoker$ServletFilterChainInvoker.invoke(FilterChainInvoker.java:49) at yjava.servlet.filter.SSLCrimeFilter.doFilter(SSLCrimeFilter.java:82) at yjava.servlet.filter.SSLCrimeFilter.doFilter(SSLCrimeFilter.java:47) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at yjava.servlet.FilterChainInvoker$ServletFilterChainInvoker.invoke(FilterChainInvoker.java:49) at yjava.servlet.filter.DoNotTrackFilter.doFilter(DoNotTrackFilter.java:110) at yjava.servlet.filter.DoNotTrackFilter.doFilter(DoNotTrackFilter.java:50) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at yjava.servlet.FilterChainInvoker$ServletFilterChainInvoker.invoke(FilterChainInvoker.java:49) at yjava.remote.ip.RemoteIPFilter.doFilter(RemoteIPFilter.java:104) at yjava.remote.ip.RemoteIPFilter.doFilter(RemoteIPFilter.java:65) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.c
[Bug 56995] Errors from servlet writer flush() causing threads in BLOCK state
https://issues.apache.org/bugzilla/show_bug.cgi?id=56995
--- Comment #1 from charlie ---
locks the socket here.
http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_55/java/org/apache/tomcat/util/net/JIoEndpoint.java
@Override
public void run() {
boolean launch = false;
synchronized (socket) {
try {
SocketState state = SocketState.OPEN;
client tries to flush but throws IOException
http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_55/java/org/apache/coyote/http11/AbstractHttp11Processor.java
case CLIENT_FLUSH: {
try {
getOutputBuffer().flush();
} catch (IOException e) {
setErrorState(ErrorState.CLOSE_NOW, e);
response.setErrorException(e);
}
break;
}
Calls setErrorState and which then calls processSocketAsync
/**
* Update the current error state to the new error state if the new error
* state is more severe than the current error state.
*/
protected void setErrorState(ErrorState errorState, Throwable t) {
boolean blockIo = this.errorState.isIoAllowed() &&
!errorState.isIoAllowed();
this.errorState = this.errorState.getMostSevere(errorState);
if (blockIo && !ContainerThreadMarker.isContainerThread()) {
// The error occurred on a non-container thread which means not all
// of the necessary clean-up will have been completed. Dispatch to
// a container thread to do the clean-up. Need to do it this way to
// ensure that all the necessary clean-up is performed.
if (response.getStatus() < 400) {
response.setStatus(500);
}
getLog().info(sm.getString("abstractProcessor.nonContainerThreadError"), t);
getEndpoint().processSocketAsync(socketWrapper,
SocketStatus.CLOSE_NOW);
}
}
Tries to hold the same lock here causing threads to be in bad BLOCKED states
which eventually make all available threads to hang.
http://svn.apache.org/repos/asf/tomcat/tc7.0.x/tags/TOMCAT_7_0_55/java/org/apache/tomcat/util/net/JIoEndpoint.java
@Override
public void processSocketAsync(SocketWrapper socket,
SocketStatus status) {
try {
synchronized (socket) {
if (waitingRequests.remove(socket)) {
--
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
[Bug 56995] Errors from servlet writer flush() causing threads in BLOCK state
https://issues.apache.org/bugzilla/show_bug.cgi?id=56995 --- Comment #2 from charlie --- Please let me know if you need any other information. Thank you. -- 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
