Although I can command Sleep and Ping, other Core DID 0 commands do not work for me.
For example CID 40h Diagnostic Level 1 gets an MRSP of 35h.
Am I missing something?
Thanks
Error 35h means the state machine that processes the API commands timed out. Double-check the packet you sent, it probably starts fine but then lacks one or more bytes.
Dan
Related
Then more I research then more I think of it as a hypothetical question.
In my application I try to proceed all command frames correctly. But while building an application I've encountered one issue: NodeJS default http server closes socket after 120 seconds of inactivity. But that's fine, I can easily disable this timeout. But why not to make it actually controllable? So now I implemented an interface to adjust timeout delay. And now I have another issue: server just break the connection. Silently. That is not really good practice for WebSocket protocol, I should send close command frame first. But which status code should I provide?
Documentation describes a set of status codes, but in general they are (1) job is done, (2) server/client going down, (3) some error occurred, (4) protocol reserved:
https://www.rfc-editor.org/rfc/rfc6455#section-7.4.1
And it's unclear to me, which one to choose for idle timeout? It sounds like 1001 (going away) is closer one, but I see nothing in documentation, and found no one ever asked this question.
So which one should I choose? Any ideas?
I was puzzled too. Seems to be no answer that is easily googleable here in 2022.
In my case I've decided to go with 1002 Protocol Error, since not answering to ping is basically protocol violation
Update: We are using AIX environment.
We have been facing some random issues with our queues (cluster queues), like:
2189 Cluster resolution error (Most frequent one)
2270 MQRC_NO_DESTINATIONS_AVAILABLE
2053 Queue full error(Weirdest) : Post one message, it will be successfully posted, post some 3-4 messages, it will throw this error
for the rest of the messages.
All these issues get resolved once we do a cluster refresh. But, I want to know the root cause, why we get these errors. What goes wrong?
How cluster refresh resolve these errors?
Could be a socket issue. You can monitor sockets according to your OS - like on windows can do
netstat -a -b -o >/newfile.txt
You could also use TCP Viewer on windows (one exe from Microsoft/ sysinternals) http://technet.microsoft.com/en-us/sysinternals/bb897437.aspx actually all the sys internal toos should be in your prod box if windows.
For sockets in linux/Un* there are other tools, some just ls commands into the RAM, depending on the version. Maybe a google will help.
Also if using windows consider moving some stuff to linux, you will have some pain in the beggining but will get better.
If this did not help you should post yor environment on your quesiton and give any other details. And if you get a jprofiler into production and use it when the issue happens.
At the very least you can do a jstack and jmap
What is version/ name of OS and of java, websphere?
If it is a socket issue can try increasing sockets (registry) and then profiling your code to see who is making too many sockets, what needs to be throttled or re-written.
Remember every page, every db connection, external cache hit (if you use) or any other URL work/ remote connection is usually a socket.
I have a custom logging process that is reading from STDIN and sending the data out via TCP to a scribed logging server.
STDIN is in my case an access log that is attached to Apache httpd 2.2 like this in httpd.conf:
CustomLog "|/usr/local/bin/serelog" default
My serelog process sometimes goes into uninterruptable sleep under FreeBSD 9.0 and does not return from it. It works reliably under other operating systems though, including FreeBSD 8, Linux 2.6 and Linux 3.1.
How can I find out what could be the reason for the uninterruptable sleep?
The overall structure is like this:
httpd --[PIPE]--> serelog --[TCP-CONNECTION]--> scribed
Until now I did the following analysis:
Using ps: stat is "D" and wchan is "-". So there is apparently no syscall, which doesn't
make too much sense to me, as the process in uninterruptable sleep and should be in kernel land.
As the process is in state "D", the process does not react to kill -9 as expected.
Attaching truss to serelog externally from a shell: As long as truss is attached, serelog runs smoothly.
Shortly (Seconds) after detaching truss from serelog, serelog goes into "D" state.
When attaching truss to serelog AFTER it has entered "D" state, truss prints nothing
In "D" state, lsof shows that the incoming PIPE is full. This is exected, as in "D" state the process "sleeps"
and cannot read any longer. The outgoing TCP-CONNECTION is empty.
If I kill the "surrounding" Apache httpd server, the serelog process eventually terminates after (e.g.) 40 minutes.
Checking what others report in forums about the uninterruptable problem was not successful: In my setup there is no NFS.
And as it is a server there is also no user interaction with CD drives or pluggable hardware.
So I am now stuck with a process that is uninterruptable, is apparently not in a syscall,
and works reliably when traced. The only good thing is that I am able to reproduce the behavior in a few
seconds or minutes when I send a lot of HTTP requests via JMeter loadtest (5 threads in JMeter).
Any tips on debugging, kernel parameter tuning are appreciated.
Greetings
The issue has proven to be an actual FreeBSD Kernel bug, and is now fixed in the Kernel.
Link to the PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=166340
Proposed Patch: http://lists.freebsd.org/pipermail/freebsd-bugs/2012-May/048610.html
I have implemented a named pipe server that communicates with multiple named pipe clients. Generally it works, but in some instances, the Client would not be able to get a valid result from TransactNamedPipe. The GetLastError code returned is 998 (Invalid memory access). Which is weird, because the handle I used for TransactNamedPipe was valid from CreateFile.
I have implemented the client to retry when it detects an error (unless the pipe server is not alive). For other error codes (997, 230, 231) it works fine. But when it encounters error code 998, no matter how many times it retries, the named pipe server does not respond; in the named pipe server logs, it just says that the client disconnected, but there was no data exchange.
What could be the reason behind this? Is it because the client requests are coming from multiple threads and the named pipe server cannot cope with the (almost) simultaneous requests? I also implemented "locks" to prevent simultaneous requests from the client to the named pipe server, but the error still occurs.
I have searched the web for named pipe communication with this similar problem, but so far, no results.
Thanks in advance
This is weird, indeed. I updated to the latest Windows SDK, pointed my project to it, and, without any changes to the code, it now works perfectly. It must have been a bug that's already been fixed. I was using the libs that came with VC++ 9.0.
Yesterday, I began encountering '999' errors on Yahoo-Pipes. It looks like they throttle requests from a given IP address.
Does anyone know the Yahoo-Pipes' requests per minute limit?
200 runs (of a given Pipe) in 10 minutes.
200 runs (of any Pipe) from an IP in 10 minutes.
If you exceed the 200 runs in a 10 minute block, your Pipe will be 999'ed for a hour.
It looks like Yahoo hasn't published any documentation on their limits yet.
The troubleshooting guide is vague:
Why am I getting "999 Errors" from
pipes.yahoo.com? A 999 error implies
you are over utilizing our service.
Please try throttling back the number
of requests made to the Pipes site and
within a few hours you should no
longer be blocked.
The Pipes team puts these measures in
place to protect the overall
experience for its users. If you think
the amount of traffic you are sending
to the Pipes site should be allowed
and would like to make more requests
than normal, please contact our
Business Development team at: pipes-bd
[at] yahoo-inc.com.
However, I did find a Pipes developer forum post posted on July 31 which indicates forthcoming documentation:
Hi,
You'll have to hang on for an hour or
so before your IP gets unblocked.
We're going to create a doc on the
rate limits, i'll post back here when
we have more info about it.
Thanks -Paul Pipes Team