2012/6/26 Gordon Sim <[email protected]>: > On 06/26/2012 02:46 PM, Zhihua Che wrote: >> >> Hi, >> I'm employing qpid in my current project and need some tips for >> common programming practice. > > > I'm assuming you are using the c++ client(?) here. >
I'm using c++ broker and c++/python client. >> 1, Are Sender/Receiver/Session/Connection thread-safe? >> ie, Is it ok for multiple threads to send messages through the >> same sender, or to create senders/receivers through the same session. > > > Yes, but accessing a session concurrently from more than one thread makes it > hard to reason about sequence in any way. I would myself tend towards using > a single thread per session unless there was a compelling reason to increase > that. > > >> 2, When do I need to create a separate session? >> I know it's feasible to create more than one session in one >> application/process, but, I wonder when it's reasonable to create two >> session, instead of only one. > > > I think of a separate session as reflecting a logically distinct > conversation. If several messages are logically related to a particular > action for example, then they are probably ideally sent on the same session. > If you have several such multi-message interactions that are each > independent of the other, then using separate sessions would likely be a > good idea. Does this help at all? > > >> 3, How do I handle the connection lost or sending/receiving failure? >> In my application, sending/receiving fails occasionally with an >> exception throw. What can I do to fix it and take another try >> initiatively at runtime if I refuse to exit the process? >> Is it reasonable to open the connection again and create new >> senders and receivers to take a new try? > > > Yes, you can do that. Unfortunately at present you can't retrieve the > indoubt messages from a sender on a failed connection (if reconnect is > enabled those would be resent for you automatically on reconnecting). > What do you mean by 'you can't retrieve the indoubt messages from a sender on a failed connection'? Do you mean that the message which causes the Sender.send() failure would not be fetched by Receiver.fetch() and 'lost' forever? By the way, I wonder why the Receiver.fetch() could throw NoMessageAvailable because I thought the function would just block until message is available or the timeout is due. I mean it doesn't make sense to throw an exception if there is no available message right now. > >> I know there is reconnect option for the Connection. But It cannot >> keep connection alive forever, right? > > > You can configure how the reconnect works (e.g. how many times it will > retry, how long it will wait for etc) through the connection options. > > >> Furthermore, I find qpid client api doesn't offer a connection >> pool mechanism, Does that mean I need to implement one by myself if I >> want or the connection pool is not recommended? > > > You would need to implement one yourself I'm afraid. > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
