AMQ 5.15.3 and camel bridging for dataservices 4.2

[kpar]

Hi, We have installed activemq and camel for Dataservices 4.2, setup
real-time jobs within dataservices (JMS config), when we send 10 of the same
messages the 1st 5 are processing and then the rest fail. We get the
following error com.acta.adapter.sdk.RecoverableOperationAdapterException:
JMS GET operation error: Timed out. Unable to receive response from the
invoked Data Services service. Adapter operation will continue.

I have also raised this with SAP. Is there a keepalive setting we can use to
prevent this connection to timeout.

Is anyone using AMQ/Camel for Dataservices real-time jobs?

Thanks



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: ActiveMQ transport error when I do a telnet check on the port

[Tim Bain]

Great, thanks for sharing the solution that worked for you.

Tim

On Mon, Apr 9, 2018, 6:01 AM jroel  wrote:

> Hello,
>
> We 've resolved this issue with a custom bash script involving the
> following
> command "nmap -sS -p PORT IPADDRESS" instead of the telnet variant.
>
> This command does not cause the errors in the logging.
>
>
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>

Re: Shared File System Master Slave

[Tim Bain]

Yes, that information is applicable and gives a good overview of the
internals of KahaDB.

Tim

On Mon, Apr 9, 2018, 1:29 AM norinos  wrote:

> I found the following site. Is this helpful for me?
>
> http://www.idevnews.com/images/emailers/110127_ProgressFUSE/WhitePapers/ActiveMQinActionCH05.pdf
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>

Re: Replicated Message Store for ActiveMQ

[Justin Bertram]

ActiveMQ Artemis fully implements the JMS specification so any client using
JMS (e.g. Apache Camel) should work without issues. For what it's worth,
Artemis ships with an example [1] using Apache Camel for bridging messages
between a 5.x broker instance and an Artemis instance.

The ActiveMQ 5.x has a lot of features, some of which are commonly used and
some of which aren't. The goal isn't 100% feature parity, but feature
parity where it makes sense. I believe most of the big use-cases are
covered. If you could clarify your particular use case(s) then I could
provide a more specific answer.

I don't understand what you mean by "durability of Artemis."  Can you
elaborate on this question?


Justin

[1]
https://github.com/apache/activemq-artemis/tree/master/examples/features/sub-modules/inter-broker-bridge/artemis-jms-bridge#5x-to-artemis-camel-jms-bridge

On Mon, Apr 9, 2018 at 12:14 AM, SubashKunjupillai 
wrote:

> Hi Tim,
>
> Thanks for your suggestions.
>
> Saying that, moving to ActiveMQ Artemis would be the ideal option. I'm also
> not sure whether all the features being used by us (camel routes are used
> to
> produce and consume JMS messages) with ActiveMQ 5.14.4 will be available in
> ActiveMQ Artemis 2.5.0.
>
> From community perspective can some one comment on the feature
> compatibility
> and durability of Artemis?
>
> Regards,
> Subash Kunjupillai
>
>
>
> -
> Subash Kunjupillai
> --
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-
> f2341805.html
>

Re: ActiveMQ transport error when I do a telnet check on the port

[jroel]

Hello,

We 've resolved this issue with a custom bash script involving the following
command "nmap -sS -p PORT IPADDRESS" instead of the telnet variant.

This command does not cause the errors in the logging.





--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html

Re: Shared File System Master Slave

[norinos]

Hi Tim ! thanks a lot.


> The documentation you linked to is for the AMQ message store, not the 
> KahaDB message store. So if you're using KahaDB as you say, then the page 
> you linked to is irrelevant. 

I finally understood that AMQ and KahaDB are different.

> KahaDB behaves as I described. You only risk losing messages that have not 
> yet been accepted (i.e. you don't risk losing anything). If I recall 
> correctly, the only thing that's flushed to disk periodically is the
> index, 
> and that can be rebuilt from the raw journal files so there's no risk of 
> data loss, just a slower broker startup. 

I feel relieved that it seems there is no risk.


I found the following site. Is this helpful for me?
http://www.idevnews.com/images/emailers/110127_ProgressFUSE/WhitePapers/ActiveMQinActionCH05.pdf





--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html