Thanks, Jonathan.
On 27.08.22 20:05, Jonathan Valliere wrote:
https://github.com/apache/mina/blob/7893dfc29bb37dcef1345ffb482709902b6b6c9f/mina-core/src/main/java/org/apache/mina/transport/socket/nio/NioSocketSession.java#L94
On Aug 26, 2022 at 5:15:42 AM, Christoph John wrote:
The
https://github.com/apache/mina/blob/7893dfc29bb37dcef1345ffb482709902b6b6c9f/mina-core/src/main/java/org/apache/mina/transport/socket/nio/NioSocketSession.java#L94
On Aug 26, 2022 at 5:15:42 AM, Christoph John
wrote:
> The constant PEER_ADDRESS is no longer present in the code in 2.2.x
>
> I
The constant PEER_ADDRESS is no longer present in the code in 2.2.x
I can see however that in
https://github.com/apache/mina/blob/7893dfc29bb37dcef1345ffb482709902b6b6c9f/mina-core/src/main/java/org/apache/mina/filter/ssl/SslFilter.java#L272
and
It should be either doing it automatically or is a configurable option in
the filter.
I’m far away from my computer right now so I can’t check.
On Wed, Aug 24, 2022 at 6:44 AM Christoph John
wrote:
> Hi Jonathan,
>
> are you able to help me with the last item on the list (see quote below)?
>
>
Hi Jonathan,
are you able to help me with the last item on the list (see quote below)?
Thank you in advance and best regards,
Chris.
On 28.07.22 16:42, Emmanuel Lécharny wrote:
3. to use SNI we formerly set the "PEER_ADDRESS". Is this still possible? Please see here:
Hi Christoph,
answers inline
On 28/07/2022 14:48, Christoph John wrote:
Hi Emmanuel,
I took a look at this and it seems the two latches were a red
herring. One is for the initiator (connector) and the other one for
the acceptor that are used in the unit test.
I must admit I haven't
Hi Emmanuel,
I took a look at this and it seems the two latches were a red herring. One is for the initiator
(connector) and the other one for the acceptor that are used in the unit test.
I must admit I haven't spent enough time to unerstand what was going on ;-)
No problem, thank you
On 21/07/2022 15:38, Christoph John wrote:
Hi Emmanuel,
I took a look at this and it seems the two latches were a red herring.
One is for the initiator (connector) and the other one for the acceptor
that are used in the unit test.
I must admit I haven't spent enough time to unerstand
Hi Emmanuel,
I took a look at this and it seems the two latches were a red herring. One is for the initiator
(connector) and the other one for the acceptor that are used in the unit test.
However, I think I found the root cause for the failing unit tests. We have an AbstractIoHandler
which
Hi Christoph,
after further analysis, it appears that we have 2 countdown latch
instances (exceptionThrownLatch) at play:
* one that is decremented in the exceptionCaught event,
[Count1]>:1]--->PKIX path validation failed:
java.security.cert.CertPathValidatorException:
Hi Christoph,
actually, there is a kind of race condition in your test.
I have added some logs:
@Override
public void exceptionCaught(NextFilter nextFilter,
IoSession session, Throwable cause)
throws Exception {
On 13/07/2022 09:37, Christoph John wrote:
Hi Emmanuel,
thanks for your analysis. The filter that should catch the exception is added
as last part in the chain. Could it be that the chain is not fully iterated
somehow? Just guessing, I don't have enough MINA experience to make an educated
Hi Emmanuel,
thanks for your analysis. The filter that should catch the exception is added
as last part in the chain. Could it be that the chain is not fully iterated
somehow? Just guessing, I don't have enough MINA experience to make an educated
guess. :)
Cheers
Chris
Jul 13, 2022 06:38:00
Here are some of my current findings.
For the (failing) test shouldFailWhenUsingBadClientCertificate, here are
the traces we get:
juil. 13, 2022 6:28:42 AM org.apache.mina.filter.ssl.SSLHandlerG0
execute_task
GRAVE: SSLHandlerG0@ae273e3[mode=server, connected=false] task() -
storing error
Never mind, I'm set up now, and in debug mode. All is good !
On 13/07/2022 00:47, Emmanuel Lécharny wrote:
Hi Christoph,
I'm trying to ran the failing tests on my machine (eclipse with Java 8
and Java 11), and I'll probably need some assistance.
I'm using the chrjohn-mina-2.2.0 branch. It
Hi Christoph,
I'm trying to ran the failing tests on my machine (eclipse with Java 8
and Java 11), and I'll probably need some assistance.
I'm using the chrjohn-mina-2.2.0 branch. It seems that the generated
code is not stored at the proper place.
Any clue?
On 09/07/2022 11:49,
Hi Christoph,
I think we should have the exact same tests in MINA. Poerting them
should not take too long.
On 06/07/2022 22:51, Christoph John wrote:
Hi
You could see the failing tests here:
https://github.com/quickfix-j/quickfixj/runs/7201285514?check_suite_focus=true
Basically these are
Thanks. Anything I can do to assist? Although I might only find time the week
after next because am currently on vacation.
Jul 9, 2022 09:00:21 Emmanuel Lécharny :
> I do think we need to have a look at it (and I may find some time to do it
> too, as I'm in vacation in the coming week)
>
>
I do think we need to have a look at it (and I may find some time to do
it too, as I'm in vacation in the coming week)
However, I think we should get this 2.0 out. Ther eis no problem in
releasing a fix if needed.
Thanks !
On 09/07/2022 07:17, Jonathan Valliere wrote:
Sooo… do I need to
Sooo… do I need to look into this or was this resolved?
On Fri, Jul 8, 2022 at 11:51 PM Emmanuel Lécharny
wrote:
> The changes I did were to ensure that any ouutbound data are sent when a
> TLS erroroccurs, because the Alert must be sent no matter what. This is
> critical for a client to know
The changes I did were to ensure that any ouutbound data are sent when a
TLS erroroccurs, because the Alert must be sent no matter what. This is
critical for a client to know what is the cause of the failure
(typically when a bad certificate is provided - expired, revoked, etc -):
Hi
You could see the failing tests here:
https://github.com/quickfix-j/quickfixj/runs/7201285514?check_suite_focus=true
Basically these are tests that should fail when using a bad certificate.
As an example here is one test that registers a filter that should get an
exception but it doesn't:
What test are you trying? Emmanuel made changes from the original design
to cause it to throw on the filter. My original design threw on the filter
but only during a subsequent read or write action thereby enforcing strong
concurrency within the pipeline.
On Jul 6, 2022 at 3:53:57 AM,
Ok, the tests in QuickFIX/J which expect the exception to be caught in a filter
still don't work.
I recall that you also did some changes in other Apache projects to make it
work with MINA 2.2.0. Could it be that I also need to adapt something in this
regard?
Thanks
Chris
Jul 5, 2022 18:47:09
24 matches
Mail list logo
