Re: Connection Refused from ActiveMQConnectionFactory

[Neduz <na...@neduz.be>]

Hello,

I've tried adding 



As first blueprint item in the blueprint xml file as this services provided
by the bundle from mvn:org.apache.activemq/activemq-osgi/5.8.0

But that doesn't resolve the problem apparently.




And the Broker is only ready about 1.1s later:


Did I correctly implement your suggestion? I've added the filter option
because file-installer also provides an ManagedServiceFactory. And the
availability and activation options I added assuming they would prevent
blueprint from just making proxies before the service is actually available.

At every Karaf start another bundle or bundles fail to start due to the
connection refused message. Sometimes (about 1 in 4 or 1 in 5 times) all
bundles start perfectly.

PS: I agree that using the "waiting" for an OSGI service to be available is
the best approach for a mixed blueprint/spring-beans environment; but was
the Blueprint method for creating a broker deliberately dropped? If yes for
what reason(s)?

Kind regards,

Tom Mercelis



--
View this message in context: http://activemq.2283324.n4.nabble.com/Connection-Refused-from-ActiveMQConnectionFactory-tp4664195p4664342.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Connection Refused from ActiveMQConnectionFactory

[Neduz <na...@neduz.be>]

Hello,

Maybe the user forum is not the recommended place for this discussion: but
besides the blueprint xml discussion; there's another "design" question that
I'm not sure of how it is seen by the AMQ devs at this moment:

I'll be making a few assumptions since I'm not very experienced with
ActiveMQ or Karaf or Blueprint:
1) The default contract of ConnectionFactory is that it can throw exceptions
if the JMS broker is not immediately available for some reason (that's at
least the behavior I'm seeing).
2) The creation of the instances of ActiveMQConnectionFactory &
PooledConnectionFactory is in my example done with Blueprint, but it could
as well be written POJO classes, in any OSGi or JEE container. So the design
is very all-purpose.

The solutions we were currently discussing are all based on the Broker and
the Client being in the same OSGI/Spring/Blueprint context, but that may not
always be true. Wouldn't it be useful to have an option in the
(Pooled)ActiveMQConnectionFactory that there's a blocking start-method that
blocks until the connection with the broker(url) is established. This would
allow the "default" behavior of OSGI to be used:
The (pooled)connectionfactory is offered as a Service, and giving it a
blocking start/init-method that retries until success or some configurable
limit is reached (time/attempts/...) would delay the start of all bundles
consuming the javax.jms.ConnectionFactory Service until the broker is really
available (whether this in in the same runtime or anywhere else on the
network).

I can implement this try/retry strategy in the init-method of all my
blueprint bundles; but I think it would be a good addition to have this
functionality in AMQ.

Kind regards,

Tom Mercelis



--
View this message in context: http://activemq.2283324.n4.nabble.com/Connection-Refused-from-ActiveMQConnectionFactory-tp4664195p4664390.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Re: Connection Refused from ActiveMQConnectionFactory

[Gary Tully <ga...@gmail.com>]

The service factory that auto creates the broker based on
etc/org.apache.activemq.server-default.cfg only supports spring xml at the
moment, the injection of properties into a blueprint context that
is explicitly created by the ManagedServiceFactory needs to be in
investigated some more to have is support blueprint in the same way.
Please create an enhancement to track this, because it is something we
should do for the next release.

But the old way of deploying a blueprint xml that contains a broker is
still possible, just drop the blueprint xml into the deploy directory or
add it to your bundle and it will be get initialised.
What has been dropped are the karaf commands that do the copy into the
deploy directory for you.
Using a managed service factory and external properties that can be visible
via config admin provides a more consistent karaf experience.


On 4 March 2013 13:11, Neduz <na...@neduz.be> wrote:

> Hello,
>
> I've tried adding
>
>
>
> As first blueprint item in the blueprint xml file as this services provided
> by the bundle from mvn:org.apache.activemq/activemq-osgi/5.8.0
>
> But that doesn't resolve the problem apparently.
>
>
>
>
> And the Broker is only ready about 1.1s later:
>
>
> Did I correctly implement your suggestion? I've added the filter option
> because file-installer also provides an ManagedServiceFactory. And the
> availability and activation options I added assuming they would prevent
> blueprint from just making proxies before the service is actually
> available.
>
> At every Karaf start another bundle or bundles fail to start due to the
> connection refused message. Sometimes (about 1 in 4 or 1 in 5 times) all
> bundles start perfectly.
>
> PS: I agree that using the "waiting" for an OSGI service to be available is
> the best approach for a mixed blueprint/spring-beans environment; but was
> the Blueprint method for creating a broker deliberately dropped? If yes for
> what reason(s)?
>
> Kind regards,
>
> Tom Mercelis
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Connection-Refused-from-ActiveMQConnectionFactory-tp4664195p4664342.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>



-- 
http://redhat.com
http://blog.garytully.com