Hi Manfred,
I looked at your singleton class and noticed it contains significant
logic in its constructor, which might have caused the non-portable
behavior you are seeing. Try deleting this constructor and moving logic
to @PostConstruct method.
-cheng
On 1/27/12 2:34 AM, forums_at_java.net wrote:
> I'm using a singleton bean (@Singleton @Startup) in my application to
> implement a pool of network connections to different servers. However,
> after
> redeploying my application, this singleton bean is not thrown away. So it
> happens, that after three redeployments there are four such beans
> lingering
> around. All these beans are active, which makes things really bad in
> my case
> since every server that I contact only allows a fixed number of logins
> with
> the same username/password. One server allows e.g. five parallel
> connections.
> Having n of those beans started after a redeployment, they would try to
> establish 5*n such connections, 5*(n-1) of which will fail, so I have n-1
> "zombies" lingering around, making my application useless.
>
> My setup: GlassFish 3.1.1 (build12), JDK 1.7.0
>
> This behaviour can be seen with a very simple example, which I have
> attached.
> If you deploy it to GF, remember to copy log4j-1.2.16.jar and
> commons-logging-1.1.1.jar to <domainHome>/lib/ext.
>
> I have also attached my pom.xml (remove .txt ending, couldn't upload
> .xml),
> if you want to compile the sources using maven.
>
> I believe that this bug is somehow related
> to http://java.net/jira/browse/GLASSFISH-12368 [1], but this is an entry
> which is 1.5 years old, I believe that there are solutions out there
> already...
>
> The reason why I chose to implement my code with a singleton bean is the
> possibility to define a @PreDestroy method to logout cleanly from the
> connected servers (otherwise they wouldn't let me in next time I try to
> connect. Yes, they are picky...). Due to the described restrictions it
> is not
> possible for me to use any other kind of bean. It is quite important
> in my
> scenario that there's only one connection pool bean.
>
> Are there any other, possibly more elegant and/or more efficient
> methods to
> implement such pools of remote connections? (some are TCP, some HTTPS,
> some
> HTTP connections).
>
>
>
> Thanks for any help in advance! I greatly appreciate your input!
>
> Cheers,
>
> Manfred
>
>
> [1] http://java.net/jira/browse/GLASSFISH-12368
>
> --
>
> [Message sent by forum member 'docmani']
>
> View Post: http://forums.java.net/node/883053
>
>
>