Try this:
-vmargs -Xms256m -vmargs -Xmx1024m
No quotes.
Nigel
saikiranp wrote, on 16/11/2010 05:55:
>
> Hi Amy,
> Sorry, i am setting the time to live as 0( Not -1).
>
> Could u send me the exact command to increase the heap levels for
> imqbroker.
>
> I tried to set using<cluster-instance-name>.ms-service.start-args =
> "-vmargs "-Xms256m -Xmx1024m"". but it is not working..
>
> Regards
> Saikiran
>
>
>
>
>
> Amy Kang-3 wrote:
>>
>> On 11/15/10 04:26, saikiranp wrote:
>>> Hi Amy,
>>> What could be the reason for message expiration?
>>>
>>>
>> the JMS client that sent the message has specified non-zero expiration
>> when sending the message.
>>> We also set time to live for all these messages as -1 ( never expire).
>>> Still could not understand why the messages are getting expired?
>>>
>>
>> 0 is never expire according to the JMS specification (section 3.4.9
>> JMSExpiration). Please also see JMS javadoc
>> http://download.oracle.com/javaee/5/api/javax/jms/MessageProducer.html#setTimeToLive(long)
>>
>> amy
>>> Regards
>>> Saikiran
>>>
>>>
>>>
>>> Amy Kang-3 wrote:
>>>
>>>>
>>>> Saikiran,
>>>>
>>>>
>>>> On 11/12/2010 04:11 AM, saikiranp wrote:
>>>>
>>>>> Hi Amy,
>>>>>
>>>>> We are actually using REJECT_NEWEST.
>>>>>
>>>>> So the messages expired are not because the max limit of the queue
>>>>> reached and then the old ones are getting removed. I could also see
>>>>> that
>>>>> the
>>>>> metrics of the queue shows that it has not reached max limit.
>>>>>
>>>>> But we can see from the imq logs that the messages are expired. May
>>>>> be
>>>>> because of the some other reason and after that i see these JMS
>>>>> rollback
>>>>> exceptions. please see the attached log for more information.
>>>>>
>>>>> http://old.nabble.com/file/p30198742/log.txt
>>>>>
>>>> [10/Nov/2010:00:18:55 CET] [B1140]: Expired 645 messages from
>>>> destination
>>>> BcsVoicePhysicalChargingServiceQueue [Queue]
>>>> [10/Nov/2010:00:19:55 CET] [B1140]: Expired 1200 messages from
>>>> destination
>>>> BcsVoicePhysicalChargingServiceQueue [Queue]
>>>> [10/Nov/2010:00:19:56 CET] WARNING [B3229]: Transaction acknowledgement
>>>> [3675199-192.168.0.4(91:2c:61:56:e2:df)-59265-1289344417629,
>>>> [consumer:2430022061644300032, type=NONE]]TUID=2430022071232245504
>>>> processing failed: [B1290]: Transaction acknowledgement could not be
>>>> processed because message
>>>> 3675199-192.168.0.4(91:2c:61:56:e2:df)-59265-1289344417629[[consumer:2430022061644300032,
>>>> type=NONE]:[consumer:0,
>>>> type=CLIENT_ACKNOWLEDGE]]TUID=2430022071232245504
>>>> reference is gone :
>>>> com.sun.messaging.jmq.jmsserver.util.BrokerException: [B1290]:
>>>> Transaction
>>>> acknowledgement could not be processed because message
>>>> 3675199-192.168.0.4(91:2c:61:56:e2:df)-59265-1289344417629[[consumer:2430022061644300032,
>>>> type=NONE]:[consumer:0,
>>>> type=CLIENT_ACKNOWLEDGE]]TUID=2430022071232245504
>>>> reference is gone
>>>> ......
>>>>
>>>> The above warning log message would cause the transaction rollback on
>>>> application side. Since the warning messages came right after the
>>>> "Expired .. messages .." log messages, it's very likely that the
>>>> rollback
>>>> was due to removed expired messages that have been delivered to client.
>>>> In 4.5 (>= build21), message expiration handling has been improvement.
>>>> Please see bug fixes 6761759, 6186088.
>>>>
>>>>
>>>>
>>>>> The sailfin version we are using is "Sun GlassFish Communications
>>>>> Server
>>>>> 1.5 ((v2.1 Patch12)(9.1_02 Patch18)) (build b01-p12)"
>>>>>
>>>>> JMS service type is "LOCAL".
>>>>>
>>>>> As the type is set as LOCAL, imqbroker will be started by sailfin. I
>>>>> would
>>>>> also like to know how to change the vmargs for broker.
>>>>>
>>>> You can use the start-args attribute of the jms-service element, please
>>>> see
>>>> http://docs.sun.com/app/docs/doc/820-7695/beaof?l=en&a=view
>>>>
>>>> amy
>>>>
>>>>
>>>>> Saikiran
>>>>>
>>>>>
>>>>> Amy Kang-3 wrote:
>>>>>
>>>>>> A message sent to client can be removed by broker under conditions,
>>>>>> e.g. message expired, destination limit reached with REMOVE_OLDEST
>>>>>> behavior, remote message rerouted due to consumer closing .. When
>>>>>> that
>>>>>> happens, the following JMSException simply instructs the transaction
>>>>>> manager to rollback the transaction, which is expected. Please check
>>>>>> the broker log to see any log message indicates reason for the message
>>>>>> removal.
>>>>>>
>>>>>> The broker exception can also occur if the client side was
>>>>>> concurrently
>>>>>> using a XA session. Which GlassFish version/build# are you using ?
>>>>>> What is the version shown at beginning of MQ broker log ? Are you
>>>>>> using
>>>>>> GlassFish or MQ cluster or single instance ?
>>>>>>
>>>>>> amy
>>>>>>
>>>>>> On 08/10/2010 04:32 AM, saikiranp wrote:
>>>>>>
>>>>>>> We have been getting JMS exceptions and we are in the process of
>>>>>>> finding
>>>>>>> the
>>>>>>> root cause for this issue.
>>>>>>>
>>>>>>> From the server.log, we observed that there were logs regarding the
>>>>>>> MDB
>>>>>>> invocation errors.
>>>>>>>
>>>>>>> [#|2010-07-23T01:54:41.731+0200|INFO|sun-glassfish-comms-server1.5|javax.enterprise.system.container.ejb.mdb|_ThreadID=385;_ThreadName
>>>>>>> =p: thread-pool-1; w:
>>>>>>> 60;backend-ear-0.0.0.1-SNAPSHOT:MessageProcessor;javax.ejb.EJBException:
>>>>>>> Transaction aborted; nested exception
>>>>>>> is: javax.transaction.RollbackException;|MDB00037:
>>>>>>> [backend-ear-0.0.0.1-SNAPSHOT:MessageProcessor]: Message-driven bean
>>>>>>> invocation ex
>>>>>>> ception: [javax.ejb.EJBException: Transaction aborted; nested
>>>>>>> exception
>>>>>>> is:
>>>>>>> javax.transaction.RollbackException]|#]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> We suspected that the broker was removing the messages even before
>>>>>>> the
>>>>>>> acknowledgement is received from the MDB due to the TTL being set for
>>>>>>> some
>>>>>>> types of messages. Hence, we changed the TTL value to 0. However,
>>>>>>> even
>>>>>>> after
>>>>>>> making the TTL to 0, we still see that the exceptions are still being
>>>>>>> thrown
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [#|2010-08-05T11:10:34.136+0200|WARNING|sun-glassfish-comms-server1.5|javax.jms|_ThreadID=435;_ThreadName=p:
>>>>>>> thread-pool-1; w:
>>>>>>> 109;_RequestID=c71cd362-db29-413b-bcd0-ffeb7a864865;|[I500]: Caught
>>>>>>> JVM
>>>>>>> Exception: com.sun.messaging.jms.JMSException:
>>>>>>> [ACKNOWLEDGE_REPLY(25)]
>>>>>>> [C4036]: A broker error occurred. :[409] [B1290]: Transaction
>>>>>>> acknowledgement could not be processed because message
>>>>>>> 2720528-192.168.0.4(c7:69:53:86:9e:d4)-59781-1280998929518[[consumer:2274927222597296128,
>>>>>>> type=NONE]:[consumer:0,
>>>>>>> type=CLIENT_ACKNOWLEDGE]]TUID=2274927222650419200
>>>>>>> reference is gone user=guest, broker=localhost:37676(43191)|#]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [#|2010-08-05T11:10:34.136+0200|WARNING|sun-glassfish-comms-server1.5|javax.enterprise.system.stream.err|_ThreadID=435;_ThreadName=p:
>>>>>>> thread-pool-1; w:
>>>>>>> 109;_RequestID=c71cd362-db29-413b-bcd0-ffeb7a864865;|
>>>>>>>
>>>>>>> MQRA:OMR:run:JMSException on message acknowledgement:Rolling back if
>>>>>>> in
>>>>>>> txn|#]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> [#|2010-08-05T11:10:34.137+0200|WARNING|sun-glassfish-comms-server1.5|javax.enterprise.system.stream.err|_ThreadID=435;_ThreadName=p:
>>>>>>> thread-pool-1; w:
>>>>>>> 109;_RequestID=c71cd362-db29-413b-bcd0-ffeb7a864865;|
>>>>>>>
>>>>>>> com.sun.messaging.jms.JMSException: [ACKNOWLEDGE_REPLY(25)] [C4036]:
>>>>>>> A
>>>>>>> broker error occurred. :[409] [B1290]: Transaction acknowledgement
>>>>>>> could
>>>>>>> not
>>>>>>> be processed because message
>>>>>>> 2720528-192.168.0.4(c7:69:53:86:9e:d4)-59781-1280998929518[[consumer:2274927222597296128,
>>>>>>> type=NONE]:[consumer:0,
>>>>>>> type=CLIENT_ACKNOWLEDGE]]TUID=2274927222650419200
>>>>>>> reference is gone user=guest, broker=localhost:37676(43191)
>>>>>>>
>>>>>>> at
>>>>>>> com.sun.messaging.jmq.jmsclient.ProtocolHandler.throwServerErrorException(ProtocolHandler.java:4019)
>>>>>>>
>>>>>>> at
>>>>>>> com.sun.messaging.jmq.jmsclient.ProtocolHandler.acknowledge(ProtocolHandler.java:2607)
>>>>>>>
>>>>>>> at
>>>>>>> com.sun.messaging.jmq.jmsclient.SessionImpl.doAcknowledge(SessionImpl.java:1442)
>>>>>>>
>>>>>>> at
>>>>>>> com.sun.messaging.jmq.jmsclient.SessionImpl.acknowledgeFromRAEndpoint(SessionImpl.java:1097)
>>>>>>>
>>>>>>> at
>>>>>>> com.sun.messaging.jms.ra.OnMessageRunner.run(OnMessageRunner.java:267)
>>>>>>>
>>>>>>> at
>>>>>>> com.sun.enterprise.connectors.work.OneWork.doWork(OneWork.java:76)
>>>>>>>
>>>>>>> at
>>>>>>> com.sun.corba.ee.impl.orbutil.threadpool.ThreadPoolImpl$WorkerThread.run(ThreadPoolImpl.java:555)
>>>>>>>
>>>>>>> Caused by: com.sun.messaging.jms.JMSException:
>>>>>>> [ACKNOWLEDGE_REPLY(25)]
>>>>>>> [C4036]: A broker error occurred. :[409] [B1290]: Transaction
>>>>>>> acknowledgement could not be processed because message
>>>>>>> 2720528-192.168.0.4(c7:69:53:86:9e:d4)-59781-1280998929518[[consumer:2274927222597296128,
>>>>>>> type=NONE]:[consumer:0,
>>>>>>> type=CLIENT_ACKNOWLEDGE]]TUID=2274927222650419200
>>>>>>> reference is gone user=guest, broker=localhost:37676(43191)
>>>>>>>
>>>>>>> at
>>>>>>> com.sun.messaging.jmq.jmsclient.ProtocolHandler.throwServerErrorException(ProtocolHandler.java:4003)
>>>>>>>
>>>>>>> ... 6 more
>>>>>>>
>>>>>>> |#]
>>>>>>>
>>>>>>> Can anybody give me some information on the root cause of this issue?
>>>>>>>
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>>
>>
>