[JBoss JIRA] (WFLY-10011) Incorrect number of messages on queue after remove of scheduled message
by Martyn Taylor (JIRA)
Martyn Taylor created WFLY-10011:
------------------------------------
Summary: Incorrect number of messages on queue after remove of scheduled message
Key: WFLY-10011
URL: https://issues.jboss.org/browse/WFLY-10011
Project: WildFly
Issue Type: Bug
Components: JMS
Reporter: Martyn Taylor
Assignee: Martyn Taylor
Removing scheduled message from queue cause incorrect number of messages reported by {{count-messages}} operation.
It looks like the operation {{count-messages}} returns value equal to _actual number of messages_ minus _number of removed scheduled messages_
*Scenario*
# send 1 message with _AMQ_SCHED_DELIVERY property set to several minutes
# remove scheduled emssage using CLI operation {{remove-message}}
# find out number of messages on queue using CLI operation {{count-messages}} - it returns value -1
This is broker related issue. It is regression against Artemis 1.5.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-10003) Client is not able to create queues
by Martyn Taylor (JIRA)
[ https://issues.jboss.org/browse/WFLY-10003?page=com.atlassian.jira.plugin... ]
Martyn Taylor updated WFLY-10003:
---------------------------------
Labels: feature-branch-blocker (was: )
> Client is not able to create queues
> -----------------------------------
>
> Key: WFLY-10003
> URL: https://issues.jboss.org/browse/WFLY-10003
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Martin Styk
> Assignee: Martyn Taylor
> Labels: feature-branch-blocker
>
> Client is not able to create queues.
> Following operations fail:
> * {{javax.jms.session.createTemporaryQueue()}}
> * {{org.apache.activemq.artemis.api,core.client.createQueue()}}
> Server logs:
> {noformat}
> 12:29:55,538 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl] (default I/O-7) RemotingConnectionID=461fd762 handling packet PACKET(CreateQueueMessage)[type=34, channelID=11, packetObject=CreateQueueMessage, address=jms.tempqueue.99f18991-b080-4b3e-ac07-bb023590337f, queueName=jms.tempqueue.99f18991-b080-4b3e-ac07-bb023590337f, filterString=null, durable=false, temporary=true]
> 12:29:55,538 TRACE [org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler] (Thread-13 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@7d7bc58e)) ServerSessionPacketHandler::handlePacket,PACKET(CreateQueueMessage)[type=34, channelID=11, packetObject=CreateQueueMessage, address=jms.tempqueue.99f18991-b080-4b3e-ac07-bb023590337f, queueName=jms.tempqueue.99f18991-b080-4b3e-ac07-bb023590337f, filterString=null, durable=false, temporary=true]
> 12:29:55,550 DEBUG [org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler] (Thread-13 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@7d7bc58e)) Sending exception to client: ActiveMQAddressDoesNotExistException[errorType=ADDRESS_DOES_NOT_EXIST message=AMQ119203: Address Does Not Exist: jms.tempqueue.99f18991-b080-4b3e-ac07-bb023590337f]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:2747) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:1676) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:588) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:628) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:556) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.slowPacketHandler(ServerSessionPacketHandler.java:346) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.onMessagePacket(ServerSessionPacketHandler.java:281) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.Actor.doTask(Actor.java:33) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_161]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_161]
> at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> {noformat}
> Client recieves following exception
> {noformat}
> javax.jms.JMSException: AMQ119203: Address Does Not Exist: jms.tempqueue.bb5dea5c-dadd-42ef-bd3d-e0da42264d41, code:GENERIC_EXCEPTION
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:404)
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:315)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.createQueue(ActiveMQSessionContext.java:572)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.internalCreateQueue(ClientSessionImpl.java:1551)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.createTemporaryQueue(ClientSessionImpl.java:299)
> at org.apache.activemq.artemis.jms.client.ActiveMQSession.createTemporaryQueue(ActiveMQSession.java:812)
> {noformat}
> This is broker related issue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-10002) Incorrect number of messages on queue after remove of scheduled message
by Martyn Taylor (JIRA)
[ https://issues.jboss.org/browse/WFLY-10002?page=com.atlassian.jira.plugin... ]
Martyn Taylor updated WFLY-10002:
---------------------------------
Labels: feature-branch-blocker (was: )
> Incorrect number of messages on queue after remove of scheduled message
> -----------------------------------------------------------------------
>
> Key: WFLY-10002
> URL: https://issues.jboss.org/browse/WFLY-10002
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Martin Styk
> Assignee: Martyn Taylor
> Labels: feature-branch-blocker
>
> Removing scheduled message from queue cause incorrect number of messages reported by {{count-messages}} operation.
> It looks like the operation {{count-messages}} returns value equal to _actual number of messages_ minus _number of removed scheduled messages_
> *Scenario*
> # send 1 message with _AMQ_SCHED_DELIVERY property set to several minutes
> # remove scheduled emssage using CLI operation {{remove-message}}
> # find out number of messages on queue using CLI operation {{count-messages}} - it returns value -1
> This is broker related issue. It is regression against Artemis 1.5.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-10002) Incorrect number of messages on queue after remove of scheduled message
by Martyn Taylor (JIRA)
[ https://issues.jboss.org/browse/WFLY-10002?page=com.atlassian.jira.plugin... ]
Martyn Taylor reassigned WFLY-10002:
------------------------------------
Assignee: Martyn Taylor (was: Jeff Mesnil)
> Incorrect number of messages on queue after remove of scheduled message
> -----------------------------------------------------------------------
>
> Key: WFLY-10002
> URL: https://issues.jboss.org/browse/WFLY-10002
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Martin Styk
> Assignee: Martyn Taylor
>
> Removing scheduled message from queue cause incorrect number of messages reported by {{count-messages}} operation.
> It looks like the operation {{count-messages}} returns value equal to _actual number of messages_ minus _number of removed scheduled messages_
> *Scenario*
> # send 1 message with _AMQ_SCHED_DELIVERY property set to several minutes
> # remove scheduled emssage using CLI operation {{remove-message}}
> # find out number of messages on queue using CLI operation {{count-messages}} - it returns value -1
> This is broker related issue. It is regression against Artemis 1.5.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-10003) Client is not able to create queues
by Martyn Taylor (JIRA)
[ https://issues.jboss.org/browse/WFLY-10003?page=com.atlassian.jira.plugin... ]
Martyn Taylor reassigned WFLY-10003:
------------------------------------
Assignee: Martyn Taylor (was: Jeff Mesnil)
> Client is not able to create queues
> -----------------------------------
>
> Key: WFLY-10003
> URL: https://issues.jboss.org/browse/WFLY-10003
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Martin Styk
> Assignee: Martyn Taylor
>
> Client is not able to create queues.
> Following operations fail:
> * {{javax.jms.session.createTemporaryQueue()}}
> * {{org.apache.activemq.artemis.api,core.client.createQueue()}}
> Server logs:
> {noformat}
> 12:29:55,538 TRACE [org.apache.activemq.artemis.core.protocol.core.impl.RemotingConnectionImpl] (default I/O-7) RemotingConnectionID=461fd762 handling packet PACKET(CreateQueueMessage)[type=34, channelID=11, packetObject=CreateQueueMessage, address=jms.tempqueue.99f18991-b080-4b3e-ac07-bb023590337f, queueName=jms.tempqueue.99f18991-b080-4b3e-ac07-bb023590337f, filterString=null, durable=false, temporary=true]
> 12:29:55,538 TRACE [org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler] (Thread-13 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@7d7bc58e)) ServerSessionPacketHandler::handlePacket,PACKET(CreateQueueMessage)[type=34, channelID=11, packetObject=CreateQueueMessage, address=jms.tempqueue.99f18991-b080-4b3e-ac07-bb023590337f, queueName=jms.tempqueue.99f18991-b080-4b3e-ac07-bb023590337f, filterString=null, durable=false, temporary=true]
> 12:29:55,550 DEBUG [org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler] (Thread-13 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$5@7d7bc58e)) Sending exception to client: ActiveMQAddressDoesNotExistException[errorType=ADDRESS_DOES_NOT_EXIST message=AMQ119203: Address Does Not Exist: jms.tempqueue.99f18991-b080-4b3e-ac07-bb023590337f]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:2747) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl.createQueue(ActiveMQServerImpl.java:1676) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:588) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:628) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.server.impl.ServerSessionImpl.createQueue(ServerSessionImpl.java:556) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.slowPacketHandler(ServerSessionPacketHandler.java:346) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.core.protocol.core.ServerSessionPacketHandler.onMessagePacket(ServerSessionPacketHandler.java:281) [artemis-server-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.Actor.doTask(Actor.java:33) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:42) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.OrderedExecutor.doTask(OrderedExecutor.java:31) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at org.apache.activemq.artemis.utils.actors.ProcessorBase.executePendingTasks(ProcessorBase.java:66) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [rt.jar:1.8.0_161]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [rt.jar:1.8.0_161]
> at org.apache.activemq.artemis.utils.ActiveMQThreadFactory$1.run(ActiveMQThreadFactory.java:118) [artemis-commons-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> {noformat}
> Client recieves following exception
> {noformat}
> javax.jms.JMSException: AMQ119203: Address Does Not Exist: jms.tempqueue.bb5dea5c-dadd-42ef-bd3d-e0da42264d41, code:GENERIC_EXCEPTION
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:404)
> at org.apache.activemq.artemis.core.protocol.core.impl.ChannelImpl.sendBlocking(ChannelImpl.java:315)
> at org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQSessionContext.createQueue(ActiveMQSessionContext.java:572)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.internalCreateQueue(ClientSessionImpl.java:1551)
> at org.apache.activemq.artemis.core.client.impl.ClientSessionImpl.createTemporaryQueue(ClientSessionImpl.java:299)
> at org.apache.activemq.artemis.jms.client.ActiveMQSession.createTemporaryQueue(ActiveMQSession.java:812)
> {noformat}
> This is broker related issue.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9921) Unable to create SSL connection if expired certificate chain used
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-9921?page=com.atlassian.jira.plugin.... ]
Martin Choma commented on WFLY-9921:
------------------------------------
[~honza889] you are right. It fits together as you describe. The key fact is "java trust manager check certificates expiration only for subordinate certificates". Thank you.
> Unable to create SSL connection if expired certificate chain used
> -----------------------------------------------------------------
>
> Key: WFLY-9921
> URL: https://issues.jboss.org/browse/WFLY-9921
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 12.0.0.CR1
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Attachments: ssl_handshake_CA.log, ssl_handshake_certificate.log
>
>
> Reproducer:
> * Server secured by certificate chain, it means Certificate is signed with Intermediate CA which is signed by root CA.
> * Server certificate is expired
> * Client has Intermediate CA in Elytron truststore
> * SSL handshake fails using Elytron client ssl context:
> {code}
> 18:27:54,540 INFO [stdout] (default task-1) default task-1, SEND TLSv1 ALERT: fatal, description = certificate_unknown
> 18:27:54,540 INFO [stdout] (default task-1) default task-1, WRITE: TLSv1 Alert, length = 2
> 18:27:54,540 INFO [stdout] (default task-1) [Raw write]: length = 7
> 18:27:54,540 INFO [stdout] (default task-1) 0000: 15 03 01 00 02 02 2E .......
> 18:27:54,541 INFO [stdout] (default task-1) default task-1, called closeSocket()
> 18:27:54,541 INFO [stdout] (default task-1) default task-1, handling exception: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateExpiredException: NotAfter: Sat Dec 16 10:49:56 CET 2017
> {code}
> Full SSL handshake log is in attached ssl_handshake_CA.log
> * If I put expired certificate itself into truststore SSL handshake pass, although warning is logged.
> {code}
> 18:35:28,648 WARN [org.wildfly.extension.elytron] (MSC service thread 1-8) WFLYELY00024: Certificate [cn=rhds05.mw.lab.eng.bos.redhat.com, ou=engineering operations, o="red hat, inc.", st=north carolina, c=us] in KeyStore is not valid: java.security.cert.CertificateExpiredException: NotAfter: Sat Dec 16 12:39:06 CET 2017
> at sun.security.x509.CertificateValidity.valid(CertificateValidity.java:274)
> at sun.security.x509.X509CertImpl.checkValidity(X509CertImpl.java:629)
> at sun.security.x509.X509CertImpl.checkValidity(X509CertImpl.java:602)
> at org.wildfly.extension.elytron.KeyStoreService.checkCertificatesValidity(KeyStoreService.java:177)
> at org.wildfly.extension.elytron.KeyStoreService.start(KeyStoreService.java:140)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1680)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1527)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1374)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Full SSL handshake log is in attached ssl_handshake_certificate.log
> So behaviour in these 2 cases is inconsistent. I think we have agreed before we let pass SSL handshake with expired certificate but warn about it in log [1].
> [1] https://issues.jboss.org/browse/JBEAP-6157
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months
[JBoss JIRA] (WFLY-9921) Unable to create SSL connection if expired certificate chain used
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/WFLY-9921?page=com.atlassian.jira.plugin.... ]
Jan Kalina commented on WFLY-9921:
----------------------------------
As discussed in JBEAP-3829, *java trust manager* check certificates expiration only for subordinate certificates - expiration of certificates present directly in truststore is ignored.
The warning message is independent feature requested in JBEAP-6157 - Elytron warns when is loads *keystore* containing expired certificate in Elytron subsystem.
[~mchoma] I don't see inconsistency here. This two are independent features, so different check conditions are ok.
> Unable to create SSL connection if expired certificate chain used
> -----------------------------------------------------------------
>
> Key: WFLY-9921
> URL: https://issues.jboss.org/browse/WFLY-9921
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 12.0.0.CR1
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Attachments: ssl_handshake_CA.log, ssl_handshake_certificate.log
>
>
> Reproducer:
> * Server secured by certificate chain, it means Certificate is signed with Intermediate CA which is signed by root CA.
> * Server certificate is expired
> * Client has Intermediate CA in Elytron truststore
> * SSL handshake fails using Elytron client ssl context:
> {code}
> 18:27:54,540 INFO [stdout] (default task-1) default task-1, SEND TLSv1 ALERT: fatal, description = certificate_unknown
> 18:27:54,540 INFO [stdout] (default task-1) default task-1, WRITE: TLSv1 Alert, length = 2
> 18:27:54,540 INFO [stdout] (default task-1) [Raw write]: length = 7
> 18:27:54,540 INFO [stdout] (default task-1) 0000: 15 03 01 00 02 02 2E .......
> 18:27:54,541 INFO [stdout] (default task-1) default task-1, called closeSocket()
> 18:27:54,541 INFO [stdout] (default task-1) default task-1, handling exception: javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateExpiredException: NotAfter: Sat Dec 16 10:49:56 CET 2017
> {code}
> Full SSL handshake log is in attached ssl_handshake_CA.log
> * If I put expired certificate itself into truststore SSL handshake pass, although warning is logged.
> {code}
> 18:35:28,648 WARN [org.wildfly.extension.elytron] (MSC service thread 1-8) WFLYELY00024: Certificate [cn=rhds05.mw.lab.eng.bos.redhat.com, ou=engineering operations, o="red hat, inc.", st=north carolina, c=us] in KeyStore is not valid: java.security.cert.CertificateExpiredException: NotAfter: Sat Dec 16 12:39:06 CET 2017
> at sun.security.x509.CertificateValidity.valid(CertificateValidity.java:274)
> at sun.security.x509.X509CertImpl.checkValidity(X509CertImpl.java:629)
> at sun.security.x509.X509CertImpl.checkValidity(X509CertImpl.java:602)
> at org.wildfly.extension.elytron.KeyStoreService.checkCertificatesValidity(KeyStoreService.java:177)
> at org.wildfly.extension.elytron.KeyStoreService.start(KeyStoreService.java:140)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1701)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1680)
> at org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1527)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1481)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1374)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Full SSL handshake log is in attached ssl_handshake_certificate.log
> So behaviour in these 2 cases is inconsistent. I think we have agreed before we let pass SSL handshake with expired certificate but warn about it in log [1].
> [1] https://issues.jboss.org/browse/JBEAP-6157
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 3 months