[ http://jira.jboss.com/jira/browse/JBESB-1434?page=all ] Work on JBESB-1434 started by Kurt Stam. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBESB-1434?page=all ] Work on JBESB-1434 stopped by Kurt Stam. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBESB-1434?page=comments#action_12395811 ] Mark Little commented on JBESB-1434: ------------------------------------ Can you confirm that when you "change the transport of a service" you undeploy the old one? If so, I can see why this causes problems. In fact, this is the only case that makes sense and the fix is straightforward in that situation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBESB-1434?page=comments#action_12395817 ] Mark Little commented on JBESB-1434: ------------------------------------ I'm wondering if the issue is to do with undeploying the old service and leaving it long enough before deploying a new service that the SI instance fails-over to the redelivery service. If the original message isn't using a LogicalEPR, then any redelivery attempt will also fail. I agree with you that once the new service comes on line the SI instance should pick it up and move over to using it. Then of course there's the issue that if we have a complete failure in an SI instance and we try to reuse it there'll never be a 2nd attempt to refresh the cache subsequently, because serviceClusterInfo.getEPRs().size() will already be zero when we hit post. We'll refresh the cache once per delivery attempt from that point forward. I need to double check that reasoning though. We definitely need the clarification from Jiri as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBESB-1434?page=comments#action_12395905 ] Jiri Pechanec commented on JBESB-1434: -------------------------------------- I was swapping File transport with JMS when I was testing jBPM integration. The problem is that there was no exception but the messages were not processed. After restart the message processing worked OK again. My guess was that after the change the EPR still operated over the dir as File EPR as was cached in service invoker in static variable. Moreover when you change the transport this way and the dir is still there then there is no reason for File invoker to fail. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ http://jira.jboss.com/jira/browse/JBESB-1434?page=comments#action_12396058 ] Mark Little commented on JBESB-1434: ------------------------------------ BTW, I should have added that the "fix" is just adding a comment, because AFAICT the expiration time should kick in (60 seconds by default) and cause the cache to be refreshed. See earlier discussion. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira