[JBoss JIRA] (ELY-1732) Intermittently failing AcmeClientSpiTest
by Ilia Vassilev (Jira)
[ https://issues.jboss.org/browse/ELY-1732?page=com.atlassian.jira.plugin.s... ]
Ilia Vassilev reassigned ELY-1732:
----------------------------------
Assignee: Ilia Vassilev (was: Farah Juma)
> Intermittently failing AcmeClientSpiTest
> ----------------------------------------
>
> Key: ELY-1732
> URL: https://issues.jboss.org/browse/ELY-1732
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Affects Versions: 1.7.0.CR2
> Reporter: Ilia Vassilev
> Assignee: Ilia Vassilev
> Priority: Minor
> Fix For: 1.8.0.CR1
>
>
> We see this failing with ratio 1:100 with error "ELY10038: Unexpected HTTP status code in response from ACME server "404": "Not Found""
> {noformat}
> org.wildfly.security.x500.cert.acme.AcmeException: ELY10038: Unexpected HTTP status code in response from ACME server "404": "Not Found"
> at org.wildfly.security.x500.cert.acme.AcmeClientSpi.handleAcmeErrorResponse(AcmeClientSpi.java:907)
> at org.wildfly.security.x500.cert.acme.AcmeClientSpi.sendGetRequest(AcmeClientSpi.java:728)
> at org.wildfly.security.x500.cert.acme.AcmeClientSpi.getResourceUrls(AcmeClientSpi.java:183)
> at org.wildfly.security.x500.cert.acme.AcmeClientSpi.getResourceUrl(AcmeClientSpi.java:711)
> at org.wildfly.security.x500.cert.acme.AcmeClientSpi.revokeCertificate(AcmeClientSpi.java:639)
> at org.wildfly.security.x500.cert.acme.AcmeClientSpiTest.revokeCertificate(AcmeClientSpiTest.java:334)
> at org.wildfly.security.x500.cert.acme.AcmeClientSpiTest.testRevokeCertificateWithReason(AcmeClientSpiTest.java:324)
> {noformat}
> {noformat}
> 00:27:53,593 INFO (nioEventLoopGroup-3-2) [org.mockserver.mock.HttpStateHandler] <LoggingFormatter.java:34> returning response:
> {
> "statusCode" : 200,
> "headers" : {
> "Cache-Control" : [ "public, max-age=0, no-cache" ],
> "Replay-Nonce" : [ "NT_I4byOA1qs22GwXEcNp9RNyoq4hO6JTBMh1iUK3yI" ],
> "Content-Type" : [ "application/json" ],
> "Link" : [ "<https://boulder:4431/terms/v7>;rel=\"terms-of-service\"" ],
> "connection" : [ "keep-alive" ]
> },
> "body" : "{\n \"id\": 384,\n \"key\": {\n \"kty\": \"RSA\",\n \"n\": \"puL-WcMYUJ2Ajdy1UsUgNzjn6ecDxiWd7NGUGq267SOLwhKjSWWMwkopfcg5VMjPJWEE38IIXyjW5nFKCqFAIf3Zlih_1SLcjgVFbibn-oMGFLZs9ggr2bjRGJsbsJQIOKmgVs2y3l5RcIyF2M-UOx4GtAUQJsYittchBLxqjs0SBjWdtpWzaX4fwTCzx48RXuZhky_mKAyKbhAYnIGdDhcVIZsff6zzEM1bpJED6OBZh6pyP-N0kOxcGmPPCHMf0MzwjnK8VrFPEaIIfQAbUC1rTauiqZX7glEnN2kYqOwl8g3nf5fbX6sUuDU15fV0cmdUthy8_GHyE2qdzjPRLw\",\n \"e\": \"AQAB\"\n },\n \"contact\": [\n \"mailto:certificates@example.com\",\n \"mailto:admin@example.com\"\n ],\n \"initialIp\": \"127.0.0.1\",\n \"createdAt\": \"2018-04-23T11:10:28-04:00\",\n \"status\": \"valid\"\n}\n"
> }
> for request:
> {
> "method" : "POST",
> "path" : "/acme/acct/384",
> "body" : "{\"protected\":\"eyJhbGciOiJSUzI1NiIsImtpZCI6Imh0dHA6Ly9sb2NhbGhvc3Q6NDAwMS9hY21lL2FjY3QvMzg0Iiwibm9uY2UiOiJma0Q4QkRreW5mSEUxVUVTcFV2SHRDTGE0UzJXa0NJd3BYZE80N1EzdnpBIiwidXJsIjoiaHR0cDovL2xvY2FsaG9zdDo0MDAxL2FjbWUvYWNjdC8zODQifQ\",\"payload\":\"e30\",\"signature\":\"cyg9Mgmgw4KcTGB96Uz1XPflyZCXgBYWRTiuppLLBMVYBG-eZvrCvzkjqlBTXfmixpBaCPoYU9PnNg3FEYgYzut8zgOsrvcgyu7byYdxnO9LxtxFCnLYPp8xGyoRD9W3owAxcbKnwTf3rmxhSKBRCDZnGs-JuZqJc25kbK4tLNZLaPfdyBS3oaE7xzxKrz6waLCIt9_CoRlSjqc9ZY9P8syUVdkdmdMtlyZJPJNt-keteulOA2_4xZzUV0RdxswlivT3v5Zz9bDuj5JPtHx-1NHSjRhLcM2pl2wk9pvm35q4_au4DjiP5enP-x_-qn6fXJuNUsuUdv_DHjmWLYL7Vw\"}",
> "headers" : {
> "Accept" : [ "text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2" ],
> "User-Agent" : [ "Elytron ACME Client/1.7.0.CR2" ],
> "Connection" : [ "keep-alive" ],
> "Host" : [ "localhost:4001" ],
> "Accept-Language" : [ "en-US" ],
> "Content-Length" : [ "599" ],
> "Content-Type" : [ "application/jose+json" ]
> },
> "keepAlive" : true,
> "secure" : false
> }
> for response action:
> {
> "statusCode" : 200,
> "headers" : {
> "Cache-Control" : [ "public, max-age=0, no-cache" ],
> "Replay-Nonce" : [ "NT_I4byOA1qs22GwXEcNp9RNyoq4hO6JTBMh1iUK3yI" ],
> "Content-Type" : [ "application/json" ],
> "Link" : [ "<https://boulder:4431/terms/v7>;rel=\"terms-of-service\"" ]
> },
> "body" : "{\n \"id\": 384,\n \"key\": {\n \"kty\": \"RSA\",\n \"n\": \"puL-WcMYUJ2Ajdy1UsUgNzjn6ecDxiWd7NGUGq267SOLwhKjSWWMwkopfcg5VMjPJWEE38IIXyjW5nFKCqFAIf3Zlih_1SLcjgVFbibn-oMGFLZs9ggr2bjRGJsbsJQIOKmgVs2y3l5RcIyF2M-UOx4GtAUQJsYittchBLxqjs0SBjWdtpWzaX4fwTCzx48RXuZhky_mKAyKbhAYnIGdDhcVIZsff6zzEM1bpJED6OBZh6pyP-N0kOxcGmPPCHMf0MzwjnK8VrFPEaIIfQAbUC1rTauiqZX7glEnN2kYqOwl8g3nf5fbX6sUuDU15fV0cmdUthy8_GHyE2qdzjPRLw\",\n \"e\": \"AQAB\"\n },\n \"contact\": [\n \"mailto:certificates@example.com\",\n \"mailto:admin@example.com\"\n ],\n \"initialIp\": \"127.0.0.1\",\n \"createdAt\": \"2018-04-23T11:10:28-04:00\",\n \"status\": \"valid\"\n}\n"
> }
> 00:27:53,601 INFO (nioEventLoopGroup-3-3) [org.mockserver.mock.HttpStateHandler] <LoggingFormatter.java:34> resetting all expectations and request logs
> 00:27:53,618 INFO (nioEventLoopGroup-3-4) [org.mockserver.mock.HttpStateHandler] <LoggingFormatter.java:34> creating expectation:
> {
> "httpRequest" : {
> "method" : "GET",
> "path" : "/directory"
> },
> "times" : {
> "remainingTimes" : 1,
> "unlimited" : false
> },
> "timeToLive" : {
> "unlimited" : true
> },
> "httpResponse" : {
> "headers" : {
> "Cache-Control" : [ "public, max-age=0, no-cache" ],
> "Content-Type" : [ "application/json" ]
> },
> "body" : "{\n \"FpVd7yM-nVU\": \"https://community.letsencrypt.org/t/adding-random-entries-to-the-director...",\n \"keyChange\": \"http://localhost:4001/acme/key-change\",\n \"meta\": {\n \"caaIdentities\": [\n \"happy-hacker-ca.invalid\"\n ],\n \"termsOfService\": \"https://boulder:4431/terms/v7\",\n \"website\": \"https://github.com/letsencrypt/boulder\"\n },\n \"newAccount\": \"http://localhost:4001/acme/new-acct\",\n \"newNonce\": \"http://localhost:4001/acme/new-nonce\",\n \"newOrder\": \"http://localhost:4001/acme/new-order\",\n \"revokeCert\": \"http://localhost:4001/acme/revoke-cert\"\n}\n"
> }
> }
> 00:27:53,634 INFO (nioEventLoopGroup-3-1) [org.mockserver.mock.HttpStateHandler] <LoggingFormatter.java:34> creating expectation:
> {
> "httpRequest" : {
> "method" : "HEAD",
> "path" : "/acme/new-nonce"
> },
> "times" : {
> "remainingTimes" : 1,
> "unlimited" : false
> },
> "timeToLive" : {
> "unlimited" : true
> },
> "httpResponse" : {
> "statusCode" : 204,
> "headers" : {
> "Cache-Control" : [ "public, max-age=0, no-cache" ],
> "Replay-Nonce" : [ "-mlJhcox_6FFuDwNhcmL06FWD6uL7K7lam9Jel-MqqM" ]
> }
> }
> }
> 00:27:53,656 INFO (nioEventLoopGroup-3-2) [org.mockserver.mock.HttpStateHandler] <LoggingFormatter.java:34> creating expectation:
> {
> "httpRequest" : {
> "method" : "POST",
> "path" : "/acme/new-acct",
> "body" : "{\"protected\":\"eyJhbGciOiJSUzI1NiIsImp3ayI6eyJlIjoiQVFBQiIsImt0eSI6IlJTQSIsIm4iOiJwdUwtV2NNWVVKMkFqZHkxVXNVZ056am42ZWNEeGlXZDdOR1VHcTI2N1NPTHdoS2pTV1dNd2tvcGZjZzVWTWpQSldFRTM4SUlYeWpXNW5GS0NxRkFJZjNabGloXzFTTGNqZ1ZGYmlibi1vTUdGTFpzOWdncjJialJHSnNic0pRSU9LbWdWczJ5M2w1UmNJeUYyTS1VT3g0R3RBVVFKc1lpdHRjaEJMeHFqczBTQmpXZHRwV3phWDRmd1RDeng0OFJYdVpoa3lfbUtBeUtiaEFZbklHZERoY1ZJWnNmZjZ6ekVNMWJwSkVENk9CWmg2cHlQLU4wa094Y0dtUFBDSE1mME16d2puSzhWckZQRWFJSWZRQWJVQzFyVGF1aXFaWDdnbEVuTjJrWXFPd2w4ZzNuZjVmYlg2c1V1RFUxNWZWMGNtZFV0aHk4X0dIeUUycWR6alBSTHcifSwibm9uY2UiOiItbWxKaGNveF82RkZ1RHdOaGNtTDA2RldENnVMN0s3bGFtOUplbC1NcXFNIiwidXJsIjoiaHR0cDovL2xvY2FsaG9zdDo0MDAxL2FjbWUvbmV3LWFjY3QifQ\",\"payload\":\"eyJvbmx5UmV0dXJuRXhpc3RpbmciOnRydWV9\",\"signature\":\"lztzTXBmbrxXGMspfEetHDGKdZ2NrpQTioysqHIa9aaL5dy8bPmKZ_Vmz68-xnUJcjK-5FMCn5vtYEKAJlJ7W3wVYzthcVuYlv-b6FNw3IYsdSSHMr5RLm0rSt9EwYd-BI4bCoT7dioYpCMHzTrd-3X8QjDS4fx1o6D-po_Hwkt4PWx5Yoo9ExlykM5cHOQlCQENPk3Pn0M4_8XkfH1QTvVTIm4A4lbo_Eko1aU9PgvWbNsqkEhRzH7rBb5FUlxFgRoSHuTJwn6uJL-H0cfYQUn-J5JyD5C-P8su3M7NoAXCj0vy_84TziHMxe1C8fI-A64M6CtlL9qGm5MwPgv8Gg\"}"
> },
> "times" : {
> "remainingTimes" : 1,
> "unlimited" : false
> },
> "timeToLive" : {
> "unlimited" : true
> },
> "httpResponse" : {
> "statusCode" : 200,
> "headers" : {
> "Cache-Control" : [ "public, max-age=0, no-cache" ],
> "Replay-Nonce" : [ "zbQR7CL_GSx0oydZ0AVoNEh7omY_XONdWFpYOfeFVQc" ],
> "Link" : [ "<https://boulder:4431/terms/v7>;rel=\"terms-of-service\"" ],
> "Location" : [ "http://localhost:4001/acme/acct/384" ]
> }
> }
> }
> 00:27:53,700 INFO (nioEventLoopGroup-3-3) [org.mockserver.mock.HttpStateHandler] <LoggingFormatter.java:34> creating expectation:
> {
> "httpRequest" : {
> "method" : "POST",
> "path" : "/acme/revoke-cert",
> "body" : "{\"protected\":\"eyJhbGciOiJSUzI1NiIsImtpZCI6Imh0dHA6Ly9sb2NhbGhvc3Q6NDAwMS9hY21lL2FjY3QvMzg0Iiwibm9uY2UiOiJ6YlFSN0NMX0dTeDBveWRaMEFWb05FaDdvbVlfWE9OZFdGcFlPZmVGVlFjIiwidXJsIjoiaHR0cDovL2xvY2FsaG9zdDo0MDAxL2FjbWUvcmV2b2tlLWNlcnQifQ\",\"payload\":\"eyJjZXJ0aWZpY2F0ZSI6Ik1JSUZaekNDQkUtZ0F3SUJBZ0lUQVBfNDBNVEh3LWw1M3lpOWVOMnptclFkX1RBTkJna3Foa2lHOXcwQkFRc0ZBREFmTVIwd0d3WURWUVFEREJSb01uQndlU0JvTW1OclpYSWdabUZyWlNCRFFUQWVGdzB4T0RBME16QXhPRFF4TURoYUZ3MHhPREEzTWpreE9EUXhNRGhhTUI0eEhEQWFCZ05WQkFNVEUyaHRlSFJ1ZFd0c2JHaDRlR3hpYUM1amIyMHdnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCQVFDWUpyX3BaQkNTeV9LZHdLd1c0TDdyNnhWYVB1R0dna1JKY3lnTE5EWUhNd2JObm9zM3FnckpEMk0tRW5HOWlrSmlIRzd5VUtfVHRGNWZrVFA3UEROUzNlallkVTl1RTFHeTM1VTcyVGVzbVpzSC1aNy11NHJsc1JxdzVXcURDUjBGeW1PR0xuUEpVa3hGN29PRlFHc1lwZ3h3T1JVV0g5TlBEUzZTT3RTWF9XbUJ0S015VGM5QW9GRjBlRHM3NlBmOWl5eXZONjh4ejF6Y3g5aENnbDB5ZVNXTFhUNHV1SUJibHIxNXZhdzdCVVFNMnBGdE9aNGFIcWRiTDUtQ05TOWVxNUk2WTRpMW1yQVBEWklkN2xMOHAxY2tQLXI0dlh0a0VVdmxEaXFNMzdiRlB3enZDMWVVeGtOanNTdnQ0OGh4TTBtMU82cHZhTVB2Qm1CWGxHOUZBZ01CQUFHamdnS2JNSUlDbHpBT0JnTlZIUThCQWY4RUJBTUNCYUF3SFFZRFZSMGxCQll3RkFZSUt3WUJCUVVIQXdFR0NDc0dBUVVGQndNQ01Bd0dBMVVkRXdFQl93UUNNQUF3SFFZRFZSME9CQllFRkl3VXBFcGpUbmhUTl9XN3JlckkwT3V2alVMck1COEdBMVVkSXdRWU1CYUFGUHQ0VHhMNVlCV0RMSjhYZnpRWnN5NDI2a0dKTUdRR0NDc0dBUVVGQndFQkJGZ3dWakFpQmdnckJnRUZCUWN3QVlZV2FIUjBjRG92THpFeU55NHdMakF1TVRvME1EQXlMekF3QmdnckJnRUZCUWN3QW9Za2FIUjBjRG92TDJKdmRXeGtaWEk2TkRRek1DOWhZMjFsTDJsemMzVmxjaTFqWlhKME1CNEdBMVVkRVFRWE1CV0NFMmh0ZUhSdWRXdHNiR2g0ZUd4aWFDNWpiMjB3SndZRFZSMGZCQ0F3SGpBY29CcWdHSVlXYUhSMGNEb3ZMMlY0WVcxd2JHVXVZMjl0TDJOeWJEQmhCZ05WSFNBRVdqQllNQWdHQm1lQkRBRUNBVEJNQmdNcUF3UXdSVEFpQmdnckJnRUZCUWNDQVJZV2FIUjBjRG92TDJWNFlXMXdiR1V1WTI5dEwyTndjekFmQmdnckJnRUZCUWNDQWpBVERCRkVieUJYYUdGMElGUm9iM1VnVjJsc2REQ0NBUVFHQ2lzR0FRUUIxbmtDQkFJRWdmVUVnZklBOEFCMUFOMlpOUHlsNXlTQXlWWm9mWUUwbVFoSnNrbjN0V25ZeDd5clAxekI4MjVrQUFBQll4Z1NzYVFBQUFRREFFWXdSQUlnTUFGb19yNFl0aWNfc1lpVmxpaE10ZGZSZDFnclNYSUl1U2pwQzNZT1NOZ0NJRzdMWTlkMGl2cVV2czJ3Y0Z1Q0tNZkFsdDFNWTNvcjR6cGJlelFsNWpvREFIY0FGdWhwd2RHVjZ0ZkQtSmNhNF9CMkFmZU00YmFkTWFoU0dMYURmekdvRlFnQUFBRmpHQkt4cFFBQUJBTUFTREJHQWlFQTRYSmZVd3JVbkxWUGxRbF9IVVFxakRUVkFRdDJIN29BdXNrWUhiT3EtYTRDSVFEcGZwa3pNbkxudlNxay02QU5ZRWRKb0p5Q0M3M1ZwdHo0WG1MVnJMNHNtekFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBc1VEMUJ6M2NWQzA4NXF4a2VkYzJqd3FUSEk0UF9OaERrQVFmSGhrQ0VlaFoyVTVmRE1YWXFwZDh0UUluZUdoZU1ZTkQ4OWRFQXYyXzI5SXNGXzhKNC1uSURrLU1XQkFsQm43VUtES2xDbEdza0RDenJPajF6clJwOUtscTNLaElFSkUzT01nTGIyM3pNbERLeWRIcXA5OGtTc25hQmFoS1VlV3l1WXcxdmNwemZ3TjE0UG9xMW1jRnJWUFAxcWRBNG1NMTVFVHgyV0tZdTFWaWIySVVESmx2STNYbUg5SFR5ODZYRTRMNXFTd20xalJFbzZ5a3FDTmhSMHJMeHhHeXhDRldWVXVLNG9SaFR3YmF0VzEzR3JvSlhGdGNQeVVuRGJkSU9iRzIwLV9DME9ZMk9Rc1pWQTNWTC1IQ2c3ckt6QnZOSTNlaVkzVVNMYVBMM1I0dWhnIiwicmVhc29uIjoxMH0\",\"signature\":\"eP8PR2UEdU-HW7hM0XyeDWuPADRh_XKwmNM8QmowJzn4WLYkp-pHbnpGnID0aRTAjFQsvvPmkWIrNN9TMCgwfr5EqP7xoU1uGS3J6uNydZI4TyjGZaJ9v1I9sqb5Zw_Q5cht-vSMnxznmuEu3K_6jrDLq9x-U22sNFyA_aoqu5odPNJl_l2D2ZHaPbO19NjOfc2-mgBKR4y850oEzz8vKsFcPjtASFMoC3Ulyc2kDHuUeH9HL3W4DqvD0ygVhcbh5R9NRzwefj1h2YSD_8QJj20DprPSReJ_LxZTZzy3-oB3WWibLUaVS6xr0ZbMCPQSp_rTSRWpekWoM7vm_XwdCQ\"}"
> },
> "times" : {
> "remainingTimes" : 1,
> "unlimited" : false
> },
> "timeToLive" : {
> "unlimited" : true
> },
> "httpResponse" : {
> "statusCode" : 200,
> "headers" : {
> "Cache-Control" : [ "public, max-age=0, no-cache" ],
> "Replay-Nonce" : [ "q4qaFhcWgftkiRaaeEZskz_fp9ue2OJGRDW3mYBGCNk" ]
> }
> }
> }
> 00:27:53,712 INFO (nioEventLoopGroup-3-2) [org.mockserver.mock.HttpStateHandler] <LoggingFormatter.java:34> request:
> {
> "method" : "GET",
> "path" : "/directory",
> "headers" : {
> "content-length" : [ "0" ],
> "Accept" : [ "text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2" ],
> "User-Agent" : [ "Elytron ACME Client/1.7.0.CR2" ],
> "Connection" : [ "keep-alive" ],
> "Host" : [ "localhost:4001" ],
> "Accept-Language" : [ "en-US" ]
> },
> "keepAlive" : true,
> "secure" : false
> }
> matched expectation:
> {
> "method" : "GET",
> "path" : "/directory"
> }
> 00:27:53,713 INFO (nioEventLoopGroup-3-2) [org.mockserver.mock.HttpStateHandler] <LoggingFormatter.java:34> returning response:
> {
> "headers" : {
> "Cache-Control" : [ "public, max-age=0, no-cache" ],
> "Content-Type" : [ "application/json" ],
> "connection" : [ "keep-alive" ]
> },
> "body" : "{\n \"FpVd7yM-nVU\": \"https://community.letsencrypt.org/t/adding-random-entries-to-the-director...",\n \"keyChange\": \"http://localhost:4001/acme/key-change\",\n \"meta\": {\n \"caaIdentities\": [\n \"happy-hacker-ca.invalid\"\n ],\n \"termsOfService\": \"https://boulder:4431/terms/v7\",\n \"website\": \"https://github.com/letsencrypt/boulder\"\n },\n \"newAccount\": \"http://localhost:4001/acme/new-acct\",\n \"newNonce\": \"http://localhost:4001/acme/new-nonce\",\n \"newOrder\": \"http://localhost:4001/acme/new-order\",\n \"revokeCert\": \"http://localhost:4001/acme/revoke-cert\"\n}\n"
> }
> for request:
> {
> "method" : "GET",
> "path" : "/directory",
> "headers" : {
> "content-length" : [ "0" ],
> "Accept" : [ "text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2" ],
> "User-Agent" : [ "Elytron ACME Client/1.7.0.CR2" ],
> "Connection" : [ "keep-alive" ],
> "Host" : [ "localhost:4001" ],
> "Accept-Language" : [ "en-US" ]
> },
> "keepAlive" : true,
> "secure" : false
> }
> for response action:
> {
> "headers" : {
> "Cache-Control" : [ "public, max-age=0, no-cache" ],
> "Content-Type" : [ "application/json" ]
> },
> "body" : "{\n \"FpVd7yM-nVU\": \"https://community.letsencrypt.org/t/adding-random-entries-to-the-director...",\n \"keyChange\": \"http://localhost:4001/acme/key-change\",\n \"meta\": {\n \"caaIdentities\": [\n \"happy-hacker-ca.invalid\"\n ],\n \"termsOfService\": \"https://boulder:4431/terms/v7\",\n \"website\": \"https://github.com/letsencrypt/boulder\"\n },\n \"newAccount\": \"http://localhost:4001/acme/new-acct\",\n \"newNonce\": \"http://localhost:4001/acme/new-nonce\",\n \"newOrder\": \"http://localhost:4001/acme/new-order\",\n \"revokeCert\": \"http://localhost:4001/acme/revoke-cert\"\n}\n"
> }
> 00:27:53,714 INFO (nioEventLoopGroup-3-4) [org.mockserver.mock.HttpStateHandler] <LoggingFormatter.java:34> request:
> {
> "method" : "GET",
> "path" : "/directory",
> "headers" : {
> "content-length" : [ "0" ],
> "Accept" : [ "text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2" ],
> "User-Agent" : [ "Elytron ACME Client/1.7.0.CR2" ],
> "Connection" : [ "keep-alive" ],
> "Host" : [ "localhost:4001" ],
> "Accept-Language" : [ "en-US" ]
> },
> "keepAlive" : true,
> "secure" : false
> }
> did not match expectation:
> {
> "method" : "HEAD",
> "path" : "/acme/new-nonce"
> }
> because:
> method matches = false
> path matches = false
> query string parameters match = true
> body matches = true
> headers match = true
> cookies match = true
> keep-alive matches = true
> ssl matches = true
> 00:27:53,715 INFO (nioEventLoopGroup-3-4) [org.mockserver.mock.HttpStateHandler] <LoggingFormatter.java:34> request:
> {
> "method" : "GET",
> "path" : "/directory",
> "headers" : {
> "content-length" : [ "0" ],
> "Accept" : [ "text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2" ],
> "User-Agent" : [ "Elytron ACME Client/1.7.0.CR2" ],
> "Connection" : [ "keep-alive" ],
> "Host" : [ "localhost:4001" ],
> "Accept-Language" : [ "en-US" ]
> },
> "keepAlive" : true,
> "secure" : false
> }
> did not match expectation:
> {
> "method" : "POST",
> "path" : "/acme/new-acct",
> "body" : "{\"protected\":\"eyJhbGciOiJSUzI1NiIsImp3ayI6eyJlIjoiQVFBQiIsImt0eSI6IlJTQSIsIm4iOiJwdUwtV2NNWVVKMkFqZHkxVXNVZ056am42ZWNEeGlXZDdOR1VHcTI2N1NPTHdoS2pTV1dNd2tvcGZjZzVWTWpQSldFRTM4SUlYeWpXNW5GS0NxRkFJZjNabGloXzFTTGNqZ1ZGYmlibi1vTUdGTFpzOWdncjJialJHSnNic0pRSU9LbWdWczJ5M2w1UmNJeUYyTS1VT3g0R3RBVVFKc1lpdHRjaEJMeHFqczBTQmpXZHRwV3phWDRmd1RDeng0OFJYdVpoa3lfbUtBeUtiaEFZbklHZERoY1ZJWnNmZjZ6ekVNMWJwSkVENk9CWmg2cHlQLU4wa094Y0dtUFBDSE1mME16d2puSzhWckZQRWFJSWZRQWJVQzFyVGF1aXFaWDdnbEVuTjJrWXFPd2w4ZzNuZjVmYlg2c1V1RFUxNWZWMGNtZFV0aHk4X0dIeUUycWR6alBSTHcifSwibm9uY2UiOiItbWxKaGNveF82RkZ1RHdOaGNtTDA2RldENnVMN0s3bGFtOUplbC1NcXFNIiwidXJsIjoiaHR0cDovL2xvY2FsaG9zdDo0MDAxL2FjbWUvbmV3LWFjY3QifQ\",\"payload\":\"eyJvbmx5UmV0dXJuRXhpc3RpbmciOnRydWV9\",\"signature\":\"lztzTXBmbrxXGMspfEetHDGKdZ2NrpQTioysqHIa9aaL5dy8bPmKZ_Vmz68-xnUJcjK-5FMCn5vtYEKAJlJ7W3wVYzthcVuYlv-b6FNw3IYsdSSHMr5RLm0rSt9EwYd-BI4bCoT7dioYpCMHzTrd-3X8QjDS4fx1o6D-po_Hwkt4PWx5Yoo9ExlykM5cHOQlCQENPk3Pn0M4_8XkfH1QTvVTIm4A4lbo_Eko1aU9PgvWbNsqkEhRzH7rBb5FUlxFgRoSHuTJwn6uJL-H0cfYQUn-J5JyD5C-P8su3M7NoAXCj0vy_84TziHMxe1C8fI-A64M6CtlL9qGm5MwPgv8Gg\"}"
> }
> because:
> method matches = false
> path matches = false
> query string parameters match = true
> body matches = false
> headers match = true
> cookies match = true
> keep-alive matches = true
> ssl matches = true
> 00:27:53,716 INFO (nioEventLoopGroup-3-4) [org.mockserver.mock.HttpStateHandler] <LoggingFormatter.java:34> request:
> {
> "method" : "GET",
> "path" : "/directory",
> "headers" : {
> "content-length" : [ "0" ],
> "Accept" : [ "text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2" ],
> "User-Agent" : [ "Elytron ACME Client/1.7.0.CR2" ],
> "Connection" : [ "keep-alive" ],
> "Host" : [ "localhost:4001" ],
> "Accept-Language" : [ "en-US" ]
> },
> "keepAlive" : true,
> "secure" : false
> }
> did not match expectation:
> {
> "method" : "POST",
> "path" : "/acme/revoke-cert",
> "body" : "{\"protected\":\"eyJhbGciOiJSUzI1NiIsImtpZCI6Imh0dHA6Ly9sb2NhbGhvc3Q6NDAwMS9hY21lL2FjY3QvMzg0Iiwibm9uY2UiOiJ6YlFSN0NMX0dTeDBveWRaMEFWb05FaDdvbVlfWE9OZFdGcFlPZmVGVlFjIiwidXJsIjoiaHR0cDovL2xvY2FsaG9zdDo0MDAxL2FjbWUvcmV2b2tlLWNlcnQifQ\",\"payload\":\"eyJjZXJ0aWZpY2F0ZSI6Ik1JSUZaekNDQkUtZ0F3SUJBZ0lUQVBfNDBNVEh3LWw1M3lpOWVOMnptclFkX1RBTkJna3Foa2lHOXcwQkFRc0ZBREFmTVIwd0d3WURWUVFEREJSb01uQndlU0JvTW1OclpYSWdabUZyWlNCRFFUQWVGdzB4T0RBME16QXhPRFF4TURoYUZ3MHhPREEzTWpreE9EUXhNRGhhTUI0eEhEQWFCZ05WQkFNVEUyaHRlSFJ1ZFd0c2JHaDRlR3hpYUM1amIyMHdnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCQVFDWUpyX3BaQkNTeV9LZHdLd1c0TDdyNnhWYVB1R0dna1JKY3lnTE5EWUhNd2JObm9zM3FnckpEMk0tRW5HOWlrSmlIRzd5VUtfVHRGNWZrVFA3UEROUzNlallkVTl1RTFHeTM1VTcyVGVzbVpzSC1aNy11NHJsc1JxdzVXcURDUjBGeW1PR0xuUEpVa3hGN29PRlFHc1lwZ3h3T1JVV0g5TlBEUzZTT3RTWF9XbUJ0S015VGM5QW9GRjBlRHM3NlBmOWl5eXZONjh4ejF6Y3g5aENnbDB5ZVNXTFhUNHV1SUJibHIxNXZhdzdCVVFNMnBGdE9aNGFIcWRiTDUtQ05TOWVxNUk2WTRpMW1yQVBEWklkN2xMOHAxY2tQLXI0dlh0a0VVdmxEaXFNMzdiRlB3enZDMWVVeGtOanNTdnQ0OGh4TTBtMU82cHZhTVB2Qm1CWGxHOUZBZ01CQUFHamdnS2JNSUlDbHpBT0JnTlZIUThCQWY4RUJBTUNCYUF3SFFZRFZSMGxCQll3RkFZSUt3WUJCUVVIQXdFR0NDc0dBUVVGQndNQ01Bd0dBMVVkRXdFQl93UUNNQUF3SFFZRFZSME9CQllFRkl3VXBFcGpUbmhUTl9XN3JlckkwT3V2alVMck1COEdBMVVkSXdRWU1CYUFGUHQ0VHhMNVlCV0RMSjhYZnpRWnN5NDI2a0dKTUdRR0NDc0dBUVVGQndFQkJGZ3dWakFpQmdnckJnRUZCUWN3QVlZV2FIUjBjRG92THpFeU55NHdMakF1TVRvME1EQXlMekF3QmdnckJnRUZCUWN3QW9Za2FIUjBjRG92TDJKdmRXeGtaWEk2TkRRek1DOWhZMjFsTDJsemMzVmxjaTFqWlhKME1CNEdBMVVkRVFRWE1CV0NFMmh0ZUhSdWRXdHNiR2g0ZUd4aWFDNWpiMjB3SndZRFZSMGZCQ0F3SGpBY29CcWdHSVlXYUhSMGNEb3ZMMlY0WVcxd2JHVXVZMjl0TDJOeWJEQmhCZ05WSFNBRVdqQllNQWdHQm1lQkRBRUNBVEJNQmdNcUF3UXdSVEFpQmdnckJnRUZCUWNDQVJZV2FIUjBjRG92TDJWNFlXMXdiR1V1WTI5dEwyTndjekFmQmdnckJnRUZCUWNDQWpBVERCRkVieUJYYUdGMElGUm9iM1VnVjJsc2REQ0NBUVFHQ2lzR0FRUUIxbmtDQkFJRWdmVUVnZklBOEFCMUFOMlpOUHlsNXlTQXlWWm9mWUUwbVFoSnNrbjN0V25ZeDd5clAxekI4MjVrQUFBQll4Z1NzYVFBQUFRREFFWXdSQUlnTUFGb19yNFl0aWNfc1lpVmxpaE10ZGZSZDFnclNYSUl1U2pwQzNZT1NOZ0NJRzdMWTlkMGl2cVV2czJ3Y0Z1Q0tNZkFsdDFNWTNvcjR6cGJlelFsNWpvREFIY0FGdWhwd2RHVjZ0ZkQtSmNhNF9CMkFmZU00YmFkTWFoU0dMYURmekdvRlFnQUFBRmpHQkt4cFFBQUJBTUFTREJHQWlFQTRYSmZVd3JVbkxWUGxRbF9IVVFxakRUVkFRdDJIN29BdXNrWUhiT3EtYTRDSVFEcGZwa3pNbkxudlNxay02QU5ZRWRKb0p5Q0M3M1ZwdHo0WG1MVnJMNHNtekFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBc1VEMUJ6M2NWQzA4NXF4a2VkYzJqd3FUSEk0UF9OaERrQVFmSGhrQ0VlaFoyVTVmRE1YWXFwZDh0UUluZUdoZU1ZTkQ4OWRFQXYyXzI5SXNGXzhKNC1uSURrLU1XQkFsQm43VUtES2xDbEdza0RDenJPajF6clJwOUtscTNLaElFSkUzT01nTGIyM3pNbERLeWRIcXA5OGtTc25hQmFoS1VlV3l1WXcxdmNwemZ3TjE0UG9xMW1jRnJWUFAxcWRBNG1NMTVFVHgyV0tZdTFWaWIySVVESmx2STNYbUg5SFR5ODZYRTRMNXFTd20xalJFbzZ5a3FDTmhSMHJMeHhHeXhDRldWVXVLNG9SaFR3YmF0VzEzR3JvSlhGdGNQeVVuRGJkSU9iRzIwLV9DME9ZMk9Rc1pWQTNWTC1IQ2c3ckt6QnZOSTNlaVkzVVNMYVBMM1I0dWhnIiwicmVhc29uIjoxMH0\",\"signature\":\"eP8PR2UEdU-HW7hM0XyeDWuPADRh_XKwmNM8QmowJzn4WLYkp-pHbnpGnID0aRTAjFQsvvPmkWIrNN9TMCgwfr5EqP7xoU1uGS3J6uNydZI4TyjGZaJ9v1I9sqb5Zw_Q5cht-vSMnxznmuEu3K_6jrDLq9x-U22sNFyA_aoqu5odPNJl_l2D2ZHaPbO19NjOfc2-mgBKR4y850oEzz8vKsFcPjtASFMoC3Ulyc2kDHuUeH9HL3W4DqvD0ygVhcbh5R9NRzwefj1h2YSD_8QJj20DprPSReJ_LxZTZzy3-oB3WWibLUaVS6xr0ZbMCPQSp_rTSRWpekWoM7vm_XwdCQ\"}"
> }
> because:
> method matches = false
> path matches = false
> query string parameters match = true
> body matches = false
> headers match = true
> cookies match = true
> keep-alive matches = true
> ssl matches = true
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (ELY-1732) Intermittently failing AcmeClientSpiTest
by Ilia Vassilev (Jira)
Ilia Vassilev created ELY-1732:
----------------------------------
Summary: Intermittently failing AcmeClientSpiTest
Key: ELY-1732
URL: https://issues.jboss.org/browse/ELY-1732
Project: WildFly Elytron
Issue Type: Bug
Components: Testsuite
Affects Versions: 1.7.0.CR2
Reporter: Ilia Vassilev
Assignee: Farah Juma
Fix For: 1.8.0.CR1
We see this failing with ratio 1:100 with error "ELY10038: Unexpected HTTP status code in response from ACME server "404": "Not Found""
{noformat}
org.wildfly.security.x500.cert.acme.AcmeException: ELY10038: Unexpected HTTP status code in response from ACME server "404": "Not Found"
at org.wildfly.security.x500.cert.acme.AcmeClientSpi.handleAcmeErrorResponse(AcmeClientSpi.java:907)
at org.wildfly.security.x500.cert.acme.AcmeClientSpi.sendGetRequest(AcmeClientSpi.java:728)
at org.wildfly.security.x500.cert.acme.AcmeClientSpi.getResourceUrls(AcmeClientSpi.java:183)
at org.wildfly.security.x500.cert.acme.AcmeClientSpi.getResourceUrl(AcmeClientSpi.java:711)
at org.wildfly.security.x500.cert.acme.AcmeClientSpi.revokeCertificate(AcmeClientSpi.java:639)
at org.wildfly.security.x500.cert.acme.AcmeClientSpiTest.revokeCertificate(AcmeClientSpiTest.java:334)
at org.wildfly.security.x500.cert.acme.AcmeClientSpiTest.testRevokeCertificateWithReason(AcmeClientSpiTest.java:324)
{noformat}
{noformat}
00:27:53,593 INFO (nioEventLoopGroup-3-2) [org.mockserver.mock.HttpStateHandler] <LoggingFormatter.java:34> returning response:
{
"statusCode" : 200,
"headers" : {
"Cache-Control" : [ "public, max-age=0, no-cache" ],
"Replay-Nonce" : [ "NT_I4byOA1qs22GwXEcNp9RNyoq4hO6JTBMh1iUK3yI" ],
"Content-Type" : [ "application/json" ],
"Link" : [ "<https://boulder:4431/terms/v7>;rel=\"terms-of-service\"" ],
"connection" : [ "keep-alive" ]
},
"body" : "{\n \"id\": 384,\n \"key\": {\n \"kty\": \"RSA\",\n \"n\": \"puL-WcMYUJ2Ajdy1UsUgNzjn6ecDxiWd7NGUGq267SOLwhKjSWWMwkopfcg5VMjPJWEE38IIXyjW5nFKCqFAIf3Zlih_1SLcjgVFbibn-oMGFLZs9ggr2bjRGJsbsJQIOKmgVs2y3l5RcIyF2M-UOx4GtAUQJsYittchBLxqjs0SBjWdtpWzaX4fwTCzx48RXuZhky_mKAyKbhAYnIGdDhcVIZsff6zzEM1bpJED6OBZh6pyP-N0kOxcGmPPCHMf0MzwjnK8VrFPEaIIfQAbUC1rTauiqZX7glEnN2kYqOwl8g3nf5fbX6sUuDU15fV0cmdUthy8_GHyE2qdzjPRLw\",\n \"e\": \"AQAB\"\n },\n \"contact\": [\n \"mailto:certificates@example.com\",\n \"mailto:admin@example.com\"\n ],\n \"initialIp\": \"127.0.0.1\",\n \"createdAt\": \"2018-04-23T11:10:28-04:00\",\n \"status\": \"valid\"\n}\n"
}
for request:
{
"method" : "POST",
"path" : "/acme/acct/384",
"body" : "{\"protected\":\"eyJhbGciOiJSUzI1NiIsImtpZCI6Imh0dHA6Ly9sb2NhbGhvc3Q6NDAwMS9hY21lL2FjY3QvMzg0Iiwibm9uY2UiOiJma0Q4QkRreW5mSEUxVUVTcFV2SHRDTGE0UzJXa0NJd3BYZE80N1EzdnpBIiwidXJsIjoiaHR0cDovL2xvY2FsaG9zdDo0MDAxL2FjbWUvYWNjdC8zODQifQ\",\"payload\":\"e30\",\"signature\":\"cyg9Mgmgw4KcTGB96Uz1XPflyZCXgBYWRTiuppLLBMVYBG-eZvrCvzkjqlBTXfmixpBaCPoYU9PnNg3FEYgYzut8zgOsrvcgyu7byYdxnO9LxtxFCnLYPp8xGyoRD9W3owAxcbKnwTf3rmxhSKBRCDZnGs-JuZqJc25kbK4tLNZLaPfdyBS3oaE7xzxKrz6waLCIt9_CoRlSjqc9ZY9P8syUVdkdmdMtlyZJPJNt-keteulOA2_4xZzUV0RdxswlivT3v5Zz9bDuj5JPtHx-1NHSjRhLcM2pl2wk9pvm35q4_au4DjiP5enP-x_-qn6fXJuNUsuUdv_DHjmWLYL7Vw\"}",
"headers" : {
"Accept" : [ "text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2" ],
"User-Agent" : [ "Elytron ACME Client/1.7.0.CR2" ],
"Connection" : [ "keep-alive" ],
"Host" : [ "localhost:4001" ],
"Accept-Language" : [ "en-US" ],
"Content-Length" : [ "599" ],
"Content-Type" : [ "application/jose+json" ]
},
"keepAlive" : true,
"secure" : false
}
for response action:
{
"statusCode" : 200,
"headers" : {
"Cache-Control" : [ "public, max-age=0, no-cache" ],
"Replay-Nonce" : [ "NT_I4byOA1qs22GwXEcNp9RNyoq4hO6JTBMh1iUK3yI" ],
"Content-Type" : [ "application/json" ],
"Link" : [ "<https://boulder:4431/terms/v7>;rel=\"terms-of-service\"" ]
},
"body" : "{\n \"id\": 384,\n \"key\": {\n \"kty\": \"RSA\",\n \"n\": \"puL-WcMYUJ2Ajdy1UsUgNzjn6ecDxiWd7NGUGq267SOLwhKjSWWMwkopfcg5VMjPJWEE38IIXyjW5nFKCqFAIf3Zlih_1SLcjgVFbibn-oMGFLZs9ggr2bjRGJsbsJQIOKmgVs2y3l5RcIyF2M-UOx4GtAUQJsYittchBLxqjs0SBjWdtpWzaX4fwTCzx48RXuZhky_mKAyKbhAYnIGdDhcVIZsff6zzEM1bpJED6OBZh6pyP-N0kOxcGmPPCHMf0MzwjnK8VrFPEaIIfQAbUC1rTauiqZX7glEnN2kYqOwl8g3nf5fbX6sUuDU15fV0cmdUthy8_GHyE2qdzjPRLw\",\n \"e\": \"AQAB\"\n },\n \"contact\": [\n \"mailto:certificates@example.com\",\n \"mailto:admin@example.com\"\n ],\n \"initialIp\": \"127.0.0.1\",\n \"createdAt\": \"2018-04-23T11:10:28-04:00\",\n \"status\": \"valid\"\n}\n"
}
00:27:53,601 INFO (nioEventLoopGroup-3-3) [org.mockserver.mock.HttpStateHandler] <LoggingFormatter.java:34> resetting all expectations and request logs
00:27:53,618 INFO (nioEventLoopGroup-3-4) [org.mockserver.mock.HttpStateHandler] <LoggingFormatter.java:34> creating expectation:
{
"httpRequest" : {
"method" : "GET",
"path" : "/directory"
},
"times" : {
"remainingTimes" : 1,
"unlimited" : false
},
"timeToLive" : {
"unlimited" : true
},
"httpResponse" : {
"headers" : {
"Cache-Control" : [ "public, max-age=0, no-cache" ],
"Content-Type" : [ "application/json" ]
},
"body" : "{\n \"FpVd7yM-nVU\": \"https://community.letsencrypt.org/t/adding-random-entries-to-the-director...",\n \"keyChange\": \"http://localhost:4001/acme/key-change\",\n \"meta\": {\n \"caaIdentities\": [\n \"happy-hacker-ca.invalid\"\n ],\n \"termsOfService\": \"https://boulder:4431/terms/v7\",\n \"website\": \"https://github.com/letsencrypt/boulder\"\n },\n \"newAccount\": \"http://localhost:4001/acme/new-acct\",\n \"newNonce\": \"http://localhost:4001/acme/new-nonce\",\n \"newOrder\": \"http://localhost:4001/acme/new-order\",\n \"revokeCert\": \"http://localhost:4001/acme/revoke-cert\"\n}\n"
}
}
00:27:53,634 INFO (nioEventLoopGroup-3-1) [org.mockserver.mock.HttpStateHandler] <LoggingFormatter.java:34> creating expectation:
{
"httpRequest" : {
"method" : "HEAD",
"path" : "/acme/new-nonce"
},
"times" : {
"remainingTimes" : 1,
"unlimited" : false
},
"timeToLive" : {
"unlimited" : true
},
"httpResponse" : {
"statusCode" : 204,
"headers" : {
"Cache-Control" : [ "public, max-age=0, no-cache" ],
"Replay-Nonce" : [ "-mlJhcox_6FFuDwNhcmL06FWD6uL7K7lam9Jel-MqqM" ]
}
}
}
00:27:53,656 INFO (nioEventLoopGroup-3-2) [org.mockserver.mock.HttpStateHandler] <LoggingFormatter.java:34> creating expectation:
{
"httpRequest" : {
"method" : "POST",
"path" : "/acme/new-acct",
"body" : "{\"protected\":\"eyJhbGciOiJSUzI1NiIsImp3ayI6eyJlIjoiQVFBQiIsImt0eSI6IlJTQSIsIm4iOiJwdUwtV2NNWVVKMkFqZHkxVXNVZ056am42ZWNEeGlXZDdOR1VHcTI2N1NPTHdoS2pTV1dNd2tvcGZjZzVWTWpQSldFRTM4SUlYeWpXNW5GS0NxRkFJZjNabGloXzFTTGNqZ1ZGYmlibi1vTUdGTFpzOWdncjJialJHSnNic0pRSU9LbWdWczJ5M2w1UmNJeUYyTS1VT3g0R3RBVVFKc1lpdHRjaEJMeHFqczBTQmpXZHRwV3phWDRmd1RDeng0OFJYdVpoa3lfbUtBeUtiaEFZbklHZERoY1ZJWnNmZjZ6ekVNMWJwSkVENk9CWmg2cHlQLU4wa094Y0dtUFBDSE1mME16d2puSzhWckZQRWFJSWZRQWJVQzFyVGF1aXFaWDdnbEVuTjJrWXFPd2w4ZzNuZjVmYlg2c1V1RFUxNWZWMGNtZFV0aHk4X0dIeUUycWR6alBSTHcifSwibm9uY2UiOiItbWxKaGNveF82RkZ1RHdOaGNtTDA2RldENnVMN0s3bGFtOUplbC1NcXFNIiwidXJsIjoiaHR0cDovL2xvY2FsaG9zdDo0MDAxL2FjbWUvbmV3LWFjY3QifQ\",\"payload\":\"eyJvbmx5UmV0dXJuRXhpc3RpbmciOnRydWV9\",\"signature\":\"lztzTXBmbrxXGMspfEetHDGKdZ2NrpQTioysqHIa9aaL5dy8bPmKZ_Vmz68-xnUJcjK-5FMCn5vtYEKAJlJ7W3wVYzthcVuYlv-b6FNw3IYsdSSHMr5RLm0rSt9EwYd-BI4bCoT7dioYpCMHzTrd-3X8QjDS4fx1o6D-po_Hwkt4PWx5Yoo9ExlykM5cHOQlCQENPk3Pn0M4_8XkfH1QTvVTIm4A4lbo_Eko1aU9PgvWbNsqkEhRzH7rBb5FUlxFgRoSHuTJwn6uJL-H0cfYQUn-J5JyD5C-P8su3M7NoAXCj0vy_84TziHMxe1C8fI-A64M6CtlL9qGm5MwPgv8Gg\"}"
},
"times" : {
"remainingTimes" : 1,
"unlimited" : false
},
"timeToLive" : {
"unlimited" : true
},
"httpResponse" : {
"statusCode" : 200,
"headers" : {
"Cache-Control" : [ "public, max-age=0, no-cache" ],
"Replay-Nonce" : [ "zbQR7CL_GSx0oydZ0AVoNEh7omY_XONdWFpYOfeFVQc" ],
"Link" : [ "<https://boulder:4431/terms/v7>;rel=\"terms-of-service\"" ],
"Location" : [ "http://localhost:4001/acme/acct/384" ]
}
}
}
00:27:53,700 INFO (nioEventLoopGroup-3-3) [org.mockserver.mock.HttpStateHandler] <LoggingFormatter.java:34> creating expectation:
{
"httpRequest" : {
"method" : "POST",
"path" : "/acme/revoke-cert",
"body" : "{\"protected\":\"eyJhbGciOiJSUzI1NiIsImtpZCI6Imh0dHA6Ly9sb2NhbGhvc3Q6NDAwMS9hY21lL2FjY3QvMzg0Iiwibm9uY2UiOiJ6YlFSN0NMX0dTeDBveWRaMEFWb05FaDdvbVlfWE9OZFdGcFlPZmVGVlFjIiwidXJsIjoiaHR0cDovL2xvY2FsaG9zdDo0MDAxL2FjbWUvcmV2b2tlLWNlcnQifQ\",\"payload\":\"eyJjZXJ0aWZpY2F0ZSI6Ik1JSUZaekNDQkUtZ0F3SUJBZ0lUQVBfNDBNVEh3LWw1M3lpOWVOMnptclFkX1RBTkJna3Foa2lHOXcwQkFRc0ZBREFmTVIwd0d3WURWUVFEREJSb01uQndlU0JvTW1OclpYSWdabUZyWlNCRFFUQWVGdzB4T0RBME16QXhPRFF4TURoYUZ3MHhPREEzTWpreE9EUXhNRGhhTUI0eEhEQWFCZ05WQkFNVEUyaHRlSFJ1ZFd0c2JHaDRlR3hpYUM1amIyMHdnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCQVFDWUpyX3BaQkNTeV9LZHdLd1c0TDdyNnhWYVB1R0dna1JKY3lnTE5EWUhNd2JObm9zM3FnckpEMk0tRW5HOWlrSmlIRzd5VUtfVHRGNWZrVFA3UEROUzNlallkVTl1RTFHeTM1VTcyVGVzbVpzSC1aNy11NHJsc1JxdzVXcURDUjBGeW1PR0xuUEpVa3hGN29PRlFHc1lwZ3h3T1JVV0g5TlBEUzZTT3RTWF9XbUJ0S015VGM5QW9GRjBlRHM3NlBmOWl5eXZONjh4ejF6Y3g5aENnbDB5ZVNXTFhUNHV1SUJibHIxNXZhdzdCVVFNMnBGdE9aNGFIcWRiTDUtQ05TOWVxNUk2WTRpMW1yQVBEWklkN2xMOHAxY2tQLXI0dlh0a0VVdmxEaXFNMzdiRlB3enZDMWVVeGtOanNTdnQ0OGh4TTBtMU82cHZhTVB2Qm1CWGxHOUZBZ01CQUFHamdnS2JNSUlDbHpBT0JnTlZIUThCQWY4RUJBTUNCYUF3SFFZRFZSMGxCQll3RkFZSUt3WUJCUVVIQXdFR0NDc0dBUVVGQndNQ01Bd0dBMVVkRXdFQl93UUNNQUF3SFFZRFZSME9CQllFRkl3VXBFcGpUbmhUTl9XN3JlckkwT3V2alVMck1COEdBMVVkSXdRWU1CYUFGUHQ0VHhMNVlCV0RMSjhYZnpRWnN5NDI2a0dKTUdRR0NDc0dBUVVGQndFQkJGZ3dWakFpQmdnckJnRUZCUWN3QVlZV2FIUjBjRG92THpFeU55NHdMakF1TVRvME1EQXlMekF3QmdnckJnRUZCUWN3QW9Za2FIUjBjRG92TDJKdmRXeGtaWEk2TkRRek1DOWhZMjFsTDJsemMzVmxjaTFqWlhKME1CNEdBMVVkRVFRWE1CV0NFMmh0ZUhSdWRXdHNiR2g0ZUd4aWFDNWpiMjB3SndZRFZSMGZCQ0F3SGpBY29CcWdHSVlXYUhSMGNEb3ZMMlY0WVcxd2JHVXVZMjl0TDJOeWJEQmhCZ05WSFNBRVdqQllNQWdHQm1lQkRBRUNBVEJNQmdNcUF3UXdSVEFpQmdnckJnRUZCUWNDQVJZV2FIUjBjRG92TDJWNFlXMXdiR1V1WTI5dEwyTndjekFmQmdnckJnRUZCUWNDQWpBVERCRkVieUJYYUdGMElGUm9iM1VnVjJsc2REQ0NBUVFHQ2lzR0FRUUIxbmtDQkFJRWdmVUVnZklBOEFCMUFOMlpOUHlsNXlTQXlWWm9mWUUwbVFoSnNrbjN0V25ZeDd5clAxekI4MjVrQUFBQll4Z1NzYVFBQUFRREFFWXdSQUlnTUFGb19yNFl0aWNfc1lpVmxpaE10ZGZSZDFnclNYSUl1U2pwQzNZT1NOZ0NJRzdMWTlkMGl2cVV2czJ3Y0Z1Q0tNZkFsdDFNWTNvcjR6cGJlelFsNWpvREFIY0FGdWhwd2RHVjZ0ZkQtSmNhNF9CMkFmZU00YmFkTWFoU0dMYURmekdvRlFnQUFBRmpHQkt4cFFBQUJBTUFTREJHQWlFQTRYSmZVd3JVbkxWUGxRbF9IVVFxakRUVkFRdDJIN29BdXNrWUhiT3EtYTRDSVFEcGZwa3pNbkxudlNxay02QU5ZRWRKb0p5Q0M3M1ZwdHo0WG1MVnJMNHNtekFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBc1VEMUJ6M2NWQzA4NXF4a2VkYzJqd3FUSEk0UF9OaERrQVFmSGhrQ0VlaFoyVTVmRE1YWXFwZDh0UUluZUdoZU1ZTkQ4OWRFQXYyXzI5SXNGXzhKNC1uSURrLU1XQkFsQm43VUtES2xDbEdza0RDenJPajF6clJwOUtscTNLaElFSkUzT01nTGIyM3pNbERLeWRIcXA5OGtTc25hQmFoS1VlV3l1WXcxdmNwemZ3TjE0UG9xMW1jRnJWUFAxcWRBNG1NMTVFVHgyV0tZdTFWaWIySVVESmx2STNYbUg5SFR5ODZYRTRMNXFTd20xalJFbzZ5a3FDTmhSMHJMeHhHeXhDRldWVXVLNG9SaFR3YmF0VzEzR3JvSlhGdGNQeVVuRGJkSU9iRzIwLV9DME9ZMk9Rc1pWQTNWTC1IQ2c3ckt6QnZOSTNlaVkzVVNMYVBMM1I0dWhnIiwicmVhc29uIjoxMH0\",\"signature\":\"eP8PR2UEdU-HW7hM0XyeDWuPADRh_XKwmNM8QmowJzn4WLYkp-pHbnpGnID0aRTAjFQsvvPmkWIrNN9TMCgwfr5EqP7xoU1uGS3J6uNydZI4TyjGZaJ9v1I9sqb5Zw_Q5cht-vSMnxznmuEu3K_6jrDLq9x-U22sNFyA_aoqu5odPNJl_l2D2ZHaPbO19NjOfc2-mgBKR4y850oEzz8vKsFcPjtASFMoC3Ulyc2kDHuUeH9HL3W4DqvD0ygVhcbh5R9NRzwefj1h2YSD_8QJj20DprPSReJ_LxZTZzy3-oB3WWibLUaVS6xr0ZbMCPQSp_rTSRWpekWoM7vm_XwdCQ\"}"
},
"times" : {
"remainingTimes" : 1,
"unlimited" : false
},
"timeToLive" : {
"unlimited" : true
},
"httpResponse" : {
"statusCode" : 200,
"headers" : {
"Cache-Control" : [ "public, max-age=0, no-cache" ],
"Replay-Nonce" : [ "q4qaFhcWgftkiRaaeEZskz_fp9ue2OJGRDW3mYBGCNk" ]
}
}
}
00:27:53,712 INFO (nioEventLoopGroup-3-2) [org.mockserver.mock.HttpStateHandler] <LoggingFormatter.java:34> request:
{
"method" : "GET",
"path" : "/directory",
"headers" : {
"content-length" : [ "0" ],
"Accept" : [ "text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2" ],
"User-Agent" : [ "Elytron ACME Client/1.7.0.CR2" ],
"Connection" : [ "keep-alive" ],
"Host" : [ "localhost:4001" ],
"Accept-Language" : [ "en-US" ]
},
"keepAlive" : true,
"secure" : false
}
matched expectation:
{
"method" : "GET",
"path" : "/directory"
}
00:27:53,713 INFO (nioEventLoopGroup-3-2) [org.mockserver.mock.HttpStateHandler] <LoggingFormatter.java:34> returning response:
{
"headers" : {
"Cache-Control" : [ "public, max-age=0, no-cache" ],
"Content-Type" : [ "application/json" ],
"connection" : [ "keep-alive" ]
},
"body" : "{\n \"FpVd7yM-nVU\": \"https://community.letsencrypt.org/t/adding-random-entries-to-the-director...",\n \"keyChange\": \"http://localhost:4001/acme/key-change\",\n \"meta\": {\n \"caaIdentities\": [\n \"happy-hacker-ca.invalid\"\n ],\n \"termsOfService\": \"https://boulder:4431/terms/v7\",\n \"website\": \"https://github.com/letsencrypt/boulder\"\n },\n \"newAccount\": \"http://localhost:4001/acme/new-acct\",\n \"newNonce\": \"http://localhost:4001/acme/new-nonce\",\n \"newOrder\": \"http://localhost:4001/acme/new-order\",\n \"revokeCert\": \"http://localhost:4001/acme/revoke-cert\"\n}\n"
}
for request:
{
"method" : "GET",
"path" : "/directory",
"headers" : {
"content-length" : [ "0" ],
"Accept" : [ "text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2" ],
"User-Agent" : [ "Elytron ACME Client/1.7.0.CR2" ],
"Connection" : [ "keep-alive" ],
"Host" : [ "localhost:4001" ],
"Accept-Language" : [ "en-US" ]
},
"keepAlive" : true,
"secure" : false
}
for response action:
{
"headers" : {
"Cache-Control" : [ "public, max-age=0, no-cache" ],
"Content-Type" : [ "application/json" ]
},
"body" : "{\n \"FpVd7yM-nVU\": \"https://community.letsencrypt.org/t/adding-random-entries-to-the-director...",\n \"keyChange\": \"http://localhost:4001/acme/key-change\",\n \"meta\": {\n \"caaIdentities\": [\n \"happy-hacker-ca.invalid\"\n ],\n \"termsOfService\": \"https://boulder:4431/terms/v7\",\n \"website\": \"https://github.com/letsencrypt/boulder\"\n },\n \"newAccount\": \"http://localhost:4001/acme/new-acct\",\n \"newNonce\": \"http://localhost:4001/acme/new-nonce\",\n \"newOrder\": \"http://localhost:4001/acme/new-order\",\n \"revokeCert\": \"http://localhost:4001/acme/revoke-cert\"\n}\n"
}
00:27:53,714 INFO (nioEventLoopGroup-3-4) [org.mockserver.mock.HttpStateHandler] <LoggingFormatter.java:34> request:
{
"method" : "GET",
"path" : "/directory",
"headers" : {
"content-length" : [ "0" ],
"Accept" : [ "text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2" ],
"User-Agent" : [ "Elytron ACME Client/1.7.0.CR2" ],
"Connection" : [ "keep-alive" ],
"Host" : [ "localhost:4001" ],
"Accept-Language" : [ "en-US" ]
},
"keepAlive" : true,
"secure" : false
}
did not match expectation:
{
"method" : "HEAD",
"path" : "/acme/new-nonce"
}
because:
method matches = false
path matches = false
query string parameters match = true
body matches = true
headers match = true
cookies match = true
keep-alive matches = true
ssl matches = true
00:27:53,715 INFO (nioEventLoopGroup-3-4) [org.mockserver.mock.HttpStateHandler] <LoggingFormatter.java:34> request:
{
"method" : "GET",
"path" : "/directory",
"headers" : {
"content-length" : [ "0" ],
"Accept" : [ "text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2" ],
"User-Agent" : [ "Elytron ACME Client/1.7.0.CR2" ],
"Connection" : [ "keep-alive" ],
"Host" : [ "localhost:4001" ],
"Accept-Language" : [ "en-US" ]
},
"keepAlive" : true,
"secure" : false
}
did not match expectation:
{
"method" : "POST",
"path" : "/acme/new-acct",
"body" : "{\"protected\":\"eyJhbGciOiJSUzI1NiIsImp3ayI6eyJlIjoiQVFBQiIsImt0eSI6IlJTQSIsIm4iOiJwdUwtV2NNWVVKMkFqZHkxVXNVZ056am42ZWNEeGlXZDdOR1VHcTI2N1NPTHdoS2pTV1dNd2tvcGZjZzVWTWpQSldFRTM4SUlYeWpXNW5GS0NxRkFJZjNabGloXzFTTGNqZ1ZGYmlibi1vTUdGTFpzOWdncjJialJHSnNic0pRSU9LbWdWczJ5M2w1UmNJeUYyTS1VT3g0R3RBVVFKc1lpdHRjaEJMeHFqczBTQmpXZHRwV3phWDRmd1RDeng0OFJYdVpoa3lfbUtBeUtiaEFZbklHZERoY1ZJWnNmZjZ6ekVNMWJwSkVENk9CWmg2cHlQLU4wa094Y0dtUFBDSE1mME16d2puSzhWckZQRWFJSWZRQWJVQzFyVGF1aXFaWDdnbEVuTjJrWXFPd2w4ZzNuZjVmYlg2c1V1RFUxNWZWMGNtZFV0aHk4X0dIeUUycWR6alBSTHcifSwibm9uY2UiOiItbWxKaGNveF82RkZ1RHdOaGNtTDA2RldENnVMN0s3bGFtOUplbC1NcXFNIiwidXJsIjoiaHR0cDovL2xvY2FsaG9zdDo0MDAxL2FjbWUvbmV3LWFjY3QifQ\",\"payload\":\"eyJvbmx5UmV0dXJuRXhpc3RpbmciOnRydWV9\",\"signature\":\"lztzTXBmbrxXGMspfEetHDGKdZ2NrpQTioysqHIa9aaL5dy8bPmKZ_Vmz68-xnUJcjK-5FMCn5vtYEKAJlJ7W3wVYzthcVuYlv-b6FNw3IYsdSSHMr5RLm0rSt9EwYd-BI4bCoT7dioYpCMHzTrd-3X8QjDS4fx1o6D-po_Hwkt4PWx5Yoo9ExlykM5cHOQlCQENPk3Pn0M4_8XkfH1QTvVTIm4A4lbo_Eko1aU9PgvWbNsqkEhRzH7rBb5FUlxFgRoSHuTJwn6uJL-H0cfYQUn-J5JyD5C-P8su3M7NoAXCj0vy_84TziHMxe1C8fI-A64M6CtlL9qGm5MwPgv8Gg\"}"
}
because:
method matches = false
path matches = false
query string parameters match = true
body matches = false
headers match = true
cookies match = true
keep-alive matches = true
ssl matches = true
00:27:53,716 INFO (nioEventLoopGroup-3-4) [org.mockserver.mock.HttpStateHandler] <LoggingFormatter.java:34> request:
{
"method" : "GET",
"path" : "/directory",
"headers" : {
"content-length" : [ "0" ],
"Accept" : [ "text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2" ],
"User-Agent" : [ "Elytron ACME Client/1.7.0.CR2" ],
"Connection" : [ "keep-alive" ],
"Host" : [ "localhost:4001" ],
"Accept-Language" : [ "en-US" ]
},
"keepAlive" : true,
"secure" : false
}
did not match expectation:
{
"method" : "POST",
"path" : "/acme/revoke-cert",
"body" : "{\"protected\":\"eyJhbGciOiJSUzI1NiIsImtpZCI6Imh0dHA6Ly9sb2NhbGhvc3Q6NDAwMS9hY21lL2FjY3QvMzg0Iiwibm9uY2UiOiJ6YlFSN0NMX0dTeDBveWRaMEFWb05FaDdvbVlfWE9OZFdGcFlPZmVGVlFjIiwidXJsIjoiaHR0cDovL2xvY2FsaG9zdDo0MDAxL2FjbWUvcmV2b2tlLWNlcnQifQ\",\"payload\":\"eyJjZXJ0aWZpY2F0ZSI6Ik1JSUZaekNDQkUtZ0F3SUJBZ0lUQVBfNDBNVEh3LWw1M3lpOWVOMnptclFkX1RBTkJna3Foa2lHOXcwQkFRc0ZBREFmTVIwd0d3WURWUVFEREJSb01uQndlU0JvTW1OclpYSWdabUZyWlNCRFFUQWVGdzB4T0RBME16QXhPRFF4TURoYUZ3MHhPREEzTWpreE9EUXhNRGhhTUI0eEhEQWFCZ05WQkFNVEUyaHRlSFJ1ZFd0c2JHaDRlR3hpYUM1amIyMHdnZ0VpTUEwR0NTcUdTSWIzRFFFQkFRVUFBNElCRHdBd2dnRUtBb0lCQVFDWUpyX3BaQkNTeV9LZHdLd1c0TDdyNnhWYVB1R0dna1JKY3lnTE5EWUhNd2JObm9zM3FnckpEMk0tRW5HOWlrSmlIRzd5VUtfVHRGNWZrVFA3UEROUzNlallkVTl1RTFHeTM1VTcyVGVzbVpzSC1aNy11NHJsc1JxdzVXcURDUjBGeW1PR0xuUEpVa3hGN29PRlFHc1lwZ3h3T1JVV0g5TlBEUzZTT3RTWF9XbUJ0S015VGM5QW9GRjBlRHM3NlBmOWl5eXZONjh4ejF6Y3g5aENnbDB5ZVNXTFhUNHV1SUJibHIxNXZhdzdCVVFNMnBGdE9aNGFIcWRiTDUtQ05TOWVxNUk2WTRpMW1yQVBEWklkN2xMOHAxY2tQLXI0dlh0a0VVdmxEaXFNMzdiRlB3enZDMWVVeGtOanNTdnQ0OGh4TTBtMU82cHZhTVB2Qm1CWGxHOUZBZ01CQUFHamdnS2JNSUlDbHpBT0JnTlZIUThCQWY4RUJBTUNCYUF3SFFZRFZSMGxCQll3RkFZSUt3WUJCUVVIQXdFR0NDc0dBUVVGQndNQ01Bd0dBMVVkRXdFQl93UUNNQUF3SFFZRFZSME9CQllFRkl3VXBFcGpUbmhUTl9XN3JlckkwT3V2alVMck1COEdBMVVkSXdRWU1CYUFGUHQ0VHhMNVlCV0RMSjhYZnpRWnN5NDI2a0dKTUdRR0NDc0dBUVVGQndFQkJGZ3dWakFpQmdnckJnRUZCUWN3QVlZV2FIUjBjRG92THpFeU55NHdMakF1TVRvME1EQXlMekF3QmdnckJnRUZCUWN3QW9Za2FIUjBjRG92TDJKdmRXeGtaWEk2TkRRek1DOWhZMjFsTDJsemMzVmxjaTFqWlhKME1CNEdBMVVkRVFRWE1CV0NFMmh0ZUhSdWRXdHNiR2g0ZUd4aWFDNWpiMjB3SndZRFZSMGZCQ0F3SGpBY29CcWdHSVlXYUhSMGNEb3ZMMlY0WVcxd2JHVXVZMjl0TDJOeWJEQmhCZ05WSFNBRVdqQllNQWdHQm1lQkRBRUNBVEJNQmdNcUF3UXdSVEFpQmdnckJnRUZCUWNDQVJZV2FIUjBjRG92TDJWNFlXMXdiR1V1WTI5dEwyTndjekFmQmdnckJnRUZCUWNDQWpBVERCRkVieUJYYUdGMElGUm9iM1VnVjJsc2REQ0NBUVFHQ2lzR0FRUUIxbmtDQkFJRWdmVUVnZklBOEFCMUFOMlpOUHlsNXlTQXlWWm9mWUUwbVFoSnNrbjN0V25ZeDd5clAxekI4MjVrQUFBQll4Z1NzYVFBQUFRREFFWXdSQUlnTUFGb19yNFl0aWNfc1lpVmxpaE10ZGZSZDFnclNYSUl1U2pwQzNZT1NOZ0NJRzdMWTlkMGl2cVV2czJ3Y0Z1Q0tNZkFsdDFNWTNvcjR6cGJlelFsNWpvREFIY0FGdWhwd2RHVjZ0ZkQtSmNhNF9CMkFmZU00YmFkTWFoU0dMYURmekdvRlFnQUFBRmpHQkt4cFFBQUJBTUFTREJHQWlFQTRYSmZVd3JVbkxWUGxRbF9IVVFxakRUVkFRdDJIN29BdXNrWUhiT3EtYTRDSVFEcGZwa3pNbkxudlNxay02QU5ZRWRKb0p5Q0M3M1ZwdHo0WG1MVnJMNHNtekFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBc1VEMUJ6M2NWQzA4NXF4a2VkYzJqd3FUSEk0UF9OaERrQVFmSGhrQ0VlaFoyVTVmRE1YWXFwZDh0UUluZUdoZU1ZTkQ4OWRFQXYyXzI5SXNGXzhKNC1uSURrLU1XQkFsQm43VUtES2xDbEdza0RDenJPajF6clJwOUtscTNLaElFSkUzT01nTGIyM3pNbERLeWRIcXA5OGtTc25hQmFoS1VlV3l1WXcxdmNwemZ3TjE0UG9xMW1jRnJWUFAxcWRBNG1NMTVFVHgyV0tZdTFWaWIySVVESmx2STNYbUg5SFR5ODZYRTRMNXFTd20xalJFbzZ5a3FDTmhSMHJMeHhHeXhDRldWVXVLNG9SaFR3YmF0VzEzR3JvSlhGdGNQeVVuRGJkSU9iRzIwLV9DME9ZMk9Rc1pWQTNWTC1IQ2c3ckt6QnZOSTNlaVkzVVNMYVBMM1I0dWhnIiwicmVhc29uIjoxMH0\",\"signature\":\"eP8PR2UEdU-HW7hM0XyeDWuPADRh_XKwmNM8QmowJzn4WLYkp-pHbnpGnID0aRTAjFQsvvPmkWIrNN9TMCgwfr5EqP7xoU1uGS3J6uNydZI4TyjGZaJ9v1I9sqb5Zw_Q5cht-vSMnxznmuEu3K_6jrDLq9x-U22sNFyA_aoqu5odPNJl_l2D2ZHaPbO19NjOfc2-mgBKR4y850oEzz8vKsFcPjtASFMoC3Ulyc2kDHuUeH9HL3W4DqvD0ygVhcbh5R9NRzwefj1h2YSD_8QJj20DprPSReJ_LxZTZzy3-oB3WWibLUaVS6xr0ZbMCPQSp_rTSRWpekWoM7vm_XwdCQ\"}"
}
because:
method matches = false
path matches = false
query string parameters match = true
body matches = false
headers match = true
cookies match = true
keep-alive matches = true
ssl matches = true
{noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-11566) ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
by Ron Sigal (Jira)
[ https://issues.jboss.org/browse/WFLY-11566?page=com.atlassian.jira.plugin... ]
Ron Sigal updated WFLY-11566:
-----------------------------
Attachment: WFLY-11566-3.tar
> ConstraintDeclarationException on JAX-RS/EJB Methods with List/Set query parameter
> ----------------------------------------------------------------------------------
>
> Key: WFLY-11566
> URL: https://issues.jboss.org/browse/WFLY-11566
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 14.0.0.Final, 15.0.1.Final
> Reporter: Alexander Wagner
> Assignee: Ron Sigal
> Priority: Critical
> Attachments: WFLY-11566-3.tar
>
>
> You got an exception if you call methods on JAX-RS endpoints which are also e.g. a stateless EJB and have Set or List as query parameters.
> As a workaround we use the "@Context UriInfo info" as parameter an read the parameter manually. As a downside this parameters are missing than in automated api generation with e.g. swagger. Without the @NotEmpty annotation it works fine. Without the generic type parameter ie just List it works fine. Making it a simple CDI bean makes it work fine.
> This issue is caused by [commit - WFLY-9628 Allow to switch to Hibernate Validator 6.0 / Bean Validation 2.0|https://github.com/wildfly/wildfly/commit/02f230d91f55f86ee6cadf53832...]
> Steps to reproduce:
> {code:java}
> @Stateless
> @Path("/")
> public class Resource {
> @POST
> @Path("put/list")
> @Consumes(MediaType.APPLICATION_JSON)
> public String putList(@NotEmpty List<String> a) {
> return "Hello bars " + a.stream().collect(Collectors.joining(", "));
> }
> }
> {code}
> {noformat}
> [mkopecky@dhcp-10-40-5-71 bin]$ curl -d '["a","b","c"]' -H "Content-Type: application/json" -X POST http://localhost:8080/jaxrs-wf/put/list
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> [mkopecky@dhcp-10-40-5-71 bin]$
> {noformat}
> {noformat}
> javax.validation.ConstraintDeclarationException: HV000151: A method overriding another method must not redefine the parameter constraint configuration, but method Resource$$$view1#putList(List) redefines the configuration of Resource#putList(List).
> at org.hibernate.validator.internal.metadata.aggregated.rule.OverridingMethodMustNotAlterParameterConstraints.apply(OverridingMethodMustNotAlterParameterConstraints.java:24)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.assertCorrectnessOfConfiguration(ExecutableMetaData.java:461)
> at org.hibernate.validator.internal.metadata.aggregated.ExecutableMetaData$Builder.build(ExecutableMetaData.java:377)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BuilderDelegate.build(BeanMetaDataImpl.java:788)
> at org.hibernate.validator.internal.metadata.aggregated.BeanMetaDataImpl$BeanMetaDataBuilder.build(BeanMetaDataImpl.java:648)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.createBeanMetaData(BeanMetaDataManager.java:192)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.lambda$getBeanMetaData$0(BeanMetaDataManager.java:160)
> at java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:324)
> at org.hibernate.validator.internal.metadata.BeanMetaDataManager.getBeanMetaData(BeanMetaDataManager.java:159)
> at org.hibernate.validator.internal.engine.ValidationContext$ValidationContextBuilder.forValidateParameters(ValidationContext.java:619)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:254)
> at org.hibernate.validator.internal.engine.ValidatorImpl.validateParameters(ValidatorImpl.java:224)
> at org.jboss.resteasy.plugins.validation.GeneralValidatorImpl.validateAllParameters(GeneralValidatorImpl.java:177)
> at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:118)
> at org.jboss.resteasy.core.ResourceMethodInvoker.internalInvokeOnTarget(ResourceMethodInvoker.java:509)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTargetAfterFilter(ResourceMethodInvoker.java:399)
> at org.jboss.resteasy.core.ResourceMethodInvoker.lambda$invokeOnTarget$0(ResourceMethodInvoker.java:363)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:365)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:337)
> at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:310)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:439)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$invoke$4(SynchronousDispatcher.java:229)
> at org.jboss.resteasy.core.SynchronousDispatcher.lambda$preprocess$0(SynchronousDispatcher.java:135)
> at org.jboss.resteasy.core.interception.PreMatchContainerRequestContext.filter(PreMatchContainerRequestContext.java:355)
> at org.jboss.resteasy.core.SynchronousDispatcher.preprocess(SynchronousDispatcher.java:138)
> at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:215)
> at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:227)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56)
> at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51)
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:791)
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:74)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:129)
> at io.opentracing.contrib.jaxrs2.server.SpanFinishingFilter.doFilter(SpanFinishingFilter.java:55)
> at io.undertow.servlet.core.ManagedFilter.doFilter(ManagedFilter.java:61)
> at io.undertow.servlet.handlers.FilterHandler$FilterChainImpl.doFilter(FilterHandler.java:131)
> at io.undertow.servlet.handlers.FilterHandler.handleRequest(FilterHandler.java:84)
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
> at io.undertow.servlet.handlers.ServletChain$1.handleRequest(ServletChain.java:68)
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:132)
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
> at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
> at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1502)
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:360)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1378)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> Links:
> * [forum|https://developer.jboss.org/thread/278822]
> * WFLY-11566
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (DROOLS-3484) Data type constraints: Date range Include/Exclude actions.
by Liz Clayton (Jira)
[ https://issues.jboss.org/browse/DROOLS-3484?page=com.atlassian.jira.plugi... ]
Liz Clayton commented on DROOLS-3484:
-------------------------------------
Thanks [~tirelli]! Sounds like this is the general formula then:
* Include/ include: [value..value]
* Include/ exclude: [value..value)
* Exclude / include: (value..value]
* Exclude/ exclude: (value..value)
> Data type constraints: Date range Include/Exclude actions.
> ----------------------------------------------------------
>
> Key: DROOLS-3484
> URL: https://issues.jboss.org/browse/DROOLS-3484
> Project: Drools
> Issue Type: Story
> Components: DMN Editor
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Priority: Major
> Labels: UX, UXTeam, drools-tools
> Attachments: date-rangeC.png
>
>
> Background
> Persona: Business analyst or Rules practitioner
> *Use Cases:*
> As a user I want the ability to define constraints for the Date data type, that enable me to specify if the start and end value is included/excluded in a selected date range.
> *Note, selection options:*
> Include/ Include [ .. ]
> Include/ Exclude [ .. )
> Exclude / Include ( .. ]
> Exclude / Exclude ( .. )
> *Verification conditions:*
> * Scrum team and PO review.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-11489) SFSB not sticky on a single cluster node when clustering of the bean is disabled
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11489?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz edited comment on WFLY-11489 at 1/11/19 1:40 PM:
---------------------------------------------------------------------
I've now had a look in detail at the affinity processing here and have an idea for a fix. There are three problems to overcome.
The first is to correct the assignment of strong and weak affinity for the SFSB with passivationEnabled == false. If the initial affinity of the proxy before session creation is (strong affinity, weak affinity) = (NONE, NONE), which is the default, then the affinity assignment we expect is either (NODE, NONE) or (NONE, NODE) which are equivalent. In other words, invocations should be tied to the node that the session is created on. This will require simple changes to the way the affinity is calculated - namely using the session cache do to the calculations.
The second problem is that the v3 protocol will not allow sending arbitrary affinity values back to the client: it is assumed that:
* updates to strong affinity are always of type ClusterAffinity
* updates to weak affinity are always of type NodeAffinity
For the code, see for example https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
This means that we can't assign (NODE, NONE) to the SFSB with passivationEnabled=false, but we can assign (NONE, NODE) which is equivalent. This seems to be the only way around this particular issue.
The third problem is that, on the client side, when the reply from the server is unpacked, there are some adjustments made to the affinity values before the invocation completes. These adjustments seem to interpret Affinity.NONE as "the affinity is not set", and try to replace Affinity.NONE with the targetAffinity which was determined when doing discovery. For example: https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org.... In fact, Affinity.NONE means "I don't care which node you send me to" and does not mean "the affinity is not set". So, for example, the affinity adjustment made in the DiscoveryEJBClientInterceptor above will transform (NONE, NODE) into (NODE, NODE) or possibly (URI, NODE) where URI is a URIAffinity assigment for the locator pointing to the server used to create the session. In this case, such a manipulation may not hurt, but it seems to be unnecessary.
So, i'll be putting together a fix which incorporates these three changes. It would have been much easier and cleaner to be able to assign to the strong or weak affinity any affinity type, but with the v3 protocol, that is currently not possible.
PS For those interested, targetAffinity is assigned as a side effect when we choose a target for the invocation. Doing discovery results in choosing a serviceURL to send the invocation to which satisfies the strong/weak affinity constraints. That serviceURL contains a location together with optional node, module and cluster attributes. The location tells us how to connect to the node, the attributes tell us what the node name is, which modules are deployed there and which clusters it belongs to. targetAffinity is NodeAffinity(<node name>) if the serviceURL does have a node attribute, and URIAffinity(<location>) if there is no node attribute. It seems to be used to make adjustments to affinity on the client based on where the last invocation attempt went. I'm really not seeing why this is needed; it may be related to the assumptions made in the v3 protocol.
was (Author: rachmato):
I've now had a look in detail at the affinity processing here and have an idea for a fix. There are three problems to overcome.
The first is to correct the assignment of strong and weak affinity for the SFSB with passivationEnabled == false. If the initial affinity of the proxy before session creation is (strong affinity, weak affinity) = (NONE, NONE), which is the default, then the affinity assignment we expect is either (NODE, NONE) or (NONE, NODE) which are equivalent. In other words, invocations should be tied to the node that the session is created on. This will require simple changes to the way the affinity is calculated - namely using the session cache do to the calculations.
The second problem is that the v3 protocol will not allow sending arbitrary affinity values back to the client: it is assumed that:
* updates to strong affinity are always of type ClusterAffinity
* updates to weak affinity are always of type NodeAffinity
For the code, see for example https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
This means that we can't assign (NODE, NONE) to the SFSB with passivationEnabled=false, but we can assign (NONE, NODE) which is equivalent. This seems to be the only way around this particular issue.
The third problem is that, on the client side, when the reply from the server is unpacked, there are some adjustments made to the affinity values before the invocation completes. These adjustments seem to interpret Affinity.NONE as "the affinity is not set", and try to replace Affinity.NONE with the targetAffinity which was determined when doing discovery. For example: https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org.... In fact, Affinity.NONE means "I don't care which node you send me to" and does not mean "the affinity is not set". So, for example, the affinity adjustment made in the DiscoveryEJBClientInterceptor above will transform (NONE, NODE) into (NODE, NODE) or possibly (URI, NODE) where URI is a URIAffinity assigment for the locator pointing to the server used to create the session. In this case, such a manipulation may not hurt, but it seems to be unnecessary.
So, i'll be putting together a fix which incorporates these three changes. It would have been much easier and cleaner to be able to assign to the strong or weak affinity any affinity type, but with the v3 protocol, that is currently not possible.
PS For those interested, targetAffinity is assigned as a side effect when we choose a target for the invocation. Doing discovery results in choosing a serviceURL to send the invocation to which satisfies the strong/weak affinity constraints. That serviceURL contains a location together with optional node, module and cluster attributes. The location tells us how to connect to the node, the attributes tell us what the node name is, which modules are deployed there and which clusters it belongs to. targetAffinity is NodeAffinity(<node name>) if the serviceURL does have a node attribute, and URIAffinity(<location>) if there is no node attribute. It seems to be used to make adjustments to affinity on the client based on where the last invocation attempt went. I'm really not seeing why this is needed.
> SFSB not sticky on a single cluster node when clustering of the bean is disabled
> --------------------------------------------------------------------------------
>
> Key: WFLY-11489
> URL: https://issues.jboss.org/browse/WFLY-11489
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Remoting
> Affects Versions: 15.0.0.Final
> Environment: A clustered environment with 2 nodes. Both nodes started with an unmodified {{standalone-ha.xml}} configuration (see _Steps to Reproduce_)
> This issue happens on 15.0.0.Final and was tested as well as on current head (sha: 372697282dccefd0b9df48e6aa4dcb69e1c4b40f).
> Reporter: Jörg Bäsner
> Assignee: Richard Achmatowicz
> Priority: Major
> Attachments: reproducer.zip
>
>
> In case a stateful session bean is annotated with:
> {{@Stateful(passivationCapable=false)}}
> then the serialization is *disabled* and thus the bean is only available on a single cluster node.
> When a client now calls two different methods on this stateful bean it intermittently ends up on different cluster nodes, resulting in the following Exception:
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (default task-2) WFLYEJB0034: EJB Invocation failed on component TestSessionEJB for method public abstract void test.ITestSession.method2(java.lang.String,java.lang.String) throws javax.ejb.EJBException,java.rmi.RemoteException: javax.ejb.NoSuchEJBException: WFLYEJB0168: Could not find EJB with id UUIDSessionID [4b0f4a27-40ba-411b-8852-0108a5ec64f4]
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:55)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:618)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:406)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:565)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:546)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:197)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-11489) SFSB not sticky on a single cluster node when clustering of the bean is disabled
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11489?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz edited comment on WFLY-11489 at 1/11/19 1:39 PM:
---------------------------------------------------------------------
I've now had a look in detail at the affinity processing here and have an idea for a fix. There are three problems to overcome.
The first is to correct the assignment of strong and weak affinity for the SFSB with passivationEnabled == false. If the initial affinity of the proxy before session creation is (strong affinity, weak affinity) = (NONE, NONE), which is the default, then the affinity assignment we expect is either (NODE, NONE) or (NONE, NODE) which are equivalent. In other words, invocations should be tied to the node that the session is created on. This will require simple changes to the way the affinity is calculated - namely using the session cache do to the calculations.
The second problem is that the v3 protocol will not allow sending arbitrary affinity values back to the client: it is assumed that:
* updates to strong affinity are always of type ClusterAffinity
* updates to weak affinity are always of type NodeAffinity
For the code, see for example https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
This means that we can't assign (NODE, NONE) to the SFSB with passivationEnabled=false, but we can assign (NONE, NODE) which is equivalent. This seems to be the only way around this particular issue.
The third problem is that, on the client side, when the reply from the server is unpacked, there are some adjustments made to the affinity values before the invocation completes. These adjustments seem to interpret Affinity.NONE as "the affinity is not set", and try to replace Affinity.NONE with the targetAffinity which was determined when doing discovery. For example: https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org.... In fact, Affinity.NONE means "I don't care which node you send me to" and does not mean "the affinity is not set". So, for example, the affinity adjustment made in the DiscoveryEJBClientInterceptor above will transform (NONE, NODE) into (NODE, NODE) or possibly (URI, NODE) where URI is a URIAffinity assigment for the locator pointing to the server used to create the session. In this case, such a manipulation may not hurt, but it seems to be unnecessary.
So, i'll be putting together a fix which incorporates these three changes. It would have been much easier and cleaner to be able to assign to the strong or weak affinity any affinity type, but with the v3 protocol, that is currently not possible.
PS For those interested, targetAffinity is assigned as a side effect when we choose a target for the invocation. Doing discovery results in choosing a serviceURL to send the invocation to which satisfies the strong/weak affinity constraints. That serviceURL contains a location together with optional node, module and cluster attributes. The location tells us how to connect to the node, the attributes tell us what the node name is, which modules are deployed there and which clusters it belongs to. targetAffinity is NodeAffinity(<node name>) if the serviceURL does have a node attribute, and URIAffinity(<location>) if there is no node attribute. It seems to be used to make adjustments to affinity on the client based on where the last invocation attempt went. I'm really not seeing why this is needed.
was (Author: rachmato):
I've now had a look in detail at the affinity processing here and have an idea for a fix. There are three problems to overcome.
The first is to correct the assignment of strong and weak affinity for the SFSB with passivationEnabled == false. If the initial affinity of the proxy before session creation is (strong affinity, weak affinity) = (NONE, NONE), which is the default, then the affinity assignment we expect is either (NODE, NONE) or (NONE, NODE) which are equivalent. In other words, invocations should be tied to the node that the session is created on. This will require simple changes to the way the affinity is calculated - namely using the session cache do to the calculations.
The second problem is that the v3 protocol will not allow sending arbitrary values affinity back to the client: it is assumed that:
* updates to strong affinity are always of type ClusterAffinity
* updates to weak affinity are always of type NodeAffinity
For the code, see for example https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
This means that we can't assign (NODE, NONE) to the SFSB with passivationEnabled=false, but we can assign (NONE, NODE) which is equivalent. This seems to be the only way around this particular issue.
The third problem is that, on the client side, when the reply from the server is unpacked, there are some adjustments made to the affinity values before the invocation completes. These adjustments seem to interpret Affinity.NONE as "the affinity is not set", and try to replace Affinity.NONE with the targetAffinity which was determined when doing discovery. For example: https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org.... In fact, Affinity.NONE means "I don't care which node you send me to" and does not mean "the affinity is not set". So, for example, the affinity adjustment made in the DiscoveryEJBClientInterceptor above will transform (NONE, NODE) into (NODE, NODE) or possibly (URI, NODE) where URI is a URIAffinity assigment for the locator pointing to the server used to create the session. In this case, such a manipulation may not hurt, but it seems to be unnecessary.
So, i'll be putting together a fix which incorporates these three changes. It would have been much easier and cleaner to be able to assign to the strong or weak affinity any affinity type, but with the v3 protocol, that is currently not possible.
PS For those interested, targetAffinity is assigned as a side effect when we choose a target for the invocation. Doing discovery results in choosing a serviceURL to send the invocation to which satisfies the strong/weak affinity constraints. That serviceURL contains a location together with optional node, module and cluster attributes. The location tells us how to connect to the node, the attributes tell us what the node name is, which modules are deployed there and which clusters it belongs to. targetAffinity is NodeAffinity(<node name>) if the serviceURL does have a node attribute, and URIAffinity(<location>) if there is no node attribute. It seems to be used to make adjustments to affinity on the client based on where the last invocation attempt went. I'm really not seeing why this is needed.
> SFSB not sticky on a single cluster node when clustering of the bean is disabled
> --------------------------------------------------------------------------------
>
> Key: WFLY-11489
> URL: https://issues.jboss.org/browse/WFLY-11489
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Remoting
> Affects Versions: 15.0.0.Final
> Environment: A clustered environment with 2 nodes. Both nodes started with an unmodified {{standalone-ha.xml}} configuration (see _Steps to Reproduce_)
> This issue happens on 15.0.0.Final and was tested as well as on current head (sha: 372697282dccefd0b9df48e6aa4dcb69e1c4b40f).
> Reporter: Jörg Bäsner
> Assignee: Richard Achmatowicz
> Priority: Major
> Attachments: reproducer.zip
>
>
> In case a stateful session bean is annotated with:
> {{@Stateful(passivationCapable=false)}}
> then the serialization is *disabled* and thus the bean is only available on a single cluster node.
> When a client now calls two different methods on this stateful bean it intermittently ends up on different cluster nodes, resulting in the following Exception:
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (default task-2) WFLYEJB0034: EJB Invocation failed on component TestSessionEJB for method public abstract void test.ITestSession.method2(java.lang.String,java.lang.String) throws javax.ejb.EJBException,java.rmi.RemoteException: javax.ejb.NoSuchEJBException: WFLYEJB0168: Could not find EJB with id UUIDSessionID [4b0f4a27-40ba-411b-8852-0108a5ec64f4]
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:55)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:618)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:406)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:565)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:546)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:197)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-11489) SFSB not sticky on a single cluster node when clustering of the bean is disabled
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11489?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz edited comment on WFLY-11489 at 1/11/19 1:33 PM:
---------------------------------------------------------------------
I've now had a look in detail at the affinity processing here and have an idea for a fix. There are three problems to overcome.
The first is to correct the assignment of strong and weak affinity for the SFSB with passivationEnabled == false. If the initial affinity of the proxy before session creation is (strong affinity, weak affinity) = (NONE, NONE), which is the default, then the affinity assignment we expect is either (NODE, NONE) or (NONE, NODE) which are equivalent. In other words, invocations should be tied to the node that the session is created on. This will require simple changes to the way the affinity is calculated - namely using the session cache do to the calculations.
The second problem is that the v3 protocol will not allow sending arbitrary values affinity back to the client: it is assumed that:
* updates to strong affinity are always of type ClusterAffinity
* updates to weak affinity are always of type NodeAffinity
For the code, see for example https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
This means that we can't assign (NODE, NONE) to the SFSB with passivationEnabled=false, but we can assign (NONE, NODE) which is equivalent. This seems to be the only way around this particular issue.
The third problem is that, on the client side, when the reply from the server is unpacked, there are some adjustments made to the affinity values before the invocation completes. These adjustments seem to interpret Affinity.NONE as "the affinity is not set", and try to replace Affinity.NONE with the targetAffinity which was determined when doing discovery. For example: https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org.... In fact, Affinity.NONE means "I don't care which node you send me to" and does not mean "the affinity is not set". So, for example, the affinity adjustment made in the DiscoveryEJBClientInterceptor above will transform (NONE, NODE) into (NODE, NODE) or possibly (URI, NODE) where URI is a URIAffinity assigment for the locator pointing to the server used to create the session. In this case, such a manipulation may not hurt, but it seems to be unnecessary.
So, i'll be putting together a fix which incorporates these three changes. It would have been much easier and cleaner to be able to assign to the strong or weak affinity any affinity type, but with the v3 protocol, that is currently not possible.
PS For those interested, targetAffinity is assigned as a side effect when we choose a target for the invocation. Doing discovery results in choosing a serviceURL to send the invocation to which satisfies the strong/weak affinity constraints. That serviceURL contains a location together with optional node, module and cluster attributes. The location tells us how to connect to the node, the attributes tell us what the node name is, which modules are deployed there and which clusters it belongs to. targetAffinity is NodeAffinity(<node name>) if the serviceURL does have a node attribute, and URIAffinity(<location>) if there is no node attribute. It seems to be used to make adjustments to affinity on the client based on where the last invocation attempt went. I'm really not seeing why this is needed.
was (Author: rachmato):
I've now had a look in detail at the affinity processing here and have an idea for a fix. There are three problems to overcome.
The first is to correct the assignment of strong and weak affinity for the SFSB with passivationEnabled == false. If the initial affinity of the proxy before session creation is (strong affinity, weak affinity) = (NONE, NONE), which is the default, then the affinity assignment we expect is either (NODE, NONE) or (NONE, NODE) which are equivalent. In other words, invocations should be tied to the node that the session is created on. This will require simple changes to the way the affinity is calculated - namely using the session cache do to the calculations.
The second problem is that the v3 protocol will not allow sending arbitrary values affinity back to the client: it is assumed that:
* updates to strong affinity are always of type ClusterAffinity
* updates to weak affinity are always of type NodeAffinity
For the code, see for example https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
This means that we can't assign (NODE, NONE) to the SFSB with passivationEnabled=false, but we can assign (NONE, NODE) which is equivalent. This seems to be the only way around this particular issue.
The third problem is that, on the client side, when the reply from the server is unpacked, there are some adjustments made to the affinity values before the invocation completes. These adjustments seem to interpret Affinity.NONE as "the affinity is not set", and try to replace Affinity.NONE with the targetAffinity which was determined when doing discovery. For example: https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org.... In fact, Affinity.NONE means "I don't care which node you send me to" and does not mean "the affinity is not set". So, for example, the affinity adjustment made in the DiscoveryEJBClientInterceptor above will transform (NONE, NODE) into (NODE, NODE) or possibly (URI, NODE) where URI is a URIAffinity assigment for the locator pointing to the server used to create the session. In this case, such a manipulation may not hurt, but it seems to be unnecessary.
So, i'll be putting together a fix which incorporates these three changes. It would have been much easier and cleaner to be able to assign to the strong or weak affinity any affinity type, but with the v3 protocol, that is currently not possible.
PS For those interested, targetAffinity is assigned as a side effect when we choose a target for the invocation. Doing discovery results in choosing a serviceURL to send the invocation to which satisfies the strong/weak affinity constraints. That serviceURL contains a location together with optional node, module and cluster attributes. The location tells us how to connect to the node, the attributes tell us what the node name is, which modules are deployed there and which clusters it belongs to. targetAffinity is NodeAffinity(<node name>) if the serviceURL does have a node attribute, and URIAffinity(<location>) if there is no node attribute.
> SFSB not sticky on a single cluster node when clustering of the bean is disabled
> --------------------------------------------------------------------------------
>
> Key: WFLY-11489
> URL: https://issues.jboss.org/browse/WFLY-11489
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Remoting
> Affects Versions: 15.0.0.Final
> Environment: A clustered environment with 2 nodes. Both nodes started with an unmodified {{standalone-ha.xml}} configuration (see _Steps to Reproduce_)
> This issue happens on 15.0.0.Final and was tested as well as on current head (sha: 372697282dccefd0b9df48e6aa4dcb69e1c4b40f).
> Reporter: Jörg Bäsner
> Assignee: Richard Achmatowicz
> Priority: Major
> Attachments: reproducer.zip
>
>
> In case a stateful session bean is annotated with:
> {{@Stateful(passivationCapable=false)}}
> then the serialization is *disabled* and thus the bean is only available on a single cluster node.
> When a client now calls two different methods on this stateful bean it intermittently ends up on different cluster nodes, resulting in the following Exception:
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (default task-2) WFLYEJB0034: EJB Invocation failed on component TestSessionEJB for method public abstract void test.ITestSession.method2(java.lang.String,java.lang.String) throws javax.ejb.EJBException,java.rmi.RemoteException: javax.ejb.NoSuchEJBException: WFLYEJB0168: Could not find EJB with id UUIDSessionID [4b0f4a27-40ba-411b-8852-0108a5ec64f4]
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:55)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:618)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:406)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:565)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:546)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:197)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-11489) SFSB not sticky on a single cluster node when clustering of the bean is disabled
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11489?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz edited comment on WFLY-11489 at 1/11/19 1:27 PM:
---------------------------------------------------------------------
I've now had a look in detail at the affinity processing here and have an idea for a fix. There are three problems to overcome.
The first is to correct the assignment of strong and weak affinity for the SFSB with passivationEnabled == false. If the initial affinity of the proxy before session creation is (strong affinity, weak affinity) = (NONE, NONE), which is the default, then the affinity assignment we expect is either (NODE, NONE) or (NONE, NODE) which are equivalent. In other words, invocations should be tied to the node that the session is created on. This will require simple changes to the way the affinity is calculated - namely using the session cache do to the calculations.
The second problem is that the v3 protocol will not allow sending arbitrary values affinity back to the client: it is assumed that:
* updates to strong affinity are always of type ClusterAffinity
* updates to weak affinity are always of type NodeAffinity
For the code, see for example https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
This means that we can't assign (NODE, NONE) to the SFSB with passivationEnabled=false, but we can assign (NONE, NODE) which is equivalent. This seems to be the only way around this particular issue.
The third problem is that, on the client side, when the reply from the server is unpacked, there are some adjustments made to the affinity values before the invocation completes. These adjustments seem to interpret Affinity.NONE as "the affinity is not set", and try to replace Affinity.NONE with the targetAffinity which was determined when doing discovery. For example: https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org.... In fact, Affinity.NONE means "I don't care which node you send me to" and does not mean "the affinity is not set". So, for example, the affinity adjustment made in the DiscoveryEJBClientInterceptor above will transform (NONE, NODE) into (NODE, NODE) or possibly (URI, NODE) where URI is a URIAffinity assigment for the locator pointing to the server used to create the session. In this case, such a manipulation may not hurt, but it seems to be unnecessary.
So, i'll be putting together a fix which incorporates these three changes. It would have been much easier and cleaner to be able to assign to the strong or weak affinity any affinity type, but with the v3 protocol, that is currently not possible.
PS For those interested, targetAffinity is assigned as a side effect when we choose a target for the invocation. Doing discovery results in choosing a serviceURL to send the invocation to which satisfies the strong/weak affinity constraints. That serviceURL contains a location together with optional node, module and cluster attributes. The location tells us how to connect to the node, the attributes tell us what the node name is, which modules are deployed there and which clusters it belongs to. targetAffinity is NodeAffinity(<node name>) if the serviceURL does have a node attribute, and URIAffinity(<location>) if there is no node attribute.
was (Author: rachmato):
I've now had a look in detail at the affinity processing here and have an idea for a fix. There are three problems to overcome.
The first is to correct the assignment of strong and weak affinity for the SFSB with passivationEnabled == false. If the initial affinity of the proxy before session creation is (strong affinity, weak affinity) = (NONE, NONE), which is the default, then the affinity assignment we expect is either (NODE, NONE) or (NONE, NODE) which are equivalent. In other words, invocations should be tied to the node that the session is created on.
The second problem is that the v3 protocol will not allow sending arbitrary values affinity back to the client: it is assumed that:
* updates to strong affinity are always of type ClusterAffinity
* updates to weak affinity are always of type NodeAffinity
For the code, see for example https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
This means that we can't assign (NODE, NONE) to the SFSB with passivationEnabled=false, but we can assign (NONE, NODE) which is equivalent. This seems to be the only way around this particular issue.
The third problem is that, on the client side, when the reply from the server is unpacked, there are some adjustments made to the affinity values before the invocation completes. These adjustments seem to interpret Affinity.NONE as "the affinity is not set", and try to replace Affinity.NONE with the targetAffinity which was determined when doing discovery. For example: https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org.... In fact, Affinity.NONE means "I don't care which node you send me to" and does not mean "the affinity is not set". So, for example, the affinity adjustment made in the DiscoveryEJBClientInterceptor above will transform (NONE, NODE) into (NODE, NODE) or possibly (URI, NODE) where URI is a URIAffinity assigment for the locator pointing to the server used to create the session. In this case, such a manipulation may not hurt, but it seems to be unnecessary.
So, i'll be putting together a fix which incorporates these three changes. It would have been much easier and cleaner to be able to assign to the strong or weak affinity any affinity type, but with the v3 protocol, that is currently not possible.
PS For those interested, targetAffinity is assigned as a side effect when we choose a target for the invocation. Doing discovery results in choosing a serviceURL to send the invocation to which satisfies the strong/weak affinity constraints. That serviceURL contains a location together with optional node, module and cluster attributes. The location tells us how to connect to the node, the attributes tell us what the node name is, which modules are deployed there and which clusters it belongs to. targetAffinity is NodeAffinity(<node name>) if the serviceURL does have a node attribute, and URIAffinity(<location>) if there is no node attribute.
> SFSB not sticky on a single cluster node when clustering of the bean is disabled
> --------------------------------------------------------------------------------
>
> Key: WFLY-11489
> URL: https://issues.jboss.org/browse/WFLY-11489
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Remoting
> Affects Versions: 15.0.0.Final
> Environment: A clustered environment with 2 nodes. Both nodes started with an unmodified {{standalone-ha.xml}} configuration (see _Steps to Reproduce_)
> This issue happens on 15.0.0.Final and was tested as well as on current head (sha: 372697282dccefd0b9df48e6aa4dcb69e1c4b40f).
> Reporter: Jörg Bäsner
> Assignee: Richard Achmatowicz
> Priority: Major
> Attachments: reproducer.zip
>
>
> In case a stateful session bean is annotated with:
> {{@Stateful(passivationCapable=false)}}
> then the serialization is *disabled* and thus the bean is only available on a single cluster node.
> When a client now calls two different methods on this stateful bean it intermittently ends up on different cluster nodes, resulting in the following Exception:
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (default task-2) WFLYEJB0034: EJB Invocation failed on component TestSessionEJB for method public abstract void test.ITestSession.method2(java.lang.String,java.lang.String) throws javax.ejb.EJBException,java.rmi.RemoteException: javax.ejb.NoSuchEJBException: WFLYEJB0168: Could not find EJB with id UUIDSessionID [4b0f4a27-40ba-411b-8852-0108a5ec64f4]
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:55)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:618)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:406)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:565)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:546)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:197)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months
[JBoss JIRA] (WFLY-11489) SFSB not sticky on a single cluster node when clustering of the bean is disabled
by Richard Achmatowicz (Jira)
[ https://issues.jboss.org/browse/WFLY-11489?page=com.atlassian.jira.plugin... ]
Richard Achmatowicz edited comment on WFLY-11489 at 1/11/19 1:25 PM:
---------------------------------------------------------------------
I've now had a look in detail at the affinity processing here and have an idea for a fix. There are three problems to overcome.
The first is to correct the assignment of strong and weak affinity for the SFSB with passivationEnabled == false. If the initial affinity of the proxy before session creation is (strong affinity, weak affinity) = (NONE, NONE), which is the default, then the affinity assignment we expect is either (NODE, NONE) or (NONE, NODE) which are equivalent. In other words, invocations should be tied to the node that the session is created on.
The second problem is that the v3 protocol will not allow sending arbitrary values affinity back to the client: it is assumed that:
* updates to strong affinity are always of type ClusterAffinity
* updates to weak affinity are always of type NodeAffinity
For the code, see for example https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
This means that we can't assign (NODE, NONE) to the SFSB with passivationEnabled=false, but we can assign (NONE, NODE) which is equivalent. This seems to be the only way around this particular issue.
The third problem is that, on the client side, when the reply from the server is unpacked, there are some adjustments made to the affinity values before the invocation completes. These adjustments seem to interpret Affinity.NONE as "the affinity is not set", and try to replace Affinity.NONE with the targetAffinity which was determined when doing discovery. For example: https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org.... In fact, Affinity.NONE means "I don't care which node you send me to" and does not mean "the affinity is not set". So, for example, the affinity adjustment made in the DiscoveryEJBClientInterceptor above will transform (NONE, NODE) into (NODE, NODE) or possibly (URI, NODE) where URI is a URIAffinity assigment for the locator pointing to the server used to create the session. In this case, such a manipulation may not hurt, but it seems to be unnecessary.
So, i'll be putting together a fix which incorporates these three changes. It would have been much easier and cleaner to be able to assign to the strong or weak affinity any affinity type, but with the v3 protocol, that is currently not possible.
PS For those interested, targetAffinity is assigned as a side effect when we choose a target for the invocation. Doing discovery results in choosing a serviceURL to send the invocation to which satisfies the strong/weak affinity constraints. That serviceURL contains a location together with optional node, module and cluster attributes. The location tells us how to connect to the node, the attributes tell us what the node name is, which modules are deployed there and which clusters it belongs to. targetAffinity is NodeAffinity(<node name>) if the serviceURL does have a node attribute, and URIAffinity(<location>) if there is no node attribute.
was (Author: rachmato):
I've now had a look in detail at the affinity processing here and have an idea for a fix. There are three problems to overcome.
The first is to correct the assignment of strong and weak affinity for the SFSB with passivationEnabled == false. If the initial affinity of the proxy before session creation is (strong affinity, weak affinity) = (NONE, NONE), which is the default, then the affinity assignment we expect is either (NODE, NONE) or (NONE, NODE) which are equivalent. In other words, invocations should be tied to the node that the session is created on.
The second problem is that the v3 protocol will not allow sending arbitrary values affinity back to the client: it is assumed that:
* updates to strong affinity are always of type ClusterAffinity
* updates to weak affinity are always of type NodeAffinity
For the code, see for example https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org...
This means that we can't assign (NODE, NONE) to the SFSB with passivationEnabled=false, but we can assign (NONE, NODE) which is equivalent. This seems to be the only way around this particular issue.
The third problem is that, on the client side, when the reply from the server is unpacked, there are some adjustments made to the affinity values before the invocation completes. These adjustments seem to interpret Affinity.NONE as "the affinity is not set", and try to replace Affinity.NONE with the targetAffinity which was determined when doing discovery. For example: https://github.com/wildfly/jboss-ejb-client/blob/master/src/main/java/org.... In fact, Affinity.NONE means "I don't care which node you send me to" and does not mean "the affinity is not set". So, for example, the affinity adjustment made in the DiscoveryEJBClientInterceptor above will transform (NONE, NODE) into (NODE, NODE) or possibly (URI, NODE) where URI is a URIAffinity assigment for the locator pointing to the server used to create the session. In this case, such a manipulation may not hurt, but it seems to be unnecessary.
So, i'll be putting together a fix which incorporates these three changes. It would have been much easier and cleaner to be able to assign to the strong or weak affinity any type of affinity, but with v3, that is currently not possible.
PS For those interested, targetAffinity is assigned when we choose a target for the invocation. Doing discovery to choose a target results in a serviceURL which contains a location and node, module and cluster attributes associated with the serviceURL. The location tells us how to connect to the node, the attributes tell us what the node name is, which modules are deployed there and which clusters it belongs to. targetAffinity is NodeAffinity(<node name>) if the serviceURL does have a node attribute, and URIAffinity(<location>) if there is no node attribute.
> SFSB not sticky on a single cluster node when clustering of the bean is disabled
> --------------------------------------------------------------------------------
>
> Key: WFLY-11489
> URL: https://issues.jboss.org/browse/WFLY-11489
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Remoting
> Affects Versions: 15.0.0.Final
> Environment: A clustered environment with 2 nodes. Both nodes started with an unmodified {{standalone-ha.xml}} configuration (see _Steps to Reproduce_)
> This issue happens on 15.0.0.Final and was tested as well as on current head (sha: 372697282dccefd0b9df48e6aa4dcb69e1c4b40f).
> Reporter: Jörg Bäsner
> Assignee: Richard Achmatowicz
> Priority: Major
> Attachments: reproducer.zip
>
>
> In case a stateful session bean is annotated with:
> {{@Stateful(passivationCapable=false)}}
> then the serialization is *disabled* and thus the bean is only available on a single cluster node.
> When a client now calls two different methods on this stateful bean it intermittently ends up on different cluster nodes, resulting in the following Exception:
> {code}
> ERROR [org.jboss.as.ejb3.invocation] (default task-2) WFLYEJB0034: EJB Invocation failed on component TestSessionEJB for method public abstract void test.ITestSession.method2(java.lang.String,java.lang.String) throws javax.ejb.EJBException,java.rmi.RemoteException: javax.ejb.NoSuchEJBException: WFLYEJB0168: Could not find EJB with id UUIDSessionID [4b0f4a27-40ba-411b-8852-0108a5ec64f4]
> at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:55)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509)
> at org.jboss.weld.module.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:81)
> at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438)
> at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:618)
> at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57)
> at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422)
> at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53)
> at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:406)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:565)
> at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:546)
> at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:197)
> at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1985)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1487)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1349)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 6 months