Google Docs.. The Good News and The Bad News..

We were working with a Google presentation, and all of a sudden google docs crashed hiding the document, with the message,

The bad news is that Google Docs has just encountered an error. The good news is that you've helped us find a bug, which we are now looking into. We apologize for any inconvenience this has caused you. In the meantime, if you'd like updates on this and other issues, try visiting our Google Docs Help Group: http://www.google.com/support/forum/p/Google+Docs Sorry, and thanks for your help! - The Google Docs Team Can't prepare without a quorum of living replicas Trace: [ 0.000] LogSession {[logKey="dchc522j_15cw6c8ng5", logSpace=logspace:global/writely.production-data.data.logspace]} +------------------------------------------------------- | Started 0.000 after root (absolute time 1276770846.526 seconds) | [ 0.000] CoordinatedLog.init key="dchc522j_15cw6c8ng5" replica=E params=op=WRITE, piggybackRead=true, dl=null, localReadPatienceMs=750, allowFailover=true | [ 0.000] Transitioning from=Init to=AskCoordinator | [ 0.000] SEND [#0] E.isUpToDate() | [ 0.000] Transitioning from=AskCoordinator to=FindPos | [ 0.000] SEND [#1] E.queryLog(queryMode=DEFAULT, piggybackReadRequest=[#8:=]com.google.rewritely.storage.ReplicatedReader$PiggybackReadRequest@f8125b, logPos=null, dl=11.000) | [ 0.000] Predicted local read (5.196 mdev=1.122) as fast as quorum (90.646 mdev=32.633); waiting 750ms before issuing majority read. | [ 0.001] CB [#0] E.isUpToDate => (up-to-date: true, pos: 216) | [ 0.004] CB [#1] E.queryLog => (appliedPos: 249, appliedTime: 1276769410763000, nextLeader: E, lastMustRoll: 249, LWM: {D=(low=228,high=228), E=(low=249,high=249), A=(low=248,high=249), B=(low=228,high=228), C=(low=248,high=249)}, logEntry: null, piggyRead: com.google.rewritely.storage.ReplicatedReader$PiggybackReadResponse@7d3de4) | [ 0.004] Transitioning from=FindPos to=FindFirstReplica | [ 0.004] Transitioning from=FindFirstReplica to=Querying +------------------------------------------------------- | *** trace being toString'd *** | Started 0.004 after root (absolute time 1276770846.530 seconds) | [ 0.000] CoordinatedLog.write key="dchc522j_15cw6c8ng5" replica=E logspace=logspace:global/writely.production-data.data.logspace | [ 0.000] Constructed proposer Proposer {[localReplica=E, id=8130, logPos=250]} timestamp=1276770846530000 syncApply=[E] syncLearn=[] | [ 0.000] Transitioning from=Init to=AcceptLdr | [ 0.000] SEND [#0] E.accept(logPos=250, proposal=[#18:=](0, 0): (nextLdr E, hash f811b883b75d1f21, @1276770846530000, logPos 250, 126 bytes), mustRollForward=false, logState=[#19:=](PS: Unready, Acpt=[], Inv=[], Mrf=[], View=replicas={A=dv, B=dv, C=dv, D=dv, E=dv}, gen=0, time=0, LWM: {D=(low=228,high=228), E=(low=249,high=249), A=(low=248,high=249), B=(low=228,high=228), C=(low=248,high=249)}), dl=1.001) | [ 0.008] CB [#0] E.accept => EXCEPTION / com.google.bigtable.BigtableOverQuotaException: OVER_QUOTA: owner class (@production) exceeds its quota, while the owner (chubby!mdb/writely) is using 36631910110495.500 of its own 108851651149824.000 disk:.|OVER_QUOTA|/bigtable/srv-gd/writely.production-data | [ 0.008] Transitioning from=AcceptLdr to=Prepare | [ 0.009] SEND [#1] A.prepare(logPos=250, proposalNum=(298744293, 7902741955929074510), mustRollForward=false, logState=[#19], dl=6.991) | [ 0.009] SEND [#2] B.prepare(logPos=250, proposalNum=(298744293, 7902741955929074510), mustRollForward=false, logState=[#19], dl=6.991) | [ 0.009] SEND [#3] C.prepare(logPos=250, proposalNum=(298744293, 7902741955929074510), mustRollForward=false, logState=[#19], dl=6.991) | [ 0.009] SEND [#4] D.prepare(logPos=250, proposalNum=(298744293, 7902741955929074510), mustRollForward=false, logState=[#19], dl=6.991) | [ 0.009] SEND [#5] E.prepare(logPos=250, proposalNum=(298744293, 7902741955929074510), mustRollForward=false, logState=[#19], dl=6.991) | [ 0.039] CB [#4] D.prepare => EXCEPTION / com.google.storage.megastore.replication.StorageException: Remote RPC failed {[status=EXCEPTION, replicationStatus=MISC, stubbyErr=/AcceptorService.Prepare to 10.230.37.70:25685 [APPLICATION_ERROR(4)] << EXCEPTION / com.google.bigtable.BigtableOverQuotaException: OVER_QUOTA: owner class (@production) exceeds its quota, while the owner (chubby!mdb/writely) is using 54750724655241.000 of its own 134580222820352.000 disk:.|OVER_QUOTA|/bigtable/srv-vb/writely.production-data | at com.google.storage.megastore.replication.StorageException.wrap(StorageException.java:65) | at com.google.storage.megastore.replication.StorageException.wrap(StorageException.java:46) | at com.google.storage.megastore.replication.monitor.RootCallback.failure(RootCallback.java:89) | at com.google.storage.megastore.replication.health.HealthTracker$HealthTrackingCallback.failure(HealthTracker.java:288) | at com.google.storage.megastore.replication.monitor.ApiTrace$ApiTraceCbk.failure(ApiTrace.java:254) | at com.google.storage.megastore.replication.acceptor.AcceptorImpl$15.failure(AcceptorImpl.java:1909) | at com.google.storage.megastore.replication.net.BtCallbackWrapper$2.run(BtCallbackWrapper.java:113) | at com.google.storage.megastore.replication.net.RequestContainer$ExceptionForwardingRunnable.run(RequestContainer.java:357) | at com.google.storage.megast ... [exception text truncated by msrepl; total 6685 characters] | [ 0.058] CB [#3] C.prepare => EXCEPTION / com.google.storage.megastore.replication.StorageException: Remote RPC failed {[status=EXCEPTION, replicationStatus=MISC, stubbyErr=/AcceptorService.Prepare to 10.13.114.19:25782 [APPLICATION_ERROR(4)] << EXCEPTION / com.google.bigtable.BigtableOverQuotaException: OVER_QUOTA: owner class (@production) exceeds its quota, while the owner (chubby!mdb/writely) is using 55970616351910.500 of its own 115976485994496.000 disk:.|OVER_QUOTA|/bigtable/srv-ia/writely.production-data | at com.google.storage.megastore.replication.StorageException.wrap(StorageException.java:65) | at com.google.storage.megastore.replication.StorageException.wrap(StorageException.java:46) | at com.google.storage.megastore.replication.monitor.RootCallback.failure(RootCallback.java:89) | at com.google.storage.megastore.replication.health.HealthTracker$HealthTrackingCallback.failure(HealthTracker.java:288) | at com.google.storage.megastore.replication.monitor.ApiTrace$ApiTraceCbk.failure(ApiTrace.java:254) | at com.google.storage.megastore.replication.acceptor.AcceptorImpl$15.failure(AcceptorImpl.java:1909) | at com.google.storage.megastore.replication.net.BtCallbackWrapper$2.run(BtCallbackWrapper.java:113) | at com.google.storage.megastore.replication.net.RequestContainer$ExceptionForwardingRunnable.run(RequestContainer.java:357) | at com.google.storage.megast ... [exception text truncated by msrepl; total 6685 characters] | [ 0.059] CB [#2] B.prepare => EXCEPTION / com.google.storage.megastore.replication.StorageException: Remote RPC failed {[status=EXCEPTION, replicationStatus=MISC, stubbyErr=/AcceptorService.Prepare to 10.224.115.11:25699 [APPLICATION_ERROR(4)] << EXCEPTION / com.google.bigtable.BigtableOverQuotaException: OVER_QUOTA: owner class (@production) exceeds its quota, while the owner (chubby!mdb/writely) is using 54920498505744.000 of its own 124683614683136.000 disk:.|OVER_QUOTA|/bigtable/srv-qa/writely.production-data | at com.google.storage.megastore.replication.StorageException.wrap(StorageException.java:65) | at com.google.storage.megastore.replication.StorageException.wrap(StorageException.java:46) | at com.google.storage.megastore.replication.monitor.RootCallback.failure(RootCallback.java:89) | at com.google.storage.megastore.replication.health.HealthTracker$HealthTrackingCallback.failure(HealthTracker.java:288) | at com.google.storage.megastore.replication.monitor.ApiTrace$ApiTraceCbk.failure(ApiTrace.java:254) | at com.google.storage.megastore.replication.acceptor.AcceptorImpl$15.failure(AcceptorImpl.java:1909) | at com.google.storage.megastore.replication.net.BtCallbackWrapper$2.run(BtCallbackWrapper.java:113) | at com.google.storage.megastore.replication.net.RequestContainer$ExceptionForwardingRunnable.run(RequestContainer.java:357) | at com.google.storage.megas ... [exception text truncated by msrepl; total 6686 characters] | [ 0.059] Proposer failing: Can't prepare without a quorum of living replicas | [ 0.059] Transitioning from=Prepare to=Failed | [ 0.061] CB [#1] A.prepare => CANCELLED | 1 unfired callbacks: {5}

Thank God.. We had a local backup, quite outdated though.. 
And once more thank God.. The document in Google Docs came alive in an hour!!!

OGSA-DAI ~Presenting in CXF~

Coding has started to accelerate. Revision 1065 customizes the built-in JAXB mapping, by an external binding file. This changes the default mapping of xs:dateTime from XMLGregorianCalendar to java.util.Calendar. For the ease of further commits, I added the respective client and server implementation folder structure in the commit 1066 along with the utility class CXFUtils.

1069 extends the Request Status Builder for the cxf client. 1070 includes the utility methods for handling the exceptions for the client toolkit. 1076 was an interesting  [ ;) ] fix, which fixes some years which I overlooked.

As with the common case of CXF stub generation, Lists are generated instead of arrays.
An example is,
-  final DataType[] inputData = inputBean.getInputLiteral();
+  final DataType[] inputData = inputBean.getInputLiteral().toArray(new DataType[inputBean.getInputLiteral().size()]);

 -              inputType.setInputLiteral(mCurrentData.getDataTypeArray());
+           inputType.getInputLiteral().clear();
+           inputType.getInputLiteral().addAll(Arrays.asList(mCurrentData.getDataTypeArray()));

1093 fixes some issues in an earlier commit related to this.

1094 and 1095 includes the CXF compliant Request management and Session Management Services respectively. 1096 is the CXF implementation of  the WS-ResourceLifetime portType operations.

1118 includes classes in execution/workflows. 

Classes in execution/Worflows.

Considerable changes in the stub generation includes,
(1) Inner class InputsType.Input replaces the class InputsTypeInput.

(2) Getters of the list returns a reference to the live list, not a snapshot. Hence to an item, getOutputStream().add(newItem);

from the method  public List getOutputStream() in OutputsType class.

(3) Regarding the generated fault types, in case of Axis, it was in the format of XXXType from the stub which needed to be used in the code, in cxf stubs, we have XXXTypes associated with XXX, where XXX from the stub is used in the code. [XXX denotes the faults.]

These changes in the stub code are reflected in the respective server side code.

1119 - The CXF implementation of Request Builder implementation. 1122, handles the AddressingUtils, which parses the SOAP Message Header.

@WebServiceProvider
public class AddressingUtils
{
....
    @Resource
    private static WebServiceContext context;


        SOAPMessageContext soapMsgContext = (SOAPMessageContext) context.getMessageContext();
        SOAPEnvelope envelope = soapMsgContext.getMessage().getSOAPPart().getEnvelope();

Commit 1128 defines CXF_MESSAGE_CONTEXT_ERROR. Commits 1144, 1154, and 1173 are for the cxf compliant data sink service, execution, and data resource information services, while 1161 and 1162 implement the data source and intrinsics  portType operations. 1159 is for the initialization class for CXF-compliant presentation layers, which is being modified at the moment. 1172 does some minor fixes in the exceptions thrown.

Mooshabaya - 1.0.0

As we are reaching the completion of the project, we have currently released the Mooshabaya binary to Sourceforge, which can be downloaded from here. At the same time, mooshabaya can also be built using ant, from the source as an open source project.

To build the distribution

trunk$ ant dist

To run the built binary

trunk/dist$ java -jar mooshabaya-1.0.0.jar

Trunk can be built currently using ant, and it is not broken at the moment as well. We have just created the tag 1.0-RC4 as well, as we always keep tagging the releases regularly.

OGSA-DAI - Coding with enthusiasm

As summer of codes officially started, I did my second commit on May 26th midnight (Sri Lankan time). In this commit, I have created the build and properties files of the client and server module. And wow, this commit has become the 1000th commit of OGSA-DAI. As an open source project OGSA-DAI has reached many mile stones and success stories in a relatively short period. Though we, GSoCers develop remotely from the mentors and the other developers, the super-friendly private/developer irc of OGSA-DAI always gives us the feeling of working in the same environment as the other developers  are.

1026 and 1030 became my third and fourth commits respectively, where 1026 was a minor fix on the wsdls, while 1030 fixed the namespace to package mapping based on the cxf -p option in the build.xml, which was handled by NStoPkg.properties in the Axis presentation layer. Currently I am in the process of developing the client and the server, which will either be committed to the trunk as a huge commit or a huge list of tiny commits, in the upcoming week.

To get the patches of my progress so far, use the below command from ogsadai_home/presentation;
svn diff -r 994:${current} cxf > gsoc2010.diff
svn diff -r 1274:${current} rest > gsoc2010Rest.diff
svn diff -r 1261:${current} ../release-scripts/ogsa-dai/cxf > gsoc2010Release.diff
svn diff -r 1406:${current} ../release-scripts/ogsa-dai/rest > gsoc2010ReSTRelease.diff

or for Release Script, from ogsa-dai/trunk/release-scripts/ogsa-dai/
svn diff -r 1261:${current} cxf > gsoc2010Release.diff

gsoc2010.diff refers to the cxf/soap based layer patch, while gsoc2010Rest.diff refers to the ReSTful layer, where gsoc2010Release.diff refers to the release script.

GSoC with OMII-UK

Google Summer of Codes officially begins today with so much of excitement, and the students have already started their development. One more energetic summer with OMII-UK has begun with 4 students, this time. As with 2008 and 2009, this summer too projects have been chosen from the set of projects under OMII-UK. Apart from Michal and Pradeeban from the OGSA-DAI team, two more students each from Rapid and SAGA teams, make the list of participants mentored by projects under OMII-UK this time.