[jira] [Work logged] (DIRMINA-1122) Add support for endpoint identification algorithm
[ https://issues.apache.org/jira/browse/DIRMINA-1122?focusedWorklogId=861287=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-861287 ] ASF GitHub Bot logged work on DIRMINA-1122: --- Author: ASF GitHub Bot Created on: 10/May/23 05:53 Start Date: 10/May/23 05:53 Worklog Time Spent: 10m Work Description: the-thing commented on PR #26: URL: https://github.com/apache/mina/pull/26#issuecomment-1541392215 Good stuff. I had a peek and I can see that the solution requires custom ssl engine creation. Drop me a message if any trouble. Issue Time Tracking --- Worklog Id: (was: 861287) Time Spent: 2h 50m (was: 2h 40m) > Add support for endpoint identification algorithm > - > > Key: DIRMINA-1122 > URL: https://issues.apache.org/jira/browse/DIRMINA-1122 > Project: MINA > Issue Type: Improvement > Components: Filter, SSL >Affects Versions: 2.0.22, 2.1.3 >Reporter: Marcin L >Assignee: Jonathan Valliere >Priority: Minor > Fix For: 2.2.0 > > Attachments: > DIRMINA-1122_-_endpoint_identification_algorithm_support.patch > > Time Spent: 2h 50m > Remaining Estimate: 0h > > Support for endpoint identification algorithm was added in Java 1.7. > Currently MINA supports providing single SNI name via > org.apache.mina.filter.ssl.SslFilter#PEER_ADDRESS session attribute, but > there is no way verifying it matches the certificate received. > It would be nice if we could provide endpoint identification algorithm to > SslFilter so certificate's common name or subject alternative names are > verified. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina] the-thing commented on pull request #26: DIRMINA-1122 - added support for endpoint identification algorithm
the-thing commented on PR #26: URL: https://github.com/apache/mina/pull/26#issuecomment-1541392215 Good stuff. I had a peek and I can see that the solution requires custom ssl engine creation. Drop me a message if any trouble. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Work logged] (DIRMINA-1122) Add support for endpoint identification algorithm
[ https://issues.apache.org/jira/browse/DIRMINA-1122?focusedWorklogId=861277=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-861277 ] ASF GitHub Bot logged work on DIRMINA-1122: --- Author: ASF GitHub Bot Created on: 10/May/23 03:44 Start Date: 10/May/23 03:44 Worklog Time Spent: 10m Work Description: elecharny commented on PR #26: URL: https://github.com/apache/mina/pull/26#issuecomment-1541304843 Ok, I pushed the modified code with the working tests! Issue Time Tracking --- Worklog Id: (was: 861277) Time Spent: 2h 40m (was: 2.5h) > Add support for endpoint identification algorithm > - > > Key: DIRMINA-1122 > URL: https://issues.apache.org/jira/browse/DIRMINA-1122 > Project: MINA > Issue Type: Improvement > Components: Filter, SSL >Affects Versions: 2.0.22, 2.1.3 >Reporter: Marcin L >Assignee: Jonathan Valliere >Priority: Minor > Fix For: 2.2.0 > > Attachments: > DIRMINA-1122_-_endpoint_identification_algorithm_support.patch > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Support for endpoint identification algorithm was added in Java 1.7. > Currently MINA supports providing single SNI name via > org.apache.mina.filter.ssl.SslFilter#PEER_ADDRESS session attribute, but > there is no way verifying it matches the certificate received. > It would be nice if we could provide endpoint identification algorithm to > SslFilter so certificate's common name or subject alternative names are > verified. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina] elecharny commented on pull request #26: DIRMINA-1122 - added support for endpoint identification algorithm
elecharny commented on PR #26: URL: https://github.com/apache/mina/pull/26#issuecomment-1541304843 Ok, I pushed the modified code with the working tests! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Updated] (SSHD-1324) Rooted file system can leak informations
[ https://issues.apache.org/jira/browse/SSHD-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet updated SSHD-1324: -- Fix Version/s: 2.10.0 > Rooted file system can leak informations > > > Key: SSHD-1324 > URL: https://issues.apache.org/jira/browse/SSHD-1324 > Project: MINA SSHD > Issue Type: Bug >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 2.10.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Assigned] (SSHD-1324) Rooted file system can leak informations
[ https://issues.apache.org/jira/browse/SSHD-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet reassigned SSHD-1324: - Assignee: Guillaume Nodet > Rooted file system can leak informations > > > Key: SSHD-1324 > URL: https://issues.apache.org/jira/browse/SSHD-1324 > Project: MINA SSHD > Issue Type: Bug >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Resolved] (SSHD-1324) Rooted file system can leak informations
[ https://issues.apache.org/jira/browse/SSHD-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Guillaume Nodet resolved SSHD-1324. --- Resolution: Fixed > Rooted file system can leak informations > > > Key: SSHD-1324 > URL: https://issues.apache.org/jira/browse/SSHD-1324 > Project: MINA SSHD > Issue Type: Bug >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: 2.10.0 > > -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina-sshd] gnodet merged pull request #362: [SSHD-1324] Rooted file system can leak informations
gnodet merged PR #362: URL: https://github.com/apache/mina-sshd/pull/362 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Call for Presentations, Community Over Code 2023
(Note: You are receiving this because you are subscribed to the dev@ list for one or more Apache Software Foundation projects.) The Call for Presentations (CFP) for Community Over Code (formerly Apachecon) 2023 is open at https://communityovercode.org/call-for-presentations/, and will close Thu, 13 Jul 2023 23:59:59 GMT. The event will be held in Halifax, Canada, October 7-10, 2023. We welcome submissions on any topic related to the Apache Software Foundation, Apache projects, or the communities around those projects. We are specifically looking for presentations in the following catetegories: Fintech Search Big Data, Storage Big Data, Compute Internet of Things Groovy Incubator Community Data Engineering Performance Engineering Geospatial API/Microservices Frameworks Content Wrangling Tomcat and httpd Cloud and Runtime Streaming Sustainability - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Closed] (SSHD-1325) Not useful sorting of signature algrithms?
[
https://issues.apache.org/jira/browse/SSHD-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jan Philipp closed SSHD-1325.
-
Resolution: Invalid
> Not useful sorting of signature algrithms?
> --
>
> Key: SSHD-1325
> URL: https://issues.apache.org/jira/browse/SSHD-1325
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.2
>Reporter: Jan Philipp
>Priority: Major
>
> We found the current (default) settings may result into authentication
> problems when using the MINA SSHD client against "modern" remote SSH servers.
> {{org.apache.sshd.common.SshException: No more authentication methods
> available}}
> A RSA key will not be accepted by the server anymore. It depends on the OS
> (well, actually, on the crypto (default) settings). The same key and the same
> destination host *will* work when using the "native" OpenSSH client.
>
> The actual culprit is the deprecation of RSA+SHA1 issue which already have
> some issue stories here at Jira also :) Basically the usage of RSA keys is
> still fine, but the usage of SHA1 will be disallowed and this is enforced by
> modern OS. Said that, OL9 (EL9) deprecates SHA1 via crypto-policies.
>
> The technical order when using {{BuiltinSignatures.VALUES}} is {{{}dsa{}}},
> {{{}dsa_cert{}}}, {{{}rsa{}}}, {{{}rsa_cert{}}}, {{{}rsaSHA256{}}}, etc. When
> using an RSA key, the type is {{ssh-rsa}} and this is _always_ {{rsa}} and
> this is always {{{}RSA with SHA1{}}}.
> Meanwhile, as far as I understand this correctly, OpenSSH clients may treat
> {{ssh-rsa}} as RSA with SHA256; the MINA SSHD client does not support this.
> That may the reason why the native OpenSSH client actually works.
> As a workaround, the list of supported signature algorithms can be tweaked
> (because the order of appearance is used for matching). If the match finder
> is trying {{rsaSHA256}} for {{ssh-rsa}} at first, it will never try the
> non-working {{rsa}} again.
> In order of not missing future value additions, I have used this code to meet
> this.
>
> {code:java}
> // push back these options to the end
> final var deprecated = List.of(
> BuiltinSignatures.dsa,
> BuiltinSignatures.dsa_cert,
> BuiltinSignatures.rsa,
> BuiltinSignatures.rsa_cert
> );
> client.setSignatureFactories(
> Stream.concat(
> BuiltinSignatures.VALUES.stream()
> .filter(not(deprecated::contains)),
> deprecated.stream()
> )
> .map(s -> (NamedFactory) s)
> .toList()
> );
> {code}
> Although this seems to work, I want to raise this here for discussion:
> # Is this workaround actually correct or have I missed something which could
> be an issue in the future?
> # I can see a growing issue of "mina does not work" because if seems to
> break with default settings. IMHO either the order (like the workaround) must
> be changed or the matcher should look for other matches also (which he does
> not atm).
> I also find some issues on this topic (NIFI-10586 is a different project, but
> seems to be the same problem), and related here SSHD-1105 and SSHD-1141. This
> does not seem to be solved in 2.9. If I have missed something, please correct
> me.
> A full demo is available in my repo-demo at
> [https://github.com/knalli/poc-mina-sshd-ssh-rsa-issue]. The demo uses
> Testcontainers for spinning up the samples, so you need Docker or something
> compatible.
> The demo contains 2x2 tests against a container with Oracle Linux 8
> respective 9 configured with password respective with a RSA public key. OL8
> works fine, and password also. Only the "modern" OL9 with an RSA public key
> fails. I've added an additiona test `run2` with the enabled workaround.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (SSHD-1325) Not useful sorting of signature algrithms?
[
https://issues.apache.org/jira/browse/SSHD-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721084#comment-17721084
]
Jan Philipp commented on SSHD-1325:
---
Thomas, thank you for details. Indeed back in 2021 we had switched to
BuiltinSignatures.VALUES because DEFAULT_SIGNATURE_PREFERENCE missed some. I
missed that, so I thought the current situation would be only-way of going for
defining the signature algorithms. My fault, sorry for the confusion. :( In a
poor attempt at justification at my side :), I would appreciate that the
JavaDocs would be more helpful what the actual defaults could/would be, at
least as a hint of useful constants in BaseBuilder.
Regarding the reference to the set. Technically you are right, the set is not a
guarantee for the order. I had actually only suspected an implicit sorting due
to the JDK (enums are "static", and and I'm probably right about that).
Nevertheless, we should not do that, no question.
So: If no signatures are defined, it works. It annoys me that I didn't have
that simple test case with me at all. If using BuiltinSignatures.VALUES, it
fails (always) because of the ordering.
End of story is: This is not an issue, we can close this. I will stick with the
BaseBuilder.DEFAULT_SIGNATURE_PREFERENCE but extended with the missing
(deprecated) items we need in this specific situation. These ensures we include
the recommended order by Mina itself.
> Not useful sorting of signature algrithms?
> --
>
> Key: SSHD-1325
> URL: https://issues.apache.org/jira/browse/SSHD-1325
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.2
>Reporter: Jan Philipp
>Priority: Major
>
> We found the current (default) settings may result into authentication
> problems when using the MINA SSHD client against "modern" remote SSH servers.
> {{org.apache.sshd.common.SshException: No more authentication methods
> available}}
> A RSA key will not be accepted by the server anymore. It depends on the OS
> (well, actually, on the crypto (default) settings). The same key and the same
> destination host *will* work when using the "native" OpenSSH client.
>
> The actual culprit is the deprecation of RSA+SHA1 issue which already have
> some issue stories here at Jira also :) Basically the usage of RSA keys is
> still fine, but the usage of SHA1 will be disallowed and this is enforced by
> modern OS. Said that, OL9 (EL9) deprecates SHA1 via crypto-policies.
>
> The technical order when using {{BuiltinSignatures.VALUES}} is {{{}dsa{}}},
> {{{}dsa_cert{}}}, {{{}rsa{}}}, {{{}rsa_cert{}}}, {{{}rsaSHA256{}}}, etc. When
> using an RSA key, the type is {{ssh-rsa}} and this is _always_ {{rsa}} and
> this is always {{{}RSA with SHA1{}}}.
> Meanwhile, as far as I understand this correctly, OpenSSH clients may treat
> {{ssh-rsa}} as RSA with SHA256; the MINA SSHD client does not support this.
> That may the reason why the native OpenSSH client actually works.
> As a workaround, the list of supported signature algorithms can be tweaked
> (because the order of appearance is used for matching). If the match finder
> is trying {{rsaSHA256}} for {{ssh-rsa}} at first, it will never try the
> non-working {{rsa}} again.
> In order of not missing future value additions, I have used this code to meet
> this.
>
> {code:java}
> // push back these options to the end
> final var deprecated = List.of(
> BuiltinSignatures.dsa,
> BuiltinSignatures.dsa_cert,
> BuiltinSignatures.rsa,
> BuiltinSignatures.rsa_cert
> );
> client.setSignatureFactories(
> Stream.concat(
> BuiltinSignatures.VALUES.stream()
> .filter(not(deprecated::contains)),
> deprecated.stream()
> )
> .map(s -> (NamedFactory) s)
> .toList()
> );
> {code}
> Although this seems to work, I want to raise this here for discussion:
> # Is this workaround actually correct or have I missed something which could
> be an issue in the future?
> # I can see a growing issue of "mina does not work" because if seems to
> break with default settings. IMHO either the order (like the workaround) must
> be changed or the matcher should look for other matches also (which he does
> not atm).
> I also find some issues on this topic (NIFI-10586 is a different project, but
> seems to be the same problem), and related here SSHD-1105 and SSHD-1141. This
> does not seem to be solved in 2.9. If I have missed something, please correct
> me.
> A full demo is available in my repo-demo at
> [https://github.com/knalli/poc-mina-sshd-ssh-rsa-issue]. The demo uses
> Testcontainers for spinning up the samples, so you need Docker or something
> compatible.
> The demo contains 2x2 tests
[jira] [Commented] (SSHD-1325) Not useful sorting of signature algrithms?
[
https://issues.apache.org/jira/browse/SSHD-1325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721061#comment-17721061
]
Thomas Wolf commented on SSHD-1325:
---
I don't understand. If the {{ClientBuilder}} is used, the default signature
order will be the one from {{BaseBuilder.DEFAULT_SIGNATURE_PREFERENCE}}. See
{{ClientBuilder.setUpDefaultSignatureFactories()}}. These default settings _do_
work.
We did notice in Eclipse before that if you include ssh-rsa in the KEX
proposal, it should come _after_ rsa-sha2-512, rsa-sha2-256. Otherwise some SSH
servers may wrongly decide on the wrong signature. But your issue is not about
KEX...
{{BuiltinSignatures.VALUES}} is a {{Set}}. Therefore, _no_ particular order is
guaranteed, so code using it should not assume any particular order. Likewise,
the order of the enumeration constants in {{BuiltinSignatures}} it unrelated to
any order that might make sense for {{PubkeyAcceptedAlgorithms}}.
> Not useful sorting of signature algrithms?
> --
>
> Key: SSHD-1325
> URL: https://issues.apache.org/jira/browse/SSHD-1325
> Project: MINA SSHD
> Issue Type: Bug
>Affects Versions: 2.9.2
>Reporter: Jan Philipp
>Priority: Major
>
> We found the current (default) settings may result into authentication
> problems when using the MINA SSHD client against "modern" remote SSH servers.
> {{org.apache.sshd.common.SshException: No more authentication methods
> available}}
> A RSA key will not be accepted by the server anymore. It depends on the OS
> (well, actually, on the crypto (default) settings). The same key and the same
> destination host *will* work when using the "native" OpenSSH client.
>
> The actual culprit is the deprecation of RSA+SHA1 issue which already have
> some issue stories here at Jira also :) Basically the usage of RSA keys is
> still fine, but the usage of SHA1 will be disallowed and this is enforced by
> modern OS. Said that, OL9 (EL9) deprecates SHA1 via crypto-policies.
>
> The technical order when using {{BuiltinSignatures.VALUES}} is {{{}dsa{}}},
> {{{}dsa_cert{}}}, {{{}rsa{}}}, {{{}rsa_cert{}}}, {{{}rsaSHA256{}}}, etc. When
> using an RSA key, the type is {{ssh-rsa}} and this is _always_ {{rsa}} and
> this is always {{{}RSA with SHA1{}}}.
> Meanwhile, as far as I understand this correctly, OpenSSH clients may treat
> {{ssh-rsa}} as RSA with SHA256; the MINA SSHD client does not support this.
> That may the reason why the native OpenSSH client actually works.
> As a workaround, the list of supported signature algorithms can be tweaked
> (because the order of appearance is used for matching). If the match finder
> is trying {{rsaSHA256}} for {{ssh-rsa}} at first, it will never try the
> non-working {{rsa}} again.
> In order of not missing future value additions, I have used this code to meet
> this.
>
> {code:java}
> // push back these options to the end
> final var deprecated = List.of(
> BuiltinSignatures.dsa,
> BuiltinSignatures.dsa_cert,
> BuiltinSignatures.rsa,
> BuiltinSignatures.rsa_cert
> );
> client.setSignatureFactories(
> Stream.concat(
> BuiltinSignatures.VALUES.stream()
> .filter(not(deprecated::contains)),
> deprecated.stream()
> )
> .map(s -> (NamedFactory) s)
> .toList()
> );
> {code}
> Although this seems to work, I want to raise this here for discussion:
> # Is this workaround actually correct or have I missed something which could
> be an issue in the future?
> # I can see a growing issue of "mina does not work" because if seems to
> break with default settings. IMHO either the order (like the workaround) must
> be changed or the matcher should look for other matches also (which he does
> not atm).
> I also find some issues on this topic (NIFI-10586 is a different project, but
> seems to be the same problem), and related here SSHD-1105 and SSHD-1141. This
> does not seem to be solved in 2.9. If I have missed something, please correct
> me.
> A full demo is available in my repo-demo at
> [https://github.com/knalli/poc-mina-sshd-ssh-rsa-issue]. The demo uses
> Testcontainers for spinning up the samples, so you need Docker or something
> compatible.
> The demo contains 2x2 tests against a container with Oracle Linux 8
> respective 9 configured with password respective with a RSA public key. OL8
> works fine, and password also. Only the "modern" OL9 with an RSA public key
> fails. I've added an additiona test `run2` with the enabled workaround.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional
[jira] [Commented] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
[
https://issues.apache.org/jira/browse/DIRMINA-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721051#comment-17721051
]
Jonathan Valliere commented on DIRMINA-1173:
Think of it like this. All of the Processor Pool threads share the same
FilterChain. So if you have 8 cores there are 16 Processor Threads. If you
add a ExecutorFilter with 4 threads then then all the tasks produced by
those 16 threads will then be executed on the 4 shared threads and it will
bottleneck.
> Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly()
> for ever
> ---
>
> Key: DIRMINA-1173
> URL: https://issues.apache.org/jira/browse/DIRMINA-1173
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.1
>Reporter: KMVS
>Priority: Critical
> Attachments: dumpLatest-1.log
>
>
> Hi All,
> I have attached thread dump too for analysis.
> I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at {*}awaitUninterruptibly{*}.
> Once this issue comes in sub sequest launches nothing will work all threads
> will be blocked forever,i have to restart the process to make it work. For
> single thread working fine,if i start 50-100 threads this thread blocking
> issue will surface.I am using the same NioSocketConnector across the threads.
> Here is an scenario, I have one gate way IP which i connect initially ,this
> gate way will return list of ips.
> now i will close the previous IOsession and will create a nio connection with
> the first ip in the list.if it did n't work then again i will try to
> connect to next ip etc..
> All these are in the critical section. i.e i will acquire a lock and then
> after successful connection i will release the lock.
> But problem i have noticed is with the awaitUninterruptibly().
> I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
>
> *Thread 1:*
> Public class g10CaptureService
> {
>
> private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> static
> {
> initConnectors()
> }
> protected static void initConnectors()
> {
> StateMachine stateMachine =
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
> G10MinaClient.CONNECTED, new G10MinaClient(processor));
> IoHandler ioHandler = new
> StateMachineProxyBuilder().setStateContextLookup(
> new IoSessionStateContextLookup(new StateContextFactory() {
> @Override
> public StateContext create() {
> final G10StateContext stateContext = new
> G10StateContext();
> stateContext.setStartedTime(new Date());
> return stateContext;
> }
> })).create(IoHandler.class, stateMachine);
>
>
> //Global connector across the system, i.e multiple threads uses the same
> connector.
> NioSocketConnector connector = new NioSocketConnector();
> connector.getFilterChain().addLast("LoggingFilter",
> G10CaptureService.loggingFilter);
> connector.getFilterChain().addLast("codecFilter",
> G10CaptureService.probeCodecFilter);
> connector.getFilterChain().addLast("executorFilter",
> G10CaptureService.executorFilter);
> connector.getFilterChain().addLast("gpbMessageFilter",
> G10CaptureService.gpbMessageFilter);
> connector.getFilterChain().addLast("keepAliveFilter",
> G10CaptureService.keepAliveFilter);
> connector.setHandler(ioHandler);
> }
>
> public void StartRecordCapture()
> {
> connectionLock.lock();
> try
> {
> ConnectFuture primaryConnectFuture = connector.connect(primaryAddress,
> initializer);
> //hungs forever if the no. of threads are more than 30
> primaryConnectFuture.awaitUninterruptibly();//no time out specified
> if (!primaryConnectFuture.isConnected())
> {
>
> if (handleIOException(searchExpression, captureHandler)) {
> return;
> }
> LOG.info("{} Apache mina connection setup time out
> happend.",
> handleConnectionFailed(primaryAddress, captureHandler,
> "Primary IP connection timeout");
>
Re: [jira] [Commented] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
Think of it like this. All of the Processor Pool threads share the same
FilterChain. So if you have 8 cores there are 16 Processor Threads. If you
add a ExecutorFilter with 4 threads then then all the tasks produced by
those 16 threads will then be executed on the 4 shared threads and it will
bottleneck.
On Tue, May 9, 2023 at 2:39 PM KMVS (Jira) wrote:
>
> [
> https://issues.apache.org/jira/browse/DIRMINA-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721040#comment-17721040
> ]
>
> KMVS commented on DIRMINA-1173:
> ---
>
> What is the effect of using our own thread pool in the execution filter ?
>
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
>
> vs
>
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(Executors.newCachedThreadPool());*
>
>
> > Apache mina 2.2.1 threads blocking on
> ConnectFuture.awaitUninterruptibly() for ever
> >
> ---
> >
> > Key: DIRMINA-1173
> > URL: https://issues.apache.org/jira/browse/DIRMINA-1173
> > Project: MINA
> > Issue Type: Bug
> > Components: Core
> >Affects Versions: 2.2.1
> >Reporter: KMVS
> >Priority: Critical
> > Attachments: dumpLatest-1.log
> >
> >
> > Hi All,
> > I have attached thread dump too for analysis.
> > I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at
> {*}awaitUninterruptibly{*}. Once this issue comes in sub sequest launches
> nothing will work all threads will be blocked forever,i have to restart the
> process to make it work. For single thread working fine,if i start 50-100
> threads this thread blocking issue will surface.I am using the same
> NioSocketConnector across the threads.
> > Here is an scenario, I have one gate way IP which i connect initially
> ,this gate way will return list of ips.
> > now i will close the previous IOsession and will create a nio connection
> with the first ip in the list.if it did n't work then again i will try to
> > connect to next ip etc..
> > All these are in the critical section. i.e i will acquire a lock and
> then after successful connection i will release the lock.
> > But problem i have noticed is with the awaitUninterruptibly().
> > I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
> >
> > *Thread 1:*
> > Public class g10CaptureService
> > {
> >
> > private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> > *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> > private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> > static
> > {
> > initConnectors()
> > }
> > protected static void initConnectors()
> > {
> > StateMachine stateMachine =
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
> > G10MinaClient.CONNECTED, new G10MinaClient(processor));
> > IoHandler ioHandler = new
> StateMachineProxyBuilder().setStateContextLookup(
> > new IoSessionStateContextLookup(new
> StateContextFactory() {
> > @Override
> > public StateContext create() {
> > final G10StateContext stateContext = new
> G10StateContext();
> > stateContext.setStartedTime(new Date());
> > return stateContext;
> > }
> > })).create(IoHandler.class, stateMachine);
> >
> >
> > //Global connector across the system, i.e multiple threads uses the same
> connector.
> > NioSocketConnector connector = new NioSocketConnector();
> > connector.getFilterChain().addLast("LoggingFilter",
> G10CaptureService.loggingFilter);
> > connector.getFilterChain().addLast("codecFilter",
> G10CaptureService.probeCodecFilter);
> > connector.getFilterChain().addLast("executorFilter",
> G10CaptureService.executorFilter);
> > connector.getFilterChain().addLast("gpbMessageFilter",
> G10CaptureService.gpbMessageFilter);
> > connector.getFilterChain().addLast("keepAliveFilter",
> G10CaptureService.keepAliveFilter);
> > connector.setHandler(ioHandler);
> > }
> >
> > public void StartRecordCapture()
> > {
> > connectionLock.lock();
> > try
> > {
> > ConnectFuture primaryConnectFuture = connector.connect(primaryAddress,
> initializer);
> > //hungs forever if the no. of threads are more than 30
> > primaryConnectFuture.awaitUninterruptibly();//no time out specified
> > if (!primaryConnectFuture.isConnected())
>
[jira] [Commented] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
[
https://issues.apache.org/jira/browse/DIRMINA-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17721040#comment-17721040
]
KMVS commented on DIRMINA-1173:
---
What is the effect of using our own thread pool in the execution filter ?
*private static final ExecutorFilter executorFilter = new
ExecutorFilter(16,32);*
vs
*private static final ExecutorFilter executorFilter = new
ExecutorFilter(Executors.newCachedThreadPool());*
> Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly()
> for ever
> ---
>
> Key: DIRMINA-1173
> URL: https://issues.apache.org/jira/browse/DIRMINA-1173
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.1
>Reporter: KMVS
>Priority: Critical
> Attachments: dumpLatest-1.log
>
>
> Hi All,
> I have attached thread dump too for analysis.
> I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at {*}awaitUninterruptibly{*}.
> Once this issue comes in sub sequest launches nothing will work all threads
> will be blocked forever,i have to restart the process to make it work. For
> single thread working fine,if i start 50-100 threads this thread blocking
> issue will surface.I am using the same NioSocketConnector across the threads.
> Here is an scenario, I have one gate way IP which i connect initially ,this
> gate way will return list of ips.
> now i will close the previous IOsession and will create a nio connection with
> the first ip in the list.if it did n't work then again i will try to
> connect to next ip etc..
> All these are in the critical section. i.e i will acquire a lock and then
> after successful connection i will release the lock.
> But problem i have noticed is with the awaitUninterruptibly().
> I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
>
> *Thread 1:*
> Public class g10CaptureService
> {
>
> private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> static
> {
> initConnectors()
> }
> protected static void initConnectors()
> {
> StateMachine stateMachine =
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
> G10MinaClient.CONNECTED, new G10MinaClient(processor));
> IoHandler ioHandler = new
> StateMachineProxyBuilder().setStateContextLookup(
> new IoSessionStateContextLookup(new StateContextFactory() {
> @Override
> public StateContext create() {
> final G10StateContext stateContext = new
> G10StateContext();
> stateContext.setStartedTime(new Date());
> return stateContext;
> }
> })).create(IoHandler.class, stateMachine);
>
>
> //Global connector across the system, i.e multiple threads uses the same
> connector.
> NioSocketConnector connector = new NioSocketConnector();
> connector.getFilterChain().addLast("LoggingFilter",
> G10CaptureService.loggingFilter);
> connector.getFilterChain().addLast("codecFilter",
> G10CaptureService.probeCodecFilter);
> connector.getFilterChain().addLast("executorFilter",
> G10CaptureService.executorFilter);
> connector.getFilterChain().addLast("gpbMessageFilter",
> G10CaptureService.gpbMessageFilter);
> connector.getFilterChain().addLast("keepAliveFilter",
> G10CaptureService.keepAliveFilter);
> connector.setHandler(ioHandler);
> }
>
> public void StartRecordCapture()
> {
> connectionLock.lock();
> try
> {
> ConnectFuture primaryConnectFuture = connector.connect(primaryAddress,
> initializer);
> //hungs forever if the no. of threads are more than 30
> primaryConnectFuture.awaitUninterruptibly();//no time out specified
> if (!primaryConnectFuture.isConnected())
> {
>
> if (handleIOException(searchExpression, captureHandler)) {
> return;
> }
> LOG.info("{} Apache mina connection setup time out
> happend.",
> handleConnectionFailed(primaryAddress, captureHandler,
> "Primary IP connection timeout");
> return;
> }
> }catch(Exception e)
> {
> }finally
> {
>
[GitHub] [mina-sshd] lgoldstein commented on pull request #362: [SSHD-1324] Rooted file system can leak informations
lgoldstein commented on PR #362: URL: https://github.com/apache/mina-sshd/pull/362#issuecomment-1540575190 > I suggest we publish a 2.10.0 without this change, and do a 2.10.1 once this is ready. I second that... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
Re: [jira] [Comment Edited] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
Yes, all sockets
On Tue, May 9, 2023 at 11:21 AM KMVS (Jira) wrote:
>
> [
> https://issues.apache.org/jira/browse/DIRMINA-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720884#comment-17720884
> ]
>
> KMVS edited comment on DIRMINA-1173 at 5/9/23 3:20 PM:
> ---
>
> What the association between NIO Connector and executorFilter ?
>
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
>
> If I have a static executorFilter then will the worker threads will be
> shared across all NIO sockets ?
>
>
>
>
> was (Author: JIRAUSER300071):
> How the association between NIO Connector and executorFilter ?
>
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
>
> If I have a static executorFilter then will the worker threads will be
> shared across all NIO sockets ?
>
>
>
> > Apache mina 2.2.1 threads blocking on
> ConnectFuture.awaitUninterruptibly() for ever
> >
> ---
> >
> > Key: DIRMINA-1173
> > URL: https://issues.apache.org/jira/browse/DIRMINA-1173
> > Project: MINA
> > Issue Type: Bug
> > Components: Core
> >Affects Versions: 2.2.1
> >Reporter: KMVS
> >Priority: Critical
> > Attachments: dumpLatest-1.log
> >
> >
> > Hi All,
> > I have attached thread dump too for analysis.
> > I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at
> {*}awaitUninterruptibly{*}. Once this issue comes in sub sequest launches
> nothing will work all threads will be blocked forever,i have to restart the
> process to make it work. For single thread working fine,if i start 50-100
> threads this thread blocking issue will surface.I am using the same
> NioSocketConnector across the threads.
> > Here is an scenario, I have one gate way IP which i connect initially
> ,this gate way will return list of ips.
> > now i will close the previous IOsession and will create a nio connection
> with the first ip in the list.if it did n't work then again i will try to
> > connect to next ip etc..
> > All these are in the critical section. i.e i will acquire a lock and
> then after successful connection i will release the lock.
> > But problem i have noticed is with the awaitUninterruptibly().
> > I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
> >
> > *Thread 1:*
> > Public class g10CaptureService
> > {
> >
> > private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> > *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> > private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> > static
> > {
> > initConnectors()
> > }
> > protected static void initConnectors()
> > {
> > StateMachine stateMachine =
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
> > G10MinaClient.CONNECTED, new G10MinaClient(processor));
> > IoHandler ioHandler = new
> StateMachineProxyBuilder().setStateContextLookup(
> > new IoSessionStateContextLookup(new
> StateContextFactory() {
> > @Override
> > public StateContext create() {
> > final G10StateContext stateContext = new
> G10StateContext();
> > stateContext.setStartedTime(new Date());
> > return stateContext;
> > }
> > })).create(IoHandler.class, stateMachine);
> >
> >
> > //Global connector across the system, i.e multiple threads uses the same
> connector.
> > NioSocketConnector connector = new NioSocketConnector();
> > connector.getFilterChain().addLast("LoggingFilter",
> G10CaptureService.loggingFilter);
> > connector.getFilterChain().addLast("codecFilter",
> G10CaptureService.probeCodecFilter);
> > connector.getFilterChain().addLast("executorFilter",
> G10CaptureService.executorFilter);
> > connector.getFilterChain().addLast("gpbMessageFilter",
> G10CaptureService.gpbMessageFilter);
> > connector.getFilterChain().addLast("keepAliveFilter",
> G10CaptureService.keepAliveFilter);
> > connector.setHandler(ioHandler);
> > }
> >
> > public void StartRecordCapture()
> > {
> > connectionLock.lock();
> > try
> > {
> > ConnectFuture primaryConnectFuture = connector.connect(primaryAddress,
> initializer);
> > //hungs forever if the no. of threads are more than 30
> > primaryConnectFuture.awaitUninterruptibly();//no time out specified
> >
[jira] [Commented] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
[
https://issues.apache.org/jira/browse/DIRMINA-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720971#comment-17720971
]
Jonathan Valliere commented on DIRMINA-1173:
Yes, all sockets
CONFIDENTIALITY NOTICE: The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and may be legally protected
from disclosure.
> Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly()
> for ever
> ---
>
> Key: DIRMINA-1173
> URL: https://issues.apache.org/jira/browse/DIRMINA-1173
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.1
>Reporter: KMVS
>Priority: Critical
> Attachments: dumpLatest-1.log
>
>
> Hi All,
> I have attached thread dump too for analysis.
> I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at {*}awaitUninterruptibly{*}.
> Once this issue comes in sub sequest launches nothing will work all threads
> will be blocked forever,i have to restart the process to make it work. For
> single thread working fine,if i start 50-100 threads this thread blocking
> issue will surface.I am using the same NioSocketConnector across the threads.
> Here is an scenario, I have one gate way IP which i connect initially ,this
> gate way will return list of ips.
> now i will close the previous IOsession and will create a nio connection with
> the first ip in the list.if it did n't work then again i will try to
> connect to next ip etc..
> All these are in the critical section. i.e i will acquire a lock and then
> after successful connection i will release the lock.
> But problem i have noticed is with the awaitUninterruptibly().
> I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
>
> *Thread 1:*
> Public class g10CaptureService
> {
>
> private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> static
> {
> initConnectors()
> }
> protected static void initConnectors()
> {
> StateMachine stateMachine =
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
> G10MinaClient.CONNECTED, new G10MinaClient(processor));
> IoHandler ioHandler = new
> StateMachineProxyBuilder().setStateContextLookup(
> new IoSessionStateContextLookup(new StateContextFactory() {
> @Override
> public StateContext create() {
> final G10StateContext stateContext = new
> G10StateContext();
> stateContext.setStartedTime(new Date());
> return stateContext;
> }
> })).create(IoHandler.class, stateMachine);
>
>
> //Global connector across the system, i.e multiple threads uses the same
> connector.
> NioSocketConnector connector = new NioSocketConnector();
> connector.getFilterChain().addLast("LoggingFilter",
> G10CaptureService.loggingFilter);
> connector.getFilterChain().addLast("codecFilter",
> G10CaptureService.probeCodecFilter);
> connector.getFilterChain().addLast("executorFilter",
> G10CaptureService.executorFilter);
> connector.getFilterChain().addLast("gpbMessageFilter",
> G10CaptureService.gpbMessageFilter);
> connector.getFilterChain().addLast("keepAliveFilter",
> G10CaptureService.keepAliveFilter);
> connector.setHandler(ioHandler);
> }
>
> public void StartRecordCapture()
> {
> connectionLock.lock();
> try
> {
> ConnectFuture primaryConnectFuture = connector.connect(primaryAddress,
> initializer);
> //hungs forever if the no. of threads are more than 30
> primaryConnectFuture.awaitUninterruptibly();//no time out specified
> if (!primaryConnectFuture.isConnected())
> {
>
> if (handleIOException(searchExpression, captureHandler)) {
> return;
> }
> LOG.info("{} Apache mina connection setup time out
> happend.",
> handleConnectionFailed(primaryAddress, captureHandler,
> "Primary IP connection timeout");
> return;
> }
> }catch(Exception e)
> {
> }finally
> {
>
[jira] [Comment Edited] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
[
https://issues.apache.org/jira/browse/DIRMINA-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720884#comment-17720884
]
KMVS edited comment on DIRMINA-1173 at 5/9/23 3:20 PM:
---
What the association between NIO Connector and executorFilter ?
*private static final ExecutorFilter executorFilter = new
ExecutorFilter(16,32);*
If I have a static executorFilter then will the worker threads will be shared
across all NIO sockets ?
was (Author: JIRAUSER300071):
How the association between NIO Connector and executorFilter ?
*private static final ExecutorFilter executorFilter = new
ExecutorFilter(16,32);*
If I have a static executorFilter then will the worker threads will be shared
across all NIO sockets ?
> Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly()
> for ever
> ---
>
> Key: DIRMINA-1173
> URL: https://issues.apache.org/jira/browse/DIRMINA-1173
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.1
>Reporter: KMVS
>Priority: Critical
> Attachments: dumpLatest-1.log
>
>
> Hi All,
> I have attached thread dump too for analysis.
> I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at {*}awaitUninterruptibly{*}.
> Once this issue comes in sub sequest launches nothing will work all threads
> will be blocked forever,i have to restart the process to make it work. For
> single thread working fine,if i start 50-100 threads this thread blocking
> issue will surface.I am using the same NioSocketConnector across the threads.
> Here is an scenario, I have one gate way IP which i connect initially ,this
> gate way will return list of ips.
> now i will close the previous IOsession and will create a nio connection with
> the first ip in the list.if it did n't work then again i will try to
> connect to next ip etc..
> All these are in the critical section. i.e i will acquire a lock and then
> after successful connection i will release the lock.
> But problem i have noticed is with the awaitUninterruptibly().
> I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
>
> *Thread 1:*
> Public class g10CaptureService
> {
>
> private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> static
> {
> initConnectors()
> }
> protected static void initConnectors()
> {
> StateMachine stateMachine =
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
> G10MinaClient.CONNECTED, new G10MinaClient(processor));
> IoHandler ioHandler = new
> StateMachineProxyBuilder().setStateContextLookup(
> new IoSessionStateContextLookup(new StateContextFactory() {
> @Override
> public StateContext create() {
> final G10StateContext stateContext = new
> G10StateContext();
> stateContext.setStartedTime(new Date());
> return stateContext;
> }
> })).create(IoHandler.class, stateMachine);
>
>
> //Global connector across the system, i.e multiple threads uses the same
> connector.
> NioSocketConnector connector = new NioSocketConnector();
> connector.getFilterChain().addLast("LoggingFilter",
> G10CaptureService.loggingFilter);
> connector.getFilterChain().addLast("codecFilter",
> G10CaptureService.probeCodecFilter);
> connector.getFilterChain().addLast("executorFilter",
> G10CaptureService.executorFilter);
> connector.getFilterChain().addLast("gpbMessageFilter",
> G10CaptureService.gpbMessageFilter);
> connector.getFilterChain().addLast("keepAliveFilter",
> G10CaptureService.keepAliveFilter);
> connector.setHandler(ioHandler);
> }
>
> public void StartRecordCapture()
> {
> connectionLock.lock();
> try
> {
> ConnectFuture primaryConnectFuture = connector.connect(primaryAddress,
> initializer);
> //hungs forever if the no. of threads are more than 30
> primaryConnectFuture.awaitUninterruptibly();//no time out specified
> if (!primaryConnectFuture.isConnected())
> {
>
> if (handleIOException(searchExpression, captureHandler)) {
>
[jira] [Work logged] (DIRMINA-1122) Add support for endpoint identification algorithm
[ https://issues.apache.org/jira/browse/DIRMINA-1122?focusedWorklogId=861194=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-861194 ] ASF GitHub Bot logged work on DIRMINA-1122: --- Author: ASF GitHub Bot Created on: 09/May/23 13:12 Start Date: 09/May/23 13:12 Worklog Time Spent: 10m Work Description: elecharny commented on PR #26: URL: https://github.com/apache/mina/pull/26#issuecomment-1540100131 Hi, I confirm the first branch (_ssl_endpoint_algorithm_) works. It mimics MINA_2.1.X, using a PEER attribute. Issue Time Tracking --- Worklog Id: (was: 861194) Time Spent: 2.5h (was: 2h 20m) > Add support for endpoint identification algorithm > - > > Key: DIRMINA-1122 > URL: https://issues.apache.org/jira/browse/DIRMINA-1122 > Project: MINA > Issue Type: Improvement > Components: Filter, SSL >Affects Versions: 2.0.22, 2.1.3 >Reporter: Marcin L >Assignee: Jonathan Valliere >Priority: Minor > Fix For: 2.2.0 > > Attachments: > DIRMINA-1122_-_endpoint_identification_algorithm_support.patch > > Time Spent: 2.5h > Remaining Estimate: 0h > > Support for endpoint identification algorithm was added in Java 1.7. > Currently MINA supports providing single SNI name via > org.apache.mina.filter.ssl.SslFilter#PEER_ADDRESS session attribute, but > there is no way verifying it matches the certificate received. > It would be nice if we could provide endpoint identification algorithm to > SslFilter so certificate's common name or subject alternative names are > verified. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina] elecharny commented on pull request #26: DIRMINA-1122 - added support for endpoint identification algorithm
elecharny commented on PR #26: URL: https://github.com/apache/mina/pull/26#issuecomment-1540100131 Hi, I confirm the first branch (_ssl_endpoint_algorithm_) works. It mimics MINA_2.1.X, using a PEER attribute. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Commented] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
[
https://issues.apache.org/jira/browse/DIRMINA-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720884#comment-17720884
]
KMVS commented on DIRMINA-1173:
---
How the association between NIO Connector and executorFilter ?
*private static final ExecutorFilter executorFilter = new
ExecutorFilter(16,32);*
If I have a static executorFilter then will the worker threads will be shared
across all NIO sockets ?
> Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly()
> for ever
> ---
>
> Key: DIRMINA-1173
> URL: https://issues.apache.org/jira/browse/DIRMINA-1173
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.1
>Reporter: KMVS
>Priority: Critical
> Attachments: dumpLatest-1.log
>
>
> Hi All,
> I have attached thread dump too for analysis.
> I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at {*}awaitUninterruptibly{*}.
> Once this issue comes in sub sequest launches nothing will work all threads
> will be blocked forever,i have to restart the process to make it work. For
> single thread working fine,if i start 50-100 threads this thread blocking
> issue will surface.I am using the same NioSocketConnector across the threads.
> Here is an scenario, I have one gate way IP which i connect initially ,this
> gate way will return list of ips.
> now i will close the previous IOsession and will create a nio connection with
> the first ip in the list.if it did n't work then again i will try to
> connect to next ip etc..
> All these are in the critical section. i.e i will acquire a lock and then
> after successful connection i will release the lock.
> But problem i have noticed is with the awaitUninterruptibly().
> I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
>
> *Thread 1:*
> Public class g10CaptureService
> {
>
> private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> static
> {
> initConnectors()
> }
> protected static void initConnectors()
> {
> StateMachine stateMachine =
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
> G10MinaClient.CONNECTED, new G10MinaClient(processor));
> IoHandler ioHandler = new
> StateMachineProxyBuilder().setStateContextLookup(
> new IoSessionStateContextLookup(new StateContextFactory() {
> @Override
> public StateContext create() {
> final G10StateContext stateContext = new
> G10StateContext();
> stateContext.setStartedTime(new Date());
> return stateContext;
> }
> })).create(IoHandler.class, stateMachine);
>
>
> //Global connector across the system, i.e multiple threads uses the same
> connector.
> NioSocketConnector connector = new NioSocketConnector();
> connector.getFilterChain().addLast("LoggingFilter",
> G10CaptureService.loggingFilter);
> connector.getFilterChain().addLast("codecFilter",
> G10CaptureService.probeCodecFilter);
> connector.getFilterChain().addLast("executorFilter",
> G10CaptureService.executorFilter);
> connector.getFilterChain().addLast("gpbMessageFilter",
> G10CaptureService.gpbMessageFilter);
> connector.getFilterChain().addLast("keepAliveFilter",
> G10CaptureService.keepAliveFilter);
> connector.setHandler(ioHandler);
> }
>
> public void StartRecordCapture()
> {
> connectionLock.lock();
> try
> {
> ConnectFuture primaryConnectFuture = connector.connect(primaryAddress,
> initializer);
> //hungs forever if the no. of threads are more than 30
> primaryConnectFuture.awaitUninterruptibly();//no time out specified
> if (!primaryConnectFuture.isConnected())
> {
>
> if (handleIOException(searchExpression, captureHandler)) {
> return;
> }
> LOG.info("{} Apache mina connection setup time out
> happend.",
> handleConnectionFailed(primaryAddress, captureHandler,
> "Primary IP connection timeout");
> return;
> }
> }catch(Exception e)
> {
> }finally
> {
>
[jira] [Commented] (DIRMINA-1173) Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly() for ever
[
https://issues.apache.org/jira/browse/DIRMINA-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17720882#comment-17720882
]
KMVS commented on DIRMINA-1173:
---
How to scale Apache mina ?
my execution filter has min 16 threads and max 32 threads, these threads are
not sufficient to
go parallelly on 135 sniffers for polling the data.
*Here is the execution filter looks like:*
*private static final ExecutorFilter executorFilter = new
ExecutorFilter(16,32);*
Is it make sense if i increase the pool size to 100 ?
where all i can improve scaling in mina ?
> Apache mina 2.2.1 threads blocking on ConnectFuture.awaitUninterruptibly()
> for ever
> ---
>
> Key: DIRMINA-1173
> URL: https://issues.apache.org/jira/browse/DIRMINA-1173
> Project: MINA
> Issue Type: Bug
> Components: Core
>Affects Versions: 2.2.1
>Reporter: KMVS
>Priority: Critical
> Attachments: dumpLatest-1.log
>
>
> Hi All,
> I have attached thread dump too for analysis.
> I have migrated from 2.0.21 to 2.023 for solving CVE, i have seen thread
> blocking issue, So used latest mina verstion 2.2.1 but still threads were
> blocked here is the sample code.Thread hungs at {*}awaitUninterruptibly{*}.
> Once this issue comes in sub sequest launches nothing will work all threads
> will be blocked forever,i have to restart the process to make it work. For
> single thread working fine,if i start 50-100 threads this thread blocking
> issue will surface.I am using the same NioSocketConnector across the threads.
> Here is an scenario, I have one gate way IP which i connect initially ,this
> gate way will return list of ips.
> now i will close the previous IOsession and will create a nio connection with
> the first ip in the list.if it did n't work then again i will try to
> connect to next ip etc..
> All these are in the critical section. i.e i will acquire a lock and then
> after successful connection i will release the lock.
> But problem i have noticed is with the awaitUninterruptibly().
> I have a state machine too. So connection set up is in one thread and
> response processing is in another thread.
>
> *Thread 1:*
> Public class g10CaptureService
> {
>
> private static final ProtocolCodecFilter probeCodecFilter = new
> ProtocolCodecFilter(new ProbeCodecFactory(G10Message.class));
> *private static final ExecutorFilter executorFilter = new
> ExecutorFilter(16,32);*
> private static final G10GPBMessageIoFilter gpbMessageFilter = new
> G10GPBMessageIoFilter(G10ParserContextFactory.getG10ParsingAndEncodingInstance());
> static
> {
> initConnectors()
> }
> protected static void initConnectors()
> {
> StateMachine stateMachine =
> StateMachineFactory.getInstance(IoHandlerTransition.class).create(
> G10MinaClient.CONNECTED, new G10MinaClient(processor));
> IoHandler ioHandler = new
> StateMachineProxyBuilder().setStateContextLookup(
> new IoSessionStateContextLookup(new StateContextFactory() {
> @Override
> public StateContext create() {
> final G10StateContext stateContext = new
> G10StateContext();
> stateContext.setStartedTime(new Date());
> return stateContext;
> }
> })).create(IoHandler.class, stateMachine);
>
>
> //Global connector across the system, i.e multiple threads uses the same
> connector.
> NioSocketConnector connector = new NioSocketConnector();
> connector.getFilterChain().addLast("LoggingFilter",
> G10CaptureService.loggingFilter);
> connector.getFilterChain().addLast("codecFilter",
> G10CaptureService.probeCodecFilter);
> connector.getFilterChain().addLast("executorFilter",
> G10CaptureService.executorFilter);
> connector.getFilterChain().addLast("gpbMessageFilter",
> G10CaptureService.gpbMessageFilter);
> connector.getFilterChain().addLast("keepAliveFilter",
> G10CaptureService.keepAliveFilter);
> connector.setHandler(ioHandler);
> }
>
> public void StartRecordCapture()
> {
> connectionLock.lock();
> try
> {
> ConnectFuture primaryConnectFuture = connector.connect(primaryAddress,
> initializer);
> //hungs forever if the no. of threads are more than 30
> primaryConnectFuture.awaitUninterruptibly();//no time out specified
> if (!primaryConnectFuture.isConnected())
> {
>
> if (handleIOException(searchExpression, captureHandler)) {
> return;
> }
> LOG.info("{} Apache mina connection setup time out
> happend.",
> handleConnectionFailed(primaryAddress,
[jira] [Work logged] (DIRMINA-1122) Add support for endpoint identification algorithm
[ https://issues.apache.org/jira/browse/DIRMINA-1122?focusedWorklogId=861155=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-861155 ] ASF GitHub Bot logged work on DIRMINA-1122: --- Author: ASF GitHub Bot Created on: 09/May/23 09:20 Start Date: 09/May/23 09:20 Worklog Time Spent: 10m Work Description: the-thing commented on PR #26: URL: https://github.com/apache/mina/pull/26#issuecomment-1539764637 I was able to crate 2 branches based of 2.2.X and they both work (still waiting for the CI to run). 1) The old method - by providing the peer address. https://github.com/the-thing/mina/tree/ssl_endpoint_algorithm Probably not desired. 2) Without providing the peer address - requires additional serverNames parameter https://github.com/the-thing/mina/tree/ssl_endpoint_2 The problem with this method is that the actual server peer address will not be automatically verified and will have to be passed as a "serverName". 3) There is also another fix that doesn't require any of the above. The unit tests uses "localhost" as a host name so I would have to recreate the keystores with appropriate hostname patterns. Issue Time Tracking --- Worklog Id: (was: 861155) Time Spent: 2h 20m (was: 2h 10m) > Add support for endpoint identification algorithm > - > > Key: DIRMINA-1122 > URL: https://issues.apache.org/jira/browse/DIRMINA-1122 > Project: MINA > Issue Type: Improvement > Components: Filter, SSL >Affects Versions: 2.0.22, 2.1.3 >Reporter: Marcin L >Assignee: Jonathan Valliere >Priority: Minor > Fix For: 2.2.0 > > Attachments: > DIRMINA-1122_-_endpoint_identification_algorithm_support.patch > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Support for endpoint identification algorithm was added in Java 1.7. > Currently MINA supports providing single SNI name via > org.apache.mina.filter.ssl.SslFilter#PEER_ADDRESS session attribute, but > there is no way verifying it matches the certificate received. > It would be nice if we could provide endpoint identification algorithm to > SslFilter so certificate's common name or subject alternative names are > verified. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[GitHub] [mina] the-thing commented on pull request #26: DIRMINA-1122 - added support for endpoint identification algorithm
the-thing commented on PR #26: URL: https://github.com/apache/mina/pull/26#issuecomment-1539764637 I was able to crate 2 branches based of 2.2.X and they both work (still waiting for the CI to run). 1) The old method - by providing the peer address. https://github.com/the-thing/mina/tree/ssl_endpoint_algorithm Probably not desired. 2) Without providing the peer address - requires additional serverNames parameter https://github.com/the-thing/mina/tree/ssl_endpoint_2 The problem with this method is that the actual server peer address will not be automatically verified and will have to be passed as a "serverName". 3) There is also another fix that doesn't require any of the above. The unit tests uses "localhost" as a host name so I would have to recreate the keystores with appropriate hostname patterns. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
[jira] [Work logged] (DIRMINA-1122) Add support for endpoint identification algorithm
[ https://issues.apache.org/jira/browse/DIRMINA-1122?focusedWorklogId=861120=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-861120 ] ASF GitHub Bot logged work on DIRMINA-1122: --- Author: ASF GitHub Bot Created on: 09/May/23 05:59 Start Date: 09/May/23 05:59 Worklog Time Spent: 10m Work Description: elecharny commented on PR #26: URL: https://github.com/apache/mina/pull/26#issuecomment-1539456424 Also tested something: using the **sniHostNames** instead of doing a _peer.getHostString()_, changes nothing... Issue Time Tracking --- Worklog Id: (was: 861120) Time Spent: 2h 10m (was: 2h) > Add support for endpoint identification algorithm > - > > Key: DIRMINA-1122 > URL: https://issues.apache.org/jira/browse/DIRMINA-1122 > Project: MINA > Issue Type: Improvement > Components: Filter, SSL >Affects Versions: 2.0.22, 2.1.3 >Reporter: Marcin L >Assignee: Jonathan Valliere >Priority: Minor > Fix For: 2.2.0 > > Attachments: > DIRMINA-1122_-_endpoint_identification_algorithm_support.patch > > Time Spent: 2h 10m > Remaining Estimate: 0h > > Support for endpoint identification algorithm was added in Java 1.7. > Currently MINA supports providing single SNI name via > org.apache.mina.filter.ssl.SslFilter#PEER_ADDRESS session attribute, but > there is no way verifying it matches the certificate received. > It would be nice if we could provide endpoint identification algorithm to > SslFilter so certificate's common name or subject alternative names are > verified. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org For additional commands, e-mail: dev-h...@mina.apache.org
