[jira] Issue Comment Edited: (AMQNET-138) Unable to select STOMP protocol

["Allan Schrum (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/activemq/browse/AMQNET-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=49152#action_49152 ] 

aschrum edited comment on AMQNET-138 at 2/5/09 11:56 AM:
--------------------------------------------------------------

When doing failover transport, I had to create TransportFactory(s) for some of the protocols that were supported. This created a need for TransportFactory.cs which has AddTransportFactory() to support all known factories. Unfortunately, Stomp (in C#) does not have a TransportFactory so it cannot be included given the current structure. Checking the Java sources, it seems that Stomp derives from TcpTransport and did have a factory. In the C# version, there is no factory, thus it is not included in the AddTransportFactory() method, which implies that it is not supported and which supports the above error messages.

If we continue in the direction of using factories for each of the transport types, then we need a Stomp factory and the associated entry added to AddTransportFactory() of TransportFactory.cs.

Before the failover code all Connections created a TcpTransport() which meant that we did not need the TransportFactory(). The code in the TcpTransport detects the Stomp protocol and continues on. In effect, "stomp" is an alias for "tcp". This suggests one of two ways to either fix or work-around this issue:

1. In TransportFactory.cs (near line 51) add a case clause for "stomp" that falls into the case for "tcp" and let the TcpTransportFactory() handle the Stomp protocol (much as it used to).
2. Create a StompTransportFactory() that derives from TcpTransportFactory() and add the appropriate entry into TransportFactory.cs (near line 51) to handle the new transport factory for Stomp.

For testing purposes (to validate that this will work) try approach #1 as a work-around (it is simple and easy to test with minimal changes). If that works, then I would suggest fixing this problem using approach #2. The second approach is moving towards a TransportFactory() concept which is now the common direction.

At the moment I have no easy way to test this, so I leave that to the group. Please report results.


      was (Author: aschrum):
    When doing failover transport, I had to create TransportFactory(s) for some of the protocols that were supported. This created a need for TransportFactory.cs which has AddTransportFactory() to support all known factories. Unfortunately, Stomp (in C#) does not have a TransportFactory so it cannot be included given the current structure. Checking the Java sources, it seems that Stomp derives from TcpTransport and did have a factory. In the C# version, there is no factory, thus it is not included in the AddTransportFactory() method, which implies that it is not supported and which supports the above error messages.

If we continue in the direction of using factories for each of the transport types, then we need a Stomp factory and the associated entry added to AddTransportFactory() of TransportFactory.cs. I would suggest that direction if possible.
  
> Unable to select STOMP protocol
> -------------------------------
>
>                 Key: AMQNET-138
>                 URL: https://issues.apache.org/activemq/browse/AMQNET-138
>             Project: ActiveMQ .Net
>          Issue Type: Bug
>          Components: ActiveMQ Client
>    Affects Versions: 1.1
>            Reporter: Jim Gomes
>            Assignee: Jim Gomes
>             Fix For: 1.1
>
>
> User reported issue with using the STOMP protocol due to recent changes made to NMS.  See the following Nabble conversation for details:
> http://www.nabble.com/Changes-to-C--client-in-5.2---Can%27t-connect-via-STOMP...-td21549608.html
> When we went to actually connect to our server (stomp://192.168.0.1:61616 or whatnot, same as always), we get the following errors:
> 19/01/2009 1:36:08 PM WRN Transmitter.Setup:: The transport stomp is not supported.
>    at Apache.NMS.ActiveMQ.Transport.TransportFactory.AddTransportFactory(String scheme)
>    at Apache.NMS.ActiveMQ.Transport.TransportFactory.findTransportFactory(Uri location)
>    at Apache.NMS.ActiveMQ.ConnectionFactory.CreateConnection(String userName, String password)
>    at FAInterface.Transmitter.Setup_R()
> This seems to be a client code issue as if we use our old DLL we can connect to both 4.1 and 5.2 brokers.  What are we missing? 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.