2013-04-30 06:49:56 +01:00
|
|
|
|
|
|
|
# Copyright 2013 Red Hat, Inc.
|
|
|
|
#
|
|
|
|
# Licensed under the Apache License, Version 2.0 (the "License"); you may
|
|
|
|
# not use this file except in compliance with the License. You may obtain
|
|
|
|
# a copy of the License at
|
|
|
|
#
|
|
|
|
# http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
#
|
|
|
|
# Unless required by applicable law or agreed to in writing, software
|
|
|
|
# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
|
|
|
|
# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
|
|
|
|
# License for the specific language governing permissions and limitations
|
|
|
|
# under the License.
|
|
|
|
|
|
|
|
import abc
|
|
|
|
|
2013-06-15 07:43:39 +01:00
|
|
|
from oslo.messaging import exceptions
|
2013-06-14 14:45:40 +01:00
|
|
|
|
|
|
|
|
|
|
|
class TransportDriverError(exceptions.MessagingException):
|
|
|
|
"""Base class for transport driver specific exceptions."""
|
|
|
|
|
2013-04-30 06:49:56 +01:00
|
|
|
|
Add IncomingMessage abstraction
When an executor polls for a message, the driver needs to return the
request context and the message.
Later, if the executor wishes to send a reply, it needs to pass back
a handle which identifies the message so that the transport can deliver
the reply.
In the current interface, we're just passing back the context and
message to the transport so this presumes that the transport would
attach whatever it needs to one of these objects.
In the AMQP drivers in openstack.common.rpc, we set attributes like
reply_q and msg_id on the returned context. However, it would be much
better if we never touched the user-supplied context and, instead, had
some other way to pass this info to the executor and then have it passed
back to the transport.
To achieve that, add an IncomingMessage abstract class which wraps the
context and message and has a reply() method. That way, transports can
subclass this class, add whatver attributes they want and implement a
reply method.
To repeat what this means ... we can allow users of the API to use
read-only mapping objects as a context, rather than requiring it to be
an object we can set arbitrary attributes on.
2013-05-13 11:33:41 +01:00
|
|
|
class IncomingMessage(object):
|
2013-04-30 06:49:56 +01:00
|
|
|
|
|
|
|
__metaclass__ = abc.ABCMeta
|
|
|
|
|
Add IncomingMessage abstraction
When an executor polls for a message, the driver needs to return the
request context and the message.
Later, if the executor wishes to send a reply, it needs to pass back
a handle which identifies the message so that the transport can deliver
the reply.
In the current interface, we're just passing back the context and
message to the transport so this presumes that the transport would
attach whatever it needs to one of these objects.
In the AMQP drivers in openstack.common.rpc, we set attributes like
reply_q and msg_id on the returned context. However, it would be much
better if we never touched the user-supplied context and, instead, had
some other way to pass this info to the executor and then have it passed
back to the transport.
To achieve that, add an IncomingMessage abstract class which wraps the
context and message and has a reply() method. That way, transports can
subclass this class, add whatver attributes they want and implement a
reply method.
To repeat what this means ... we can allow users of the API to use
read-only mapping objects as a context, rather than requiring it to be
an object we can set arbitrary attributes on.
2013-05-13 11:33:41 +01:00
|
|
|
def __init__(self, listener, ctxt, message):
|
|
|
|
self.conf = listener.conf
|
|
|
|
self.listener = listener
|
|
|
|
self.ctxt = ctxt
|
|
|
|
self.message = message
|
2013-04-30 06:49:56 +01:00
|
|
|
|
|
|
|
@abc.abstractmethod
|
Add IncomingMessage abstraction
When an executor polls for a message, the driver needs to return the
request context and the message.
Later, if the executor wishes to send a reply, it needs to pass back
a handle which identifies the message so that the transport can deliver
the reply.
In the current interface, we're just passing back the context and
message to the transport so this presumes that the transport would
attach whatever it needs to one of these objects.
In the AMQP drivers in openstack.common.rpc, we set attributes like
reply_q and msg_id on the returned context. However, it would be much
better if we never touched the user-supplied context and, instead, had
some other way to pass this info to the executor and then have it passed
back to the transport.
To achieve that, add an IncomingMessage abstract class which wraps the
context and message and has a reply() method. That way, transports can
subclass this class, add whatver attributes they want and implement a
reply method.
To repeat what this means ... we can allow users of the API to use
read-only mapping objects as a context, rather than requiring it to be
an object we can set arbitrary attributes on.
2013-05-13 11:33:41 +01:00
|
|
|
def reply(self, reply=None, failure=None):
|
2013-04-30 06:49:56 +01:00
|
|
|
pass
|
|
|
|
|
|
|
|
@abc.abstractmethod
|
Add IncomingMessage abstraction
When an executor polls for a message, the driver needs to return the
request context and the message.
Later, if the executor wishes to send a reply, it needs to pass back
a handle which identifies the message so that the transport can deliver
the reply.
In the current interface, we're just passing back the context and
message to the transport so this presumes that the transport would
attach whatever it needs to one of these objects.
In the AMQP drivers in openstack.common.rpc, we set attributes like
reply_q and msg_id on the returned context. However, it would be much
better if we never touched the user-supplied context and, instead, had
some other way to pass this info to the executor and then have it passed
back to the transport.
To achieve that, add an IncomingMessage abstract class which wraps the
context and message and has a reply() method. That way, transports can
subclass this class, add whatver attributes they want and implement a
reply method.
To repeat what this means ... we can allow users of the API to use
read-only mapping objects as a context, rather than requiring it to be
an object we can set arbitrary attributes on.
2013-05-13 11:33:41 +01:00
|
|
|
def done(self):
|
2013-04-30 06:49:56 +01:00
|
|
|
# so the transport can ack the message
|
|
|
|
pass
|
|
|
|
|
Add IncomingMessage abstraction
When an executor polls for a message, the driver needs to return the
request context and the message.
Later, if the executor wishes to send a reply, it needs to pass back
a handle which identifies the message so that the transport can deliver
the reply.
In the current interface, we're just passing back the context and
message to the transport so this presumes that the transport would
attach whatever it needs to one of these objects.
In the AMQP drivers in openstack.common.rpc, we set attributes like
reply_q and msg_id on the returned context. However, it would be much
better if we never touched the user-supplied context and, instead, had
some other way to pass this info to the executor and then have it passed
back to the transport.
To achieve that, add an IncomingMessage abstract class which wraps the
context and message and has a reply() method. That way, transports can
subclass this class, add whatver attributes they want and implement a
reply method.
To repeat what this means ... we can allow users of the API to use
read-only mapping objects as a context, rather than requiring it to be
an object we can set arbitrary attributes on.
2013-05-13 11:33:41 +01:00
|
|
|
|
|
|
|
class Listener(object):
|
|
|
|
|
|
|
|
__metaclass__ = abc.ABCMeta
|
|
|
|
|
|
|
|
def __init__(self, driver, target):
|
|
|
|
self.conf = driver.conf
|
|
|
|
self.driver = driver
|
|
|
|
self.target = target
|
|
|
|
|
2013-05-11 13:19:59 +01:00
|
|
|
@abc.abstractmethod
|
Add IncomingMessage abstraction
When an executor polls for a message, the driver needs to return the
request context and the message.
Later, if the executor wishes to send a reply, it needs to pass back
a handle which identifies the message so that the transport can deliver
the reply.
In the current interface, we're just passing back the context and
message to the transport so this presumes that the transport would
attach whatever it needs to one of these objects.
In the AMQP drivers in openstack.common.rpc, we set attributes like
reply_q and msg_id on the returned context. However, it would be much
better if we never touched the user-supplied context and, instead, had
some other way to pass this info to the executor and then have it passed
back to the transport.
To achieve that, add an IncomingMessage abstract class which wraps the
context and message and has a reply() method. That way, transports can
subclass this class, add whatver attributes they want and implement a
reply method.
To repeat what this means ... we can allow users of the API to use
read-only mapping objects as a context, rather than requiring it to be
an object we can set arbitrary attributes on.
2013-05-13 11:33:41 +01:00
|
|
|
def poll(self):
|
|
|
|
# returns an IncomingMessage
|
2013-05-11 13:19:59 +01:00
|
|
|
pass
|
|
|
|
|
2013-04-30 06:49:56 +01:00
|
|
|
|
|
|
|
class BaseDriver(object):
|
|
|
|
|
|
|
|
__metaclass__ = abc.ABCMeta
|
|
|
|
|
|
|
|
def __init__(self, conf, url=None, default_exchange=None):
|
|
|
|
self.conf = conf
|
|
|
|
self._url = url
|
2013-05-11 16:22:37 +01:00
|
|
|
self._default_exchange = default_exchange
|
2013-04-30 06:49:56 +01:00
|
|
|
|
|
|
|
@abc.abstractmethod
|
2013-05-17 18:48:55 +01:00
|
|
|
def send(self, target, ctxt, message,
|
|
|
|
wait_for_reply=None, timeout=None, envelope=False):
|
2013-04-30 06:49:56 +01:00
|
|
|
"""Send a message to the given target."""
|
|
|
|
return None
|
|
|
|
|
|
|
|
@abc.abstractmethod
|
2013-05-06 15:29:37 -04:00
|
|
|
def listen(self, target):
|
2013-04-30 06:49:56 +01:00
|
|
|
"""Construct a Listener for the given target."""
|
|
|
|
return None
|