May 10th, 2016 by Christian Hauschild

This is the 4th installment of our series about being a Product Owner. For the other posts, see here, here and here.

Give me information

The Gatherer mainly focuses on gathering as much information/feedback from stakeholders as he can. This helps him build a direction for the product for a specific period of time. Although he gets new requirements, features and requests, he strives to keep the direction steady and aligns new requirements to it. Together with the team, he prioritizes the backlog consequently. This helps him ensure that the direction is clear to the team.

Remember to write it down

The Gatherer keeps a personal log for all the possible long-term features that could be implemented in the product. He notes everything down regardless of whether the come from from customers, or by comparing with other similar products in the market. As soon as one of these features is barely considered valid for implementation, adds them to the product backlog and discussed it with the team.

Groomed and clean

He insists on frequent grooming sessions; they keep everyone in the team informed and mentally prepared for the forthcoming tasks. Moreover, grooming sessions keep the backlog clean and optimised, since most of the old issues would have been already solved and need to be deleted or rephrased.

 

Team, Team and Team

The Gatherer always tries to keep the team involved. At the regular meetings with customers, he usually summarises the notes and shares them with the team. Likewise, he tends to convey the feedback from stakeholders (positive or negative) about the development process, the quality of deliverables, and their expectation to the product and the team.

 

A responsible role

As a Product Owner, he believes in the role as responsible for defining the product path. That is of course after analysing requirements, business needs and use cases. He has established a strong relationship with the customers, based on mutual trust and sending a clear signal that he takes product ownership seriously.

 

This post concludes the series about different flavours of a Product Owner.

Now hiring in Dubai! - Read more

Posted in develop software, process Tagged with: , , , , ,

July 14th, 2015 by Per Steffensen

In this blog I will look at the inner workings of a Zookeeper client as of version 3.4.6, which I believe is the most commonly used version at the time of writing (even though 3.5.0 has been released – it probably works the same way anyway). Especially the exact conditions of getting ConnectionLossException and SessionExpiredException

On Apache Zookeeper cwiki and wiki you will find state-diagrams for a ZK client
zookeeper_state_diagram

But he diagram leaves some questions about what exactly makes those DISCONNECTED and SESSION_EXPIRED events occur?

One important thing to know about the inner workings of a ZK client is that it has two very important threads running

  • SendThread: Handles communication with the server, doing the actual sending to and receiving from server, sending pings/heartbeats if needed, handling state-transitions etc
  • EventThread: Handles communication with the user of the client, receiving requests and forwarding them to SendThread, getting responses and forwarding them to the user of the client. Handling watchers

It is mostly the inner workings of SendThread that is interesting when we want to answer the above questions

So lets look at a very simplified pseudo-code description of how the SendThread works. Basically SendThread runs in an infinite loop until its state is set to CLOSED (explicitly indirectly by the user of the client or due to SESSION_EXPIRED event). After that the SendThread dies and the entire ZK client is useless.

The client holds a state. The state can be one of NOT_CONNECTED, CONNECTING, CONNECTED, CONNECTEDREADONLY, CLOSED or AUTH_FAILED, starting out at NOT_CONNECTED. Lets just consider CONNECTED and CONNECTEDREADONLY the same for this simplified description (Hint: Before reading the pseudo-code you may want to click “Expand code” in the top bar – will appear if you move your mouse-pointer into the code-block)

When you use the ZK client (create znode, set-data, get-data etc) it will put a request on the outgoing queue, and wait it to finish processing (“hand the response over to the client” in SendThread pseudo-code above)

The code refers to two values

  • read-timeout: Two thirds of session-timeout
  • connect-timeout: session-timeout divided by number of Zookeeper nodes in the Zookeeper ensemble

As long as you are not connected the session-timeout used for the above calculations is the value you give when constructing your ZK client. After connection it is the session-timeout the client negotiated with the server

Lets look at details on one of the statements in the pseudo-code above

Now we are ready to answer the questions

  • DISCONNECTED event occurs (all outgoing and pending requests will get ConnectionLossException) when
    • You are connected but have not heard from server for more than read-timeout (two thirds of session-timeout)
    • OR, You are not connected and have not heard from server for more than connect-timeout (session-timeout divided by number of Zookeeper nodes). Response for connect-request not received within that period of time
  • SESSION_EXPIRED event occurs (all outgoing requests will get SessionExpiredException) when
    • You were connected at some point, but lost the connection
    • AND, You got hold of the server again
    • BUT, not within session-timeout (told by the server)

If you, as a user of the client, are not doing any interaction with the server yourself, SendThread will try do a ping/heartbeat request when half of read-timeout has passed, just to keep session alive.

Please note that the client single handedly decides if a DISCONNECTED event is going to occur, but that the client never decides that a SESSION_EXPIRED event is going to occur without being told by the server. Hence you will never get a SESSION_EXPIRED while the client is not able to talk to the server.

Also please note about terminology. The diagram mentions queued and pending requests. The pseudo-code mentions outgoing and pending queue/requests. Just to clarify

  • Outgoing queue (pseudo-code): Containing requests ready to be sent to the server, but not sent yet
  • Outgoing request (pseudo-code): A request on the outgoing queue
  • Pending queue (pseudo-code): Requests already sent to the server, but no response received yet
  • Pending request (diagram and pseudo-code): In diagram “pending request” means a request on either outgoing queue or on pending queue. In pseudo-code “pending request” means a request on the pending queue
  • Queued request (diagram): A request about to go onto outgoing queue (but does not because it fails immediately)

For consistency you could claim that the diagram ought to say

  • AUTH_FAILED (state): any queued request fail with AUTH_FAILED
  • CLOSED (state): any queued request fail with SESSION_EXPIRED

How to interpret the exceptions

  • ConnectionLossException: The client lost the connection to the server. You do not know if the requested operation was actually carried out or not
  • SessionExpiredException: The client has been connected at some point, but was disconnected and did not reconnect in time before the server timed out its session. All of your Ephemeral znodes are lost, and you have to go into recovery

When you, as the client user, get a ConnectionLossException, you do not know if the operation was actually carried out on the server or not. But the client itself might know for sure that it was not, but is not telling it in the exception. If the request is still on outgoing queue it has definitely not been carried out on the server. It is a shame that this information is not put forward to the client – e.g. introducing ConnectionLossReqNotPerformedException and ConnectionLossReqMaybePerformedException

Why does the exceptions every occur

Since the client will keep the connection alive for you, by sending ping/heartbeat in good time before read-timeout, how come you ever get into situations where those events/exceptions actually occur? You will of course see the exceptions in case of actual network problems, but they also occur if the environment in which the client/server runs is too busy and thus not giving enough execution time for the client/server to do its job in time – e.g.

  • JVM uses lots of time garbage-collecting. Especially in cases where stop-the-world phases takes too long
  • Other threads in the same JVM or other processes on the same machine occupy all resources
Now hiring in Dubai! - Read more

Posted in develop software Tagged with: ,