I am seeing following exception in my system log.
2019-09-09T07:08:09.491Z [priority='WARN' thread='TaskScheduler-5' user='' org='' trace=''] c.v.s.c.c.i.SlowRequestInterceptor - API call GET 'http://event:1234/event/api/subscriptions/broker-project-subscriber/poll/1' with response 200 OK took 420 ms.
2019-09-09T07:08:10.070Z [priority='INFO' thread='http-nio-8000-exec-10' user='-' org='-' trace='-'] GET /actuator/readiness HTTP/1.1 200 bytes='29' duration='2'
2019-09-09T07:08:11.070Z [priority='INFO' thread='http-nio-8000-exec-1' user='-' org='-' trace='-'] GET /readiness HTTP/1.1 200 bytes='29' duration='2'
2019-09-09T07:08:12.070Z [priority='INFO' thread='http-nio-8000-exec-2' user='-' org='-' trace='-'] GET /readiness HTTP/1.1 200 bytes='29' duration='2'
2019-09-09T07:08:12.696Z [priority='INFO' thread='TaskScheduler-3' user='' org='' trace=''] c.a.b.b.t.d.s.DeploymentProjectServiceImpl - Registering xxxx-service callbacks
2019-09-09T07:08:12.719Z [priority='INFO' thread='TaskScheduler-3' user='' org='' trace=''] c.a.b.b.xx.xx.gateway.XXXXXGateway - Registered callback for yyyyy-service-deployment.
2019-09-09T07:08:12.908Z [priority='WARN' thread='TaskScheduler-1' user='' org='' trace=''] c.v.s.c.c.i.SlowRequestInterceptor - API call GET 'http://event:1234/event/api/subscriptions/broker-project-subscriber/poll/1' with response 200 OK took 417 ms.
2019-09-09T07:08:13.070Z [priority='INFO' thread='http-nio-8000-exec-4' user='-' org='-' trace='-'] GET /readiness HTTP/1.1 200 bytes='29' duration='2'
2019-09-09T07:08:14.070Z [priority='INFO' thread='http-nio-8000-exec-6' user='-' org='-' trace='-'] GET /readiness HTTP/1.1 200 bytes='29' duration='2'
2019-09-09T07:08:15.071Z [priority='INFO' thread='http-nio-8000-exec-7' user='-' org='-' trace='-'] GET /readiness HTTP/1.1 200 bytes='29' duration='3'
2019-09-09T07:08:15.503Z [priority='ERROR' thread='http-nio-8000-exec-8' user='' org='' trace='3199f921d4ee6d75'] o.a.c.c.C.[.[.[/].[dispatcherServlet] - Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is java.lang.ClassCastException] with root cause
java.lang.ClassCastException: null
I have no clue on when it happens. It is coming from apache library. There is nothing before and after it. Could someone provide some, direction please ?
Related
I'm trying to recreate a request that works in Postman using a Spring RestTemplate. I've tried to make the requests identical, down to the fake "User-Agent" header, but for whatever reason the one from Postman returns 200 OK and the one from RestTemplate returns 301 Moved.
What could I possibly be doing wrong?
Both requests are below, "anonymized" by removing the urls and session cookie, both of which are identical - confirmed by copying one and searching the other.
This is the working request from Postman.
Frame 1541: 638 bytes on wire (5104 bits), 638 bytes captured (5104 bits) on interface en0, id 0
Transmission Control Protocol, Src Port: 51102, Dst Port: 80, Seq: 573, Ack: 840, Len: 572
Hypertext Transfer Protocol
POST <removed> HTTP/1.1\r\n
User-Agent: Java/17.0.2\r\n
Accept: text/plain, application/json, application/*+json, */*\r\n
Content-Type: application/x-www-form-urlencoded; charset=UTF-8\r\n
Cookie: JSESSIONID="<removed>"\r\n
Host: <removed>\r\n
Connection: keep-alive\r\n
Content-Length: 63\r\n
\r\n
[Full request URI: <removed>
[HTTP request 2/2]
[Prev request in frame: 1373]
[Response in frame: 1596]
File Data: 63 bytes
HTML Form URL Encoded: application/x-www-form-urlencoded
Form item: "<removed>" = "<removed>"
Key: <removed>
Value: <removed>
This is the failing request using RestTemplate.
Frame 3365: 129 bytes on wire (1032 bits), 129 bytes captured (1032 bits) on interface en0, id 0
Transmission Control Protocol, Src Port: 51110, Dst Port: 80, Seq: 509, Ack: 1, Len: 63
[2 Reassembled TCP Segments (571 bytes): #3363(508), #3365(63)]
Hypertext Transfer Protocol
POST <removed> HTTP/1.1\r\n
User-Agent: Java/17.0.2\r\n
Accept: text/plain, application/json, application/*+json, */*\r\n
Content-Type: application/x-www-form-urlencoded;charset=UTF-8\r\n
Cookie: JSESSIONID="<removed>"\r\n
Host: <removed>\r\n
Connection: keep-alive\r\n
Content-Length: 63\r\n
\r\n
[Full request URI: <removed>
[HTTP request 1/1]
[Response in frame: 3377]
File Data: 63 bytes
HTML Form URL Encoded: application/x-www-form-urlencoded
Form item: "<removed>" = "<removed>"
Key: <removed>
Value: <removed>
I have installed Cypress in two PCs with similar features. On the first one Cypress works, it's fast and doesn't give me any problems. On the second one I'm having difficulties:
The cy.visit command takes a very long time to reach my site, even 60 seconds. Actually the site has no problem of reachability
if I close the test execution and relaunch it, the test runner opens in an "about.blank" page
I've tried everything, uninstalled Cypress, cleared cypress cache. I have uninstalled node.js and npm. I then reinstalled the whole thing. But the problems remain. If you need more information I remain available. Below what is printed in powershell during the first test that contains a "cy.visit" (it took more than 80 seconds in all)
GET /__/ 200 45.608 ms - -
GET /__cypress/runner/cypress_runner.css 200 68.125 ms - -
GET /chrome-variations/seed?osname=win&channel=stable&milestone=89 304 652.798 ms - -
POST /ListAccounts?gpsia=1&source=ChromiumBrowser&json=standard 200 604.179 ms - -
GET /__cypress/runner/cypress_runner.js 200 71.181 ms - -
GET /__cypress/static/favicon.ico 200 4.437 ms - -
GET /__cypress/iframes/integration/pr/te.js 200 7.769 ms - 843
GET /__cypress/runner/fonts/fa-solid-900.woff2 200 3.737 ms - 76120
GET /v1/pages/ChRDaHJvbWUvODkuMC40Mzg5LjExNBIQCcmLdcaTM2VsEgUNkWGVThIXCQPNs0E5ZBKtEgUNL4g-ghIFDZFhlU4=?alt=proto 200 385.975 ms - -
GET /__cypress/tests?p=cypress%5Cintegration%5Cpr%5Cte.js 200 8102.285 ms - -
GET /__cypress/tests?p=cypress%5Csupport%5Cindex.js 200 8122.208 ms - -
GET /__/ 200 1.715 ms - -
GET /__cypress/runner/cypress_runner.css 200 1.567 ms - -
GET /__cypress/runner/cypress_runner.js 200 4.923 ms - -
GET /__cypress/iframes/integration/pr/te.js 200 2.085 ms - 849
GET /__cypress/runner/fonts/fa-solid-900.woff2 200 2.107 ms - 76120
GET /__cypress/tests?p=cypress%5Csupport%5Cindex.js 200 9.996 ms - -
GET /__cypress/tests?p=cypress%5Cintegration%5Cpr%5Cte.js 200 5.663 ms - -
GET /v1/pages/ChRDaHJvbWUvODkuMC40Mzg5LjExNBIQCXTM6vS20UQ9EgUNkWGVThIXCRevpbqZx6oNEgUNL4g-ghIFDZFhlU4=?alt=proto 200 87.250 ms - -
GET /men/1-1-hummingbird-printed-t-shirt.html 200 201.834 ms - -
GET /themes/classic/assets/css/theme.css 200 358.023 ms - -
GET /js/jquery/ui/themes/base/minified/jquery.ui.theme.min.css 200 221.726 ms - -
GET /modules/ps_imageslider/css/homeslider.css 200 299.205 ms - -
GET /themes/classic/assets/css/custom.css 200 294.395 ms - -
GET /themes/core.js 200 177.118 ms - -
GET /themes/classic/assets/js/theme.js 200 537.278 ms - -
GET /modules/ps_emailsubscription/views/js/ps_emailsubscription.js 200 148.071 ms - -
GET /js/jquery/ui/jquery-ui.min.js 200 281.471 ms - -
GET /modules/ps_imageslider/js/responsiveslides.min.js 200 237.210 ms - -
GET /modules/ps_imageslider/js/homeslider.js 200 388.981 ms - -
GET /modules/ps_searchbar/ps_searchbar.js 200 186.480 ms - -
GET /modules/ps_shoppingcart/ps_shoppingcart.js 200 272.364 ms - -
GET /themes/classic/assets/js/custom.js 200 235.551 ms - -
GET /img/logo.png 200 219.762 ms - -
GET /2-large_default/hummingbird-printed-t-shirt.jpg 200 1297.510 ms - -
GET /2-home_default/hummingbird-printed-t-shirt.jpg 200 164.662 ms - -
GET /modules/blockreassurance/img/ic_verified_user_black_36dp_1x.png 200 217.993 ms - -
GET /modules/blockreassurance/img/ic_local_shipping_black_36dp_1x.png 200 160.820 ms - -
GET /modules/blockreassurance/img/ic_swap_horiz_black_36dp_1x.png 200 147.800 ms - -
GET /img/m/1.jpg 200 115.767 ms - -
GET /js/jquery/ui/themes/base/minified/jquery-ui.min.css 200 12482.121 ms - -
GET /themes/classic/assets/css/082a71677e756fb75817e8f262a07cb4.svg 200 133.134 ms - -
GET /themes/classic/assets/css/8b05d51ede908907d65695558974d86f.svg 200 135.111 ms - -
GET /js/jquery/ui/themes/base/minified/images/ui-bg_flat_75_ffffff_40x100.png 200 193.227 ms - -
GET /themes/classic/assets/css/b1db819132e64a3e01911a1413c33acf.svg 200 499.059 ms - -
GET /themes/classic/assets/css/570eb83859dc23dd0eec423a49e147fe.woff2 200 228.871 ms - -
GET /themes/classic/assets/css/19c1b868764c0e4d15a45d3f61250488.woff2 200 268.473 ms - -
GET /themes/classic/assets/css/199038f07312bfc6f0aabd3ed6a2b64d.woff2 200 230.125 ms - -
GET /v1/pages/ChRDaHJvbWUvODkuMC40Mzg5LjExNBIQCSH1MkjtAoVnEgUNu1dWahIXCbpTXag6Wh1tEgUNjsJ8QRIFDctunW4SEAl5ngwDYftELxIFDYOoWz0=?alt=proto 200 101.980 ms - -
GET /themes/classic/assets/css/ffddcb3736980b23405b31142a324b62.svg 200 13351.874 ms - -
GET /themes/classic/assets/css/99db8adec61e4fcf5586e1afa549b432.svg 200 13350.633 ms - -
GET /themes/classic/assets/css/e049aeb07a2ae1627933e8e58d3886d2.svg 200 13445.685 ms - -
POST /carrello 200 389.199 ms - -
POST /module/ps_shoppingcart/ajax 200 388.407 ms - -
GET /__cypress/runner/fonts/fa-regular-400.woff2 200 6.671 ms - 13600
GET /carrello?action=show 200 443.053 ms - -
GET /js/jquery/ui/themes/base/minified/jquery.ui.theme.min.css 200 133.347 ms - -
GET /js/jquery/ui/themes/base/minified/jquery-ui.min.css 200 149.125 ms - -
GET /themes/classic/assets/css/custom.css 200 145.832 ms - -
GET /themes/classic/assets/css/theme.css 200 165.264 ms - -
EDIT: thanks to the advice received from the chat https://gitter.im/cypress-io/cypress I concluded that the problem was related to Chrome. I uninstalled and reinstalled the browser and the problem was resolved.
When I use curl to post a SOAP message into message flow, it takes 9 seconds to respond. Debug won't stop at breakpoints and User Trace doesn't report anything. Meanwhile when I do the same request from Postman or SoapUI (the first message takes the same amount of time, later all messages take around 70 - 200ms) debugger and user trace work as intended. What is cause of this behavior?
IBM App Connect Enterprise 11.0.0.8
curl --trace-time output:
03:29:07.484000 * Trying <host>...
03:29:07.484000 * TCP_NODELAY set
03:29:07.531000 * Connected to <host_name> (<host>) port 7800 (#0)
03:29:07.531000 > POST /service HTTP/1.1
03:29:07.531000 > Host: <host_name>:7800
03:29:07.531000 > User-Agent: curl/7.55.1
03:29:07.531000 > Accept: */*
03:29:07.531000 > Content-Length: 508
03:29:07.531000 > Content-Type: application/x-www-form-urlencoded
03:29:07.531000 >
03:29:07.546000 * upload completely sent off: 508 out of 508 bytes
03:29:16.671000 < HTTP/1.1 200 OK
03:29:16.671000 < Cache-Control: no-cache
03:29:16.671000 < Pragma: no-cache
03:29:16.687000 < Expires: -1
03:29:16.687000 < X-AspNet-Version: 4.0.30319
03:29:16.687000 < X-Powered-By: ASP.NET
03:29:16.687000 < Date: Fri, 22 May 2020 01:29:14 GMT
03:29:16.687000 < Content-Type: text/xml; charset=utf-8
03:29:16.703000 < Server: IBM App Connect Enterprise
03:29:16.703000 < Content-Length: 243
EDIT: I'm still trying to resolve the problem - this time with help of Wireshark and user trace:
curl:
02:56:37.781000 > POST /service HTTP/1.1
after few milliseconds Wireshark detects POST message from "curl machine" - that means there are no problems with the connection
after around 10s delay SoapInput receives data. Why it takes so long?
2020-05-23 02:56:37.257076 6220 UserTrace BIP11304I: The Parser of type 'MQROOT' has been deleted from address '0x131f1312190'. This thread now has '0' cached parsers.
2020-05-23 02:56:40.591580 3684 UserTrace BIP11303I: A Parser of type 'MQROOT' has been created at address '0x131f13144a0'. This thread now has '36' cached parsers.
2020-05-23 02:56:45.143380 3684 UserTrace BIP11501I: Received data from input node 'SOAP Input'.
The input node 'SOAP Input' has received data and has propagated it to the message flow 'link'.
2020-05-23 02:56:45.143880 3684 UserTrace BIP6060I: Node 'link.SOAP Input' used parser type 'Properties' to process a portion of the incoming message of length '0' bytes beginning at offset '0'.
Fixed by restarting the machine. Any clue what exactly caused this problem?
Thread Name: Thread Group 1-1
Sample Start: 2019-02-08 15:51:46 IST
Load time: 1412
Connect Time: 525
Latency: 1412
Size in bytes: 1508
Sent bytes:603
Headers size in bytes: 843
Body size in bytes: 665
Sample Count: 1
Error Count: 1
Data type ("text"|"bin"|""): text
Response code: 401
Response message: Unauthorized
Response headers:
HTTP/1.1 401 Unauthorized
Public-Key-Pins-Report-Only: pin-sha256="9n0izTnSRF+W4W4JTq51avSXkWhQB8duS2bxVLfzXsY="; pin-sha256="5kJvNEMw0KjrCAu7eXY5HZdvyCS13BbA0VJG1RSP91w="; pin-sha256="njN4rRG+22dNXAi+yb8e3UMypgzPUPHlv4+foULwl1g="; max-age=86400; includeSubDomains; report-uri="https://a.forcesslreports.com/hpkp-report/00Dq0000000DFMbm";
Expect-CT: max-age=0; report-uri="https://a.forcesslreports.com/Expect-CT-report/00Dq0000000DFMbm";
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Content-Security-Policy: upgrade-insecure-requests
Referrer-Policy: origin-when-cross-origin
Cache-Control: no-cache,must-revalidate,max-age=0,no-store,private
Content-Type: text/html;charset=UTF-8
Expires: Thu, 01 Jan 1970 00:00:00 GMT
X-Powered-By: Salesforce.com ApexPages
P3P: CP="CUR OTR STA"
Transfer-Encoding: chunked
Looking into JMeter – Logging Into Salesforce for Automated Testing article you need to extract session id dynamic parameter from the very first request (Log In). The process is known as correlation
The Session ID parameter can be extracted using XPath Extractor, the relevant configuration would be something like:
The server rejects the request with a “401 Unauthorized” error because your app needs to be authorized. Usually Authentication request returns this value. So, you need to extract this token from the answer.
Add Cookie Manager to your Test Plan.
Add Regular Expressions Extractor to your auth request to Extract auth token to variable and send its value to the next request (where you get error) with
This guide also could be helpful how to test authentification with JMeter
I've encountered the same issue as in this question, using Spring Boot 1.3.0 and not having my controllers annotated with #RestController, just #Path and #Service. As the OP in that question says,
this is, to me, anything but sensible
I also can't understand why would they have it redirect to /error. And it is very likely that I'm missing something, because I can only give back 404s or 200s to the client.
My problem is that his solution doesn't seem to work with 1.3.0, so I have the following request flow: let's say my code throws a NullPointerException. It'll be handled by one of my ExceptionMappers
#Provider
public class GeneralExceptionMapper implements ExceptionMapper<Throwable> {
private static final Logger LOGGER = LoggerFactory.getLogger(GeneralExceptionMapper.class);
#Override
public Response toResponse(Throwable exception) {
LOGGER.error(exception.getLocalizedMessage());
return Response.status(Response.Status.INTERNAL_SERVER_ERROR).build();
}
}
And my code returns a 500, but instead of sending it back to the client, it tries to redirect it to /error. If I don't have another resource for that, it'll send back a 404.
2015-12-16 18:33:21.268 INFO 9708 --- [nio-8080-exec-1] o.glassfish.jersey.filter.LoggingFilter : 1 * Server has received a request on thread http-nio-8080-exec-1
1 > GET http://localhost:8080/nullpointerexception
1 > accept: */*
1 > host: localhost:8080
1 > user-agent: curl/7.45.0
2015-12-16 18:33:29.492 INFO 9708 --- [nio-8080-exec-1] o.glassfish.jersey.filter.LoggingFilter : 1 * Server responded with a response on thread http-nio-8080-exec-1
1 < 500
2015-12-16 18:33:29.540 INFO 9708 --- [nio-8080-exec-1] o.glassfish.jersey.filter.LoggingFilter : 2 * Server has received a request on thread http-nio-8080-exec-1
2 > GET http://localhost:8080/error
2 > accept: */*
2 > host: localhost:8080
2 > user-agent: curl/7.45.0
2015-12-16 18:33:37.249 INFO 9708 --- [nio-8080-exec-1] o.glassfish.jersey.filter.LoggingFilter : 2 * Server responded with a response on thread http-nio-8080-exec-1
2 < 404
And client's side (curl):
$ curl -v http://localhost:8080/nullpointerexception
* STATE: INIT => CONNECT handle 0x6000572d0; line 1090 (connection #-5000)
* Added connection 0. The cache now contains 1 members
* Trying ::1...
* STATE: CONNECT => WAITCONNECT handle 0x6000572d0; line 1143 (connection #0)
* Connected to localhost (::1) port 8080 (#0)
* STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x6000572d0; line 1240 (connection #0)
* STATE: SENDPROTOCONNECT => DO handle 0x6000572d0; line 1258 (connection #0)
> GET /nullpointerexception HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.45.0
> Accept: */*
>
* STATE: DO => DO_DONE handle 0x6000572d0; line 1337 (connection #0)
* STATE: DO_DONE => WAITPERFORM handle 0x6000572d0; line 1464 (connection #0)
* STATE: WAITPERFORM => PERFORM handle 0x6000572d0; line 1474 (connection #0)
* HTTP 1.1 or later with persistent connection, pipelining supported
< HTTP/1.1 404 Not Found
* Server Apache-Coyote/1.1 is not blacklisted
< Server: Apache-Coyote/1.1
< Content-Length: 0
< Date: Wed, 16 Dec 2015 17:33:37 GMT
<
* STATE: PERFORM => DONE handle 0x6000572d0; line 1632 (connection #0)
* Curl_done
* Connection #0 to host localhost left intact
So it's always a 404. Unless I do have such an /error resource, then what? what am I supposed to return? All I have at that point is a GET request to /error. And I don't want those extra requests consuming resources and polluting my logs.
What am I missing? And if nothing, what should I do with my exception handling?
You can set the Jersey property ServerProperties.RESPONSE_SET_STATUS_OVER_SEND_ERROR to true.
Whenever response status is 4xx or 5xx it is possible to choose between sendError or setStatus on container specific Response implementation. E.g. on servlet container Jersey can call HttpServletResponse.setStatus(...) or HttpServletResponse.sendError(...).
Calling sendError(...) method usually resets entity, response headers and provide error page for specified status code (e.g. servlet error-page configuration). However if you want to post-process response (e.g. by servlet filter) the only way to do it is calling setStatus(...) on container Response object.
If property value is true the method Response.setStatus(...) is used over default Response.sendError(...).
Type of the property value is boolean. The default value is false.
You can set Jersey property simply by calling property(key, value) in your ResourceConfig subclass constructor.