Hi Tang,
I've also noticed that the deployment of groovy-all bundles is really a
bottleneck. I haven't analyzed in depth why this is the case but I think
there are multiple full artifact scans on the way at deployment time
down to the level of annotation scanning for each and every class.
As the groovy-all 1.8.6 bundle contains 3715 classes it could take a while.
Also I think the process of scanning an artifact is not (yet)
parallelized, which also doesn't help the overall deployment time.
Also, GLASSFISH-16560 comes to my mind here.
The reason for the shell to be not responsive during deployment time is
that (AFAIK) it is a single synchronous call to the server. I think this
can only be improved by making the client communication session-aware
and using an asynchronous approach, so that we could also start multiple
deployments in parallel. But the latter has to be supported by the
server as well, which I think currently is not the case with OSGi.
@Sahoo: please correct me if I am wrong at this.
Cheers,
Ancoron
On 02/23/2013 10:42 AM, Tang Yong wrote:
>> In addition, deploying groovy-all-1.8.6 bundle[2] is very slow and even
>
> [2]:
> http://repo1.maven.org/maven2/org/codehaus/groovy/groovy-all/1.8.6/groovy-all-1.8.6.jar
>
> Tang
>
> Tang Yong wrote:
>> In addition, deploying groovy-all-1.8.6 bundle[2] is very slow and even
>> hangs, and noticing that during the hanging state, in felix-cache and
>> domain1/application, some deployed directories and files can be
>> generated, however, cmd shell is in hanging state.
>>
>> Thanks
>> --Tang
>>
>> Tang Yong wrote:
>>> Hi Sahoo, Hong
>>>
>>> I have a question about deployment as following:
>>>
>>> Today, I tried vaadin(https://vaadin.com/) related to GLASSFISH-18381.
>>>
>>> To reproduce GLASSFISH-18381, first, needing to deploy vaadin bundle[1].
>>>
>>> [1]: http://repo1.maven.org/maven2/com/vaadin/vaadin/6.7.5/vaadin-6.7.5.jar
>>>
>>> So, I tried to execute the following command:
>>>
>>> asadmin deploy --type=osgi vaadin-6.7.5.jar
>>>
>>> Although deploying is successfully, in the whole deployment process
>>> there are two unacceptable issues for an user:
>>>
>>> 1) command shell is in hanging state for long time
>>> 2) the whole deployment time is 188,032 milliseconds(for my env)
>>>
>>> In the server.log, there are the following info:
>>>
>>> [#|2013-02-23T18:08:50.640+0900|INFO|glassfish
>>> 4.0|javax.enterprise.logging.stdout|_ThreadID=82;_ThreadName=admin-listener(1);_TimeMillis=1361610530640;_LevelValue=800;|Installed
>>> com.vaadin [286] from
>>> reference:file:/D:/20130125/glassfish4/glassfish/domains/domain1/applications/vaadin-6.7.5/|#]
>>>
>>> [#|2013-02-23T18:08:50.671+0900|INFO|glassfish
>>> 4.0|javax.enterprise.logging.stdout|_ThreadID=82;_ThreadName=admin-listener(1);_TimeMillis=1361610530671;_LevelValue=800;|Started
>>> com.vaadin [286]|#]
>>>
>>> [#|2013-02-23T18:08:50.750+0900|INFO|glassfish
>>> 4.0|javax.enterprise.system.core|_ThreadID=82;_ThreadName=admin-listener(1);_TimeMillis=1361610530750;_LevelValue=800;|vaadin-6.7.5
>>> was successfully deployed in 188,032 milliseconds.|#]
>>>
>>> So, I ask you to confirm whether the same with me. Normal state should
>>> be that deployment process should be fast for such an artifact.
>>>
>>> Thanks
>>> --Tang
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>