David,
Thanks detailed reply.
Comments is inline.
Best Regards
Tang
David Zhao wrote:
> Comments is inline.
>
> Thanks,
> David Zhao
>
>
>> -----Original Message-----
>> From: Tang Yong [mailto:tangyong_at_cn.fujitsu.com]
>> Sent: Thursday, December 19, 2013 10:45 AM
>> To: David Zhao
>> Cc: Sanjeeb Sahoo; John Wells; dev_at_glassfish.java.net
>> Subject: Re: About GLASSFISH-20934
>>
>> David,
>>
>> I have another thing and want to discuss with you:
>>
>> in jms core, only ActiveJmsResourceAdapter class extends
>> ActiveInboundResourceAdapterImpl class and depeneds on
>> org.glassfish.main.connectors.inbound-runtime module.
>>
>> 1) considering in the future whether using interface or composite
>> rather than "extends"?
> [David Zhao] What is the purpose of replacing "extends" with "implements"? Can this solve "this issue" you mentioned? Generally, JMS ActiveJmsResourceAdapter should be both ActiveOutboundResourceAdapter and ActiveInboundResourceAdapter, which is required by Connector. Comparing to implementing, extending can simplify things that JMS doesn't need to be changed for any methods which it doesn't care, even for the future interface changes.
1. What is the purpose of replacing "extends" with "implements"?
Or exactly speaking, using similar @Service way of composition.
The purpose is for better modularation rather than depending on module's
implementation(onnectors inbound implementation). Here, although I am
not an expert of Connector, I have a feeling: after seeing
ActiveJmsResourceAdapter's source, Connector module(whether for inbound
or for outbound) should offer a general behavior by some way(eg.
@Service), then, in ActiveJmsResourceAdapter, injecting these services
by interface to simplify things. At this point,I absolutely agree with
you that "simplify things that JMS doesn't need to be changed for any
methods which it doesn't care".
2.Can this solve "this issue" you mentioned?
For this issue, simply saying:
A Thread:
starting org.glassfish.main.connectors.inbound-runtime module
B Thread:
starting org.glassfish.main.jms.core --> resolving
org.glassfish.main.connectors.inbound-runtime
So, if A Thread and B Thread are in cross running while system is in
heavy load state, then, felix runtime will throw the exception(
"org.osgi.framework.BundleException: Unable to acquire global lock for
resolve") and org.glassfish.main.connectors.inbound-runtime module
started failed.
Well, if decouping org.glassfish.main.jms.core with
org.glassfish.main.connectors.inbound-runtime, then, while kernel is
starting, the issue will not happen.
>> 2) an interesting thing is that once jms core do not depened on
>> org.glassfish.main.connectors.inbound-runtime, this issue will not
>> happen. Of course, this is not issue's nature. :)
> [David Zhao] What do you mean "jms core depends on org.glassfish.main.connectors.inbound-runtime"? Extending ActiveInboundResourceAdapterImpl or having the dependency in pom? What is "this issue"? Your observation is interesting, which might needs further investigation.
apart from what I commented on 1), from pom, you can also see the following:
<dependency>
<groupId>org.glassfish.main.connectors</groupId>
<artifactId>connectors-inbound-runtime</artifactId>
<version>${project.version}</version>
</dependency>
Finally, I must say this is only a solution for the issue, and not the
issue's nature. What I found is some *side effect*. about true fixing ,
pl. seeing my patch in the jira if you are interested in it.
>> Thanks
>> Tang
>>
>> David Zhao wrote:
>>> Hi Tang,
>>>
>>> JmsProviderLifecycle depends on ActiveJmsResourceAdapter, and
>> ActiveJmsResourceAdapter depends on JMXStartupService. Because
>> JMXStartupService is in PostStartupRunLevel, I am afraid of that
>> promoting JmsProviderLifecycle to be StartupRunLevel is not feasible.
>>> Thanks,
>>> David Zhao
>>>
>>>> -----Original Message-----
>>>> From: Tang Yong [mailto:tangyong_at_cn.fujitsu.com]
>>>> Sent: Wednesday, December 18, 2013 5:23 PM
>>>> To: dev_at_glassfish.java.net
>>>> Cc: Sahoo; John Wells
>>>> Subject: About GLASSFISH-20934
>>>>
>>>> JMS)Leader
>>>> CC: Sahoo
>>>>
>>>> pl. allowing me open a new thread for GLASSFISH-20934.
>>>>
>>>> Firstly, I request you can see the issue. if having any issue, pl.
>>>> tell me and I will re-check my description.
>>>>
>>>> Secondly, about fixing way, I have a very simple method as following:
>>>>
>>>> [original definition]
>>>> @Service
>>>> @RunLevel(value=PostStartupRunLevel.VAL,
>>>> mode=RunLevel.RUNLEVEL_MODE_NON_VALIDATING)
>>>> public class JmsProviderLifecycle implements PostConstruct{ ...
>>>> }
>>>>
>>>> [my fixing way]
>>>> @Service
>>>> @RunLevel(value=StartupRunLevel.VAL,
>>>> mode=RunLevel.RUNLEVEL_MODE_NON_VALIDATING)
>>>> public class JmsProviderLifecycle implements PostConstruct{ ...
>>>> }
>>>>
>>>>
>>>> That is to say, making org.glassfish.main.jms.core can be started
>>>> earlier. Because this is also related to kernel starting, cc Sahoo
>>>> for evaluation.
>>>>
>>>> Thanks
>>>> Tang
>>>> --
>>>> －－－－－－－－－－－－－－－－－－－－－－
>>>> Tang Yong
>>>> Senior Engineer
>>>> GlassFish Committer (OSGi & OSGi-JavaEE) OSGi Alliance Supporter
>>>> Blog: http://osgizone.typepad.com/tangyong/
>>>>
>>>> Nanjing Fujitsu NanDa Software Tec CO.,LTD
>>>> http://www.fujitsu.com/cn/fnst
>>>> Tel: +86-25-86630566-8310
>>>> Fax: +86-25-83317685
>>>> －－－－－－－－－－－－－－－－－－－－－－
>>>>
>>>>
>>>
>> --
>> －－－－－－－－－－－－－－－－－－－－－－
>> Tang Yong
>> Senior Engineer
>> GlassFish Committer (OSGi & OSGi-JavaEE) OSGi Alliance Supporter
>> Blog: http://osgizone.typepad.com/tangyong/
>>
>> Nanjing Fujitsu NanDa Software Tec CO.,LTD
>> http://www.fujitsu.com/cn/fnst
>> Tel: +86-25-86630566-8310
>> Fax: +86-25-83317685
>> －－－－－－－－－－－－－－－－－－－－－－
>>
>
>
--
－－－－－－－－－－－－－－－－－－－－－－
Tang Yong
Senior Engineer
GlassFish Committer (OSGi & OSGi-JavaEE)
OSGi Alliance Supporter
Blog: http://osgizone.typepad.com/tangyong/
Nanjing Fujitsu NanDa Software Tec CO.,LTD
http://www.fujitsu.com/cn/fnst
Tel: +86-25-86630566-8310
Fax: +86-25-83317685
－－－－－－－－－－－－－－－－－－－－－－