Server Fails To Start With Unmodified 6.0 Install

[David Swift]

Just making sure someone saw this - unless I mis-searched I didn't
see anything about it.

-bash-3.1$ bin/voldemort-server.sh config/single_node_cluster/
metadata init().
admin-port not defined for node:0 using default value:6667 as
(socket_port + 1):
Exception in thread "main" voldemort.xml.MappingException:
org.jdom.JDOMException: Exception in startElement: cvc-complex-type.
2.4.a: Invalid content was found starting with element 'value-
transformation'. One of '{routing, routing-strategy, preferred-reads,
required-reads, preferred-writes, required-writes, value-serializer,
view-class}' is expected.
at voldemort.xml.StoreDefinitionsMapper.readStoreList
(StoreDefinitionsMapper.java:131)
at voldemort.store.metadata.MetadataStore.convertStringToObject
(MetadataStore.java:414)
at voldemort.store.metadata.MetadataStore.initCache
(MetadataStore.java:331)
at voldemort.store.metadata.MetadataStore.init
(MetadataStore.java:317)
at voldemort.store.metadata.MetadataStore.<init>
(MetadataStore.java:113)
at voldemort.store.metadata.MetadataStore.readFromDirectory
(MetadataStore.java:125)
at voldemort.server.VoldemortServer.<init>
(VoldemortServer.java:78)
at voldemort.server.VoldemortServer.main(VoldemortServer.java:
223)
Caused by: org.jdom.JDOMException: Exception in startElement: cvc-
complex-type.2.4.a: Invalid content was found starting with element
'value-transformation'. One of '{routing, routing-strategy, preferred-
reads, required-reads, preferred-writes, required-writes, value-
serializer, view-class}' is expected.
at org.jdom.transform.JDOMSource$DocumentReader.parse
(JDOMSource.java:525)
at
org.apache.xerces.jaxp.validation.ValidatorHandlerImpl.validate
(Unknown Source)
at org.apache.xerces.jaxp.validation.ValidatorImpl.validate
(Unknown Source)
at javax.xml.validation.Validator.validate(Validator.java:127)
at voldemort.xml.StoreDefinitionsMapper.readStoreList
(StoreDefinitionsMapper.java:117)
... 7 more
Caused by: org.jdom.JDOMException: Exception in startElement: cvc-
complex-type.2.4.a: Invalid content was found starting with element
'value-transformation'. One of '{routing, routing-strategy, preferred-
reads, required-reads, preferred-writes, required-writes, value-
serializer, view-class}' is expected.
at org.jdom.output.SAXOutputter.startElement(SAXOutputter.java:
1030)
at org.jdom.output.SAXOutputter.element(SAXOutputter.java:894)
at org.jdom.output.SAXOutputter.elementContent
(SAXOutputter.java:1097)
at org.jdom.output.SAXOutputter.elementContent
(SAXOutputter.java:1069)
at org.jdom.output.SAXOutputter.element(SAXOutputter.java:897)
at org.jdom.output.SAXOutputter.elementContent
(SAXOutputter.java:1097)
at org.jdom.output.SAXOutputter.elementContent
(SAXOutputter.java:1069)
at org.jdom.output.SAXOutputter.element(SAXOutputter.java:897)
at org.jdom.output.SAXOutputter.output(SAXOutputter.java:621)
at org.jdom.transform.JDOMSource$DocumentReader.parse
(JDOMSource.java:518)
... 11 more
Caused by: org.xml.sax.SAXParseException: cvc-complex-type.2.4.a:
Invalid content was found starting with element 'value-
transformation'. One of '{routing, routing-strategy, preferred-reads,
required-reads, preferred-writes, required-writes, value-serializer,
view-class}' is expected.
at
org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException
(Unknown Source)
at org.apache.xerces.util.ErrorHandlerWrapper.error(Unknown
Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown
Source)
at org.apache.xerces.impl.xs.XMLSchemaValidator
$XSIErrorReporter.reportError(Unknown Source)
at
org.apache.xerces.impl.xs.XMLSchemaValidator.reportSchemaError(Unknown
Source)
at
org.apache.xerces.impl.xs.XMLSchemaValidator.handleStartElement
(Unknown Source)
at org.apache.xerces.impl.xs.XMLSchemaValidator.startElement
(Unknown Source)
at
org.apache.xerces.jaxp.validation.ValidatorHandlerImpl.startElement
(Unknown Source)
at org.jdom.output.SAXOutputter.startElement(SAXOutputter.java:
1027)
... 20 more

[Geir Magnusson Jr.]

what version of V? What is a "unmodified 6.0 install"?

> --
>
> You received this message because you are subscribed to the Google Groups "project-voldemort" group.
> To post to this group, send email to project-...@googlegroups.com.
> To unsubscribe from this group, send email to project-voldem...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/project-voldemort?hl=en.
>
>

[Alex Feinberg]

That is my fault, I used an older version of the release-060 branch
when making the tarball. Yet, I sanity-checked (following the
quickstart scenario) with the latest release-060 branch, rather than
the tarball. You can see the *correct* stores.xm here:

http://github.com/voldemort/voldemort/blob/release-060/config/single_node_cluster/config/stores.xml

Use this stores.xml instead (just tested and checked that everything
works fine with it). I'll put up new tarballs (likely bumping the
version to 0.60.1 to avoid any issues with checksums of the release
files) shortly.

Thanks,
- Alex

[Alex Feinberg]

Just pushed the new archives (as 0.60.1):

http://cloud.github.com/downloads/voldemort/voldemort/voldemort-0.60.1.tar.gz
http://cloud.github.com/downloads/voldemort/voldemort/voldemort-0.60.1.zip

Thanks,
- Alex

[Geir Magnusson Jr.]

One of the things that we do at the ASF that's very effective is to have a release vote on the candidate binary. This sounds bureaucratic, but it does three things :

1) It ensure that we're releasing what we think we're releasing

2) It provides a mechanism to get other project members and users to test the thing before it goes out. We require 3 +1 votes and no -1 votes, and this means that it's rather loose and flexible - whoever can lend a hand lends a hand...

3) And while this wouldn't apply to us : at the ASF, we have a notion that the "PMC" (Project Management Committee) votes are a binding action of the ASF (in the same way that work done by an employee is considered an act of the employer, not the employee), so in the event of a problem (like source from a 3rd party that wasn't open sourced is included), any legal action falls on the shoulders of the ASF, not the committer that did the release. That's the "legal umbrella" that we sometimes talk about. Now, we don't have that structure here, but I thought it worth noting for anyone interested.

Anyway, something to consider maybe?

geir

[bhupesh bansal]

hmm make sense, but I think we should start with a low overhead/less bureaucratic process

This is what I have in my mind  

1) 12th of month : Cut a release branch 

2) active folks check out the branch and do local testing, release notes check , all features are part of it etc 

we can implement a voting system if needed here, mostly we should go with full quorum. 

3) 15th cut the official release. 

I think the extra days and extra eyes on the release will help .. my 2 cents ..  or 3 :) 

Best

Bhupesh 

[Geir Magnusson Jr.]

It's not that bad, actually. I like what you have (I was going to discuss the pre-release-artifact-build process), so that's good.

But a simple additional step like

1) Xth : cut a release branch and announce to list
2) X+Nth : release manager produces the candidate artifact, asking for a 3 day release vote
3) people download and play with it...
4) X+N+3 : release if all is well

The process you outlined seems like it wouldn't have caught what happened here. The additional step would have as we all would have sanity checked the final tarball.

geir

[Alex Feinberg]

Perhaps it makes sense to do "adversarial" testing of binaries, APIs
and documentation.

Release manager (me) creates a tarball, gives it to somebody else.
Someone else follows instructions included in the tarball, verifies
that they can be followed. Release manager pushes the tarballs.

We've already done this internally for documentation (Jay reviewed the
documentation and API for AdminClient, which was written by Bhupesh
and I).

Thanks,
- Alex

[Geir Magnusson Jr.]

On Dec 18, 2009, at 4:11 PM, Alex Feinberg wrote:

> Perhaps it makes sense to do "adversarial" testing of binaries, APIs
> and documentation.
>
> Release manager (me) creates a tarball, gives it to somebody else.
> Someone else follows instructions included in the tarball, verifies
> that they can be followed. Release manager pushes the tarballs.

Yep. Exactly. But what I'm proposing allows us all to be involved - whoever is around and has time.

It also lets more people participate in the process with now real downside or slowdown.

geir

[Alex Feinberg]

I am all for this process. It would have certainly caught the issue.

I certainly should have done "adversarial" testing myself (I did
attempt following the quick-start, but I didn't start with a tarball
-- rather, I started with source code from the latest release branch).

Thanks,
- Alex

[Jay Kreps]

Yeah me too, I don't think this will be too much overhead. We tend to
miss the little things like the example configs, and this would be
exact the kind of thing this process would catch.

Cheers,

-Jay