I am ready and prepared to be either the maintainer or a co-maintainer of AnyEvent::STOMP. If (on PAUSE) you can transfer or abandon maintainer-ship of the module, or add me as a co-maintainer, I would appreciate it.
Fulko On Thu, Jan 9, 2014 at 2:58 PM, Michael S. Fischer <mich...@dynamine.net>wrote: > Hi Fulko, > > I no longer actively maintain AnyEvent::STOMP (and haven't touched it on > > 2 years) so I'm not in a position anymore to evaluate or test any patches. > > However, I'm willing to delegate authorship and maintenance to someone who > will take good care of it. Are you interested? > > Thanks, > > --Michael > > > On Thu, Jan 9, 2014 at 11:48 AM, Fulko Hew <fulko....@gmail.com> wrote: > >> >> Thanks for writing AnyEvent::STOMP... but... >> >> -------------- >> Attached is an enhanced version I'd like you to package up and distribute >> (so my people can download a 'released' package)... here's why: >> >> While moving someone else's code from Net::STOMP to AnyEvent::STOMP >> I encountered a problem with the ActiveMQ environment they were >> interacting with. It turns out that AnyEvent::STOMP _always_ >> provides a 'content-length' header, but, the presence of that header >> determines/changes how ActiveMQ formats messages sent to JMS based >> systems. >> >> See the section: 'Working with JMS Text/Bytes Messages and Stomp' >> in: http://activemq.apache.org/stomp.html >> >> So (just like Net::STOMP) we need a mechanism to disable the >> transmission of that header. There are 4 changes in this >> new version: >> >> 1/ The module's version #. >> 2/ Added POD (basically stolen from Net::STOMP) for the new feature. >> 3/ Code to add/omit the 'content-type' header. >> 4/ Refactor of the sprintf to account for the 'no headers' situation. >> -------------- >> >> Now a question... >> >> -------------- >> While testing, I noticed that my (TCP) connections were not being closed. >> ie. when (I thought) $client was going out of scope. >> >> What I noticed was that your DESTROY was never being invoked. >> Something keeps the object from going out of scope ??? >> >> So I tried calling $client->DESTROY; manually, just like if the object >> _were_ >> to go out of scope. Then you get your 'Missing destination' warning >> message. >> So I'd say your 'destroy' stuff doesn't work right. >> >> And there may be a memory leak issue that prevents $client from going out >> of scope, preventing DESTROY from being called... preventing the STOMP >> connection from being closed and the TCP connection from being closed. >> >> Currently I explicitly do a $client->{handle}->destroy so that its >> AnyEvent::Handle is shutdown. >> -------------- >> >> Fulko >> >> >> >
