headers
Bill Barker | 1 May 2012 06:59
Picon
Favicon

[GUMP <at> vmgump]: Project tomcat-tc7.0.x-test (in module tomcat-7.0.x) failed

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at general <at> gump.apache.org.

Project tomcat-tc7.0.x-test has an issue affecting its community integration.
This issue affects 1 projects.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
    - tomcat-tc7.0.x-test :  Tomcat 7.x, a web server implementing Java Servlet 3.0,
    ...

Full details are available at:
    http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Dependency on tomcat-tc7.0.x-dbcp exists, no need to add for property tomcat-dbcp-src.jar.
 -DEBUG- Dependency on commons-daemon exists, no need to add for property commons-daemon.native.src.tgz.
 -DEBUG- Dependency on commons-daemon exists, no need to add for property tomcat-native.tar.gz.
 -DEBUG- Dependency on tomcat-tc7.0.x-dbcp exists, no need to add for property tomcat-dbcp.home.
 -INFO- Failed with reason build failed
 -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-7.0.x/output/build/logs

The following work was performed:
http://vmgump.apache.org/gump/public/tomcat-7.0.x/tomcat-tc7.0.x-test/gump_work/build_tomcat-7.0.x_tomcat-tc7.0.x-test.html
Work Name: build_tomcat-7.0.x_tomcat-tc7.0.x-test (Type: Build)
Work ended in a state of : Failed
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill Barker | 1 May 2012 07:27
Picon
Favicon

[GUMP <at> vmgump]: Project tomcat-trunk-test (in module tomcat-trunk) failed

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at general <at> gump.apache.org.

Project tomcat-trunk-test has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 2 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
    - tomcat-trunk-test :  Tomcat 8.x, a web server implementing Java Servlet 3.1,
    ...

Full details are available at:
    http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were provided:
 -DEBUG- Dependency on tomcat-trunk-dbcp exists, no need to add for property tomcat-dbcp-src.jar.
 -DEBUG- Dependency on commons-daemon exists, no need to add for property commons-daemon.native.src.tgz.
 -DEBUG- Dependency on commons-daemon exists, no need to add for property tomcat-native.tar.gz.
 -DEBUG- Dependency on tomcat-trunk-dbcp exists, no need to add for property tomcat-dbcp.home.
 -INFO- Failed with reason build failed
 -INFO- Project Reports in: /srv/gump/public/workspace/tomcat-trunk/output/build/logs

The following work was performed:
http://vmgump.apache.org/gump/public/tomcat-trunk/tomcat-trunk-test/gump_work/build_tomcat-trunk_tomcat-trunk-test.html
Work Name: build_tomcat-trunk_tomcat-trunk-test (Type: Build)
(Continue reading)

Permalink | Reply | 0 comments |
headers
olamy | 1 May 2012 09:14
Picon
Favicon
Gravatar

svn commit: r1332541 - /tomcat/maven-plugin/trunk/pom.xml

Author: olamy
Date: Tue May  1 07:14:43 2012
New Revision: 1332541

URL: http://svn.apache.org/viewvc?rev=1332541&view=rev
Log:
compiler plugin 2.4 which is faster for multi modules

Modified:
    tomcat/maven-plugin/trunk/pom.xml

Modified: tomcat/maven-plugin/trunk/pom.xml
URL: http://svn.apache.org/viewvc/tomcat/maven-plugin/trunk/pom.xml?rev=1332541&r1=1332540&r2=1332541&view=diff
==============================================================================
--- tomcat/maven-plugin/trunk/pom.xml (original)
+++ tomcat/maven-plugin/trunk/pom.xml Tue May  1 07:14:43 2012
 <at>  <at>  -508,7 +508,7  <at>  <at> 
         </plugin>
         <plugin>
           <artifactId>maven-compiler-plugin</artifactId>
-          <version>2.3.2</version>
+          <version>2.4</version>
           <configuration>
             <encoding>${project.build.sourceEncoding}</encoding>
             <source>${maven.compiler.source}</source>
Permalink | Reply | 0 comments |
headers
bugzilla | 1 May 2012 11:35
Picon
Favicon

[Bug 53169] New: [patch] don't do chunking with Connection: close

https://issues.apache.org/bugzilla/show_bug.cgi?id=53169

          Priority: P2
            Bug ID: 53169
          Assignee: dev <at> tomcat.apache.org
           Summary: [patch] don't do chunking with Connection: close
          Severity: minor
    Classification: Unclassified
                OS: All
          Reporter: kustos <at> gmx.net
          Hardware: All
            Status: NEW
           Version: trunk
         Component: Catalina
           Product: Tomcat 7

Created attachment 28702
  --> https://issues.apache.org/bugzilla/attachment.cgi?id=28702&action=edit
patch against trunk

The attached patch disables chunking on if there is a Connection: close header,
we're on HTTP 1.1 and there's no Content-Length header.

This helps to implement Server-Sent Events [1]. Server-Sent Event are
conceptually similar to the forever streaming iframe in the sense that there's
an "infinite" response from the server that always gets updated. But they're
easier to use and with less issues. They are also easier to use than WebSockets
if you don't need a back channel.

The specification reccoments to disable chunking. Jetty implements the same
(Continue reading)

Permalink | Reply | 2 comments |
headers
bugzilla | 1 May 2012 12:58
Picon
Favicon

[Bug 53171] New: Deadlock under Java 7 / DefaultInstanceManager

https://issues.apache.org/bugzilla/show_bug.cgi?id=53171

          Priority: P2
            Bug ID: 53171
          Assignee: dev <at> tomcat.apache.org
           Summary: Deadlock under Java 7 / DefaultInstanceManager
          Severity: normal
    Classification: Unclassified
                OS: Linux
          Reporter: al.lias <at> gmx.de
          Hardware: PC
            Status: NEW
           Version: 7.0.27
         Component: Catalina
           Product: Tomcat 7

Created attachment 28703
  --> https://issues.apache.org/bugzilla/attachment.cgi?id=28703&action=edit
Changing the Hashmap by Collections.synchonizedMap()

Not sure if it is java 7 related, but I had repeatetly that deadlock when I got
the srver under some load. A simple replacement of the HashMap by a synchonized
one did help (patch attached); but I dont know if that is a good solution as I
dont get the idea of the AnnotationCache.

http-apr-80-exec-348" daemon prio=10 tid=0x00007f4f64da9000 nid=0x6306 waiting
for monitor entry [0x00007f4f46cd7000]
   java.lang.Thread.State: BLOCKED (on object monitor)
    at
org.apache.catalina.core.DefaultInstanceManager.populateAnnotationsCache(DefaultInstanceManager.java:256)
(Continue reading)

Permalink | Reply | 1 comment |
headers
bugzilla | 1 May 2012 15:54
Picon
Favicon

[Bug 53173] New: maxConnections feature hangs the system

https://issues.apache.org/bugzilla/show_bug.cgi?id=53173

          Priority: P2
            Bug ID: 53173
          Assignee: dev <at> tomcat.apache.org
           Summary: maxConnections feature hangs the system
          Severity: normal
    Classification: Unclassified
          Reporter: fhanik <at> apache.org
          Hardware: PC
            Status: NEW
           Version: 7.0.27
         Component: Connectors
           Product: Tomcat 7

Created attachment 28704
  --> https://issues.apache.org/bugzilla/attachment.cgi?id=28704&action=edit
fix missing count down for maxConnections latch

We've run into a scenario where the JIO Acceptor thread hangs as connections
are not counted down properly.

<Executor name="tomcatThreadPool" 
          namePrefix="tomcat-8080-" 
          minSpareThreads="50" 
          maxThreads="300"/>

<Connector port="8080" 
           redirectPort="${bio.https.port}"              
           protocol="org.apache.coyote.http11.Http11Protocol"
(Continue reading)

Permalink | Reply | 7 comments |
headers
bugzilla | 1 May 2012 15:58
Picon
Favicon

[Bug 53174] New: JIO default maxConnections is not a good default

https://issues.apache.org/bugzilla/show_bug.cgi?id=53174

          Priority: P2
            Bug ID: 53174
          Assignee: dev <at> tomcat.apache.org
           Summary: JIO default maxConnections is not a good default
          Severity: normal
    Classification: Unclassified
          Reporter: fhanik <at> apache.org
          Hardware: PC
            Status: NEW
           Version: 7.0.27
         Component: Connectors
           Product: Tomcat 7

http://svn.apache.org/viewvc?view=revision&revision=1099855

This feature automatically sets maxConnections to maxThreads. It has a negative
effect for the following reasons

1. It completely changes behavior from Tomcat 6 to 7, and unless one reads the
fine print, one will never find out

2. In servlet 3.0, with the introduction of async servlets, there is a way to
keep a connection open without having a worker thread associated with it.

For case 2. the system SHOULD be able to handle this type of usage through its
default configuration. 

Reverting this fix, and correcting the documentation has no foreseeable impact
(Continue reading)

Permalink | Reply | 2 comments |
headers
bugzilla | 1 May 2012 16:09
Picon
Favicon

[Bug 53174] JIO default maxConnections is not a good default

https://issues.apache.org/bugzilla/show_bug.cgi?id=53174

Mark Thomas <markt <at> apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 OS|                            |All

--- Comment #1 from Mark Thomas <markt <at> apache.org> ---
Read the following for background:
http://tomcat.markmail.org/thread/wmirgjskvkm4x52k

re point 1 - r1099855 should ensure that the behaviour is the same for both
Tomcat 6 and Tomcat 7.

re point 2 - That is true for write but not true for read. With maxConnections
> maxThreads and blocking IO there is always the risk that a connection with
data to read is unable to acquire a thread while all threads are tied up by
connections without data to read.

Reverting the fix has significant impact since it opens up the risk of problems
as described in the thread from a year ago.

With the increasing move towards async, there is an increasinglg strong
argument for making NIO rather than BIO the default and potentially going as
far as dropping the BIO connector all together but that is a debate that
belongs on the dev list not on this issue.

--

-- 
You are receiving this mail because:
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla | 1 May 2012 16:57
Picon
Favicon

[Bug 53174] JIO default maxConnections is not a good default

https://issues.apache.org/bugzilla/show_bug.cgi?id=53174

Filip Hanik <fhanik <at> apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #2 from Filip Hanik <fhanik <at> apache.org> ---
(In reply to comment #1)
> 
> With the increasing move towards async, there is an increasinglg strong
> argument for making NIO rather than BIO the default and potentially going as
> far as dropping the BIO connector all together but that is a debate that
> belongs on the dev list not on this issue.

Agreed.

--

-- 
You are receiving this mail because:
You are the assignee for the bug.
Permalink | Reply | 0 comments |
headers
Christopher Schultz | 1 May 2012 17:04

Re: Duplicate String values

Konstantin,

On 4/28/12 8:58 PM, Konstantin Kolinko wrote:
> 2012/4/27 Christopher Schultz <chris <at> christopherschultz.net>:
>> All,
>>
>> I've been doing some memory profiling on my webapp to see where I can
>> reduce our memory footprint a bit by combining equivalent objects.
>> YourKit has some nice utilities to look for duplicate objects --
>> especially Strings.
>>
>> I can see that the string "java.lang.String" has lots of duplicates.
>> Many of the ones I've inspected so far can be traced-back to
>> catalina.mbeans.MBeanUtils and the registry of MBeans that it contains.
>>
>> Would anyone object to using String-interning to share copies of class
>> names for MBeans? I could even restrict such interning to Strings that
>> start with "java.lang" since those are probably the most-used ones, and
>> those strings are probably already interned by all the RTTI
>> infrastructure in the JVM anyway.
> 
> I think that the string returned by class.getName() as well as field
> and method names should be already interned by JVM.
> 
> So instead of String.intern() it should be possible to call class.getName(). :/

That's what I would have expected, but I can see logs of duplicate
String values (like "java.lang.String" for instance), many linked from
JMX beans. I haven't looked at the code, but I'll bet the string values
from directly from the XML files and aren't resolved against actually
(Continue reading)

Permalink | Reply | 1 comment |

Gmane