om class loader. Is there any
other way to make this work?
Thanks,
Chirag
On Thu, Jul 23, 2020 at 11:32 PM Chirag Dewan
wrote:
> Hey Mark,
>
> Any clues, how to proceed with this for embedded?
>
> Thanks
> Chirag
>
>
> On Wed, 22 Jul, 2020, 7:31 pm Chirag Dewan,
&
Hey Mark,
Any clues, how to proceed with this for embedded?
Thanks
Chirag
On Wed, 22 Jul, 2020, 7:31 pm Chirag Dewan,
wrote:
> I tried that with standalone Tomcat and it works. I can deploy Jersey-1
> and Jersey-2 apps together.
>
> I was wondering whether Loader with delegate=f
I tried that with standalone Tomcat and it works. I can deploy Jersey-1 and
Jersey-2 apps together.
I was wondering whether Loader with delegate=false work in context for
embedded?
Thanks
Chirag
On Wed, 22 Jul, 2020, 5:03 pm Mark Thomas, wrote:
> On 22/07/2020 11:35, Chirag Dewan wr
Thanks for a very quick reply Mark.
The Tomcat version is 8.5.46.
Though I do plan to upgrade to 9.0.36 in the coming weeks.
Chirag
On Wed, 22 Jul, 2020, 4:03 pm Mark Thomas, wrote:
> On 22/07/2020 11:18, Chirag Dewan wrote:
> > Hi,
> >
> > Due to some backward compatibi
gh it says that the order of loading
JavaEE classes is bootstrap first, it never says anything about WEB-INF as
a source for these jars.
So if there any way I can load javax.* classes from WEB-INF\lib?
Thanks in advance
Chirag
Thanks a lot, Mark.
https://ibb.co/LgzFh6t - Memory snapshot after 15minutes of the test.
It's certainly better than the graph with 9.0.36, but I will wait for this
test to run for another few hours. I will update later.
Cheers,
Chirag
On Fri, Jun 26, 2020 at 6:20 PM Mark Thomas wrote:
Absolutely Mark. Shouldn't take long.
On Fri, 26 Jun, 2020, 4:16 pm Mark Thomas, wrote:
> Aha!
>
> h2c could be the significant factor here. Let me take a look.
>
> Are you in a position to test against a dev build if the need arises?
>
> Mark
>
>
> On 2
long does a single request take to process?*
In normal scenarios, less than 3ms.
Thanks,
Chirag
On Fri, Jun 26, 2020 at 3:26 PM Mark Thomas wrote:
> Hi,
>
> Thanks for the additional information. The GC roots were particularly
> informative.
>
> Those RequestInfo objects are as
u to
> experiment with.
>
> Some additional questions that might aid understanding:
>
> - What is the typical response size for one of these requests?
> - How long does a typical test take to process?
> - What are the GC roots for those RequestInfo objects?
>
> Thank
Hi Mark,
Its the default APR connector with 150 Threads.
Chirag
On Thu, 25 Jun, 2020, 7:30 pm Mark Thomas, wrote:
> On 25/06/2020 11:00, Chirag Dewan wrote:
> > Thanks for the quick check Mark.
> >
> > These are the images I tried referring to:
> >
> > htt
Thanks for the quick check Mark.
These are the images I tried referring to:
https://ibb.co/LzKtRgh
https://ibb.co/2s7hqRL
https://ibb.co/KmKj590
The last one is the MAT screenshot showing many RequestInfo objects.
Thanks,
Chirag
On Wed, Jun 24, 2020 at 8:30 PM Mark Thomas wrote:
>
uch a situation. Thanks in
advance.
On Sun, Jun 14, 2020 at 11:30 AM Chirag Dewan
wrote:
> Hi,
>
> This is without load balancer actually. I am directly sending to Tomcat.
>
> Update:
>
> A part issue I found was to be 9.0.29. I observed that when request were
> timed
:42 schrieb Chirag Dewan:
> > Hi,
> >
> > We are observing that under high load, my clients start receiving a
> GoAway
> > frame with error:
> >
> > *Connection[{id}], Stream[{id}] an error occurred during processing that
> > was fatal to the connection.*
>
Hi,
We are observing that under high load, my clients start receiving a GoAway
frame with error:
*Connection[{id}], Stream[{id}] an error occurred during processing that
was fatal to the connection.*
Background : We have implemented our clients to close connections after
every 500-1000 requests
).
And even in such kind of a connection strategy, we see ~6K around
throughput. And to my surprise, even with 20 established connections, we
could not reach the throughput in an HTTP1.1 connector.
Are there any benchmarking results for HTTP2, in comparison to HTTP1.1 I
can refer?
Chirag
On Fri, May
BLOCKED threads:
[image: image.png]
Most of the threads are blocked in *writeHeaders. *
Am I missing something here? Any help is much appreciated.
Thank you
Chirag
Hi Mark,
Thanks for the quick update. That would work.
Thank you,
Chirag
On Wed, 15 Apr, 2020, 1:00 PM Mark Thomas, wrote:
> On 15/04/2020 06:32, Chirag Dewan wrote:
> > Hi,
> >
> > I have a Jersey application deployed on an Embedded Tomcat 9.0.29. I have
> > ena
coyoteRequest - org.apache.coyote.Request
has only HTTP1.1 headers and skips HTTP2 headers.
Although I know that I can probably use coyoteRequest to get the URL, path
and other pseudo header details, but is there any other way to get the
pseudo headers like other HTTP1.1 headers?
Thanks,
Chirag
closed by the server.
And second request onwards handshaking happens again.
Appreciate all of you for your help.
Chirag.
Sent from Yahoo! Mail on Android
Hi ,
A small update. The customers client is C++ client,which uses OpenSSL. And I
found that client hello message is SSLv2 protocol. And the server
response(server hello) is a TLSv1 protocol. Is there something I am missing?
Chirag
On Wednesday, 9 October 2013 9:25 PM, Chirag Dewan
wrote
Chris,
This is a legacy code and do need some tweaks for sure.
Regarding the issue,for some other Cipher as well the handshaking is failing. I
get a TCP_ZERO_WINDOW in my snoops. And thus resulting in Server sending a RST
to client.
Chirag
Sent from Yahoo! Mail on Android
( "Exception occurred while enabling lookups. "
);
}
}
and I attach it to the container by :
Embedded embedded = new Embedded();
embedded.addConnector( connector );
connector.start();
and I call embedded.start(); during intialization,so I have the Tomca
tion. I am now setting cipher,as you can see. And
it is selecting the specified cipher,so that way I can limit the cipher sets to
be selected by Server.
On Wednesday, 9 October 2013 5:45 PM, Christopher Schultz
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Chirag,
On 10/8/13 9:48 PM
Hi Chris,
Thanks for the code,it helped a lot.
Now,using that code on my server machine I found out that
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA is not even in the defaults ciphers for
jdk1.6.0_39. Isn't this a strange behaviour? Server can only select available
ciphers,I suppose.
Thanks
C
connector and the
client will select from that particular set and can thus avoid the particular
cipher. Can I do this in embedded tomcat? And what set of ciphers should I
allow with that connector?
Thanks!
Chirag
Sent from Yahoo! Mail on Android
cypher suite? Or any
other way that I can resolve this issue.
Thanks a lot.
Chirag Dewan
ocket.connect(localInetSocketAddress2, i);
return localSocket;
}
Can different sockets create different sessions?
So for HTTP I am not creating any new sessions,same should be the case for
HTTPS. Right?
The only thing which differs in my is the SSLSocketFactory Implem
ketFactory(trustStore);
Scheme sch = new Scheme("https", port, socketFactory);
pm.getSchemeRegistry().register(sch);
Chirag
From: "Caldarale, Charles R"
To: Tomcat Users List
Sent: Wednesday, 12 June 2013 11:18
100 simultaneous threads.
Both my server and clients are on Linux 64 bit machines.
I believe that this is something related to the client 1 i.e. either the
HTTPClient 3.1 or the MultiThreadedConnectionManager,but posting here if
someone can assist me in what might be the root cause.
Chirag
Chris,
Sorry I should have posted the data first. I probably missed the most important
part of a load test. I will do it shortly.
And I am not using Jmeter now,I am using an http client for load test. I am
testing it on Solaris x86 server 64bit JVM. And i have collected the samples
for Tomcat
ist
Sent: Friday, 24 May 2013 3:24 AM
Subject: Re: Performance Issue while upgrading from Embedded Tomcat 6 to Tomcat
7
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Chirag,
On 5/23/13 1:21 PM, Chirag Dewan wrote:
> With c=1 it is 70k req/sec and with c=2 it is 35k in both i.e the
&g
Chris,
With c=1 it is 70k req/sec and with c=2 it is 35k in both i.e the total req/sec
cannot be scaled beyond 70k. With Tomcat 6 it is 60k in both clients i.e total
of 120k.
I do not expect more than 75k req/sec being served by Tomcat 7,but its the
benchmark set by Tomcat 6 which I can't over
: SHA256
Chirag,
On 5/21/13 11:03 PM, Chirag Dewan wrote:
> I was monitoring the CPU utilization specifically. I can
> compromise on 1 less transactions/sec,but 80-90% utilization is
> not good.
While it's nice to reduce resource utilization as much as possible,
why would you want
PGP SIGNED MESSAGE-
Hash: SHA256
Chirag,
On 5/21/13 11:03 PM, Chirag Dewan wrote:
> I was monitoring the CPU utilization specifically. I can
> compromise on 1 less transactions/sec,but 80-90% utilization is
> not good.
While it's nice to reduce resource utilization as mu
Yes. With same JVM on both Solaris and Linux i.e Java 1.6.39. It is 64 bit
version.
Thanks.
Sent from Yahoo! Mail on Android
.
From: Christopher Schultz
To: Tomcat Users List
Sent: Tuesday, 21 May 2013 9:08 PM
Subject: Re: Performance Issue while upgrading from Embedded Tomcat 6 to Tomcat
7
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Chirag,
On 5/20/13 10:38 AM, Chirag Dewan
?
Thanks.
From: Chirag Dewan
To: Tomcat Users List
Sent: Monday, 20 May 2013 8:08 PM
Subject: Re: Performance Issue while upgrading from Embedded Tomcat 6 to Tomcat
7
I ran my test client on Hello World example servlet on Tomcat 7.0.30. It was
12K req/sec
: Performance Issue while upgrading from Embedded Tomcat 6 to Tomcat
7
On 20/05/2013 06:59, Chirag Dewan wrote:
> Hi,
>
> I have profiled the application using JProfiler,and it seems to me
> that its my servlet which is taking the majority of time.
>
>
> Though the time i
throughput?
Thanks.
From: Chirag Dewan
To: "users@tomcat.apache.org" ; "ma...@apache.org"
Sent: Friday, 17 May 2013 6:30 PM
Subject: Re: Performance Issue while upgrading from Embedded Tomcat 6 to Tomcat
7
I am running it on Solaris x
I am running it on Solaris x86 server. I haven't even changed my code much.
Let me add a profiler,will post the results.
Thanks.
Sent from Yahoo! Mail on Android
Another important factor is the CPU utilization. Earlier for same trans/sec it
was 40% now its close to 80%.
And yes,the OS,JVM and memory setting are unchanged.
Thanks.
Sent from Yahoo! Mail on Android
I am comparing tomcat 6.0.18 with tomcat 7.0.30.
Would adding NIO or APR connector help? Currently I am using default(BIO)
connector.
Thanks.
Sent from Yahoo! Mail on Android
Hi All,
I have upgraded my application from Embedded Tomcat 6 to Embedded Tomcat 7.
With Tomcat 6, I was getting around 7 Transactions per sec with a simple
HTTP service,which sets the HTTPResponse and returns it.
Now with Tomcat 7,I am getting 54000 transactions per sec. Going through th
__
From: Mark Thomas
To: Tomcat Users List
Sent: Thursday, 16 May 2013 3:04 PM
Subject: Re: Embedded Tomcat 7 SSL Properties
On 16/05/2013 04:09, Chirag Dewan wrote:
>
>
> Sorry for the previous mail. Adding Subject.
>
> - Forwarded Message
Sorry for the previous mail. Adding Subject.
- Forwarded Message -
From: Chirag Dewan
To: Tomcat Users List
Sent: Thursday, 16 May 2013 8:37 AM
Subject:
Hi All,
I am upgrading my Embedded Tomcat 6 to Tomcat 7. I am adding an HTTPS connector
to my service.
Code for Tomcat 6
ent: Tuesday, 14 May 2013 2:41 AM
Subject: Re: Port still busy after removing connector in Embedded Tomcat 7.0.30
On 13/05/2013 16:34, Chirag Dewan wrote:
> Hi,
>
> I am embedding Apache Tomcat 7.0.30 in my application. I am using the Tomcat
> class,and my application requires dynam
Monday, 13 May 2013 10:13 PM
Subject: Re: Port still busy after removing connector in Embedded Tomcat 7.0.30
Chirag Dewan wrote:
>> How do you observe that the connector is still bound to the port?
>
> Yes. I used netstat to observe that. Plus when I try to add another context
&
edded Tomcat 7.0.30
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Chirag,
On 5/13/13 11:34 AM, Chirag Dewan wrote:
> I am embedding Apache Tomcat 7.0.30 in my application. I am using
> the Tomcat class,and my application requires dynamic addition and
> removal of connectors(HTTP).
Hi,
I am embedding Apache Tomcat 7.0.30 in my application. I am using the Tomcat
class,and my application requires dynamic addition and removal of
connectors(HTTP).
Now while removing the connectors,the application gets undeployed but the port
remains occupied and the connector continue to li
request.
Remote attackers could exploit the vulnerability to cause an OutOfMemory
error and crash the server.
Will you be able to provide a patch or it’s already there then can you
please point down there?
Thanks and Regards,
Chirag
internals we can not build Or trim in regular
Tomcat to save more, if any ?
Thanks for your help.
Thanks,
Chirag
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
51 matches
Mail list logo
