Re: Problems with sending / receiving notifications

Hi Jens,

On 9/19/07, Rottgardt, Jens (K-SOB-2/3) <[email protected]> wrote:
> Hello,
>
> I have a application which sends notifications to remote clients. After a
> while (maybe one day) the server does not send any notifications or only for
> some mbeans (I have changed the log level during runtime to trace and no
> notifications where send). Could it be that for some circumstances listener
> registrations in the server get lost ?
>
> Could it be that the notification mechanisim becomes problems when the
> notification buffer is full ? The trace output in this case is
>
> Notification buffer full: NotificationBuffer@673416f2[first=116896,
> last=117920, size=1024, lowestExpected=99439, maxCapacity=1024,
> purgeDistance=128]
> Notification added to buffer: NotificationBuffer@673416f2[first=116897,
> last=117921, size=1024, lowestExpected=99439, maxCapacity=1024,
> purgeDistance=128]
> Sending notifications from FSPResourceKey[lwfis21.A11F2111.fhdh0000.KSG3]
>         Listener is:
> mx4j.remote.DefaultRemoteNotificationServerHandler$ServerListener@7030d6f2
>         Filters - Handback for this listener:
> [javax.management.NotificationBroadcasterSupport$FilterHandbackPair@39a516f3
> ]
>                 Filter is: null, enabled: true
>                 Handback is: 561
>
> This message comes up very early, maybe 10 minutes after I have started the
> server process. But at this time everything is ok; notifications are
> received from client.

When the notification buffer becomes full, the oldest notification in
the buffer is removed and will not be delivered to clients.

Are you playing with MX4JRemoteConstants.FETCH_NOTIFICATIONS_TIMEOUT ?

How many notifications will be generated by the server in one minute ?

If you can describe precisely your environment (number of clients,
notifications/second generated by server, timeouts values, reliability
of the clients, and client logs) then we can recreate a test case and
reproduce the behavior.

If you can also trace the client's log will be useful, in particular
the "Notification Fetcher" thread (if terminates or not).

It could be that in your case, setting some parameter to non-default
values will solve the problem.

Thanks,

Simon
-- 
http://bordet.blogspot.com

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/