Looks like you've done some good debugging here... I am afraid I can't help you on this, as the error *seems* to come from the inner driver level. It may worth a try to post your information to the RxTx list - just make sure you separate it from the SMSLib lib. Maybe the guys over there have heard about similar cases.
On Sep 10, 4:58 pm, ravindra <[email protected]> wrote: > Thanks for the reply Thanasis, > > I have tested on linux configuring the switches, nothing works.I > think the problem is in RXTXComm.jar > particularly on linux.What i observed is, the following two methods > utilizing most of the CPU, even when there is no messages activity on > modem.These things i observed using Java VisualVM. > > gnu.io.RXTXPort.sendEvent(int,boolean) -- takes 70% cpu time > org.smslib.helper.SerialPortEvent.getEventType() --- takes 30% cpu > time > > One more thing is, I deploy and undeploy my application some > times.In linux even i undeploy application and redeploy it is > failing , and getting **PortInUseException**.I had to restart my > server to start application smoothly. > > I think the gnu.io.RXTXPort.sendEvent(int,boolean) is not releasing > the port at all,using continuously. > This may be the cause? > > Any Clues? > > On Sep 10, 12:35 am, Thanasis <[email protected]> wrote: > > > > > I assume that the only thing that could lead to such a behavior is > > some problem with the comm port. > > > The only switches that could make a difference is the "- > > Dsmslib.serial.polling" (which you already tried) and the "- > > Dsmslib.nocmti". All others should *not* have any effect at all for > > your problem. > > > If possible, try to get another phone or modem to test for a couple of > > hours... > > > On Sep 9, 4:21 pm, ravindra <[email protected]> wrote: > > > > Hi, > > > > > like you. Its obvious that it has something to do with the serial comm > > > > but I don't know what... > > > > you mean, is it problem with comm.jar library? or the serial gsm > > > modem that I am using? > > > > I am using two modems with same model,I never tried a diiferent model. > > > > And I tried "-Dsmslib.serial.polling" and other parameters like "- > > > Dsmslib.serial.pollinginterval","-Dsmslib.serial.keepalive=nnn","- > > > Dsmsib.watchdog=nnn" .It does't work still one modem is using 50% CPU. > > > I have to tweak these parameters and check the performance on linux. > > > > As I already have the SMSLib project setup , I also tried > > > changing the SMSServer.conf smsserver.balancer to below one and > > > rebuild the jar.There is no improvement in performance. > > > # Set a different balancer than the default. > > > smsserver.balancer=LoadBalancer > > > > Any suggestions to fix this problem really helpful. > > > > Thank you, > > > Ravindra. > > > > Please > > > > On Sep 9, 1:04 pm, Thanasis <[email protected]> wrote: > > > > > Hi, > > > > > First of all, I've never heard of a similar thing. So I am searching > > > > like you. Its obvious that it has something to do with the serial comm > > > > but I don't know what... > > > > > For starters, can you use the "-Dsmslib.serial.polling" startup switch > > > > (see:http://code.google.com/p/smslib/wiki/SMSLib_Troubleshooting#Linux_and...) > > > > and see if this over-utilization thing still exists? > > > > > Are you testing with one modem/phone? Have you tried to test with some > > > > other to see if this issue still happens? > > > > > On Sep 9, 8:52 am, ravindra <[email protected]> wrote: > > > > > > Thanks for the reply, > > > > > > We are facing this issue on both O/S,windows xp and linux se5.The > > > > > modem is serial and connected to RS232 port.The processor is intel > > > > > core2 duo.We followed installation instructions on smslib site. > > > > > > For Windows xp ,copied win32com.dll to jre/bin, javax.comm.properties > > > > > to jre/lib and comm.jar to jre/lib/ext. > > > > > For Linux(SE5) copied linuxSerial.so to jre/bin, javax.comm.properties > > > > > to jre/lib and RXTXcomm.jar to jre/lib/ext (we faced some issues with > > > > > comm.jar so using RXTX). > > > > > > We run JVisual VM on linux to see where it is spending lot of time, > > > > > the more amount of time it is spending in RXTXPort > > > > > $SerialInputStream.read() method.It is just what i observed , this may > > > > > not be the root cause.One more observation is if we connect one modem > > > > > and run part of the application it uses 50% then if we start another > > > > > it will reaches 100%. > > > > > > Finally, the jdk version is 1.6.0_14, we are using 64bit jvm on linux > > > > > (Production) and 32bit on windows. > > > > > > Thanks again, > > > > > Ravindra. > > > > > > On Sep 8, 11:03 pm, Thanasis <[email protected]> wrote: > > > > > > > Hi, > > > > > > > describe your environment please: comm library, O/S, modems, > > > > > > connection (serial/usb), etc. > > > > > > > On Sep 8, 8:47 pm, ravindra <[email protected]> wrote: > > > > > > > > Hi Everybody, > > > > > > > > We are using SMSLib-3.0 to send and receive SMS message through > > > > > > > two > > > > > > > GSM devices.It is able to send and receive messages, but when we > > > > > > > run > > > > > > > our SMS application the CPU utilization is already 100%.And if we > > > > > > > try > > > > > > > to run other applications, that have to work with SMS > > > > > > > application, are > > > > > > > getting slower and some times not able to run. > > > > > > > > We are using default properties. > > > > > > > Has anyone come across with any performance related issues? > > > > > > > Answers really helpful for us. > > > > > > > > Thanks, > > > > > > > Ravindra.- Hide quoted text - > > > > > > > - Show quoted text -- Hide quoted text - > > > > > - Show quoted text -- Hide quoted text - > > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SMSLib for Java User Group" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/smslib?hl=en -~----------~----~----~----~------~----~------~--~---
