Question

I’m facing a problem after the migration from Spring 2.5, Flex 3.5, BlazeDS 3 and Java 6 to Spring 3.1, Flex 4.5, BlazeDS 4 and Java 7. I’ve declared a ClientFeed in order to send a sort of “alarm” messages to the flex client. There are three methods those alarms are sent. The first one is via snmp traps, a thread is started and wait for any trap, as one is received an alarm will be sent. The second method is via a polling mechanism, at the beginning of the web application a thread is started and will poll after a constant amount of time the alarms and send them to the client. The third method is the explicit poll command from the user, this will call a specific function on the dedicated service. This function uses then the same algorithm used in the second methods to perform a poll and shall send those alarms to the client.

The problem is that after the migration the first two methods are working without a problem, but the third one doesn’t. I suspect there is a relation with the threads. Is there any known issue between messagetemplate and the threads with the new frameworks ?

Here is a snapshot of the used client feed:

@Component
public class ClientFeed {

private MessageTemplate messageTemplate;

@Autowired
public void setTemplate(MessageTemplate messageTemplate) {
    this.messageTemplate = messageTemplate;
}

public void sendAlarmUpdate(final Alarm myAlarm) {

    if (messageTemplate != null) {
        System.out.println("Debug Thread: " + Thread.currentThread().getName());
        messageTemplate.send(new AsyncMessageCreator() {

            public AsyncMessage createMessage() {
                AsyncMessage msg = messageTemplate.createMessageForDestination("flexClientFeed");
                msg.setHeader("DSSubtopic", "Alarm");
                msg.setBody(myAlarm);

                return msg;
            }
        });    
    }
}

}

By the three methods I reach this piece of code and the displayed thread name are respectively: “Thread-14”, “Thread-24” and “http-bio-80-exec-10”.

Answer 1

I solved the problem by creating a local thread on the server to perform the job. Therewith the client feed is called via this new created thread instead of the http-thread.