Matthew Monson wrote:
Just an update,
I tested the problem on a LAN using the client example:
java javaclients.HelloWorldSubscribe - session.name
<http://session.name/> client/joe/session/1
-dispatch/callback/retries -1 -plugin/socket/hostname 192.168.0.3
<http://192.168.0.3>
connecting to a default server setup with no xmlBlaster.properties file:
java -jar lib/xmlBlaster.jar
I pulled out the network cable and plugged it back in, reconnected
successfully.
I then pulled out the network cable and changed my IP address and
plugged it
back in and the client could NOT reconnect to the server, still
nothing appearing
on the server logs.
I then pulled the cable out and changed my IP address back to what it was
plugged it back in and the client reconnected successfully.
Bug?
Thanks for this details, that is exactly what i suspected.
I'll have a look at this a.s.a.p,
regards
Marcel
On 11/29/06, *Marcel Ruff* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
Brad Clements wrote:
> On 29 Nov 2006 at 14:28, Marcel Ruff wrote:
>
>
>> Ok,
>>
>> thanks for the details!
>>
>> I will try the case of changing client side IP address with a
java client
>> as soon as i find time for it and come back to this issue,
>>
>
> When using the socket protocol, why does a subscribe need to
specify the client's
> IP address in the callback specification?
>
> I thought the socket protocol ignored the callback IP, even
though it's required..
>
> If it's not ignored, would it be reasonable for the socket
protocol to specify 0.0.0.0 <http://0.0.0.0>
> as the IP (any port #) which means "send callbacks to my current
end-point"
>
Yes, the callback address is simply ignored on server side, as we
tunnel
the response back
in the same socket.
It could be useful when we want to force the server to open a separate
connection
for callbacks (similar to XMLRPC etc.) but this feature was never
implemented.
Marcel