[
https://issues.apache.org/jira/browse/SYNAPSE-287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12598318#action_12598318
]
Jake Lambert commented on SYNAPSE-287:
--------------------------------------
Actually, I can consistently reproduce this HTTP-NIO lockup by sending larger
messages (> 300KB - both with and without attachments) *and* >50 threads of
concurrency using SoapUI as a client. I'm directing the messages through a
simple forwarding proxy service. This happens for me on both Windows and Linux
(Red-Hat and Ubuntu) platforms, both tuned and not.
After a lot of investigation, here's what I've found:
- each of the transport receiver I/O dispatcher threads can block writing to
the request pipe sink in ServerHandler's inputReady() method when there are no
ServerWorker processing threads left
- the block occurs because the pipe's sink can only buffer a limited number of
bytes until a ServerWorker thread is actively reading from the pipe's source
- a blocked I/O dispatcher thread stops all incoming reads from the client and
writes back to the client for its associated connections
- as more requests come in with no free ServerWorker threads, more of the
incoming I/O dispatcher threads are blocked until they are *all* permanently
blocked
- the ServerWorker threads are all blocked either waiting for a free
ClientWorker thread or blocked waiting for more input from the client (because
the incoming mediation can be complete before a request has been fully read
from the incoming socket - this is where I think the larger messages come into
play)
- the ClientWorker threads are all busy waiting to send to their responses back
to the client (as previously mentioned, the socket writes back to the client
have been for all I/O dispatcher threads)
- there's no way out of the situation, so Synapse is effectively disabled. As
you can see, increasing the number of I/O dispatchers and worker threads can
only delay and not fix the problem.
Since ClientHandler's inputReady() can also block in this way, it probably
should be fixed also.
> An Invalid configuration can lead to lockup
> -------------------------------------------
>
> Key: SYNAPSE-287
> URL: https://issues.apache.org/jira/browse/SYNAPSE-287
> Project: Synapse
> Issue Type: Bug
> Components: Transports
> Affects Versions: 1.1.1
> Environment: Windows XP SP2, JDK SUN 1.5.0_15
> Ubuntu Server 6.10, JDK SUN 1.5.0_15
> Reporter: Nicolas KOHUT
> Assignee: Asankha C. Perera
> Priority: Minor
> Attachments: 10000_gros_message_KO_CPU.JPG, full_Linux.JPG,
> GipMock.war, read_time_out.JPG, synapse.xml, test de perf.jmx,
> too_main_files.JPG
>
>
> Synapse has some networks problems.
> When it is stressed, is freeze synapse in transport http.
> This behavior is obtained by influencing 2 parameters:
> - the number of competitors access (number of thread).
> - the size of messages sent.
>
> More generally, the higher the speed is high (combination of 2 parameters
> above) synapse freezes more quickly.
> A simple test case (using JMeter):
> - Install distribution synapse-1.1.1 default.
> - Setting up a proxy with sequences in and out empty.
> - Launch a thread (1 single thread is sufficient ...) which calls the proxy
> with a message 6Ko infinite loop. The thread sits 100 ms between each call.
> Synapse must freeze (random) after about 2 000 calls (5 max 000).
> The freeze takes place at a rate of 7 messages (6Ko) per second ...
>
> The only configuration synapse that I could find is the file in the folder
> synapse.properties Conf of synapse.
> This file can affect a pool of thread used by synapse. Increase the various
> parameters of the pool has no impact and does not correct the problem.
> Listed JVM, jconsole indicates that there is no leakage and no memory thread
> in deadlock.
> Finally, the synapse approved http requests with nio-http (I do not know
> more).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
