twitter-archive / cloudhopper-smpp Goto Github PK

In ch-smpp 5.0.0 POM file there are range based version dependencies:

<properties>
    <main.java.package>com.cloudhopper.smpp</main.java.package>
    <ch-commons-util.version>[6.0.0,)</ch-commons-util.version>
    <ch-commons-charset.version>[3.0.0,)</ch-commons-charset.version>
    <ch-commons-gsm.version>[3.0.0,)</ch-commons-gsm.version>
    <netty.version>3.5.8.Final</netty.version>
  </properties>

This causes maven to re-download maven metadata for all dependencies with every build, which is very annoying and slows down the development process. Could you specify concrete versions and re-deploy to central repo please?

hello folks, I have been looking around in the documentation for cloudhopper for provisions to send long SMS using CloudHopper using UDH (Not Optional Parameters).
Does Cloudhopper have a ready client or utility that can be used to send long SMS using UDH ?

It would be great to have OSGi support.

I've just forked the cloudhopper* projects to add support myself, but found that the super pom isn't on github or at least I couldn't find it.

<parent>
    <groupId>cloudhopper</groupId>
    <artifactId>ch-maven-parent-public</artifactId>
    <version>1.0</version>
  </parent>

Can you please add this project to github? Or will you accept the maven bundle plugin definitions cluttered in each cloudhopper* pom?

The name needs to be escaped for non JMX compatible characters, like "=" ":" etc..

        // register this session as an mbean
        if (configuration.isJmxEnabled()) {
            session.registerMBean(configuration.getJmxDomain() + ":type=" + configuration.getName() + "Sessions,name=" + sessionId);
        }

I was trying out a performance test on a test client under the following condition.

1. 80 % traffic the server response to SUBMI_SM in 10 milliseconds.
2. 15 % traffic the server response to SUBMI_SM in 100 milliseconds.
3. 5 % traffic the server response to SUBMI_SM in 1000 milliseconds.

Client is sending asynchronously, but I'm having problem sending more than 200 messages a second. If I reduce the response time (submit_sm_resp) I'm able to send more messages but with the above delays I'm unable to send because the output messages fluctuates maybe per second there is no messages sent out and the other around 300 is pushed out.

I have tried the following.

1. Increased the window size (As I can see the window size is growing but the window wait time is always zero)
2. Increased submitting thread count.
3. Increased the expected session count when creating the DefaultSmppClient.

Can you tell me what I'm doing wrong and how can I improve the performance?

Thank you in advance.

It would be nice to have the jar and pom dependencies published in a maven repository.

http://maven.apache.org/guides/mini/guide-central-repository-upload.html

Hi everyone,

I've recently begun the migration of my organization's legacy messaging platform, leveraging logica smpp, onto ch-smpp. I've noticed that it appears to be missing the SubmitMultiSm pdu does not exist in the library.

According to the smpp 3.4 spec:

The maximum message length which can be specified in sm_length field (see section 5.2.21) is 254 octets. If an ESME wishes to submit a message of length greater than 254 octets, the sm_length field must be set to NULL and the message_payload optional parameter must be populated with the message length value and user data.
SMPP supports extended message lengths in the submit_sm, submit_multi, data_sm and deliver_sm PDUs.

How is SubmitMultiSm supported, for instance with UTF-16 messages?

Thanks.

dan

I'm busy building a simulator to include in a gateway application for testing purposes, using cloudhopper.

I have modified ServerMain (https://github.com/twitter/cloudhopper-smpp/blob/master/src/test/java/com/cloudhopper/smpp/demo/ServerMain.java) to set a UUID in the MessageId, and would now like to schedule an async DeliveryReceipt. I'm struggling with this, if you have advice I'd much appreciate it.

I used the library to build an smpp server. However when I want to send an asynchronous pdu to the connected esme it hangs the server

I've noticed while reading the code of DefaultSmppServer (line 115) that the executor parameter is never used.
I'm not sure if this is intended behaviour.

After downloading cloudhopper I cd to the dir and... this is what I see when I run $ make server.

$ make server
mvn -e test-compile exec:java -Dexec.classpathScope="test" -Dexec.mainClass="com.cloudhopper.smpp.demo.ServerMain"
[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
Downloading: http://repo1.maven.org/maven2/com/cloudhopper/ch-maven-parent-oss/1.4/ch-maven-parent-oss-1.4.pom
Downloaded: http://repo1.maven.org/maven2/com/cloudhopper/ch-maven-parent-oss/1.4/ch-maven-parent-oss-1.4.pom (21 KB at 7.8 KB/sec)
[WARNING]
[WARNING] Some problems were encountered while building the effective model for com.cloudhopper:ch-smpp:jar:5.0.2-SNAPSHOT
[WARNING] The expression ${scm.url} is deprecated. Please use ${project.scm.url} instead.
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]

[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2:47.939s
[INFO] Finished at: Sun May 26 08:22:00 SAST 2013
[INFO] Final Memory: 5M/81M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project ch-smpp: Could not resolve dependencies for project com.cloudhopper:ch-smpp:jar:5.0.2-SNAPSHOT: Failed to collect dependencies for [com.cloudhopper:ch-commons-util:jar:[6.0.0,) (compile), com.cloudhopper:ch-commons-charset:jar:[3.0.0,) (compile), org.slf4j:slf4j-api:jar:[1.5.0,) (compile), io.netty:netty:jar:3.5.8.Final (compile), junit:junit:jar:[4.0,) (test), com.cloudhopper:ch-commons-gsm:jar:[3.0.0,) (test), ch.qos.logback:logback-core:jar:[1.0,) (test), ch.qos.logback:logback-classic:jar:[1.0,) (test)]: Failed to read artifact descriptor for ch.qos.logback:logback-core:jar:1.0.4: Could not find artifact ch.qos.logback:logback-parent:pom:1.0.4 in central (http://repo1.maven.org/maven2) -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal on project ch-smpp: Could not resolve dependencies for project com.cloudhopper:ch-smpp:jar:5.0.2-SNAPSHOT: Failed to collect dependencies for [com.cloudhopper:ch-commons-util:jar:[6.0.0,) (compile), com.cloudhopper:ch-commons-charset:jar:[3.0.0,) (compile), org.slf4j:slf4j-api:jar:[1.5.0,) (compile), io.netty:netty:jar:3.5.8.Final (compile), junit:junit:jar:[4.0,) (test), com.cloudhopper:ch-commons-gsm:jar:[3.0.0,) (test), ch.qos.logback:logback-core:jar:[1.0,) (test), ch.qos.logback:logback-classic:jar:[1.0,) (test)]
at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:196)
at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:108)
at org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.project.DependencyResolutionException: Could not resolve dependencies for project com.cloudhopper:ch-smpp:jar:5.0.2-SNAPSHOT: Failed to collect dependencies for [com.cloudhopper:ch-commons-util:jar:[6.0.0,) (compile), com.cloudhopper:ch-commons-charset:jar:[3.0.0,) (compile), org.slf4j:slf4j-api:jar:[1.5.0,) (compile), io.netty:netty:jar:3.5.8.Final (compile), junit:junit:jar:[4.0,) (test), com.cloudhopper:ch-commons-gsm:jar:[3.0.0,) (test), ch.qos.logback:logback-core:jar:[1.0,) (test), ch.qos.logback:logback-classic:jar:[1.0,) (test)]
at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:139)
at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:171)
... 22 more
Caused by: org.sonatype.aether.collection.DependencyCollectionException: Failed to collect dependencies for [com.cloudhopper:ch-commons-util:jar:[6.0.0,) (compile), com.cloudhopper:ch-commons-charset:jar:[3.0.0,) (compile), org.slf4j:slf4j-api:jar:[1.5.0,) (compile), io.netty:netty:jar:3.5.8.Final (compile), junit:junit:jar:[4.0,) (test), com.cloudhopper:ch-commons-gsm:jar:[3.0.0,) (test), ch.qos.logback:logback-core:jar:[1.0,) (test), ch.qos.logback:logback-classic:jar:[1.0,) (test)]
at org.sonatype.aether.impl.internal.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:262)
at org.sonatype.aether.impl.internal.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:345)
at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:131)
... 23 more
Caused by: org.sonatype.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for ch.qos.logback:logback-core:jar:1.0.4
at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:317)
at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:172)
at org.sonatype.aether.impl.internal.DefaultDependencyCollector.process(DefaultDependencyCollector.java:419)
at org.sonatype.aether.impl.internal.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:243)
... 25 more
Caused by: org.apache.maven.model.resolution.UnresolvableModelException: Could not find artifact ch.qos.logback:logback-parent:pom:1.0.4 in central (http://repo1.maven.org/maven2)
at org.apache.maven.repository.internal.DefaultModelResolver.resolveModel(DefaultModelResolver.java:126)
at org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:819)
at org.apache.maven.model.building.DefaultModelBuilder.readParent(DefaultModelBuilder.java:670)
at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:308)
at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:232)
at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:308)
... 28 more
Caused by: org.sonatype.aether.resolution.ArtifactResolutionException: Could not find artifact ch.qos.logback:logback-parent:pom:1.0.4 in central (http://repo1.maven.org/maven2)
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:541)
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:220)
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:197)
at org.apache.maven.repository.internal.DefaultModelResolver.resolveModel(DefaultModelResolver.java:122)
... 33 more
Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Could not find artifact ch.qos.logback:logback-parent:pom:1.0.4 in central (http://repo1.maven.org/maven2)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$4.wrap(WagonRepositoryConnector.java:945)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$4.wrap(WagonRepositoryConnector.java:940)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$GetTask.flush(WagonRepositoryConnector.java:695)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector$GetTask.flush(WagonRepositoryConnector.java:689)
at org.sonatype.aether.connector.wagon.WagonRepositoryConnector.get(WagonRepositoryConnector.java:445)
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:460)
... 36 more
[ERROR]
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
make: *** [server] Error 1

Hi,
recently we noticed the following case:

We received a SubmitSm PDU where everything was ok BUT the ShortMessageLength was set too small (while the command length was ok).
That caused that the Session was destroyed immediately.

We would have assumed that the Server might throw an Exception like an UnrecoverablePduException or a RecoverablePduException or anything like that so that we were at least able to send a response (rejection) to the message.

We are still running on the following version: 5.0.0 (2012-10-26). As I did not find any matching issue here we assume that this issue is still present in the current version. Could anyone please confirm this?

Example PDU for testing:
00000070000000040000000000000008000501414243444546000101303132333435363738393132000000000000010000003c6b61746265686f6c7a20667269656e646c792074657374206d65737361676520323a204772656574696e67732066726f6d205669656e6e61203a2d2900
(Command Length is 112 bytes, ShortMessageLength is set to 60 bytes while it is actually 61 bytes long due to the 0-byte at the end)

If anyone has an idea to handle this issue without changing the code base of the Cloudhopper, please let me know. Maybe there is any RuntimeException we did not notice so far but could catch in "our part" of the code.

Thanks in advance for your help.

Hello joelauer,

I would like to know how can I implement the query_sm, replace_sm and cancel_sm without forgetting the submit_mutli pdu requests.

Thanks

$ make client
mvn -e test-compile exec:java -Dexec.classpathScope="test" -Dexec.mainClass="com.cloudhopper.smpp.demo.ClientMain"
[INFO] Error stacktraces are turned on.
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective model for com.cloudhopper:ch-smpp:jar:5.0.2-SNAPSHOT
[WARNING] The expression ${scm.url} is deprecated. Please use ${project.scm.url} instead.
[WARNING]
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING]
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building ch-smpp 5.0.2-SNAPSHOT
[INFO] ------------------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1.860s
[INFO] Finished at: Sun May 26 08:54:35 SAST 2013
[INFO] Final Memory: 6M/81M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project ch-smpp: Could not resolve dependencies for project com.cloudhopper:ch-smpp:jar:5.0.2-SNAPSHOT: Failed to collect dependencies for [com.cloudhopper:ch-commons-util:jar:[6.0.0,) (compile), com.cloudhopper:ch-commons-charset:jar:[3.0.0,) (compile), org.slf4j:slf4j-api:jar:[1.5.0,) (compile), io.netty:netty:jar:3.5.8.Final (compile), junit:junit:jar:[4.0,) (test), com.cloudhopper:ch-commons-gsm:jar:[3.0.0,) (test), ch.qos.logback:logback-core:jar:[1.0,) (test), ch.qos.logback:logback-classic:jar:[1.0,) (test)]: Failed to read artifact descriptor for ch.qos.logback:logback-core:jar:1.0.4: Failure to find ch.qos.logback:logback-parent:pom:1.0.4 in http://repo1.maven.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal on project ch-smpp: Could not resolve dependencies for project com.cloudhopper:ch-smpp:jar:5.0.2-SNAPSHOT: Failed to collect dependencies for [com.cloudhopper:ch-commons-util:jar:[6.0.0,) (compile), com.cloudhopper:ch-commons-charset:jar:[3.0.0,) (compile), org.slf4j:slf4j-api:jar:[1.5.0,) (compile), io.netty:netty:jar:3.5.8.Final (compile), junit:junit:jar:[4.0,) (test), com.cloudhopper:ch-commons-gsm:jar:[3.0.0,) (test), ch.qos.logback:logback-core:jar:[1.0,) (test), ch.qos.logback:logback-classic:jar:[1.0,) (test)]
at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:196)
at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.resolveProjectDependencies(LifecycleDependencyResolver.java:108)
at org.apache.maven.lifecycle.internal.MojoExecutor.ensureDependenciesAreResolved(MojoExecutor.java:258)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:201)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.project.DependencyResolutionException: Could not resolve dependencies for project com.cloudhopper:ch-smpp:jar:5.0.2-SNAPSHOT: Failed to collect dependencies for [com.cloudhopper:ch-commons-util:jar:[6.0.0,) (compile), com.cloudhopper:ch-commons-charset:jar:[3.0.0,) (compile), org.slf4j:slf4j-api:jar:[1.5.0,) (compile), io.netty:netty:jar:3.5.8.Final (compile), junit:junit:jar:[4.0,) (test), com.cloudhopper:ch-commons-gsm:jar:[3.0.0,) (test), ch.qos.logback:logback-core:jar:[1.0,) (test), ch.qos.logback:logback-classic:jar:[1.0,) (test)]
at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:139)
at org.apache.maven.lifecycle.internal.LifecycleDependencyResolver.getDependencies(LifecycleDependencyResolver.java:171)
... 22 more
Caused by: org.sonatype.aether.collection.DependencyCollectionException: Failed to collect dependencies for [com.cloudhopper:ch-commons-util:jar:[6.0.0,) (compile), com.cloudhopper:ch-commons-charset:jar:[3.0.0,) (compile), org.slf4j:slf4j-api:jar:[1.5.0,) (compile), io.netty:netty:jar:3.5.8.Final (compile), junit:junit:jar:[4.0,) (test), com.cloudhopper:ch-commons-gsm:jar:[3.0.0,) (test), ch.qos.logback:logback-core:jar:[1.0,) (test), ch.qos.logback:logback-classic:jar:[1.0,) (test)]
at org.sonatype.aether.impl.internal.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:262)
at org.sonatype.aether.impl.internal.DefaultRepositorySystem.collectDependencies(DefaultRepositorySystem.java:345)
at org.apache.maven.project.DefaultProjectDependenciesResolver.resolve(DefaultProjectDependenciesResolver.java:131)
... 23 more
Caused by: org.sonatype.aether.resolution.ArtifactDescriptorException: Failed to read artifact descriptor for ch.qos.logback:logback-core:jar:1.0.4
at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:317)
at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.readArtifactDescriptor(DefaultArtifactDescriptorReader.java:172)
at org.sonatype.aether.impl.internal.DefaultDependencyCollector.process(DefaultDependencyCollector.java:419)
at org.sonatype.aether.impl.internal.DefaultDependencyCollector.collectDependencies(DefaultDependencyCollector.java:243)
... 25 more
Caused by: org.apache.maven.model.resolution.UnresolvableModelException: Failure to find ch.qos.logback:logback-parent:pom:1.0.4 in http://repo1.maven.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced
at org.apache.maven.repository.internal.DefaultModelResolver.resolveModel(DefaultModelResolver.java:126)
at org.apache.maven.model.building.DefaultModelBuilder.readParentExternally(DefaultModelBuilder.java:819)
at org.apache.maven.model.building.DefaultModelBuilder.readParent(DefaultModelBuilder.java:670)
at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:308)
at org.apache.maven.model.building.DefaultModelBuilder.build(DefaultModelBuilder.java:232)
at org.apache.maven.repository.internal.DefaultArtifactDescriptorReader.loadPom(DefaultArtifactDescriptorReader.java:308)
... 28 more
Caused by: org.sonatype.aether.resolution.ArtifactResolutionException: Failure to find ch.qos.logback:logback-parent:pom:1.0.4 in http://repo1.maven.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:541)
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:220)
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:197)
at org.apache.maven.repository.internal.DefaultModelResolver.resolveModel(DefaultModelResolver.java:122)
... 33 more
Caused by: org.sonatype.aether.transfer.ArtifactNotFoundException: Failure to find ch.qos.logback:logback-parent:pom:1.0.4 in http://repo1.maven.org/maven2 was cached in the local repository, resolution will not be reattempted until the update interval of central has elapsed or updates are forced
at org.sonatype.aether.impl.internal.DefaultUpdateCheckManager.checkArtifact(DefaultUpdateCheckManager.java:190)
at org.sonatype.aether.impl.internal.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:430)
... 36 more
[ERROR]
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
make: *** [client] Error 1

I am using this library as a SMPPServer and it seems the SmppSessionCounters are per session, does the library support the counters per SMPPServer? Basically, can it group all the counters for each session.

We receive this error occasionally when we attempt to reconnect to the SMSC in the event of a connection error or lost session connection.

Has anyone seen this issue before and know if there is a fix for it? See below:

[SMPPMainThread] INFO com.cloudhopper.smpp.impl.DefaultSmppSession - send PDU: ...
[SMPPMainThread] INFO com.cloudhopper.smpp.impl.DefaultSmppSession - write bytes: ...
[SMPPMainThread] ERROR smpp.SMPP - Unexpected close occurred...
[SMPPMainThread] INFO com.cloudhopper.smpp.impl.DefaultSmppSession - Session channel is already closed, not going to unbind
[SMPPMainThread] ERROR smpp.SMPP - Exception:
java.lang.IllegalStateException: await_() in I/O thread causes a dead lock or sudden performance drop. Use addListener() instead or call await_() from a different thread.
at org.jboss.netty.channel.DefaultChannelFuture.checkDeadLock(DefaultChannelFuture.java:343)
at org.jboss.netty.channel.DefaultChannelFuture.await0(DefaultChannelFuture.java:307)
at org.jboss.netty.channel.DefaultChannelFuture.await(DefaultChannelFuture.java:248)
at com.cloudhopper.smpp.impl.DefaultSmppClient.createConnectedChannel(DefaultSmppClient.java:248)
at com.cloudhopper.smpp.impl.DefaultSmppClient.doOpen(DefaultSmppClient.java:212)
at com.cloudhopper.smpp.impl.DefaultSmppClient.bind(DefaultSmppClient.java:181)
at smpp.SMPP$ClientSessionTask.reconnect(SMPP.java:174)
at smpp.SMPP$ClientSessionTask$ClientSmppSessionHandler.fireChannelUnexpectedlyClosed(SMPP.java:284)
at com.cloudhopper.smpp.impl.DefaultSmppSession.fireChannelClosed(DefaultSmppSession.java:688)
at com.cloudhopper.smpp.channel.SmppSessionWrapper.channelClosed(SmppSessionWrapper.java:88)
at org.jboss.netty.channel.SimpleChannelHandler.handleUpstream(SimpleChannelHandler.java:113)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:565)
at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:793)
at org.jboss.netty.handler.codec.frame.FrameDecoder.cleanup(FrameDecoder.java:489)
at org.jboss.netty.handler.codec.frame.FrameDecoder.channelClosed(FrameDecoder.java:372)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:93)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:565)
at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:793)
at com.cloudhopper.smpp.channel.SmppSessionLogger.handleUpstream(SmppSessionLogger.java:104)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:565)
at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:793)
at com.cloudhopper.smpp.channel.SmppSessionThreadRenamer.handleUpstream(SmppSessionThreadRenamer.java:59)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:565)
at org.jboss.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendUpstream(DefaultChannelPipeline.java:793)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.channelClosed(SimpleChannelUpstreamHandler.java:215)
at org.jboss.netty.channel.SimpleChannelUpstreamHandler.handleUpstream(SimpleChannelUpstreamHandler.java:93)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:565)
at org.jboss.netty.channel.DefaultChannelPipeline.sendUpstream(DefaultChannelPipeline.java:560)
at org.jboss.netty.channel.Channels.fireChannelClosed(Channels.java:476)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.close(AbstractNioWorker.java:730)
at org.jboss.netty.channel.socket.nio.NioWorker.read(NioWorker.java:89)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.processSelectedKeys(AbstractNioWorker.java:471)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:332)
at org.jboss.netty.channel.socket.nio.NioWorker.run(NioWorker.java:35)
at org.jboss.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:102)
at org.jboss.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
at java.lang.Thread.run(Thread.java:662)
Session 0 is not bound, binding or open. Attempting to reconnect...
[SmppSessionMonitorThread] INFO com.cloudhopper.smpp.impl.DefaultSmppSession - Session channel is already closed, not going to unbind
[SmppSessionMonitorThread] INFO com.cloudhopper.smpp.impl.DefaultSmppSession - sync send PDU: ...
[SmppSessionMonitorThread] INFO com.cloudhopper.smpp.impl.DefaultSmppSession - write bytes: ...
Enquire link to keep session 0 alive.
[SMPPMainThread] INFO com.cloudhopper.smpp.impl.DefaultSmppSession - read bytes: ...
[SMPPMainThread] INFO com.cloudhopper.smpp.impl.DefaultSmppSession - received PDU: ...
[SmppSessionMonitorThread] INFO smpp.SMPP - Session reconnected!

Hi Folks

How do i receive split long message from an smpp client in cloudhopper. We are using the library to receipt messages and forward to SMSC.

Kind Regards

William

Hi,

Is monitorExecutor in DefaultSmppClient actually used ?. I see it is a private field and this DefaultSmppClient is not using it anywhere.

Thanks,
Luis

Hello,
I got NullPointerException when I set WriteTimeout of object SmppSessionConfiguration to 1 (very slow value).

java.lang.NullPointerException: null
at com.cloudhopper.smpp.impl.DefaultSmppSession

.sendRequestPdu(DefaultSmppSession.java:531) ~[ch-smpp-5.0.4.jar:5.0.4]

It happened because channelFuture.getCause() return null
file: DefaultSmppSession.java
line: 531
Screenshot of debugger is attached.
Thank you.

Like this:

    @SuppressWarnings("unchecked")
    public <R extends PduResponse> R  submit(PduRequest<R> request, long timeoutInMillis) throws RecoverablePduException, UnrecoverablePduException, SmppTimeoutException, SmppChannelException, InterruptedException {
        assertValidRequest(request);
        PduResponse response = sendRequestAndGetResponse(request, timeoutInMillis);
        SmppSessionUtil.assertExpectedResponse(request, response);
        return (R) response;
    }

I am currently building an SMPP Server using the cloudhopper-smpp library. I would like to know how I can connect to a database to store the messages and retrieve them as when.

Please do assist

The SMPP 3.4 spec section 5.2.17 contains an inconsistency in the description of the registered_delivery flag. The text says "bit 5" (0x20) while the bit pattern indicates bit 4 (0x10). Later the spec for SMPP 5.0 section 4.7.21 says "bit 4" and has the same bit pattern (0x10 in both cases).

SmppConstants has REGISTERED_DELIVERY_INTERMEDIATE_NOTIFICATION_MASK=0x20 and REGISTERED_DELIVERY_INTERMEDIATE_NOTIFICATION_REQUESTED=0x20 which appear wrong, think they ought to be 0x10. Test cases (see e.g. SmppUtilTest.java) would also need to be modified as well as they contain 0x20.

Be careful though, the "esm_class" field does use bit 5 for intermediate notifications.

The DeliveryReceipt class inapprorpiately parses error code out of short message. The smpp spec states that the err code is a "C-Octet Fixed Length String", the DeliveryReceipt class currently assumes it is an integer.

I've forked and made changes in the following repository:

https://github.com/williamd1618/cloudhopper-smpp.git

When smppClient.bind() throws an exception, the SessionHandler still gets called.

Hi,

I am currently using the library to build an SMPP server. I would like to know how I can decode the pduRequest sent by the client.

So Maven 3.0 which I am using to build is more strict about certain things, for the moment they are only warnings but in future maven releases they will become failures.

[awhiteside@aaronwhiteside1 cloudhopper-smpp]$ mvn clean package -DskipTests
[INFO] Scanning for projects...
[WARNING] 
[WARNING] Some problems were encountered while building the effective model for cloudhopper:ch-smpp:jar:4.1.2
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-compiler-plugin is missing. @ cloudhopper:ch-maven-parent-public:1.6, /home/awhiteside/.m2/repository/cloudhopper/ch-maven-parent-public/1.6/ch-maven-parent-public-1.6.pom, line 88, column 15
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-jar-plugin is missing. @ cloudhopper:ch-maven-parent-public:1.6, /home/awhiteside/.m2/repository/cloudhopper/ch-maven-parent-public/1.6/ch-maven-parent-public-1.6.pom, line 113, column 15
[WARNING] 'build.plugins.plugin.version' for org.apache.maven.plugins:maven-source-plugin is missing. @ cloudhopper:ch-maven-parent-public:1.6, /home/awhiteside/.m2/repository/cloudhopper/ch-maven-parent-public/1.6/ch-maven-parent-public-1.6.pom, line 101, column 15
[WARNING] The expression ${pom.groupId} is deprecated. Please use ${project.groupId} instead.
[WARNING] The expression ${pom.artifactId} is deprecated. Please use ${project.artifactId} instead.
[WARNING] 'reporting.plugins.plugin.version' for org.apache.maven.plugins:maven-javadoc-plugin is missing.
[WARNING] 'reporting.plugins.plugin.version' for org.apache.maven.plugins:maven-jxr-plugin is missing.
[WARNING] 'reporting.plugins.plugin.version' for org.apache.maven.plugins:maven-project-info-reports-plugin is missing.
[WARNING] 'reporting.plugins.plugin.version' for org.apache.maven.plugins:maven-surefire-report-plugin is missing.
[WARNING] 'reporting.plugins.plugin.version' for org.codehaus.mojo:taglist-maven-plugin is missing.
[WARNING] 'reporting.plugins.plugin.version' for org.apache.maven.plugins:maven-checkstyle-plugin is missing.
[WARNING] 'reporting.plugins.plugin.version' for org.apache.maven.plugins:maven-changelog-plugin is missing.
[WARNING] 
[WARNING] It is highly recommended to fix these problems because they threaten the stability of your build.
[WARNING] 
[WARNING] For this reason, future Maven versions might no longer support building such malformed projects.
[WARNING] 
[INFO]                                                                         
[INFO] ------------------------------------------------------------------------
[INFO] Building ch-smpp 4.1.2
[INFO] ------------------------------------------------------------------------

When I tried to bind with a SMSC using DefaultSmppClient, this error ocurrs:

java.lang.IllegalStateException: await*() in I/O thread causes a dead lock or sudden performance drop. Use addListener() instead or call await*() from a different thread.
at org.jboss.netty.channel.DefaultChannelFuture.checkDeadLock(DefaultChannelFuture.java:343)
at org.jboss.netty.channel.DefaultChannelFuture.await0(DefaultChannelFuture.java:307)
at org.jboss.netty.channel.DefaultChannelFuture.await(DefaultChannelFuture.java:248)
at com.cloudhopper.smpp.impl.DefaultSmppClient.createConnectedChannel(DefaultSmppClient.java:266)
at com.cloudhopper.smpp.impl.DefaultSmppClient.doOpen(DefaultSmppClient.java:216)
at com.cloudhopper.smpp.impl.DefaultSmppClient.bind(DefaultSmppClient.java:185)

It seems a problem with the netty.io library. I've already google this issue, and the only solution it appeared was to set the deadLockChecker to false:

 DefaultChannelFuture.setUseDeadLockChecker(false);

But making this, when ever I try to submit a message, this error happens:

com.cloudhopper.smpp.type.SmppChannelException
at com.cloudhopper.smpp.impl.DefaultSmppSession.sendRequestPdu(DefaultSmppSession.java:526)
at com.cloudhopper.smpp.impl.DefaultSmppSession.sendRequestAndGetResponse(DefaultSmppSession.java:463)
at com.cloudhopper.smpp.impl.DefaultSmppSession.submit(DefaultSmppSession.java:446

Caused by: java.nio.channels.ClosedChannelException
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.cleanUpWriteBuffer(AbstractNioWorker.java:784)
at org.jboss.netty.channel.socket.nio.AbstractNioWorker.writeFromUserCode(AbstractNioWorker.java:507)
at org.jboss.netty.channel.socket.nio.NioClientSocketPipelineSink.eventSunk(NioClientSocketPipelineSink.java:125)
at com.cloudhopper.smpp.channel.SmppSessionLogger.handleDownstream(SmppSessionLogger.java:110)
at org.jboss.netty.channel.Channels.write(Channels.java:712)
at org.jboss.netty.channel.Channels.write(Channels.java:679)
at org.jboss.netty.channel.AbstractChannel.write(AbstractChannel.java:248)
at com.cloudhopper.smpp.impl.DefaultSmppSession.sendRequestPdu(DefaultSmppSession.java:521)
at com.cloudhopper.smpp.impl.DefaultSmppSession.sendRequestAndGetResponse(DefaultSmppSession.java:463)
at com.cloudhopper.smpp.impl.DefaultSmppSession.submit(DefaultSmppSession.java:446)

But when I check if the channel is really closed with session.isClosed(), it returns false.

Assuming I want to test receiving message between clients so I create a server and 2 clients. To run server, I used the command "make server". Then in other machine, a client connected to my server and send 1 message to other client which has phone number "123456" using following code

submit0.setSourceAddress(new Address((byte)0x03, (byte)0x00, "654321"));
submit0.setDestAddress(new Address((byte)0x01, (byte)0x01, "123456"));
submit0.setShortMessage(textBytes);

SubmitSmResp submitResp = session0.submit(submit0, 10000); 

How can client which has phone number "123456" check message from phone number "654321"?

Hi Joe,

First of all, Happy new year to you. Hope, you are doing good.

We are using cloudhopper-smpp to submit the SMS to SMSC. But, SMSC has a restriction that we cannot send the SMS longer than 160 characters. If you want then you have to set the UDH. I was looking for some example/documentation, but did not find any. Can you please help us with some code snippet where we can send the long messages using UDH.

Best Regards,
Deepak

Is there some reason why only

    smppServer.stop();

is called, and not

    smppServer.destroy();
    monitorExecutor.shutdown();

I would expect to see #stop at some demo which actually shows rerunning of the server.

Provide facility to decode the shortMessage, in BaseSM, so that the Pdu.toString() method can print something human readable.

Akin to the PduTranscoderContext that supports translating command status's and custom tlv tags into human readable text.

Perhaps a new method like PduTranscoderContext.decodeShortMessage( byte[] shortMessage, byte dataCoding ) and a default implementation that decodes based on the SMPP spec?

As the title says, I noticed that length is not validated for PDUs. They still get sent, leaving it for the other end to figure out that I overstepped the specified SMPP lengths. And then on my end, I've no idea that my field size is what went wrong.

[main] INFO com.cloudhopper.smpp.impl.DefaultSmppSession - sync send PDU: (bind_transceiver: 0x00000037 0x00000009 0x00000000 0x00000001) (body: systemId [skytreader] password [morethanninecharacters] systemType [] interfaceVersion [0x34] addressRange (0x00 0x00 [])) (opts: )
[main] INFO com.cloudhopper.smpp.impl.DefaultSmppSession - write bytes: [00000037000000090000000000000001736b7974726561646572006d6f72657468616e6e696e6563686172616374657273000034000000]
[jamsesh] INFO com.cloudhopper.smpp.impl.DefaultSmppSessionHandler - Default handling is to discard an unexpected channel closed

Note: As per SMPP3.4 specs, BIND password is only up to 9 chars.

(The scenario here is that I'm testing our Cloudhopper-based ESME app against a non-Cloudhopper-based local SMSC simulator. Thanks to that, I realized my blunder with the password length.)

Is there a reason why this is not included? This seems pretty simple I guess I can contribute if this is in anyone else's wishlist.

Hi. He wants to implement the following functionality in USSD:

• Enquire_link send and enquire_link_resp every 1 second
• Ussd session is initiated from the phone by dialing *123# + send
• Ussd gateway receives the request and sends to the application client a deliver_sm
• The application client receives deliver_sm, stopping enquire_link and send a submit_sm
• Wait to submit_sm_resp
• Send deliver_sm_resp
• Continue send enquire_link untils receives other deliver_sm

The problem is the following:

• The first time, wait to submit_sm_resp is successful
• The second time, wait for the submit_sm_resp failure (unable to get response)
• The third time, wait to submit_sm_resp is successful
• The fourth time, wait for the submit_sm_resp failure (unable to get response)

What could be causing this behavior? Could someone help me with a code that does what I need?

PS: Sorry for my English, I only speak Spanish

Cloudhopper is a neat environment to be able to develop SMPP servers with, and I am sure there are some of the test cases that would be available, but after quite a bit of search, I am still unable to figure out about the adversarial testing.

How do we develop adversarial test cases to check how our cloudhopper environment works. Examples include: creating and sending a malformed command ID, which is a mandatory header parameter. Transmitting / receiving such packages would help us ensure the reliability of the development with Cloudhopper.

Are there any test case samples that are already available to do these kind of testing?

Since I am new to cloudhopper, even any pointers relating to it would be much much appreciated.

Bala

I think you should check doneDate for null instead of submitDate at DeliveryReceipt.java line 192.

We are using the async version of sendRequestPdu to submit a SMS:
session.sendRequestPdu(submitSm, timeout, false);

What we've seen is that the timeout only works with the ack PDU, but this timeout is not considered in the response PDU. In the synchronous version, the expiryTimeout is used (instead of the one in the call) to discard responses after exceeding expiryTimeout. However, in asynchronous version all the PDU responses are fired by the SmppSession without considering any timeout.

Moreover, if the SMSC does not reply with a response PDU, no timeout is triggered and we cannot send any timeout to our client.

Is there any mechanism to handle timeouts (for response PDUs) when using asynchronous version?

Hi,

is there an example of a long-lived smpp session. I have requirement for a very long-lived smpp client session with automatic re-bind and enquireLink. What would you suggest to make as much use as possible of the existing session event notifications and the existing excutors?

Regards,
Leen

I need to implement SSL support. The good starting point is the example http://docs.jboss.org/netty/3.2/xref/org/jboss/netty/example/securechat/
What is the next step? Can I contribute? I think the approach to take is to extend com.cloudhopper.smpp.impl classes DefaultSmppClient and DefaultSmppServer. The method createSession() must be able to add a custom SSLHandler to the top of pipeline.
Maybe not touching the method createSession(). Instead, introduce a new method AddSSLHanlder().
Please, advice.

In SmppServerHandler.sessionBindRequested() the InetAddress of the connecting client should be exposed.

Hi,

Think the subject says what I'm trying to achieve. I noticed that the username and password is in free text when performing a bind and want to know how to turn this off so no sensitive information is written to the logs when the bind occurs.

I'm hoping there's an easy fix for this that I'm not aware of.

Hello,

I am using cloudhopper to implement an smpp server. However whenever I send 1 million messages from one client to the server it hangs and prevents any other binding and submit_sm.

Can someone help?

Hi Guys,

For our project I want to use cloudhopper-smpp. However I realized it misses the submit_multi req/resp. See SMPP Specs 5.0 Section "4.2.3 submit_multi Operation"

I am ready to contribute patch for this.

could you confirm if this API support sending binary messages (e.g. ringtone, contact, calendar, logo etc..) ? it will be great help if you can provide an example for the same.thanks

This code in DeliveryReceipt.toShortMessage():

        if (this.submitDate == null) {
            buf.append("0000000000");
        } else {
            buf.append(dateFormatTemplate.print(this.doneDate));
        }

doesn't prevent trying to format a null this.doneDate.

We are using SMPP cloud-hopper library to SMS long long messages to SMS gateway Innovativetxt.com, but it seems like when we split following the long message To 140 bytes each part. The number of characters in each message gets to 134 character.

However industry standard is kind of 153 character shall be for each part of GSM Encoded long message. Is it something wrong we are doing by having only 134 character when we split via 140 byte? If we trying to submit greater than 140 bytes message, the gateway provider rejects it with message over-sized message body.

It seems like the Cloudhopper message split utility is doing message split based on 8 bit encoding instead of 7 bit GSM 0.038 encoding.

Any thought how to have message split based on 7 bit GSM encoding?

Hi,

I am looking into the source code , and am unable to figure out if we can receive the DR back from SMSC using cloudhopper.

Can anyone please guide me on that?

Thanks

The cloudhopper library is registering the following error randomly (and when it happens, it is written multiple times):

00:58:39.550 [session.0.Monitor] ERROR - The parent Window was garbage collected in this WindowMonitor(): missing call to Window.reset() to stop this monitoring thread (will throw exception to cancel this recurring execution!)

We are not sure why it is thrown this error and if it is actually a problem that we must be concerned about.

Would you mind to clarify it?

Hi,

What about ReplaceSM PDU?

https://github.com/krasa/cloudhopper-smpp/tree/bug
Start ServerMain and PerformanceClientMain

It happens quite often when SmppSession#submit is used. So I copypasted #sendRequestAndGetResponse and added some logging:

    ...
        // 3 possible scenarios once completed: success, failure, or cancellation
        final boolean success = future.isSuccess();
        final boolean cancelled = future.isCancelled();
        final boolean done = future.isDone();
        final PduResponse response = future.getResponse();
        final long doneTimestamp = future.getDoneTimestamp();
        if (success) {
            return future.getResponse();
        } else if (future.getCause() != null) {
            Throwable cause = future.getCause();
            if (cause instanceof ClosedChannelException) {
                throw new SmppChannelException("Channel was closed after sending request, but before receiving response", cause);
            } else {
                throw new UnrecoverablePduException(cause.getMessage(), cause);
            }
        } else {
            if (cancelled) {
                logger.error("{} {} {} {} {}", done, success, cancelled, doneTimestamp, response);
                logger.error("{} {} {} {} {}", future.isDone(), future.isSuccess(), future.isCancelled(), future.getDoneTimestamp(), future.getResponse());
                throw new RecoverablePduException("Request was cancelled");
            } else {
                logger.error("{} {} {} {} {}", done, success, cancelled, doneTimestamp, response);
                logger.error("{} {} {} {} {}", future.isDone(), future.isSuccess(), future.isCancelled(), future.getDoneTimestamp(), future.getResponse());
                throw new UnrecoverablePduException("Unable to sendRequestAndGetResponse successfully (future was in strange state)");
            }
        }

it produces:

PerformanceClientMain - true false false 1396892258272 (submit_sm_resp: 0x00000011 0x80000004 0x00000000 0x0000ADCA result: "OK") (body: (messageId [])) (opts: )
PerformanceClientMain - true true false 1396892258272 (submit_sm_resp: 0x00000011 0x80000004 0x00000000 0x0000ADCA result: "OK") (body: (messageId [])) (opts: )

PerformanceClientMain - true false true 0 null
PerformanceClientMain - true true false 1396892262655 (submit_sm_resp: 0x00000011 0x80000004 0x00000000 0x0000DE74 result: "OK") (body: (messageId [])) (opts: )

PerformanceClientMain - true false true 1396892295576 (submit_sm_resp: 0x00000011 0x80000004 0x00000000 0x00014F6D result: "OK") (body: (messageId [])) (opts: )
PerformanceClientMain - true true false 1396892295576 (submit_sm_resp: 0x00000011 0x80000004 0x00000000 0x00014F6D result: "OK") (body: (messageId [])) (opts: )

When using packed 7-bit GSM encoding, no padding with a CR is done if the last 7 bits are all zero. This causes "interesting" effects where different inputs are encoded to the same output bytes. "same" is true in the test case below:

byte[] requiresPadding = CharsetUtil.CHARSET_PACKED_GSM.encode("1234567");
byte[] endsWithAt = CharsetUtil.CHARSET_PACKED_GSM.encode("1234567@");
boolean same = java.util.Arrays.equals(requiresPadding, endsWithAt);
Assert.assertFalse(same);

Similarly, such a padding CR character should be ignored when decoding.

Of course one can manually patch up the padding after encoding/decoding, but that's not very convenient. When to pad depends on if the first character starts at an even byte boundary or somewhere else (like sometimes when following a UDH). Maybe the encode method should be extended to take a variable amount of prefix-bits for packed GSM encoding, and then when decoding specify a start-bit-offset.