Should we move this discussion to the jira?

-Steve

> -----Original Message-----
> From: Carl Trieloff [mailto:[email protected]] 
> Sent: Friday, November 20, 2009 10:45 AM
> To: Alan Conway
> Cc: [email protected]; [email protected]
> Subject: Re: [jira] Created: (QPID-2211) API change to 
> qpid::broker::MessageStore not portable
> 
> 
> Alan Conway wrote:
> > On 11/19/2009 08:17 PM, Carl Trieloff wrote:
> >> Steve Huston (JIRA) wrote:
> >>> API change to qpid::broker::MessageStore not portable
> >>> -----------------------------------------------------
> >>>
> >>> Key: QPID-2211
> >>> URL: https://issues.apache.org/jira/browse/QPID-2211
> >>> Project: Qpid
> >>> Issue Type: Bug
> >>> Components: C++ Broker
> >>> Affects Versions: 0.6
> >>> Reporter: Steve Huston
> >>> Assignee: Alan Conway
> >>>
> >>>
> >>> The following pure virtual function was added to
> >>> qpid::broker::MessageStore:
> >>>
> >>> virtual std::string getStoreDir() const = 0;
> >>>
> >>> Two problems as a result:
> >>>
> >>> 1. No corresponding change was made to the
> >>> qpid/store/MessageStorePlugin.cpp, which is the portable 
> persistence
> >>> plug-in layer (or, that's it's purpose, anyway). This broker the
> >>> Windows build.
> >>>
> >>> 2. Not all message stores have a store dir - this is (at 
> this point,
> >>> anyway) an option only for the Red Hat store.
> >>>
> >>> Could this addition be explained please? Also, if it 
> needs to stay as
> >>> is, please fix the Windows build.
> >>>
> >>>
> >>
> >>
> >> Coping Alan, I expect he just wants to write a marker for 
> cluster auto
> >> restart for crash recovery... I expect he could just as 
> well use data
> >> dir and create a generic file there maybe.
> >>
> >
> > The cluster needs to annotate the store with some 
> additional info: a 
> > cluster-wide store identifier and also a marker to identify stores

> > that were shut down by the same management event.
> >
> > I can move this to data_dir, although logically it belongs with
the 
> > store so it would be nice to keep it together if the store is
moved.
> >
> > For now I will revert the change and use data_dir, but it would be

> > good to come up with a portable way to store 
> plugin-specific state in 
> > a store. Is that feasible at all with the kinds of store 
> you envision? 
> > The cluster's requirements so far are modest (2 UUIDs) but 
> in general 
> > it seems like plugin's may have persistent state that should be 
> > associated with the store.
> >
> 
> Why could the store not provide a dir for such things even if 
> it backed 
> to a DB for example?
> 
> Carl.
> 
> 
> 
>
---------------------------------------------------------------------
> Apache Qpid - AMQP Messaging Implementation
> Project:      http://qpid.apache.org
> Use/Interact: mailto:[email protected]
> 
> 


---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:[email protected]

Reply via email to