- 07 10月, 2011 1 次提交
-
-
由 Daniel P. Berrange 提交于
If we send back an unknown program error for async messages, we will confuse the client because they only expect replies for method calls. Just log & drop any invalid async messages * src/rpc/virnetserver.c: Don't send error for async messages
-
- 06 9月, 2011 1 次提交
-
-
由 Michal Privoznik 提交于
This patch annotates APIs with low or high priority. In low set MUST be all APIs which might eventually access monitor (and thus block indefinitely). Other APIs may be marked as high priority. However, some must be (e.g. domainDestroy). For high priority calls (HPC), there are some high priority workers (HPW) created in the pool. HPW can execute only HPC, although normal worker can process any call regardless priority. Therefore, only those APIs which are guaranteed to end in reasonable small amount of time can be marked as HPC. The size of this HPC pool is static, because HPC are expected to end quickly, therefore jobs assigned to this pool will be served quickly. It can be configured in libvirtd.conf via prio_workers variable. Default is set to 5. To mark API with low or high priority, append priority:{low|high} to it's comment in src/remote/remote_protocol.x. This is similar to autogen|skipgen. If not marked, the generator assumes low as default.
-
- 01 9月, 2011 1 次提交
-
-
由 Daniel P. Berrange 提交于
Commit 2c85644b attempted to fix a problem with tracking RPC messages from streams by doing - if (msg->header.type == VIR_NET_REPLY) { + if (msg->header.type == VIR_NET_REPLY || + (msg->header.type == VIR_NET_STREAM && + msg->header.status != VIR_NET_CONTINUE)) { client->nrequests--; In other words any stream packet, with status NET_OK or NET_ERROR would cause nrequests to be decremented. This is great if the packet from from a synchronous virStreamFinish or virStreamAbort API call, but wildly wrong if from a server initiated abort. The latter resulted in 'nrequests' being decremented below zero. This then causes all I/O for that client to be stopped. Instead of trying to infer whether we need to decrement the nrequests field, from the message type/status, introduce an explicit 'bool tracked' field to mark whether the virNetMessagePtr object is subject to tracking. Also add a virNetMessageClear function to allow a message contents to be cleared out, without adversely impacting the 'tracked' field as a naive memset() would do * src/rpc/virnetmessage.c, src/rpc/virnetmessage.h: Add a 'bool tracked' field and virNetMessageClear() API * daemon/remote.c, daemon/stream.c, src/rpc/virnetclientprogram.c, src/rpc/virnetclientstream.c, src/rpc/virnetserverclient.c, src/rpc/virnetserverprogram.c: Switch over to use virNetMessageClear() and pass in the 'bool tracked' value when creating messages.
-
- 30 8月, 2011 1 次提交
-
-
由 Guannan Ren 提交于
The bufferOffset has been initialized to zero in virNetMessageEncodePayloadRaw(), so, we use bufferLength to represent the length of message which is going to be sent to client side.
-
- 26 8月, 2011 1 次提交
-
-
由 Jiri Denemark 提交于
In case we add a new program in the future (we did that in the past and we are going to do it again soon) current daemon will behave badly with new client that wants to use the new program. Before the RPC rewrite we used to just send an error reply to any request with unknown program. With the RPC rewrite in 0.9.3 the daemon just closes the connection through which such request was sent. This patch fixes this regression.
-
- 17 8月, 2011 1 次提交
-
-
由 Daniel P. Berrange 提交于
If a stream gets a server initiated abort, the client may still send an abort request before it receives the server side abort. This causes the server to send back another abort for the stream. Since the protocol defines that abort is the last thing to be sent, the client gets confused by this second abort from the server. If the stream is already shutdown, just drop any client requested abort, rather than sending back another message. This fixes the regression from previous versions. Tested as follows In one virsh session virsh # start foo virsh # console foo In other virsh session virsh # destroy foo The first virsh session should be able to continue issuing commands without error. Prior to this patch it saw virsh # list error: Failed to list active domains error: An error occurred, but the cause is unknown virsh # list error: Failed to list active domains error: no call waiting for reply with prog 536903814 vers 1 serial 9 * src/rpc/virnetserverprogram.c: Drop abort requests for streams which no longer exist
-
- 01 7月, 2011 2 次提交
-
-
由 Daniel P. Berrange 提交于
We ignore any stream data packets which come in for streams which are not registered, since these packets are async and do not have a reply. If we get a stream control packet though we must send back an actual error, otherwise a (broken) client may hang forever making it hard to diagnose the client bug. * src/rpc/virnetserverprogram.c: Send back error for unexpected stream control messages
-
由 Daniel P. Berrange 提交于
If a message packet for a invalid stream is received it is just free'd. This is not good because it doesn't let the client RPC request counter decrement. If a stream is shutdown with pending packets the message also isn't released properly because of an incorrect header type * daemon/stream.c: Fix message header type * src/rpc/virnetserverprogram.c: Send dummy reply instead of free'ing ignored stream message
-
- 29 6月, 2011 1 次提交
-
-
由 Daniel P. Berrange 提交于
On stream completion it is neccessary to send back a message with an empty payload. The message header was not being filled out correctly, since we were not writing any payload. Add a method for encoding an empty payload which updates the message headers correctly. * src/rpc/virnetmessage.c, src/rpc/virnetmessage.h: Add a virNetMessageEncodePayloadEmpty method * src/rpc/virnetserverprogram.c: Write empty payload on stream completion
-
- 24 6月, 2011 1 次提交
-
-
由 Daniel P. Berrange 提交于
To facilitate creation of new daemons providing XDR RPC services, pull a lot of the libvirtd daemon code into a set of reusable objects. * virNetServer: A server contains one or more services which accept incoming clients. It maintains the list of active clients. It has a list of RPC programs which can be used by clients. When clients produce a complete RPC message, the server passes this onto the corresponding program for handling, and queues any response back with the client. * virNetServerClient: Encapsulates a single client connection. All I/O for the client is handled, reading & writing RPC messages. * virNetServerProgram: Handles processing and dispatch of RPC method calls for a single RPC (program,version). Multiple programs can be registered with the server. * virNetServerService: Encapsulates socket(s) listening for new connections. Each service listens on a single host/port, but may have multiple sockets if on a dual IPv4/6 host. Each new daemon now merely has to define the list of RPC procedures & their handlers. It does not need to deal with any network related functionality at all.
-