CometD 3.1.4 java implementation uses a buffer to keep track of the incoming message and this buffer has a default size of 2MB. When restarting from a disconnection, spikes can occur and you can exceed the limit.
What behaviour does the library have? Bytes are lost and if subsequent notifications from the server side are received they can be processed ?
The client-side buffering limit can be configured as explained here.
However, I recommend that you review your logic, as sending MiBs of messages to the client is typically not recommended, as the client may take a long while to process them all. Also, if the messages are few but with large data, you may want to setup things so that the client gets a CometD message with a download URI to be downloaded on the side, rather than sending the data in the CometD messages.
Having said that, you can write a server-side extension to, for example, discard old messages so that you don't send MiBs of data in case of reconnections.
The message acknowledgment extension guarantees server-to-client delivery, so -- provided you don't exceed the client-side receive buffer -- you can guarantee that queued messages are delivered to clients.
You may need a combination of things that is specific to your application. You may need a server-side listener to control the size of the message queue, the acknowledgment extension to guarantee delivery, and maybe a larger client-side buffer.
This is not done by default by CometD because everybody wants a different solution: some want to fail the session, some want to discard all messages, some want to keep only the last N, etc.
CometD provides you with the hooks you need to implement your logic.