> seems like you have installed the proxy filter before the ssl filter in
> your chain. Can you do the opposite ?
I don't build the chain manually, I simply use a "ProxyConnector" (from package
"org.apache.mina.proxy")
to make a proxy connection (this also explains, why I had the
> Ok, but you can insert teh SslFilter *before* the proxyFilter. Once you
> get the ProxyConnector instance, get the connector and do :
Well, I am using a patched QuickFixJ version, in which the control flow is a
bit different.
Here is an excerpt from the code they are using:
If you look at the stacktraces, I sent in my previous mails, you see, that the
order, in which the
filters are called, is right:
When receiving:
...
at
org.apache.mina.filter.ssl.SslHandler.flushScheduledEvents(SslHandler.java:310)
<--- SslFilter
at
I attached a stacktrace of the two threads, which are in a deadlock.
Jon maybe right, when saying the write stack is threadsafe, the problem is,
that simultaneously
a read operation is going on, and both stacks use the same filters.
Thread "NioProcessor-2":
flushScheduledEvents():308,
Hello,
I did a "threaddump" with visualvm in the deadlock situation (not sure if this
is what you wanted, but I don't see
anything else), it shows the same deadlock situation (at the bottom of this
mail), as in my previous mail.
2016-02-10 13:04:58
Full thread dump Java HotSpot(TM) 64-Bit
Hello,
I am trying to patch QuickFIX/J to use SOCKS Proxy connections.
I found a patch on the QuickFIX/J Jira (QFJ-285), which I used as a start,
and which, after some
tweaking, I got to work with Mina-2.0.10/Mina-2.0.11.
The main problem, when doing so, was, that I had to disable the
> The new version I have put on http://people.apache.org/~elecharny should
> solve the problem : instead of getting the lock whe we enter in the
> flushScheduledEvents() event, we exit immediately, doing nothing but
> incrementing the number of scheduled-events, instead of getting the
> lock.
