[jira] Commented: (AMQ-952) .Net Client ConnectionFactory requires additional configurable attributes

2006-10-18 Thread james strachan (JIRA)
[ 
https://issues.apache.org/activemq/browse/AMQ-952?page=comments#action_37228 ] 

james strachan commented on AMQ-952:


So the only things left for this I think are closeTimeout and connectTimeout. 
For closeTimeout, we currently are not waiting for a receipt to come back from 
the broker when we send a ShutdownInfo - which seems fine to me. The Java 
client will do a timeout based request-response up to the closeTimeout - am not 
sure how useful that is to implement in .Net though.

For connectTimeout, in Java we set that as a property on the Socket class when 
doing a Connect() - I don't see any way to do something similar on .Net. Though 
the SendTimeout and ReceiveTimeout properties can be set via the URI notation 
of transport.socket.sendTimeout=1234 etc

> .Net Client ConnectionFactory requires additional configurable attributes
> -
>
> Key: AMQ-952
> URL: https://issues.apache.org/activemq/browse/AMQ-952
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: NMS (C# client)
>Reporter: Rob Lugt
>Priority: Minor
>
> The Java Client has a rich set of configuration options, which should also be 
> available on the .Net client.
> As a mimimum I believe we need:-
> closeTimeout
> retroactiveConsumer
> Is it also worth considering a connectTimeout property - or should this be 
> transport specific?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (AMQ-952) .Net Client ConnectionFactory requires additional configurable attributes

2006-10-18 Thread james strachan (JIRA)
[ 
https://issues.apache.org/activemq/browse/AMQ-952?page=comments#action_37227 ] 

james strachan commented on AMQ-952:


Incidentally, while looking at the Connection.Dispose(), we no longer call 
Dispose() on child sessions as they are iDisposable - by the same logic I guess 
we should no longer call transport.Dispose() too?

> .Net Client ConnectionFactory requires additional configurable attributes
> -
>
> Key: AMQ-952
> URL: https://issues.apache.org/activemq/browse/AMQ-952
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: NMS (C# client)
>Reporter: Rob Lugt
>Priority: Minor
>
> The Java Client has a rich set of configuration options, which should also be 
> available on the .Net client.
> As a mimimum I believe we need:-
> closeTimeout
> retroactiveConsumer
> Is it also worth considering a connectTimeout property - or should this be 
> transport specific?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (AMQ-952) .Net Client ConnectionFactory requires additional configurable attributes

2006-10-18 Thread james strachan (JIRA)
[ 
https://issues.apache.org/activemq/browse/AMQ-952?page=comments#action_37226 ] 

james strachan commented on AMQ-952:


I've added API  access to the various consumer related configuration options; 
so you can now do things like

ISession session = ...
session.Retroactive = true
session.CreateConsumer()... 

etc

Also you should be able to use the URI syntax currently...

new ActiveMQQueue("Foo.BAR?consumer.retroactive=true") etc



> .Net Client ConnectionFactory requires additional configurable attributes
> -
>
> Key: AMQ-952
> URL: https://issues.apache.org/activemq/browse/AMQ-952
> Project: ActiveMQ
>  Issue Type: New Feature
>  Components: NMS (C# client)
>Reporter: Rob Lugt
>Priority: Minor
>
> The Java Client has a rich set of configuration options, which should also be 
> available on the .Net client.
> As a mimimum I believe we need:-
> closeTimeout
> retroactiveConsumer
> Is it also worth considering a connectTimeout property - or should this be 
> transport specific?

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira