Màquines d'estat en JAVA

Gestionar els estats dels objectes en un entorn multi-thread, orientat a events, és complexe. Especialment si el mateix event pot provocar diferents accions depenent de l'estat sobre el que s'aplica.

Potser si parlem d'un problema en concret resultarà més fàcil comprendre la problemàtica. Vaig començar a enfrontar-me a aquest repte quan desenvolupava protocols en temps real per a la transmissió de veu. En concret, si miren la RFC sobre SIP, https://www.ietf.org/rfc/rfc3261.txt, una transacció servidor de SIP INVITE estaria descrita per:

                               |INVITE

                               |pass INV to TU

            INVITE             V send 100 if TU won't in 200ms

            send response+-----------+

                +--------|           |--------+101-199 from TU

                |        | Proceeding|        |send response

                +------->|           |<-------+

                         |           |          Transport Err.

                         |           |          Inform TU

                         |           |--------------->+

                         +-----------+                |

            300-699 from TU |     |2xx from TU        |

            send response   |     |send response      |

                            |     +------------------>+

                            |                         |

            INVITE          V          Timer G fires  |

            send response+-----------+ send response  |

                +--------|           |--------+       |

                |        | Completed |        |       |

                +------->|           |<-------+       |

                         +-----------+                |

                            |     |                   |

                        ACK |     |                   |

                        -   |     +------------------>+

                            |        Timer H fires    |

                            V        or Transport Err.|

                         +-----------+  Inform TU     |

                         |           |                |

                         | Confirmed |                |

                         |           |                |

                         +-----------+                |

                               |                      |

                               |Timer I fires         |

                               |-                     |

                               |                      |

                               V                      |

                         +-----------+                |

                         |           |                |

                         | Terminated|<---------------+

                         |           |

                         +-----------+

O bé dones amb una manera senzilla d'implementar aquest problema o acabaràs tenint codi difícil d'escriure, mantenir, propens a errors, dificil de testejar i impossible de tracejar. T'adonaràs que estàs en aquesta situació si téns un munt de if/else, synchronized i t'has passat els últims 2 dies intentant entendre perquè la teva aplicació ha arribat a un estat concret que no esperaves.

Si t'has trobat en algun moment en aquesta situació, hauries de fer un cop d'ull a la meva llibreria https://bitbucket.org/xferro/sicoris-statemachine . Fins i tot, hi ha un SNAPSHOT disponible en cas que vulguis començar a provar-la.

Qualsevol comentari és benvingut. Espero que ho gaudiu!

Máquinas de estado para JAVA

Manejar los estados de los objetos en un entorno multi-thread, orientado a eventos, es duro. Especialmente si este evento puede provocar diferentes acciones dependiendo del estado sobre el que se aplique.

Quizás sea más fácil entenderlo con un problema concreto. Empecé a pensar sobre este problema cuando desarrollaba protocolos en tiempo real para voz. En concreto, si miramos la RFC sobre SIP https://www.ietf.org/rfc/rfc3261.txt, una A SIP INVITE server transaction tendría una pinta como sigue:

                               |INVITE

                               |pass INV to TU

            INVITE             V send 100 if TU won't in 200ms

            send response+-----------+

                +--------|           |--------+101-199 from TU

                |        | Proceeding|        |send response

                +------->|           |<-------+

                         |           |          Transport Err.

                         |           |          Inform TU

                         |           |--------------->+

                         +-----------+                |

            300-699 from TU |     |2xx from TU        |

            send response   |     |send response      |

                            |     +------------------>+

                            |                         |

            INVITE          V          Timer G fires  |

            send response+-----------+ send response  |

                +--------|           |--------+       |

                |        | Completed |        |       |

                +------->|           |<-------+       |

                         +-----------+                |

                            |     |                   |

                        ACK |     |                   |

                        -   |     +------------------>+

                            |        Timer H fires    |

                            V        or Transport Err.|

                         +-----------+  Inform TU     |

                         |           |                |

                         | Confirmed |                |

                         |           |                |

                         +-----------+                |

                               |                      |

                               |Timer I fires         |

                               |-                     |

                               |                      |

                               V                      |

                         +-----------+                |

                         |           |                |

                         | Terminated|<---------------+

                         |           |

                         +-----------+

Si no das con una solución fácil para implementar esta máquina de estados, acabarás teniendo un código: difícil de escribir, difícil de mantener, error-prone, difícil de probar y imposible de tracear. El signo que estás en una situación similar es que tienes un montón de if/else, synchronized y y te has pasado 2 días intentando encontrar cómo has podido entrar en un estado que no tenías previsto.

Por tanto, si te has encontrado con este problema, deberías mirar mi solución. Acabo de finalizar una nueva iteración sobre el código y estoy muy satisfecho del resultado: https://bitbucket.org/xferro/sicoris-statemachine . Hay un SNAPSHOT disponible si quieres empezar a probar.

Cualquier comentario es bienvenido! Espero que lo disfrutéis!

State machines for Java

Managing object states for multi-threaded applications is hard. Especially, when this state can transition to another state depending on multiple events. 

I started thinking about this problem when implementing SIP protocol solutions. A SIP INVITE server transaction would look like:

                               |INVITE

                               |pass INV to TU

            INVITE             V send 100 if TU won't in 200ms

            send response+-----------+

                +--------|           |--------+101-199 from TU

                |        | Proceeding|        |send response

                +------->|           |<-------+

                         |           |          Transport Err.

                         |           |          Inform TU

                         |           |--------------->+

                         +-----------+                |

            300-699 from TU |     |2xx from TU        |

            send response   |     |send response      |

                            |     +------------------>+

                            |                         |

            INVITE          V          Timer G fires  |

            send response+-----------+ send response  |

                +--------|           |--------+       |

                |        | Completed |        |       |

                +------->|           |<-------+       |

                         +-----------+                |

                            |     |                   |

                        ACK |     |                   |

                        -   |     +------------------>+

                            |        Timer H fires    |

                            V        or Transport Err.|

                         +-----------+  Inform TU     |

                         |           |                |

                         | Confirmed |                |

                         |           |                |

                         +-----------+                |

                               |                      |

                               |Timer I fires         |

                               |-                     |

                               |                      |

                               V                      |

                         +-----------+                |

                         |           |                |

                         | Terminated|<---------------+

                         |           |

                         +-----------+

If you don’t think of an easy approach to representing/coding these state machines, you will end up having something: difficult to write, error prone, difficult to test and impossible to trace. The main sign that you are doing it wrong is when your code is full of if/else, synchronized blocks and you had to debug for 2d to find out how the hell you ended up in such an unexpected state.

So, if you happen to have to manage complex state objects, you should take a look to my library. I just finished a new iteration to the code and. Much happier than ever with it: https://bitbucket.org/xferro/sicoris-statemachine . There's already a SNAPSHOT version available, so you can use it already.

Any feedback is more than welcome!

Better JDBC Prepared Statements?

After using PreparedStatements for a while, you understand how painful it is maintaining SQL queries. Setting values by position is error-prone and tough.

Let's imagine a query that you want to check multiple columns against the same value:

SELECT * FROM Table WHERE a > ? AND b < ? AND c == ?

You will need to have the following code in place:

int THE_VALUE = 12345;
stmt.setInt(1, THE_VALUE);
stmt.setInt(2, THE_VALUE);
stmt.setInt(3, THE_VALUE);

Just imagine that you need to refactor the query such as the new values don't have nothing to do with THE_VALUE. The query could look like this:

SELECT * FROM Table WHERE (a > ? OR ? ) AND (b < ? OR ?) AND c == ?

You'd need to refactor your previous query such as:

int THE_VALUE = 12345;
boolean ANOTHER_VALUE = false;
stmt.setInt(1, THE_VALUE);
stmt.setInt(3, THE_VALUE);
stmt.setInt(5, THE_VALUE);
stmt.setBoolean(2, ANOTHER_VALUE);
stmt.setBoolean(4, ANOTHER_VALUE);

Not sure what you think about, but having to count question marks in a query to make things work never looked very attractive to me. I think we could be smarter than that

So what?

Why not having something like:

SELECT * FROM Table WHERE a > @{startDate} AND b < @{startDate} AND C = @{startDate}

and code like:

int THE_VALUE = 12345;
smartStatement.setInt("startDate", THE_VALUE);

The second approach is not impacted by any refactoring and it's less error prone. So, this small library tackles this problem with a very simplistic approach.

The approach

The library is very compact and simple. It is responsible for parsing the sql query and populating prepared statement values, but nothing more. So, creation of the prepared statement itself is not part of this library. I wanted to avoid over-engineered wrappers for such a small problem

What is not supported?

Do not use parametrized values in the queries. It might break the parsing logic. So something like this will break:

String sql = "SELECT * FROM MY_STRINGS WHERE str = \"a string containing weird stuff: ${else}\" AND id = ${id}";

Use the following instead:

String weird = "a string containing weird stuff: ${else}";
String sql = "SELECT * FROM MY_STRINGS WHERE str = ${weird} AND id = ${id}";
smartStatement.setString(stmt, "weird", weird);
smartStatement.setString(stmt, "id", "WTF");

That's brilliant. Where can I find it?

Check my sicoris-jdbc bickbucket repo . Comment it, fork it, use it. Any feedback is more than welcome.

Y Java7 entrará en EOL

Cuando muchas organizaciones están migrando a Java7, entramos en las últimas semanas de soporte. Se espera que a será EOL para el fin de 2015H1

Java7 EOL

Java8 - See your dependencies

Critical Patch Update for java 8 - 8u11. Further details in http://www.oracle.com/technetwork/java/javase/8u11-relnotes-2232915.html

They added a nice tool to take a look at, jdeps: http://docs.oracle.com/javase/8/docs/technotes/tools/unix/jdeps.html . It will provide you all your dependencies

Finite State Machine for Java... and 2

I just needed to refactor the finite state machine for java project that is available in https://github.com/xaviferro/xiron-statemachine . 

Why? I was not happy with it. Now I think it's much more consistent. I just used the commuting time again for this.

I copy below the README file available in github, in case anyone might be interested. Any feedback is more than welcome.

--------------------------

A state machine is a well-known way of defining and managing complex instance state

for a finite state machine in a high concurrent event-driven environment. 

The state changes quickly and we need to avoid repetitive manual work for managing

the state, which ends up being quite error prone.

The goal of this library is to provide an easy and simple implementation that covers 

most of the cases in a concurrent system. On top of that, the library provides

some nice decoration annotations that allow developers to create state machines

easily.

So, what is a state machine? You might find quite some nice explanations in wikipedia

about Finite State Machine. In my words, a state machine is defined as a set of states, 

events that might be triggered and transitions between states, which happen given an 

specified event. A transition is a tuple of state-event-state. Each tuple defines an 

allowed transition between the source state and target state based on a triggered event.

Transitions that have not been declared will throw an exception, as they are not

allowed at all.

In order to provide fully control on the execution of the transition, each transition

is divided in 3 phases:

- First phase, when exiting the source state. It's the only phase that allows cancelling

  the transaction. See ExitStateController.

  

- Second phase, the transition itself. It's the phase that developers are going to use

  the most. Take a look at TransitionController.

  

- And last but not least, when entering the target state. In this phase we might want

  to process a new event without releasing the lock. This is very useful for intermediate

  conditional states that evaluate a condition and take a decision. See

  EnterStateController.

Some other properties of the state machine are:

- A state machine has one starting state.

- A state machine has multiple intermediate states.

- A state machine has multiple finish states.

- We cannot define transitions sourced in a final state unless they are reflexive ones.

- When created, the state machine state is the starting state.

- Transitions are executed atomically.

The basic model of the state machine, separates the definition -StateMachiheDefinition-,

from the execution state -StateMachine- from the execution strategy -StateMachineStrategy-.

You can see in the model that I have separated the definition of the state machine 

(see StateMachineDefinition for further details) from the execution (see StateMachine)

Apart from the manual state machine definition, the library enriches the model with

some annotation utilities. For example, the following class would define a state machine:

@AStateMachine

public class LegalStateMachineTest {

    @State(isStart=true) public static final String STATE_A = "STATE_A";

    @State public static final String STATE_B = "STATE_B";

    @State public static final String STATE_COND = "STATE_COND";

    @State public static final String STATE_D = "STATE_D";

    

    @Event public static final String EVENT_AB = "EVENT_AB";

    @Event public static final String EVENT_BB = "EVENT_BB";

    @Event public static final String EVENT_BC = "EVENT_BC";

    @Event public static final String EVENT_CD = "EVENT_CD";

    

    @Transitions({@Transition(source=STATE_A, target=STATE_B, event=EVENT_AB),

                  @Transition(source=STATE_B, target=STATE_COND, event=EVENT_BC),

                  @Transition(source=STATE_COND, target=STATE_D, event=EVENT_CD)})

    public void noop(TransitionInfo info) {

        System.out.println("#tx: " + info);

    }

    

    @ExitState(STATE_A)

    public Boolean exitA(TransitionInfo info) {

        System.out.println("#exit: " + info);

        return true;

    }

    

    @EnterState(STATE_COND)

    public EventInfo transitionBC(TransitionInfo info) {

        System.out.println("#enter: " + info);

        return new EventInfo(EVENT_CD, null);

    }

    

    @Test

    public void test() throws StateMachineException {

        StateMachine sm = StateMachines.newNonReentrant(this);

        sm.processEvent(EVENT_AB, null);

        sm.processEvent(EVENT_BC, null);

        

        Assert.assertEquals(sm.getCurrentState(), STATE_D);

    }

}

If we execute the previous test, we would get the following output:

#exit: [STATE_A + EVENT_AB -> STATE_B]

#tx: [STATE_A + EVENT_AB -> STATE_B]

#tx: [STATE_B + EVENT_BC -> STATE_COND]

#enter: [STATE_B + EVENT_BC -> STATE_COND]

#tx: [STATE_COND + EVENT_CD -> STATE_D]

In order to instantiate this class we need to invoke StateMachines.newReentrant(the_object),

that will return a state machine with:

- 4 states: STATE_A, STATE_B, STATE_COND and STATE_D

- 4 events: EVENT_AB, EVENT_BB, EVENT_BC and EVENT_CD

- 1 enter state definition. When entering the state STATE_COND, we decide to trigger a new

  event before releasing the lock

- 3 transitions: 

        STATE_A + EVENT_AB -> STATE_B 

        STATE_B + EVENT_BC -> STATE_COND

        STATE_COND + EVENT_CD -> STATE_D

Hopefully, the example is clear enough.

The last point to mention is about choosing the right strategy when creating a state machine.

There are only two at the moment:

- Reentrant. Means that we can trigger an event when executing a transaction from that thread

  (outside the allowed step during the enter state). Be careful on that.

- Non reentrant. Means that the state machine won't allow transitions during a transition.

  This enforces to think more about the concurrency model and it's, normally, a safer approach.

  

HTTP 2.0 First draft

You can find the first draft of the HTTP 2.0 protocol in here: http://tools.ietf.org/html/draft-ietf-httpbis-http2-00. 
If you don't have a better idea, just copy it. Take the SPDY protocol as your draft and ... DONE! Interesting. At least they haven't reinvented the wheel :-)

Java6 EOL en Febrero 2013

Java6 EOL ha sido retrasado hasta Febrero de 2013. En nuestra empresa no estamos preparados aún. Damm it!

http://www.infoq.com/news/2012/08/ava-6-eol-extended

state machine for java

Not bad. I started the project after my last post. That means less than 3 weeks. Done in my spare time, when commuting to work. In tram 4. Motivation changes the dimension time/productivity.

The result: just a basic concurrent state machine api that allows easily managing complex states and transitions. Besides, I have enriched the controllers with some fancy annotations for simplifying the state machine definition.

Very happy with the result. Still pending some improvements and functionalities.

My first open source contribution after several years thinking about it, under Apache 2.0 license.

Any feedback would be great. I hope you enjoy it: https://github.com/xaviferro/xiron-statemachine

the Singleton pattern reviewed

Interesting approach to the singleton pattern in Joshua Bloch's book 'Effective Java' 2nd edition.


public enum Singleton {
    INSTANCE;
}

This simple idiom solves a lot of non-trivial problems, as synchronization or serialization. I do really like this approach -I had never thought about this option. 


What about you?