Hide Forgot
Created attachment 561648 [details] agent log Description of problem: JON 3.01 RC4, rhq-agent displays remote client exception, as shown below. I have no idea how to repro this or how it happened....hopefully the stack trace will yield some clues. Attaching agent log. UP: CPU 3 Sending the availability report to the server... Done. > org.rhq.enterprise.communications.command.client.RemoteIOException: A remote input stream with an ID of [4] and server endpoint of [socket://192.168.0.103:16163/?backlog=200&clientMaxPoolSize=304&enableTcpNoDelay=true&maxPoolSize=303&numAcceptThreads=1&rhq.communications.connector.rhqtype=agent&socketTimeout=60000] has not yet been assigned a sender object - cannot access the stream at org.rhq.enterprise.communications.command.client.RemoteInputStream.sendRequest(RemoteInputStream.java:266) at org.rhq.enterprise.communications.command.client.RemoteInputStream.close(RemoteInputStream.java:186) at org.rhq.core.pc.content.RetrieveContentBitsRunner.run(RetrieveContentBitsRunner.java:106) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:636) >
triage crouch, mfoley, loleary. dev to take 1st pass.
I really don't understand this code. Not sure why it is streaming the same file three times in a row. The exception is dumped because someone used e.printStackTrace rather than doing what we are supposed to be doing in the PC - that is, logging the exception. I'll change that real quick, but that won't solve the issue - all it would do is move the excepton to the log file as opposed to the console.
Created attachment 566104 [details] change to remove printStackTrace attached is a diff that removes the printStackTrace calls and replaces them with log calls.
it looks like this is a failure while trying to calculate the SHA256 (athough I'm not sure why its doing this with a remote file). Did this happen when you enabled content discovery on the resource? The only other thing I can think of is that something got nicked durign the latest refactoring of the content subsystem.
for the record, git commit c7a3cd80a75f9f5141a5a95553906eb4e361d134 added these additional two streaming calls to set the sha256 and md5. Not sure why it is being asked to stream three separate times - we could probably have streamed it once and done all three things we needed concurrently. But in any event, this was introduced close to 2 years ago, so somethng else must have nicked this and caused the streaming to now break (??)
git commit to master: 4daf76814cf38969fb1873938b78a43d3119aaf6
(In reply to comment #6) > git commit to master: 4daf76814cf38969fb1873938b78a43d3119aaf6 just to be clear, that commit ONLY removes the printStackTrace and logs the error instead. It doesn't attempt to fix anything.
Mazz, can you take another look at this and see if there is anything that jumps out as could be causing this.
as an aside and for the record - 4daf76814cf38969fb1873938b78a43d3119aaf6 is already in the release/jon3.1.x branch.
no way to know what happened. If the server was in the process of shutting down, this could be an expected condition. Since it was a one-off anomoly and can't be reproduced, closing wiht INSUFFICIENT_DATA. We can revisit if this happens again. But again, this is expected if the server was in the middle of shutting down while the agent is streaming.