Re: Deadlock when using SslFilter and ProxyFilter together

2016-02-11 Thread Norbert Irmer

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 org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:534)
at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:542)
at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48)
at 
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:943)
at 
org.apache.mina.proxy.filter.ProxyFilter.messageReceived(ProxyFilter.java:153)  
   <--- 
ProxyFilter
...


When sending:

---
at org.apache.mina.proxy.filter.ProxyFilter.writeData(ProxyFilter.java:208) 
 <  ProxyFilter
- waiting to lock <0x00076ef8b1d8> (a 
org.apache.mina.proxy.handlers.socks.Socks4LogicHandler)
at org.apache.mina.proxy.filter.ProxyFilter.filterWrite(ProxyFilter.java:192)
at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:625)
at 
org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:48)
at 
org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:953)
at 
org.apache.mina.filter.ssl.SslHandler.flushScheduledEvents(SslHandler.java:316)
at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:653) 
   < SslFilter



I am only writing the client part of an application.  I communicate with a 
FIX/SSL server behind a SOCKS proxy,
so I cannot change the order in which Ssl encryption and proxy framing must be 
done.




Re: Deadlock when using SslFilter and ProxyFilter together

2016-02-11 Thread Emmanuel Lécharny
Le 11/02/16 10:10, Norbert Irmer a écrit :
> 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 org.apache.mina.filter.ssl.SslFilter.messageReceived(SslFilter.java:534)
> at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callNextMessageReceived(DefaultIoFilterChain.java:542)
> at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1300(DefaultIoFilterChain.java:48)
> at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.messageReceived(DefaultIoFilterChain.java:943)
> at 
> org.apache.mina.proxy.filter.ProxyFilter.messageReceived(ProxyFilter.java:153)
>  
> <--- ProxyFilter
> ...
>
>
> When sending:
>
> ---
> at org.apache.mina.proxy.filter.ProxyFilter.writeData(ProxyFilter.java:208)   
><  ProxyFilter
> - waiting to lock <0x00076ef8b1d8> (a 
> org.apache.mina.proxy.handlers.socks.Socks4LogicHandler)
> at org.apache.mina.proxy.filter.ProxyFilter.filterWrite(ProxyFilter.java:192)
> at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain.callPreviousFilterWrite(DefaultIoFilterChain.java:625)
> at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain.access$1500(DefaultIoFilterChain.java:48)
> at 
> org.apache.mina.core.filterchain.DefaultIoFilterChain$EntryImpl$1.filterWrite(DefaultIoFilterChain.java:953)
> at 
> org.apache.mina.filter.ssl.SslHandler.flushScheduledEvents(SslHandler.java:316)
> at org.apache.mina.filter.ssl.SslFilter.filterWrite(SslFilter.java:653)   
>  < SslFilter
> 
>
>
> I am only writing the client part of an application.  I communicate with a 
> FIX/SSL server behind a SOCKS proxy,
> so I cannot change the order in which Ssl encryption and proxy framing must 
> be done.
Ok, I *think* that the problem is due to the fact that the
flushScheduledEvents() method was not protecting writes *and* reads, so
they can be executed at the same time by two threads. Then what happens
is that both reach the ProxyFilter synchronized section,

FixMessageProcessor takes the SslHandler lock
FixMessageProcessor takes the ProxyFilter lock

and at the same time :

NioProcessor takes the ProxyFilter lock
NioProcessor takes the SslHandler lock

resulting in a Deadlock.


NioProcessor >[ProxyFilter]--->[SslHandler]> IoHandler
NioProcessor <[ProxyFilter]<---[SslHandler]< IoHandler

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. That means the thread which actually hold this lock will process
all the enqueued messages itself, until the counter get down to 0.

Can you give this version a try ?







Re: Deadlock when using SslFilter and ProxyFilter together

2016-02-11 Thread Norbert Irmer


> 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. That means the thread which actually hold this lock will process
> all the enqueued messages itself, until the counter get down to 0.
> 
>Can you give this version a try ?


Looks very good, I am running my application now for 20 minutes or so, and still
have no deadlock.

I am using now your snapshot versions without any changes. This is very nice,
now it's possible to send a pull request for proxy support to the QuickFixJ 
people
the next time you do a Mina  release.

Thanks a lot,
Norbert
 



Re: Deadlock when using SslFilter and ProxyFilter together

2016-02-11 Thread Emmanuel Lécharny
Le 11/02/16 17:38, Norbert Irmer a écrit :
>
>> 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. That means the thread which actually hold this lock will process
>> all the enqueued messages itself, until the counter get down to 0.
>>
>> Can you give this version a try ?
>
> Looks very good, I am running my application now for 20 minutes or so, and 
> still
> have no deadlock.
>
> I am using now your snapshot versions without any changes. This is very nice,
> now it's possible to send a pull request for proxy support to the QuickFixJ 
> people
> the next time you do a Mina  release.
>
> Thanks a lot,
> Norbert
>  
>
Glad that seems to be fixed !

Norbert, I have to tell you that I really appreciated your patience, and
I'm really sorry to have tried to deflect the prb for a couple of days.
I really thought it was something else, and it took me some time (and
the price was sleep deprivation :/) to realize that there were a deadlock.

Worst part : this deadlock was already detected months ago by Terence
Marks (https://issues.apache.org/jira/browse/DIRMINA-1019), a patch was
proposed, and I fucked it up thinking it was overdoing. My bad...


I'm going to cut a release asap. Expect it to be ready by the beginning
of next week.

thanks a lot !



ApacheCon NA 2016 - Important Dates!!!

2016-02-11 Thread Melissa Warnkin
 Hello everyone!
I hope this email finds you well.  I hope everyone is as excited about 
ApacheCon as I am!
I'd like to remind you all of a couple of important dates, as well as ask for 
your assistance in spreading the word! Please use your social media platform(s) 
to get the word out! The more visibility, the better ApacheCon will be for 
all!! :)
CFP Close: February 12, 2016CFP Notifications: February 29, 2016Schedule 
Announced: March 3, 2016
To submit a talk, please visit:  
http://events.linuxfoundation.org/events/apache-big-data-north-america/program/cfp

Link to the main site can be found here:  
http://events.linuxfoundation.org/events/apache-big-data-north-america

Apache: Big Data North America 2016 Registration Fees:
Attendee Registration Fee: US$599 through March 6, US$799 through April 10, 
US$999 thereafterCommitter Registration Fee: US$275 through April 10, US$375 
thereafterStudent Registration Fee: US$275 through April 10, $375 thereafter
Planning to attend ApacheCon North America 2016 May 11 - 13, 2016? There is an 
add-on option on the registration form to join the conference for a discounted 
fee of US$399, available only to Apache: Big Data North America attendees.
So, please tweet away!!
I look forward to seeing you in Vancouver! Have a groovy day!!
~Melissaon behalf of the ApacheCon Team






ApacheCon NA 2016 - Important Dates!!!

2016-02-11 Thread Melissa Warnkin
 Hello everyone!
I hope this email finds you well.  I hope everyone is as excited about 
ApacheCon as I am!
I'd like to remind you all of a couple of important dates, as well as ask for 
your assistance in spreading the word! Please use your social media platform(s) 
to get the word out! The more visibility, the better ApacheCon will be for 
all!! :)
CFP Close: February 12, 2016CFP Notifications: February 29, 2016Schedule 
Announced: March 3, 2016
To submit a talk, please visit:  
http://events.linuxfoundation.org/events/apache-big-data-north-america/program/cfp

Link to the main site can be found here:  
http://events.linuxfoundation.org/events/apache-big-data-north-america

Apache: Big Data North America 2016 Registration Fees:
Attendee Registration Fee: US$599 through March 6, US$799 through April 10, 
US$999 thereafterCommitter Registration Fee: US$275 through April 10, US$375 
thereafterStudent Registration Fee: US$275 through April 10, $375 thereafter
Planning to attend ApacheCon North America 2016 May 11 - 13, 2016? There is an 
add-on option on the registration form to join the conference for a discounted 
fee of US$399, available only to Apache: Big Data North America attendees.
So, please tweet away!!
I look forward to seeing you in Vancouver! Have a groovy day!!
~Melissaon behalf of the ApacheCon Team