Actions
Incident #8860
closed
Sharing of post does not handle eventual consistency properly
Added by Massimiliano Assante almost 8 years ago. Updated almost 8 years ago.
Start date:
Jun 06, 2017
Due date:
% Done:
100%
Estimated time:
Infrastructure:
Production
Description
The user Anna shared a post on the VRE /d4science.research-infrastructures.eu/D4Research/ICES_AbundanceEstimationFromAcoustic the sharing of posts is made of 2 writes, the first write the Post in the Feed "Table" the Second write it in the VRE_Timeline Table.
Before the second write the method tries to read the post from the Feed "Table", It seems that when the second write was attempted the DB was not in a consistent state and an exception was raised, this caused the notification via email not to be sent (at the very least).
Updated by Massimiliano Assante almost 8 years ago
Here the exception
2017-06-06 14:23:46,973 INFO server.ShareUpdateServiceImpl [http-bio-9090-exec-124,sharePostWithLinkPreview:172] %[PORTAL] 1730978401 [http-bio-9090-exec-124] INFO org.gcube.portlets.user.shareupdates.server.ShareUpdateServiceImpl - Attempting to save Feed with text: To all course participants, <br/> Please be aware that you are expected to be familiar with the use of R for this course. Paul and John have suggested this online tutorial for you to look at before the course. <br/> <a class="link" style="font-size:14px;" href="https://www.youtube.com/watch?v=iffR3fWv4xw&list=PLOU2XLYxmsIK9qQfztXeybpHvru-TrqAP" target="_blank">https://www.youtube.com/watch?v=iffR3fWv4xw&list=PLOU2XLYxmsIK9qQfztXeybpHvru-TrqAP</a> Level: SINGLE_VRE Timeline=/d4science.research-infrastructures.eu/D4Research/ICES_AbundanceEstimationFromAcoustic
2017-06-06 14:23:46,976 INFO ex.FeedIDNotFoundException [http-bio-9090-exec-124,<init>:11] %[PORTAL] 1730978404 [http-bio-9090-exec-124] INFO org.gcube.portal.databook.shared.ex.FeedIDNotFoundException - The Post having id: afd12147-3cda-47af-9aed-4216fd118362 is not present in the database: The requested feedid: afd12147-3cda-47af-9aed-4216fd118362 is not existing
org.gcube.portal.databook.shared.ex.FeedIDNotFoundException
at org.gcube.portal.databook.server.DBCassandraAstyanaxImpl.readFeed(DBCassandraAstyanaxImpl.java:473)
at org.gcube.portal.databook.server.DBCassandraAstyanaxImpl.saveFeedToVRETimeline(DBCassandraAstyanaxImpl.java:443)
at org.gcube.portlets.user.shareupdates.server.ShareUpdateServiceImpl.sharePostWithLinkPreview(ShareUpdateServiceImpl.java:200)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.google.gwt.user.server.rpc.RPC.invokeAndEncodeResponse(RPC.java:561)
at com.google.gwt.user.server.rpc.RemoteServiceServlet.processCall(RemoteServiceServlet.java:208)
at com.google.gwt.user.server.rpc.RemoteServiceServlet.processPost(RemoteServiceServlet.java:248)
at com.google.gwt.user.server.rpc.AbstractRemoteServiceServlet.doPost(AbstractRemoteServiceServlet.java:62)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:650)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:731)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:303)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:116)
at sun.reflect.GeneratedMethodAccessor372.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at com.liferay.portal.kernel.bean.ClassLoaderBeanHandler.invoke(ClassLoaderBeanHandler.java:67)
at com.sun.proxy.$Proxy731.doFilter(Unknown Source)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:116)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDirectCallFilter(InvokerFilterChain.java:165)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:96)
at com.liferay.portal.kernel.servlet.PortalClassLoaderFilter.doFilter(PortalClassLoaderFilter.java:74)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.processDoFilter(InvokerFilterChain.java:204)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilterChain.doFilter(InvokerFilterChain.java:109)
at com.liferay.portal.kernel.servlet.filters.invoker.InvokerFilter.doFilter(InvokerFilter.java:119)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:220)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:170)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:957)
at org.gcube.portal.threadlocalexec.SmartGearsPortalValve.invoke(SmartGearsPortalValve.java:69)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116)
at org.apache.catalina.ha.tcp.ReplicationValve.invoke(ReplicationValve.java:333)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:423)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1079)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:620)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)
Updated by Massimiliano Assante almost 8 years ago
- Subject changed from Sharing of post does not handle eventually consistency properly to Sharing of post does not handle eventual consistency properly
Updated by Costantino Perciante almost 8 years ago
- Status changed from New to In Progress
- % Done changed from 0 to 100
I have analysed the flow of execution of the code when a user writes a post, and taking into account the fact that @anna.davies@ices.dk posted without the notification on purpose (we asked her), I can say that there was no incident at all.
However, looking at the exception I saw that the write-on-vre-timeline method is invoked twice. The first one there is a single operation which writes the post in two column families (feed and vre timeline). The second time the operation is invoked, a check on the existence of the post is performed (by a read, which is the one that failed).
For sure the social library should be enhanced to improve exception handling and taking into account the fact that a read may fail the first time. I'm going to open an improvement task for this.
Updated by Costantino Perciante almost 8 years ago
- Status changed from In Progress to Closed
Actions
