https://issues.apache.org/bugzilla/show_bug.cgi?id=44454
--- Comment #26 from feizheng ---
Created attachment 28807
--> https://issues.apache.org/bugzilla/attachment.cgi?id=28807&action=edit
Mod_jk scheduling errors
--
You are receiving this mail because:
You are the assignee for the bug.
[
https://issues.apache.org/jira/browse/MTOMCAT-156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter lynch updated MTOMCAT-156:
Attachment: exec-war-any-packaging.patch
attached patch
> exec-war should allow c
Peter lynch created MTOMCAT-156:
---
Summary: exec-war should allow creation of exec-war in projects
with any packaging type
Key: MTOMCAT-156
URL: https://issues.apache.org/jira/browse/MTOMCAT-156
Project:
[
https://issues.apache.org/jira/browse/MTOMCAT-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter lynch updated MTOMCAT-155:
Attachment: warRunDependency-in-current-execution.patch
attached patch
> allow ex
Peter lynch created MTOMCAT-155:
---
Summary: allow exec-war war run dependencies that are generated in
current mvn execuion, but not yet installed to maven repo
Key: MTOMCAT-155
URL: https://issues.apache.org/jira/bro
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 gene...@gump.apache.org.
Project tomcat-trunk-test has an issue affecting its community integration.
This i
[
https://issues.apache.org/jira/browse/MTOMCAT-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter lynch updated MTOMCAT-154:
Attachment: support-warRunDependency-classifier.patch
attached patch
> support ex
Peter lynch created MTOMCAT-154:
---
Summary: support exec-war war run dependencies with classifiers
Key: MTOMCAT-154
URL: https://issues.apache.org/jira/browse/MTOMCAT-154
Project: Apache Tomcat Maven Plug
[
https://issues.apache.org/jira/browse/MTOMCAT-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter lynch updated MTOMCAT-153:
Attachment: align-maven-versions.patch
Attached patch
> align all Maven dependenc
Peter lynch created MTOMCAT-153:
---
Summary: align all Maven dependency versions to 2.0.11
Key: MTOMCAT-153
URL: https://issues.apache.org/jira/browse/MTOMCAT-153
Project: Apache Tomcat Maven Plugin
Author: kkolinko
Date: Sun May 20 22:50:12 2012
New Revision: 1340864
URL: http://svn.apache.org/viewvc?rev=1340864&view=rev
Log:
Update external:
Fix unused imports to make checkstyle happy.
Modified:
tomcat/tc7.0.x/trunk/modules/ (props changed)
Propchange: tomcat/tc7.0.x/trunk/modules/
Author: kkolinko
Date: Sun May 20 22:33:42 2012
New Revision: 1340861
URL: http://svn.apache.org/viewvc?rev=1340861&view=rev
Log:
Fix unused imports to make checkstyle happy.
Modified:
tomcat/trunk/modules/jdbc-pool/src/test/java/org/apache/tomcat/jdbc/test/PoolPurgeTest.java
Modified:
tom
On 05/20/2012 08:37 PM, Mark Thomas wrote:
Therefore, I intend modifying the APR/native code to support per socket
time outs. I would be grateful if those of you with more C knowledge
than I (which is most people on this list) could:
a) tell me now if this is a crazy idea (and why)
b) keep an ext
> That is what we do currently. I'm not convinced that is a scalable long
> term solution as the number of things that need different time outs
> increases.
Main question is :
What will be the faster to handle ?
A table of pollsets and associate sockets to them (ie: 30s, 60s, 120s,
infinite) or
On 20/05/2012 19:46, Henri Gomez wrote:
> And what about using pollsets with specific timeout and associate sockets to
> pollset according to their timeout needs ?
That is what we do currently. I'm not convinced that is a scalable long
term solution as the number of things that need different tim
On 20/05/2012 19:44, Henri Gomez wrote:
> Did there is a need to have sockets with differents timeout in day to day
> case ?
So far, no. The requirements could be met by three pollsets. One for new
connections, one for keep-alive connections and one for WebSocket
connections.
My concern is that
And what about using pollsets with specific timeout and associate sockets to
pollset according to their timeout needs ?
Just an idea.
Le 20 mai 2012 à 20:37, Mark Thomas a écrit :
> Currently, time outs for APR/native sockets are managed at the Pollset
> level. This means all sockets in a sin
Did there is a need to have sockets with differents timeout in day to day case ?
For example did it is required by specs or API ?
The finer, the better but only if there is a real need :-)
Btw, i'll take a look to your commits.
Le 20 mai 2012 à 20:37, Mark Thomas a écrit :
> Currently, time
Currently, time outs for APR/native sockets are managed at the Pollset
level. This means all sockets in a single Pollset must have the same
time out. This is starting to become a nuisance.
I have already had to add a second Pollset to AprEndpoint to handle
separate connection and keep-alive time o
https://issues.apache.org/bugzilla/show_bug.cgi?id=53266
Priority: P2
Bug ID: 53266
Assignee: dev@tomcat.apache.org
Summary: ServletContainerInitializer will crash catalina if
dependcy is not present.
Severity: minor
Clas
https://issues.apache.org/bugzilla/show_bug.cgi?id=53074
--- Comment #5 from huck ---
Hi,
+1 here for the option of configuring the timeout. My application requires an
infinite connection which will be closed when required. I was negatively
suprised to see tomcat has such a short timeout option.
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
+---+
| Bugzilla Bug ID |
| +-+
| | Status: UNC=Unconfirmed NEW=New ASS=Assigned
28 matches
Mail list logo
