1227 Notification subscriber not found error

[ConvertFromOldNGs]

by Michael >> Mon, 23 Apr 2007 4:28:44 GMT

Afternoon,

I'm getting a 1227 Notification subscriber not found error on one of our client sites. I seems from what I've been told, happening on only one machine, it happens several times a day and it doesn't matter where they are in the program. The only details I have at the moment are:

Error Number 1227
Error Message Notification subscriber not found
Error JADE Code
JadeShowModal in jadpmap @ line # 456
<Source not available>
form.showModal ;
CallControlEvent in jadpmap @ line # 295
inheritMethod(btn);

<<aSGLPPSRResponseForm>> Form::_showModal(456)
<<aSGLPPSRResponseForm>> Form::showModal(111)
<<aSGLLendingAccountForm>> SGLLendingAccountForm::butPPSR_click(485) <<aACAButton>> Button::click(295)
<<aACAButton>> ACAButton::click(208)

I have requested logs from the machine and will also get the ones for the server as well.

We have tried to recreate the issue but have not been able to. With that and the fact that it is only happening on that machine, suggests to me that it maybe a issue specific to that machine.

[ConvertFromOldNGs]

by Michael >> Mon, 23 Apr 2007 4:31:31 GMT

oops finger slipped....

Does anyone have any suggestions as to where or what I need to look for? Is my assumption that it maybe machine specific likely to be correct?
Any other suggestions?

Cheers

Michael

[ConvertFromOldNGs]

by Alan >> Mon, 23 Apr 2007 9:52:10 GMT

I have had this message in the past when the object that subscribed for the notificcation was deleted without coding an endNotification (as appropriate for the subscribe) do you have any causeEvents coded in the execution path?

[ConvertFromOldNGs]

by Michael >> Mon, 23 Apr 2007 20:46:44 GMT

No causeEvents.

Form::load has
beginClassNotification(SGLExtInterfaceRequestPPSR, false, Object_Create_Event, Response_Continuous, null) ;
beginClassNotification(SGLExtInterfaceRequestPPSR, false, Object_Update_Event, Response_Continuous, null) ;
beginClassNotification(SGLExtInterfaceRequestPPSR, false, Object_Delete_Event, Response_Continuous, null) ;

Form::unload has
endClassNotification(SGLExtInterfaceRequestPPSR, false, Object_Create_Event) ;
endClassNotification(SGLExtInterfaceRequestPPSR, false, Object_Update_Event) ;
endClassNotification(SGLExtInterfaceRequestPPSR, false, Object_Delete_Event) ;

[ConvertFromOldNGs]

by Brendan >> Mon, 23 Apr 2007 21:52:43 GMT

I've had a similar problem reported and, like you, the code looks OK in that endNotifications (in my case endNotificationForSubscriber) were called. It would appear that the form is being deleted but the unload event is not invoked. Under what circumstances can this happen?

Have you tried putting the endNotification in the delete method of the form rather than the unload event? Better may be an endNotificationForSubscriber in both the unload and the delete event. To be sure, to be sure.

You may also try trapping the exception in a global handler but that isn't really fixing the problem.

Cheers, Brendan

[ConvertFromOldNGs]

by Alan >> Wed, 25 Apr 2007 7:19:54 GMT

Is it possible that an instance of SGLExtInterfaceRequestPPSR is created / updated / deleted during the form load (after the begin notification)?

I'm thinking that the notification has been registered but the form load has not completed therefore the form is not actually available yet to send the notification to.

[ConvertFromOldNGs]

by BeeJay >> Mon, 30 Apr 2007 3:54:56 GMT

It's less likely to be machine specific and more likely that something earlier on has left their App setup to continue getting these faults until their app is shutdown. That also explains why it is apparently happening in different areas of the app. It's not necessarily the code executing at the time that is "causing" the problem, but rather when your app reaches the point where a notification can be delivered the call stack will be whatever other methods were active at the time. eg: only the 1227 entry if you app was completely idle, or if you have forms showing modally those methods prior to the show modal will also be on the call stack but not directly a cause of the 1227 exception.

The first thing you need to do is identify what object the notification was trying to be delivered to - the error object in the standard UHE dialog and logging gives you this information. If you have your own excoption handler trapping this, make sure you log this information as well. Then, you need to identify the class for that object and attempt to determine how a notification could have been left registered for an instance of that class after the said instance in question had been deleted.

The user will continue to get these 1227 exceptions until such time as they restart their application. You may want to suggest that they restart the application to prevent further occurrences of the 1227 - unless of course they are regularly performing the sequence that sets the system up for subsequent failure.

Cheers,
BeeJay.