I added try {...} catch (Exception e) { log.error(e.getMessage(); throw e; }
around the code. I can't see any error messages in the logs since I made
that change. But in the encode method just before that try catch block I
have log.warn("Encoding!") line, which is not being reached or outputted
most of the time. So I am guessing encode method might not be called
properly under certain circumstances. But I can't seem to understand why
adding try and catch masks the error that I saw before.I think that you are right it might be that session getting discarded,. what might cause premature session discards? Another thing to note since I am using UnorderedThreadPoolExecutor and since session.write(ackObject); is the first thing in my messagehandler, rest of the messagehandler works just fine(not writing anything back to session though) My question is If session is discarded like you have said, would that be the case?(would rest of the messagehandler work fine?) Erinc On Tue, Mar 23, 2010 at 9:00 PM, Emmanuel Lécharny <[email protected]>wrote: > On 3/24/10 1:33 AM, Erinc Arikan wrote: > >> Sure; but before doing so I am wondering what will happen if the client >> sends a message and disconnects while I was intending to send >> acknowledgement back, will I receive the same null pointer exception? >> >> > no, I don't think so, from the top of my head. However, it has to be double > checked (the session might have been closed, all the pending message being > discarded from the queues...) > > > Because in the past whenever I had a problem in the response encoder, I >> used >> to see it in the stack trace(like exception at line25 responseencoder.java >> etc). I don't feel that message even gets to the encode method in the >> encoder. >> >> My encoder is as follows: It simply creates a byte array from getter >> methods >> of the object. >> >> > Is it possible you add a try {...} catch (Exception e) { > e.prntStackTrace(); throw e } around your code, so that you have the > opportunity to know where exactly you get this NPE? > > Another possibility is that the session has been discarded before the > message is processed completely, so the ProtocolEncoderOutput is null when > you try to inject the encoded message. > > You can also call the session.close() with a parameter to tell the session > to close only when there is no more messages to process. (it's a bit vague > in my memory though, and as it's almost 2 am here, i'm too lazzy to check > the code ;) > > The problem with the MINA NPE is that it does not inform you about the real > exception you've got. > > public void encode(IoSession session, Object message, >> ProtocolEncoderOutput >> out) throws Exception { >> >> int capacity = 1; >> //log.warn("encoding the response"); >> IoBuffer buffer = IoBuffer.allocate(capacity, false); >> buffer.setAutoExpand(true); >> >> if(message instanceof ResponseMessage) >> { >> ... >> >> } >> else if (message instanceof AckMessage) >> { >> >> AckMessage msg = (AckMessage) message; >> >> buffer.put((byte)1); >> int tmpMod = msg.getModuloCounter(); >> byte[] modData = new byte[3]; >> >> modData[2] = (byte)(tmpMod& 255); >> tmpMod = tmpMod>> 8; >> modData[1] = (byte)(tmpMod& 255); >> tmpMod = tmpMod>> 8; >> modData[0] = (byte)(tmpMod& 255); >> buffer.put(modData[0]); >> buffer.put(modData[1]); >> buffer.put(modData[2]); >> buffer.put(msg.getPriority()); >> buffer.put(msg.getStatus()); >> buffer.put(msg.getPacketNumber()); >> >> buffer.put((byte)msg.getMdtId().length()); >> >> buffer.putString(msg.getMdtId(),Charset.forName("ASCII").newEncoder()); >> buffer.put(msg.getFleetIdLength()); >> >> buffer.putString(msg.getFleetId(),Charset.forName("ASCII").newEncoder()); >> buffer.put(msg.getCmtTokenLength()); >> >> >> buffer.putString(msg.getCmtToken(),Charset.forName("ASCII").newEncoder()); >> >> buffer.putChar((char) 0); >> buffer.put((byte)4); >> buffer.flip(); >> } >> >> try >> { >> byte[] byteArray = TrimArray(buffer.array()); >> >> int tmpCrc = CRCCalculation(byteArray); >> byte[] crcData = new byte[2]; >> >> >> crcData[1] = (byte)(tmpCrc& 255); >> tmpCrc = tmpCrc>> 8; >> crcData[0] = (byte)(tmpCrc& 255); >> >> byteArray[byteArray.length-3] = crcData[0]; >> byteArray[byteArray.length-2] = crcData[1]; >> >> buffer = IoBuffer.wrap(Stuff(byteArray)); >> >> out.write(buffer); >> } >> catch(Exception e) >> { >> log.error(e.getMessage()); >> } >> } >> >> On Tue, Mar 23, 2010 at 7:30 PM, Emmanuel Lecharny<[email protected] >> >wrote: >> >> >> >>> On 3/24/10 12:08 AM, Erinc Arikan wrote: >>> >>> >>> >>>> I am using MINA 2.0.0.RC1, I built my own protocol codec filter to deal >>>> with >>>> messages. All of my tests went fine in test environments and I went live >>>> recently. I am processing almost a message every second. >>>> >>>> The issue that I experienced in the production environment is random >>>> null >>>> pointer exceptions. I suspect that they are happening when I try to >>>> write >>>> back an ack message to the session in my custom message handler. >>>> Following >>>> is the exception trace: >>>> >>>> >>>> >>>> >>> You most certainly have an issue in your encoder. Now, I agree that it's >>> difficult to tell exactly what's going wrong with this stack trace... >>> >>> Is it possible to see the code of your encoder ? >>> >>> -- >>> Regards, >>> Cordialement, >>> Emmanuel Lécharny >>> www.nextury.com >>> >>> >>> >>> >>> >> >> > > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.nextury.com > > >
