On 7 Maj, Saint-Martin Cécile wrote:
> I have this exception when :
> - i undeploy the bean
> - i send a message to the bean
> - i deploy the bean (nothing appends)
As described below: if you send messages here, the one's sent during
undeploy will also be delivered. If no messages are sent before you
undeploy, no messages will be sent.
The reason is that the connection is in stoped mode when the session
pool are set up. The sessions will get the messages, but will not
deliver themn until a message arrive while the connection is in start()
mode.
I consider this a bug in JBossMQ and not in the MDB container. I am
trying to reach Hiram, who is the one who wrote the JBossMQ part of
this.
//Peter
> - i undeploy the bean
>
> I try, like u made, to send message after deploying the bean (and send
> message when it wasn't deploy), but messages send when it wasn't deployed
> are defintivly lost!!
>
> We can call it a bug, no??
>
> Cécile Saint-Martin
> [EMAIL PROTECTED]
>
> On 4 Maj, Till: [EMAIL PROTECTED] wrote:
>> On 4 Maj, Saint-Martin Cécile wrote:
>>> In fact, i had already problem when un deploying MDB :
>>> 04/05/2001 15:25:35 ERROR
>>> org.jboss.logging.Log4jService.handleNotification -
>>> java.lang.NullPointerException
>>> 04/05/2001 15:25:35 INFO
>>> org.jboss.logging.Log4jService.handleNotification - Could not close
>>> JMSContainerInvoker connection:javax.jms.JMSEx
>>> ception: Cannot close properly the connection
>>>
>>
>> That's strange. Have to look into it.
>>
>> //Peter
>
> Hi, I have done som preliminary checks. I know there is one place in the
> code where a possible bug reside, but it should never be reached during
> normal execution.
>
> I have tried to reproduce your problem, but can not do it:
> (This is with 2.2.1, but should be the same with the 2.3.x)
>
> Undeploy:
> [Auto deploy] Auto undeploy of
> file:/home/pra/test/amsterdam-1.2/server/deploy/m
> db.jar
> [J2EE Deployer Default] Stopping module mdb.jar
> [Container factory]
> Undeploying:file:/home/pra/test/amsterdam-1.2/server/tmp/dep
> loy/Default/mdb.jar
> [Container factory] Stopping JMSContainerInvoker
> [Container factory] Clearing 15 from ServerSessionPool
> [Container factory] Stopping JMSContainerInvoker
> [Container factory] Clearing 15 from ServerSessionPool
> [Container factory] Stopping JMSContainerInvoker
> [Container factory] Clearing 15 from ServerSessionPool
> [Container factory] Stopping JMSContainerInvoker
> [Container factory] Clearing 15 from ServerSessionPool
> [Container factory] Stopping JMSContainerInvoker
> [Container factory] Clearing 15 from ServerSessionPool
> [Container factory] Destroying JMSContainerInvoker
> [Container factory] Destroying JMSContainerInvoker
> [Container factory] Destroying JMSContainerInvoker
> [Container factory] Destroying JMSContainerInvoker
> [Container factory] Destroying JMSContainerInvoker
> [Container factory] Undeployed application:
> file:/home/pra/test/amsterdam-1.2/se
> rver/tmp/deploy/Default/mdb.jar
> [J2EE Deployer Default] Destroying application mdb.jar
>
> Looking fine with all the beans from jbosstest.
>
> I have also done a new test with durable, and to my supprise the result
> is the following:
>
> If messages are send during the time a durable MDB is not deployed (but
> has been): when the bean is redeployed, JMS will NOT deliver the missed
> messages imediately. When new messages are sent, the missed messages
> will be sent to. The rather strange behaviour I get is that for 10
> missed messages, five will be sent with a new 10 messages batch, 5 with
> the next.
>
> This must be the implemented behaviour in JBossMQ, since the MDB part is
> totally dependant on the JMS provider.
>
> //Peter
>
>>>
>>> ----- Original Message -----
>>> From: "Saint-Martin Cécile" <[EMAIL PROTECTED]>
>>> To: <[EMAIL PROTECTED]>
>>> Sent: Friday, May 04, 2001 3:04 PM
>>> Subject: Re: [JBoss-dev] Message driven bean
>>>
>>>
>>>
>>>
>>>>The only way to take down a container is by undeploying the bean.
>>>>
>>>>To check if durable work, create your bean. Deploy it by copying it to
>>>>deploy/. Send some messages. Remove it from deploy. Send some messages.
>>>>Copy it in again. If it recives the messages sent when it was undeployed
>>>>durable work.
>>>
>>> I did that and i had a problem when i re-deployed the MDB :
>>> 04/05/2001 14:51:59 ERROR
>>> org.jboss.logging.Log4jService.handleNotification -
>>> java.rmi.RemoteException: ; nested exception is:
>>> javax.jms.JMSException: The login id has an assigned client id.
>>> That client id is already connected to the server!
>>>
>>> (I used the subscriber example)
>>>
>>> In fact, i dont' really understand how durable subscription works on
> JBoss
>>> :(
>>> Why do we need to create a user??
>>>
>
>
>
> _______________________________________________
> Jboss-development mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/jboss-development
--
Jobba hos oss: http://www.tim.se/weblab
------------------------------------------------------------
Peter Antman Technology in Media, Box 34105 100 26 Stockholm
Systems Architect WWW: http://www.tim.se
Email: [EMAIL PROTECTED] WWW: http://www.backsource.org
Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942
------------------------------------------------------------
_______________________________________________
Jboss-development mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-development
