On Sat, Jun 14, 2008 at 10:54 PM, <glassfish_at_javadesktop.org> wrote:
> In our environment we have many SLAM gadgets, possibly 10,000. Each SLAM
> exposes a web service and communicates to the clustered application servers
> exposing web services using a standard xml format. One troublesome
> restriction is that for each SLAM, an incrementing command id must be
> included in the message, message order maintained, and monotonically
> incremented. If the SLAM receives messages out of order, the response ACK
> has an error code and the request is not processed. Message responses from
> the SLAM's are ACK's. There is a time to live for each message and, when
> processing the request, if the time to live has expired, the SLAM will ACK
> with an appropriate error, not processing the request. Retries and the time
> to live are message dependent and set by the caller; with the restriction
> that a retry flag is set and the command id increments.
>
> 1. Various solutions have been discussed including a database table which
> would basically have a busy flag, a timeout, and the command id for each
> SLAM id.
> 2. Somehow storing references to stateful session beans pinned to each SLAM
> and storing state in those references specific to each SLAM has been
> discussed.
> 3. The threaded state machine wrapped in a JCA adapter is also on the
> table.
> 4. Send the messages concurrently and, if the SLAM responds with the out of
> order message try again.
5. Create a JMS message queue for each SLAM, have a processor that processes
this queue, esentially wrapping each SLAM (whatever they are) as a JMS queue
>
>
> We must consider a long run architectural solution which is scalable and
> fail safe. The SLAM's are 24 X 7 and the application servers which support
> them must also be available 24 X 7 and be able to be upgraded without
> service interruption. Message volume could be extremely high from all
> SLAMS, but there will only be rare cases where there will be two concurrent
> messages to be sent to the same
It's the rare cases that will cause you 95% of the pain! ;-)
> SLAM. The SLAM code is not available. The webservice interface for each
> SLAM is likely backed by an non-order maintaining queue.
>
> 4. has the advantage of the simple approach and will probably work, but we
> have the possiblity of a SLAM for which there are many concurrent requests
> getting bombarded with out of order messages. This may be a livable rarity
> but cannot be determined in advance of deployment.
>
> 1. is probably the most dependable solution but requires table access for
> all those SLAMS that just have one request for that rare case where a
> specific SLAM has multiple requests. Also, the blocking could be
> problematic where responses were slow.
>
> 3. Ouch, but is the most dependable and efficient solution.
>
> 2. The pinning of a stateful session been to each SLAM has advantegous
> beyond handling the concurrent requests, including state management without
> db access. This is like a shopping cart for each SLAM, but not from a
> client but within the application server. I know of no such
> implementations. Since the SLAMS live forever and can be added and removed,
> I don't know how exactly this would be implemented or if even practical
> within a clustered appserver environment.
>
> Comments, other alternatives.
> [Message sent by forum member 'quill49' (quill49)]
>
> http://forums.java.net/jive/thread.jspa?messageID=280359
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>